quick-plan
Quick Plan: Conversation Into Implementation Plan
Turn the work already discussed in this session into the same comprehensive, TDD-driven implementation plan write-plan produces — but without a spec. An engineer (or downstream agent) can execute it task-by-task without re-deriving intent.
The output is a single markdown plan at .beagle/plans/<slug>/plan.md. The plan captures HOW — file structure, task decomposition, exact tests, exact commands. Because there is no spec, quick-plan also captures the WHAT and WHY inside the plan, in an Intent header it synthesizes from the conversation and verifies before locking.
What Replaces the Spec
write-plan leans on a reviewed spec for three things. quick-plan reconstructs each, because skipping them is how plans bake in unexamined assumptions:
| The spec gives write-plan… | quick-plan reconstructs it from… |
|---|---|
| WHAT / WHY (requirements, core value, out-of-scope) | The conversation — what the user has been asking for, correcting, and ruling out this session — distilled into an Intent Brief. |
| Key Decisions (vetted architectural choices) | Fanout domain-expert subagents that recommend an approach grounded in this codebase's real patterns and the stack's idioms. |
| Reference Points (analogous existing code) | The same fanout subagents, returning file:line analogs the plan mirrors. |
| A human-reviewed gate | A gap check: proceed silently when the conversation is unambiguous; ask the user targeted questions only where intent has real holes. |
The spec is a contract written before planning. quick-plan writes that contract during planning, from cheaper signals, and confirms only the load-bearing parts with the user. Everything downstream of the Intent Brief — task decomposition, TDD discipline, the recoverability test, the self-review gates — is identical to write-plan. Same output, different front-half.