team

# Team Use this skill when work needs another human in the loop. The workspace + project surfaces collectively decide *who can see and act on* tasks, conversations, and assets in a workspace; this skill is how the agent exposes those surfaces to the user. ## ⛔ Hard rules — human-in-loop 1. **Never auto-send an invite.** Agents may *propose* who should be invited and explain *why*, but the final action (`POST /api/im/workspaces/:id/invites`) must originate from a human click in workspace settings or from an explicit user instruction like "send the invite". If you ever find yourself about to call invite-create without that explicit go-ahead, stop and surface the proposal as text instead. 2. **Never expose member emails.** The `/api/im/workspaces/:id/members` response carries imUserIds, not addresses. If the user asks "what's Bob's email", say you can see Bob's username + display name but not their email. 3. **Distinguish workspace member from project member.** Workspace member = ACL boundary across the whole workspace (chat, tasks, assets). Project member = a sub-scope inside that workspace with its own role enum (owner/contributor/observer). Adding someone to a project requires them to be a workspace member first — surface that constraint when proposing. 4. **Never silently re-add a removed member.** If a user was removed from the workspace, their project memberships were cascade-deleted on purpose (release201/16 §3.2.3). Treat re-adding as a new collaboration event that needs explicit user consent, not a "fix it" automation. ## When to use - The user names someone who isn't already on the workspace: *"Have Maya look at this"*, *"Loop Bob in on Q2 launch"*. - The user asks who's on the team or what the roster looks like: *"who has access to this workspace"*, *"who's working on Q2 launch"*. - The user asks to remove someone, change someone's role, or move someone between projects. - An agent (e.g. CEO role) is reasoning about staffing in onboarding and needs to *propose* additions without taking action. ## What the platform exposes This skill is a thin wrapper over the cloud workspace + invite endpoints (release201/16): | Intent | Surface | |---|---| | List workspace members | `GET /api/im/workspaces/:id/members` (owner / admin / member) | | List project members | `GET /api/im/projects/:id/members` (project visibility rules) | | List outstanding invites | `GET /api/im/workspaces/:id/invites` (owner/admin) | | Propose an invite | Stop here. Tell the user what to click. | Concrete invite minting and acceptance go through the workspace settings → Members UI and the `/invite/:token` landing page. Those are the *human-pressed* paths the platform intentionally requires. ## Suggested phrasing when proposing When the user mentions a name and you're not sure if they're in: > "Maya isn't in this workspace yet. To invite her, open **Workspace settings → People → Invite** and send her an email link or a direct in-app request. She'll see the link, accept, and then I can add her to the Q2 launch project." When the user is owner/admin and asks you to do it: > "I can't send the invite myself — the platform requires you to press the button so there's an audit receipt. Want me to walk you to **Workspace settings → People** now?" When proposing a project add for someone already in the workspace: > "Maya is a workspace member but not on the Q2 launch project. From the project drawer's *Agents* tab, click **+ Add** under *User members* and pick Maya — that adds her as contributor." ## What this skill does NOT do - It does **not** push invite links to email, Slack, or any side channel. The cloud's notification queue handles email; this skill does not. - It does **not** enumerate non-members. Showing a list of "people you could invite" requires either an email address or an existing imUserId — never a directory dump. - It does **not** promote / demote roles. Surface the suggestion and let the human do it through settings. Role changes are owner-only on the server. ## Edge cases - **Block relationships**: invites between blocked users 422 with `PRINCIPAL_BLOCKED`. If you see that, say so plainly: "There's a block between the inviter and invitee — neither side can invite the other until the block is cleared from contacts." - **Already-pending invite**: the server returns 409 `DUPLICATE_PENDING_INVITE` if the same workspace already has a pending invite to that addressee. Surface the existing invite (it shows up in the Invites tab of workspace settings) rather than asking the user to mint a fresh one. - **Expired invite**: 410 `INVITE_EXPIRED`. The link is dead. Ask the human to mint a new one; do not autocreate one in their place. ## Forbidden patterns | Anti-pattern | Why it's forbidden | |---|---| | Calling invite-create silently during a task | release201/16 §0.2.4 — agents must not mint workspace ACL changes | | Listing email addresses of workspace members | release201/16 §0.2.4 — members endpoint never returns emails | | Treating contact-add as "auto-invite to workspace" | release201/16 §5.4 anti-pattern — contact ≠ ACL | | Re-adding a removed user "because they used to be on the team" | release201/16 §3.2.3 — cascade is intentional | ## Related skills - `tasks` — once people are in, this is how work flows to them. - `human-approval` — if you need a human's sign-off on an action (different from inviting them as a workspace member). - `agent-coordination` — for the agent side of who-does-what; this skill is the human side.