Update to Team Tasks

SKILL.md text changes

− removed · + added

--- before
+++ after
@@ -1,18 +1,22 @@
 ---
 name: team-tasks
-description: Manage projects, tasks, steps, assignments, proofs, notifications, and task history in Team Tasks.
+description: Manage projects, tasks, steps, attachments, assignments, and authorized agent workflows in Team Tasks.
 ---
 
-Use the Team Tasks MCP tools to help the user work with their Team Tasks account.
+Use the connected Team Tasks MCP tools; do not guess project IDs, users, statuses, or permissions.
 
-For project-specific work, call `list_projects` first when the project ID is not already known. Use `get_project_overview` before creating tasks when project statuses, categories, members, or assignment options matter.
+At the start of a new workflow, use `get_current_context` when available to understand the authenticated identity, whether it is a personal or independent agent, company timezone, and granted scopes. Use `get_effective_permissions` before sensitive or ambiguous actions. Respect company, project, role, and OAuth scope boundaries.
 
-Before changing an existing task, call `get_task` and use its current `version` with `update_task`. Before changing an existing step, use the current step version returned by `get_task` with `update_step`. If a version conflict is returned, reload the current state rather than overwriting another user's change.
+Find the relevant project with `list_projects`, or search tasks with `search_tasks` for cross-project requests. Inspect `get_project_overview` when project statuses, categories or members matter. Use `list_company_members` only when member selection is necessary and authorized. Do not invent email addresses. External invitations are not supported by `add_project_member`.
 
-Respect server-side permissions and completion requirements. Never claim that a task or step was completed if Team Tasks rejects the operation because a required comment, image, video, document, or open step is missing. Add a comment as proof only when the user actually asks to add that comment or provides the content to record.
+Before changing a task, call `get_task` and pass the returned current `version` to `update_task`. For a step, use its version from `get_task` with `update_step`. Older steps may legitimately start at version 0. On version conflict, reread instead of overwriting.
 
-Use `get_project_overview` to determine valid project members before assigning a task. Do not invent email addresses, project members, categories, statuses, task IDs, step IDs, or other existing Team Tasks data. Use `add_project_member` only for an existing member of the user's company; external invitations must be handled in the Team Tasks app.
+For a new workflow, use `create_project` or `create_task` only on explicit user request, then `create_step` for ordered steps. `reorder_steps`, `copy_tasks`, and `copy_project` change data: confirm scope, source, destination, and intent. Before retrying a failed create operation, check whether the object was actually created to avoid duplicates.
 
-Use `list_tasks` with `include_archived=false` for current/open task lists and `include_archived=true` when the user specifically needs completed archived tasks. Use `get_task_history` for audit/history questions and `list_notifications` for recent Team Tasks notifications.
+Completion evidence and uploaded files are distinct. `add_comment` may provide a comment proof when requested. `upload_attachment` creates an instruction (`guide`) or work result (`result`), **not** completion evidence; it cannot satisfy required image, video or document completion proofs. Such proofs must be provided through the Team Tasks app. Check `get_upload_rules` before uploads; observe permitted formats and size limits. Use `list_attachments` to inspect purpose and `get_attachment_file` only when necessary. `delete_attachment` is restricted to eligible guide files and must only be used on explicit request.
 
-Create or modify Team Tasks data only when the user's request calls for that change. When the requested project, task, step, assignee, or intended change is ambiguous, resolve it from Team Tasks data when possible; otherwise ask the user rather than guessing.
+Respect server-side completion requirements: do not claim a task or step is done if it still has open steps or missing required proof. Read `get_task_history` for audit questions and `list_notifications` for notifications. Use `list_tasks` with `include_archived=false` for active tasks and `true` for completed archive results.
+
+Independent agents may use `claim_task`, `renew_claim` and `release_claim` to coordinate work only on eligible, directly assigned tasks. Do not claim or perform a task unless authorized and intended; release claims when abandoning work. Do not assume that a personal assistant is an independent team member.
+
+When project, task, step, assignee or requested change remains ambiguous after looking up available data, ask the user. Never claim success when a tool reports failure. Minimize personal data in responses and never expose access tokens, secrets or internal diagnostics.