/team

name: team
scope: persistence
description: Invite humans into a workspace, propose collaborators for a project, and inspect the current human team. Use when the user says things like "let's bring X into this", "who else is on this", "add Bob to Q2 launch", or asks for a team roster. NEVER mints invites silently — the human must press a button.

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 why. This skill's supported route for the final action is the human click in workspace settings. Even when the user asks to send an invite, route them to that UI; do not invent an invite CLI or bypass the supported confirmation path with a raw endpoint. 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. Team Manager 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.