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
- 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. - Never expose member emails. The
/api/im/workspaces/:id/membersresponse 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. - 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.
- 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_INVITEif 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.
