/plan-create

name: plan-create
description: Create structured implementation plans for autonomous TDD development. Use for new features, multi-file changes, or anything requiring multiple steps or tests. Triggers on aspirational openers ("let's build", "let's start building", "I want to make", "I want an app that", "help me build"), capability lists ("users should be able to X, Y, Z"), vague-noun patterns ("a system for", "a way to", "an app that", "functionality for"), and explicit build verbs ("build", "create", "add a feature", "help me implement", "I need to build"). Do NOT use this for "implement the plan" or "run the plan" - those should use plan-orchestrate instead. Skip for quick bug fixes, single-line changes, questions, or documentation.
argument-hint: "[feature description]"

Plan Create

Transform feature requests into structured plans with task breakdowns, dependencies, and TDD requirements for parallel autonomous execution.

Project Architecture

<architecture> @.claude/architecture.md </architecture>

Execution Flow

Phase 0: Pre-plan hook

Run this once, at the very start, before Phase 1 discovery.

**Run the `pre-plan` hook.**

Run the discovery script — never enumerate agent files by hand:

"{skill-base-dir}/../../hooks/discover-hooks.sh" --hook=pre-plan

`{skill-base-dir}` is the **`Base directory for this skill`** value stated when this skill loaded. `${CLAUDE_PLUGIN_ROOT}` is not available in a skill's Bash calls.

• **Exit 0, empty stdout** → empty hook. This is the default. Return immediately: print nothing, spawn nothing, say nothing about the hook at all, and proceed to Phase 1. Do **not** narrate that the script returned no agents — that is the narration `HOOKS.md` forbids.
• **Exit 0, output** → **print the output verbatim** as the resolved agent order, then spawn each listed agent in order per its `mode`.
• **Any non-zero exit** → **stop**. Surface the script's stderr verbatim and do not continue planning. Exit 3 means an agent file declares an invalid `phase` or `mode`; exit 4 means enrollment drifted. Neither is an empty hook. If the script is missing or not executable, that is also a hard stop — there is no fallback, and you must not reconstruct the routine by hand.

**Capture the enrollment fingerprint** now, for Phase 6's drift check:

"{skill-base-dir}/../../hooks/discover-hooks.sh" --fingerprint

Hold that value. **A fingerprint is only ever produced by running the script** — never reconstruct, abbreviate, or recall one from memory. If it is not to hand at Phase 6, re-run the command and say so. A hallucinated digest makes every later check fail with bogus drift and bricks the plan.

**IMPORTANT — no plan name exists yet.** The `pre-plan` hook fires *before* Phase 1 discovery. The plan name and plan directory are not created until Phase 3, so there is **no plan name to pass**. Each `pre-plan` agent receives only: 1. The raw feature request (the user's verbatim ask). 2. The project's architecture context:

## Project Architecture
{paste the COMPLETE content of <architecture> verbatim}

Do **not** attempt to pass a plan name or plan directory to a `pre-plan` agent — neither exists yet. The `pre-plan` hook is thin by design (policy gate / house-context injection).

Phase 1: Discovery & Assumption Brainstorm

Approach this phase like a solution architect meeting with a client to flush out scope and requirements. Your job is not to ask everything — it's to think hard about the shape of the solution before asking grounded questions. Find the integration points, then enumerate the design axes the user probably hasn't thought about.

**Quick scope check first.** If the ask already specifies data model, scope boundaries, and integration points (e.g., "Add an `email_verified_at` column to users and a `SendVerificationEmail` job"), do a brief existence-check (do the named files/models exist?) and skip ahead to Phase 2 — the brainstorm below is for under-specified asks.

**1. Codebase discovery**

Read files specifically related to the ask. Architecture context is already loaded via the `<architecture>` block at the top of this skill — do not re-read `.claude/architecture.md`. Instead:

• Glob for domain-related files (e.g., for "track books", look for `book*`, `*Book*`, library/reading-list files)
• Read existing models, controllers, or components that overlap with the ask
• Note existing patterns the new feature must conform to or extend
• Identify what's already built vs. greenfield

**2. Permutation & assumption brainstorm**

For each noun and verb in the ask, enumerate plausible interpretations. Then enumerate the **hidden axes** — design decisions the user almost certainly hasn't specified but the implementer needs to know. Surface the non-obvious ones a senior engineer would catch and a junior would miss.

Focus on permutations that meaningfully change **scope, data model, or architecture**. Avoid minutiae (button colors, naming bikesheds, trivial config defaults).

Example for "track books I'm reading":

• **Book schema**: title only? +author/ISBN/cover/genre/pages/publication date?
• **List structure**: one global list, or multiple states ("want to read", "reading", "finished")?
• **"Finished" semantics**: boolean state, dated event, or reversible?
• **Hidden axes the ask didn't mention**: auth/multi-user, persistence layer, edit/delete operations, search/filter/sort, ratings/notes, web vs mobile UI, external lookups (ISBN APIs).

**3. Diff against codebase**

Produce a short "what I found vs. what you asked" comparison. Examples:

• "You have a `User` model with auth — books would extend it for per-user lists"
• "No models exist yet — this is greenfield"
• "Your existing controllers follow a `ResourceController` pattern; book routes would conform"

**Issue Detection:** If the user references a GitHub issue (e.g., "#18", "issue 18", a GitHub issue URL), capture it for the `## Related Issues` field in `_plan.md`. Use