/quick-plan

name: quick-plan
description: "Use when you need a bite-sized, TDD-driven implementation plan but do NOT have a brainstorm-beagle spec to plan against. quick-plan reconstructs intent from the current conversation, fans out domain-expert exploration subagents across the codebase, and synthesizes the same plan format write-plan produces — without requiring `.beagle/concepts/<slug>/spec.md`. Triggers on: \"quick plan\", \"plan this out\", \"plan what we just discussed\", \"turn this into an implementation plan\", \"plan this without a spec\", \"I don't have a spec, just plan it\", \"write-plan but no spec\". Make sure to use this skill whenever the user wants an implementation or TDD plan and there is no spec to plan against — even if they just say \"plan it\" after discussing a feature. Writes to `.beagle/plans/<slug>/plan.md`. If a finalized spec already exists at `.beagle/concepts/<slug>/spec.md`, prefer write-plan. Does NOT brainstorm specs, write code, or execute the plan — produces the plan document (and an optional handoff prompt) only."

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.

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