plan

Planning a demand into cards

Turn a demand into work that a fresh agent with zero context can pick up and build. The artifact is the cards in Agents Board — not a spec file, not a message in the chat.

Load the agents-board skill first if it isn't loaded in this conversation — it covers the project binding, the board's tools and conventions this skill builds on.

Hard rule: do not write code, scaffold, edit files or mutate the board until the user has approved the plan. This holds for every demand — "too simple to plan" is exactly where a wrong assumption gets baked in. The plan can be three sentences, but you present it and get approval.

Flow

Run in order. Steps 3–6 are the whole point of the skill; none of them is optional, though a small demand passes through them fast.

1. Understand the demand. Read what the user wrote and restate the goal in one sentence. If they described several independent systems (a chat platform and storage and billing and analytics), stop: propose a sequence and plan one module at a time.
2. Explore what already exists. Resolve the project (binding first). Then read: search_docs for the decisions and module knowledge that touch this area, search_cards plus the open todo/backlog cards for work that overlaps, and the actual code paths involved. Never propose against a blank slate.
   • Extend, don't stack. If the demand only extends a card that hasn't started (todo/backlog), update that card after approval instead of creating a twin. Once a card is in_progress it's locked — the demand becomes its own card. Unsure it's the same deliverable? Ask.
3. First clarification round — remove the doubts you already have. Make it unambiguous what is being built: goal, scope, constraints, acceptance. Two things to resolve, both with the user (see Never decide alone): ambiguities (what they actually want) and missing pieces (a brief is almost always incomplete — it asks for login but never says which hash, asks for a list but never says empty/error states). Hunt the gaps; don't fill them silently.
4. Offer research — never run it unannounced. See Research is an offer. Ask whether to dig deeper, say what each option would answer and whether you think it's worth it, and run only what the user picks.
5. Second clarification round — only what the research opened. Research routinely surfaces a fork that didn't exist before ("this library needs a background worker — where does it run?"). Take those back to the user the same way, with a recommended default. Don't re-ask what round 1 already settled.
6. Present the design for approval. Lay out what will be built, section by section: a direct demand in a few sentences, a complex one in ~200–300 words. Where there's a real fork, give 2–3 approaches with trade-offs, your recommendation and why. Include the proposed card breakdown in one line each. Revise until the user approves — only then create anything.
7. Create the cards — see Writing a card, Sizing a card and Where the work lives.
8. Self-review the cards with fresh eyes and fix inline — see Self-review.
9. Hand off. Present the final set (each key + one line, grouped by story). Execution is the user's workflow, whatever it is; the board contract for it lives in the agents-board skill — move the card to in_progress, land it in review with a test-plan comment, and done only on the user's approval.
10. Close the inbox loop. For every inbox demand you planned, mark_inbox_planned(id, cardKeys[]) (a discarded one isn't marked — ask the user to archive_inbox or destroy_inbox). Then re-check list_inbox fresh — the user may have dropped something while you planned; offer once to plan what isn't covered.