/plan

description: Create a strictly sequential (waterfall) implementation plan, grounded in best practices. Requires plan mode.
argument-hint: "[feature or change to plan]"
allowed-tools: Read, Glob, Grep, Skill, Task, AskUserQuestion, WebFetch, mcp__plugin_ccf_context7__resolve-library-id, mcp__plugin_ccf_context7__query-docs, mcp__plugin_ccf_microsoft-learn__*
model: opus

You are running CCF `/ccf:plan`.

0. Plan-mode gate (backup for the hook)

**STOP.** Confirm this session is in plan mode before anything else. If it is not, refuse to continue: tell the user to enter plan mode (Shift+Tab cycles to 'plan', or start the session with `--permission-mode plan`), then re-run `/ccf:plan`. Do not run any step below. The `plan-mode-guard` hook blocks this deterministically too; this sentence is the backup for the case where the hook does not fire.

0a. Style for user-facing text (applies to every step below that writes text into the plan)

**Scope boundary:** this rule governs CCF-generated text meant for the human reader (the plan body, task files, explanations to the user). It does NOT apply to the CCF repo's own source, which stays English per `.claude/rules/components.md` (never translate the repo itself).

• Write in the SAME language the user is using in this conversation; never mix two languages inside one sentence.
• Keep identifiers verbatim (file names, function names, variable names, command names, field names, event names) — translating an identifier makes it wrong.
• Translate a concept when the user's language has a natural equivalent; keep a difficult or ambiguous English term verbatim and add a short parenthetical explanation on first use.
• No em dash; use a comma, colon, or parentheses instead.
• One idea per sentence; split a sentence longer than two lines.
• A language that uses diacritics (e.g. Vietnamese) must keep them; never write bare ASCII when the language needs marks.
• Do not invent abbreviations; if one is used, spell it out on first use.
• Open with the point itself; never with generic filler. End when the content ends; never restate what was just said as a summary.
• Cut adjectives that add no information; a claim earns its adjective with a concrete fact, number, or name.
• Use as many bullets as there are real points, never a rounded count; prefer plain prose when ideas are not parallel.
• Prefer a specific example, number, or name over an abstract description; give one clear recommendation instead of an option list with no conclusion; state uncertainty plainly.
• Vary sentence length; do not repeat the same key phrase within a paragraph.
• No icons or emoji in generated text; review markers use the word set FAIL:/WARN:/PASS:.

1. Read existing context

Read `CLAUDE.md` (root + nested) + `.claude/rules/*` + `.claude/plan/PLAN.md`. The new plan must be consistent with the spec and slot into the existing sequential backlog.

1b. Discover the codebase with 5 parallel analyzers

Launch **5 `ccf-codebase-analyzer` subagents in parallel** via Task, each on ONE of the agent's **set B (planning) slices**. Pass `run_in_background: false` on all 5 and wait for every report before step 2: since Claude Code v2.1.198 an omitted `run_in_background` defaults to background, which would let the interview start against reports that do not exist yet. Read-only research may fan out; that exemption (shared with `/ccf:init` B1) does not touch the sequential law, which governs WRITING work.

Route discovery through `ccf-codebase-analyzer` rather than the built-in `Explore` agent, and do not sweep the whole codebase by hand in the main conversation. CCF does not own `Explore`'s prompt, so it cannot be told what a planner needs; `ccf-codebase-analyzer` is read-only by `disallowedTools`, returns a fixed report shape with a mandatory **Unknowns** section, and keeps 5 slices of findings out of the main context window. Reading a specific file yourself stays fine, since the ban is on the broad sweep.

Give every one of the 5 the SAME context — the requested change (`$ARGUMENTS` plus anything already known from step 1) — then assign one slice each: 1. Impact surface (the files/functions the change must touch) 2. Patterns to conform to (nearest precedents + conventions) 3. Existing test surface (what covers it, and the EXACT command that runs it) 4. Integration points & dependencies (boundaries + data contracts) 5. Blast radius & fragility (what depends on it, where it is weak)

• **Skip ONLY on a greenfield project.** Check with Glob whether any source file exists outside `.claude/`, `CLAUDE.md` and docs. With no code to discover, skip this step and say so in one line ("no source files yet, skipping codebase discovery"). Never skip silently, and never skip because the change looks small: "small" is a judgment the reports exist to check.
• **Model — ask, do not decide silently.** Before spawning, use `AskUserQuestion` ONCE to ask which model runs all 5 analyzers. **Recommend `haiku`** and label it as the recommendation: the slices gather evidence over a bounded surface, `haiku` is the agent's frontmatter default paired with `effort: low`, and 5 spawns of a stronger model on every plan costs real money for little gain. Offer `sonnet` as the step-up for a large or unfamiliar codebase, where slices 1 and 5 need the most inference (who calls this, what breaks), and `opus` only if the user asks. Accept a model ALIAS only, never a dated model ID.
• Do not spawn `sonnet` (or anything else) just because it is the session's model. The analyzer's `model` frontmatter is a DEFAULT, and a call site overriding it without asking is the behavior this bullet exists to stop.
• If `AskUserQuestion` is genuinely unavailable (non-interactive session), fall back to `haiku` and say in one line that the default was used because asking was blocked. Never proceed as if the user had chosen.
• If the user already named an analyzer model earlier in this session, reuse it without re-asking.
• Reports are