Skip to content

Manage Tasks

Download SKILL.md

Skill ID: manage-tasks Server: RingEX Chat

Handles the full lifecycle of a Team Chat task — find, create, update, complete/reopen, and delete — resolving the chat and any assignees first, and verifying completion state afterward since that write returns nothing. The full skill source below is pulled directly from its SKILL.md file, so it always reflects the current version.

Manage Tasks

Goal

Give the user one skill for the full lifecycle of a RingCentral Team Chat task — find it, create it, update it, mark it complete or reopen it, or delete it — with every write built on a resolved chat and person, and every completion verified rather than assumed.

Trigger examples

  • "Create a task in the launch channel to review the BRD, assign it to Priya."
  • "What tasks are open in the product-updates chat?"
  • "Mark the 'Fix auth bug' task done."
  • "Reopen the deploy checklist task, I closed it too soon."
  • "Push the due date on that task to next Friday."
  • "Delete the old onboarding task in the sales channel."

Scope boundary

  • RingCentral Team Chat tasks only, via read_team_chat/manage_chat_item — not Jira, monday.com, or any other tracker (those have their own skills/tools).
  • This skill only manages the task item itself — notes and events use the same two tools but a different resource, and are out of scope here.
  • Reuse a chatId, taskId, or resolved person id already established earlier in the conversation. Re-resolving something already known wastes calls and risks landing on a different match the second time.

Workflow

  1. Resolve the chat.

    • A known chatId → use it directly.
    • A named channel/team → read_team_chat (resource: "chat", action: "list"), matched by name, case-insensitively, preferring an exact match. If more than one plausibly matches, disambiguate rather than guess.

  2. Resolve any people involved.

    • "Me"/"myself" → the authenticated user's own Team Chat person id.
    • A named assignee → find_person. A personId and an extensionId are distinct fields — never substitute one for the other.

  3. Find an existing task, if the request is about one.

    • read_team_chat (resource: "task", action: "list", chatId) to list a chat's tasks, or action: "get" with a known taskId for one task's detail.
    • Match a task named by title case-insensitively, preferring an exact match. If several plausible tasks remain, ask which one before writing — never guess on an ambiguous title, especially before a delete.

  4. Create, update, complete/reopen, or delete, via manage_chat_item.

    • Create (resource: "task", action: "create"): requires the resolved chatId plus the task's content and assignee fields — build the payload from what the user actually asked for rather than padding in defaults; the exact field names for this action are visible in tools/list.
    • Update (action: "update", taskId): send only the fields that should change.
    • Complete or reopen (action: "complete", taskId, status): status is required on every call to this action. Send "Complete" to close it or "Incomplete" to reopen it — the completed state a subsequent read reports back is spelled "Completed", a deliberate asymmetry, not a bug. This action's write response is empty, so always verify afterward with read_team_chat (resource: "task", action: "get", taskId) before telling the user it succeeded.
    • Delete (action: "delete", taskId): only on an explicit ask, and only once the exact task is confirmed — this is irreversible.

Guidance

  • Never create a task into a loosely resolved chat, or assign it to a loosely resolved person — resolve first, act second.
  • Never guess which task a title refers to when more than one plausible match exists; ask instead, particularly before a delete.
  • Never claim a task completed or reopened without the follow-up get confirming it — the write call succeeding at the transport level isn't the same thing.
  • Never resend a complete/reopen call without its status field, and never treat a rejected, correctly-formed request as a schema problem to probe by trial and error — read the task once to see its actual state, retry at most once if the failure looks transient, and otherwise report the rejection plainly.

← Back to Skill Library