Cursor Canvases for team workflows

A Cursor Canvas is worth keeping when it carries decisions a pull request can be checked against: owners, paths, rules, and the risks still open. A Canvas is a visual planning surface in Cursor, Anysphere's AI code editor, where a team pins boundaries before agents start editing files. The trouble starts when the drawing arrives after the real calls were already made in chat. Then it is a prettier transcript, and reviewers navigate by a map that no longer matches the repo.

I watched this happen in one sprint review. The Canvas said the agent handles tests. The PR that shipped named no test path and no verification command. The diagram looked finished, the decisions stayed verbal, and review stayed blind. The fix is small: give every Canvas that touches code a block of text the team can quote and correct.

Give each Canvas one job

A Canvas with one job survives. A Canvas that tries to capture everything captures nothing a reviewer can act on. In team workflows, four jobs are worth the effort:

• Map a feature boundary before subagents split the work.
• Show how rules and skills apply to a folder.
• Record an architecture decision that affects review.
• Name which MCP connectors a workflow is allowed to call.

If your Canvas does not answer one of those questions, it belongs in notes, not in the review path. Saying that out loud saves everyone the meeting ritual of admiring a drawing nobody will check against the diff.

Write a review header you can diff

Text is what your team can diff, quote, and fix. So every Canvas that influences code gets a short header. The picture can stay visual; the decision lives in words.

# Canvas review header

- Decision: split onboarding flow into UI, API, and analytics workstreams.
- Owner: product engineering lead.
- Applies to: `apps/site/src/app/onboarding/**`
- Related rules: `.cursor/rules/onboarding.mdc`
- Related skill: `skills/onboarding-review/SKILL.md`
- Open risks: analytics payload shape, API validation, copy approval.
- Review evidence: PR must link this Canvas and list which risks closed.

That header points at enforceable files instead of floating beside them. When the Canvas and a repo rule disagree, the rule wins and the Canvas gets updated, never the reverse.

Draw it before the agents start

A Canvas drawn after delegation is an alibi. Drawn before, it is a boundary that scopes owners and paths. The sequence that keeps it honest moves from framing to review, and each step leaves a repo artifact behind:

The worktree mechanics behind the delegate step live in Cursor 3.2: subagents, worktrees, multi-root, and the wider pattern sits in the subagents and skills topic hub.

Pair the diagram with one small rule

A diagram that says "agent handles tests" without a test path creates no accountability. Tie each Canvas to one rule so the design artifact survives into the review artifact.

Any PR that cites a Cursor Canvas must include:
- the Canvas decision;
- the paths affected;
- the owner for each unresolved risk;
- the verification command used after the agent finished.

This is the Design to Review bridge in our methodology. The surfaces a Canvas binds are documented under Cursor Rules, Cursor Skills, Cursor Agent, and Cursor MCP, with connector contracts in the Model Context Protocol specification and surface changes in the changelog. A Canvas without an owner column is a whiteboard photographed at the end of a meeting: everyone nods, nobody is bound.

Common questions

• What are Cursor Canvases for in a team workflow?

  Cursor Canvases work best as decision artifacts created before agents edit files. Use one to map a feature boundary, show how rules and skills apply to a folder, record an architecture decision, or name the MCP connectors a workflow may call. If a Canvas does not do one of those jobs, it belongs in notes rather than in the review path that reviewers actually check.

• Should a Canvas be allowed to block a PR?

  Yes, but only through its text. A PR that cites a Canvas should carry the decision, the affected paths, the owner of each unresolved risk, and the verification command run after the agent finished. The visual part informs the team, and the review header is what reviewers check the diff against when they decide to merge.

• How do Canvases connect to Cursor rules and skills?

  The review header names the related .mdc rule and the related SKILL.md, so the diagram points at enforceable files instead of floating beside them. When the Canvas and a repo rule disagree, the rule wins and the Canvas gets updated. The repo is the source of truth, never the drawing.

• When should the Canvas be drawn?

  Draw it before subagents split the work, not after. Drawn before delegation, the Canvas is a boundary that scopes owners and paths. Drawn after, it decorates decisions already made in chat. Keep the sequence in order: frame, assign, constrain, delegate, review, and each step leaves something in the repo.

Try it on one workflow

Pick one active workflow and write the Canvas review header before any agent starts. If the owner, the rule, and the verification command are missing, the Canvas is not ready to guide code yet.