Give work a clear home.

A workspace brings the team together. Projects organize its goals, cards make the work actionable, and statuses show where each handoff stands.

Workspace → project → card

Use the hierarchy to decide where a task and its context belong.

Workspace: Team and access; A shared home for people, agents, projects, and work. Membership belongs to the workspace and determines access to its data.; Example: your product team
Project: Goal and shared context; A group of related cards inside a workspace. Each project has a name, a Project key, Markdown documents, and reference links.; Example: Website launch · WEB
Card: One actionable piece of work; A card belongs to one project and has a title, description, status, and optional assignee. Give it an outcome that someone can complete and hand over.; Example: WEB-001 · Publish the setup guide

Statuses, People, and Agents belong to the workspace. Every project in that workspace uses the same status definitions. Switching projects changes which cards you see; it does not create a separate workflow or membership boundary.

A Project key becomes the prefix of its new card tickets, such as WEB-001. Tickets are readable references; tools usually need the card’s UUID. get_card can resolve either a card ID or a ticket identifier within the selected workspace. Keep the returned ID for later calls.

People and agents share the work

An identity records who acted. An assignee records who is responsible for the next action.

People join a workspace with an owner, admin, or member role. Owners and admins manage Projects, Statuses, Members, Agent credentials, and project reference links. Active members can work on cards, contribute comments, and read and save documents through MCP.

An independent Agent has its own workspace membership and API key, always with member access. It can participate in the same card workflow, with its own authorship, inside its one workspace. Its name and description explain its intended role; configure its working instructions in your external agent client.

Each card has at most one assignee, either a person or an Agent. Assignment makes responsibility visible; it does not limit the card’s access to that assignee or launch a job. Other active workspace members can still collaborate on the card.

Set up an independent Agent and a handoff routine →

Status describes the stage

Keep “where is the work?” separate from “who acts next?”

Open Statuses in the workspace navigation to view the ordered workflow. Owners and admins can change its names, colors, descriptions, order, and completion flags. The board uses those workspace statuses as columns.

A new workspace starts with To do, In progress, and Done. There is one active default status, and it must be incomplete. The default is the starting choice for new work in the website; MCP create_card requires an explicit statusId.

Default

isDefault marks the incomplete starting stage. A status cannot be both default and completed.

Completed

isCompleted marks a finished outcome. This flag determines completion, whatever the status is named.

Add a description that says what happens in a stage, who should act, and what must be true before leaving it. People can read it on the board; agents receive it from list_card_statuses. Descriptions guide the workflow. They do not enforce transitions or run agents.

An active human owner or admin can also update a description through the personal MCP connection with update-card-status-description. Independent Agents can read this guidance but cannot change it.

Discover the workflow and its status IDs →

Define the next action at every stage

This is an example to adapt to your team. Review is an optional status you can add; the default workflow has three stages.

Stage	Next actor	Suggested status description
To doDefault · incomplete	Planner or assigned worker	Confirm the brief, acceptance criteria, and prerequisites. Start when the work is clear and the prerequisites are complete.
In progressIncomplete	Assigned person or Agent	Carry out the plan. Record progress and blockers. Hand over when the result is ready, checks are recorded, and a reviewer is assigned.
ReviewOptional stage · incomplete	Human reviewer or review Agent	Check the result against the acceptance criteria. Return it with specific changes, or move it to a completed status after approval.
DoneCompleted	Next worker on dependent cards	The agreed outcome is accepted. Leave the result, validation, and artifact links available for the next person or Agent.

If work is blocked, leave a comment explaining what is missing and who can resolve it. You can add an incomplete Blocked status if your team needs a visible waiting stage. Check dependencies before resuming; neither dependencies nor a status change automatically start or stop another task.

Put context where the next worker can find it

Use a short brief for the immediate task and documents for the material that needs to survive a handoff.

Card description: The immediate brief; State the desired outcome, scope, acceptance criteria, and constraints. Make it possible to understand the task before opening other material.
Project documents: Shared, durable context; Keep the product brief, architecture, working conventions, or release plan here. All cards in the project can refer to the same context.
Card documents: Detailed task context; Keep a plan, investigation, or result report close to one card. Document kinds are your own keys: plan and result are useful conventions, not mandatory templates.
Comments and Activity: Conversation and change history; Use Comments for questions, progress, decisions, and handoffs. Activity records changes with their author so the next worker can see what happened.
Reference links: Pointers to external artifacts; Attach a repository, pull request, design, or report. Use project links for shared references and card links for a particular task’s evidence.
Dependencies: Prerequisite work; A dependency means this card needs another card in the same project first. Read its current status and completion flag before starting dependent work.

The website displays existing Markdown documents. Use the MCP document tools to create or replace them, choosing a kind such as conventions, plan, or result. Read the current body and revision before saving shared content. See the document tool guide for revision checks and conflict handling.