-
Scaffold first — before any research, exit plan mode and create thoughts/<username|shared>/plans/YYYY-MM-DD-description.md from cc-plugin/base/skills/planning/template.md. (Use the user's name when known, e.g. taras; fall back to thoughts/shared/ otherwise.) The file grows incrementally; the user can correct course early.
-
Sub-agent everything heavy — file reads, research, validation. Default to run_in_background: true. Keep raw tool output out of the main session.
Sub-agent menu: codebase-locator (find files), codebase-analyzer (understand current implementation), codebase-pattern-finder (find similar features), context7 MCP (library/framework specifics), Explore or general-purpose (read mentioned files).
Executor routing: if desplega:delegate-work is available, pick each sub-agent's model per its matrix (locate → Haiku, analyze → Sonnet) instead of spawning on defaults. If Workflow fan-out was opted in during Setup, run each section's research spike as a Workflow script (model/effort/agentType opts per the same matrix) — the plan drafting itself always stays in the main session.
-
Ask via AskUserQuestion — see desplega:ask-user for conventions. Never ask in chat as plain bullets.
-
Ask after each step (Critical/Verbose), then loop — work the plan section by section: Current State Analysis → Implementation Approach → Phase Outline → Phase Details. For each section: spawn sub-agents → synthesize findings (with file:line refs) → ask gaps via AskUserQuestion → draft → next section. Assumed inputs are the #1 source of bad plans.
-
Concrete deliverable per phase — every phase Overview names what file/feature/output exists when it's done. "Improve X", "refactor Y" are smells.
-
Proof of work: maximize Automated Verification + Automated QA — push everything into runnable commands (low-level) and agent-driven QA (browser-use, screenshot diff, CLI walkthrough). Manual Verification is the exception. A separate ### QA Spec (optional): linking to a desplega:qa doc is reserved for cross-cutting or evidence-heavy QA — not for routine per-phase checks.
-
Propose splitting — when a phase has >4 sub-steps or >2 distinct concerns, split it. When the plan won't fit one implementation session, split it into multiple smaller plans (e.g., contract → storage → UI). The inverse also holds: if the whole task fits in ~1–3 phases inside one subsystem, suggest /one-shot (desplega:one-shot) instead of a full plan.
-
Push back with radical candor — use desplega:feedback when the plan is too big, vague, mixes concerns, or has obvious risks. Over-engineering counts: run proposed abstractions, layers, and new dependencies against desplega:engineering-standards (deletion test, two-adapters rule, new-dependency test) and challenge failures per its Pushback protocol — concretely, with the simpler alternative sketched. Silence is Ruinous Empathy.
-
Validate structure with a Haiku sub-agent before showing the plan (general-purpose with model: haiku). Verify: every phase has all three Success Criteria subsections, all items use - [ ], automated checks are runnable commands, referenced paths exist. Apply fixes before reveal.
-
Hand off to a fresh session — never implement here. Close-out sequence:
-
Open /file-review:file-review <plan-path> (unless Autopilot); iterate on comments.
-
Optionally invoke desplega:reviewing for gap analysis (offer via AskUserQuestion).
-
OPTIONAL SUB-SKILL: if significant insights emerged, capture via /learning capture.
-
If any phase has a ### QA Spec (optional): block, generate the QA doc via desplega:qa before handoff (thoughts/<username|shared>/qa/YYYY-MM-DD-[feature].md). Scenarios live in the doc, not the plan.
-
Ask the user via AskUserQuestion:
| Question | Options |
|---|
| "Plan ready. What's next?" | 1. Implement in a fresh session, 2. Run /review first, 3. Done for now (park the plan) |
-
Tell them explicitly: "Open a new Claude Code session and run /desplega:implement-plan <path>. Starting fresh keeps the implementation context clean."