Document plan checks - #37

What changed and why

The plan editor's Checks menu — the one-click quality passes you run over a plan before any code is written — was undocumented. This adds plans/collaboration/checks.mdx, listing the ten generally available checks with their menu labels and descriptions verbatim, and leading with the distinction a reader needs before clicking anything: whether a check edits the plan, adds a section, or only reports findings in chat and waits for confirmation. The page is added to the Collaboration group before Review Requests (run checks, then ask a human), plus one cross-linking sentence each in Best Practices and step 5 of Your First Plan.

Verified

All claims confirmed in ref-tools/ref:

• Check list, labels, descriptions, action tags, menu order — plan-app/client/src/components/ChecksMenu.tsx, PLAN_CHECK_DEFINITIONS. Labels and descriptions in the table are copied verbatim from that array; the "Action" column is each check's actionLabel, which is the tag rendered next to the label in the menu (checks-menu__action-tag).
• What each action tag means — buildPromptTemplate in the same file. auto-edit and coherence edit the plan in place ("use the Edit tool to make improvements in place"; coherence explicitly "Do not add a new review section"); add-section appends a new section; chat-review prepends CHAT_REVIEW_PROMPT_PREFIX, which instructs a terse numbered list of findings in chat, the question "Which of these should I apply to the plan?", and "Do NOT edit the plan document until the user confirms which items to apply".
• Every check reads the plan first — every prompt starts "Read the current plan using the Read tool."
• Where the menu lives — desktop trigger renders in the editor controls cluster via EditorRightActionControls.tsx; its title/aria-label is "Run plan check". Mobile trigger is reached from the header overflow menu, whose item label is "Run a check" (HeaderOverflowMenu.tsx).
• Running a check starts its own chat thread — handleCheckSelected calls sendMessage(planId, prompt, null, …) with a null threadId; plan-app/server/src/routes/plansMessages.ts creates a new thread when no threadId is supplied. The thread/agent is named Check: <label> (passed as taskShortDescription, surfaced by formatAgentLabel in plan-app/client/src/lib/agentUtils.ts), which is why the page says the thread is named after the check.

Unverified / omitted

• Emojimaxxing — deliberately left out. It is the eleventh check and the only one gated separately (FeatureFlags.EMOJIMAXXING, a Statsig gate that defaults off and is filtered out of visibleChecks when off), so most readers would not see it in their menu. Its "Creates new plan" action tag is therefore also absent from the action-tag list. Judgement call: documenting a menu item behind a rollout gate would put the page out of sync with what most users see. If the gate goes to 100%, the check and its action tag can be added in one small edit.
• Credit cost, tier availability, and MCP reachability — omitted entirely. Nothing was verified about credit consumption or tier gating for checks, and PLAN_CHECKS is referenced only by client components, with no MCP tool exposing them, so no claim either way is made.
• Version history interaction — considered a line about reviewing what an editing check changed via version history, but the diff/restore behaviour was not verified, so it was left out.
• Concurrency — no claim about running multiple checks at once; not verified.

Conflicts

This PR edits docs.json (one added line in the Collaboration group). Sibling PRs in this batch also edit docs.json, so a small conflict there is expected.

Generated by Claude Code