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](../write-plan/SKILL.md) 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.

## Workflow

Complete these steps in order:

1. **Reconstruct intent** — distill the conversation into an *Intent Brief* (goal, must-haves, constraints, out-of-scope, any approach signals). See *Reconstructing Intent*.
2. **Gap check** — decide whether the Brief is solid enough to plan. Proceed silently if unambiguous; ask targeted questions only for real holes. See *Gap Check*.
3. **Fan out exploration + experts** — dispatch parallel subagents, one per codebase region the plan will touch. Each is briefed as a domain expert and returns a file map, conventions, exact test commands, `file:line` reference points, and idiom/pitfall guidance. See *Fanout Exploration*.
4. **Read project conventions** — scan `AGENTS.md`/`CLAUDE.md` (root and nested) for testing tiers, comment policy, commit format, forbidden patterns the plan must respect.
5. **Design file structure** — map files to create/modify before writing any task.
6. **Decompose into tasks** — bite-sized (2-5 min) TDD steps with exact paths, tests, and commands — using write-plan's format exactly. See *Plan Format*.
7. **Self-review** — run the checklist (intent coverage, placeholders, discriminating assertions, spike/parallel gates). See *Self-Review*.
8. **Present draft to user** — show the full draft in chat; iterate on request.
9. **Write to disk** — save to `.beagle/plans/<slug>/plan.md` only after explicit approval, then offer the execution handoff.

```text
Reconstruct Intent Brief from conversation
        ↓
Gap check ── real holes? ── Yes → ask targeted questions → fill Brief
          └──────────────── No  → proceed silently
        ↓
Fan out exploration + expert subagents (parallel)  ─┐
Read project conventions (AGENTS.md / CLAUDE.md)   ─┘→ merge findings into Brief
        ↓
Design file structure → Decompose into TDD tasks
        ↓
Self-review → fix inline
        ↓
Present draft → User review
               ├─ Changes? → Revise
               └─ Approved? → Write to .beagle/plans/<slug>/plan.md
```

**The terminal state is a written plan.** quick-plan does not execute the plan, run tests, or modify production code. After writing it asks whether to generate an execution handoff prompt via the **subagent-prompt** skill ([../../../beagle-core/skills/subagent-prompt/SKILL.md](../../../beagle-core/skills/subagent-prompt/SKILL.md)).

## Reconstructing Intent

The conversation is the raw material the spec would otherwise be. Mine it before doing anything else, and write the result down — the Intent Brief is the contract the plan plans against, so it must be explicit, not held in your head.

Pull from the **whole session**, not just the last message: the feature asked for, behaviors described, corrections the user made ("no, it should…"), examples or error logs pasted, things explicitly ruled out, and any tech/library named. A correction the user made three messages ago is a requirement; treat it like one.

Draft the Intent Brief with these fields. This becomes the plan's **Intent** header verbatim:

- **Goal** — one sentence: what this builds and the value it delivers.
- **Must-haves** — the observable behaviors that define "done." Each must be specific enough to write a test against.
- **Out of scope** — what the user ruled out or what you're deliberately deferring. Without a spec, scope creep is the main failure mode; name the boundary.
- **Constraints** — tech stack, libraries, performance/compatibility limits the conversation pinned.
- **Approach signals** — any HOW the user already expressed a preference about (and, after fanout, the expert-recommended approach with its rationale — this is the spec's *Key Decisions* equivalent).
- **Open questions** — anything the conversation left genuinely ambiguous (feeds the gap check).

If the conversation is too thin to fill **Goal**, **Must-haves**, and **Out of scope** at all, quick-plan is premature — the work hasn't been thought through enough to plan. Say so and offer [brainstorm-beagle](../brainstorm-beagle/SKILL.md) to shape it first, rather than