/init

description: Use only when the user explicitly asks to bootstrap a new project or onboard an existing one into the CCF workflow, because it writes the project's spec files. Generates CLAUDE.md + .claude specs + an initial plan of vertical slices.
argument-hint: "[optional: short description of what you want to build]"
allowed-tools: Read, Write, Edit, Glob, Grep, Bash, Task, Skill, 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:init`. Produce a best-practice-grounded context layer (`CLAUDE.md` plus `.claude/`) and an initial implementation plan of vertical slices, following Anthropic's Explore then Plan workflow. Write no application code in this command: `/ccf:plan` details the first feature, and it is then implemented directly in the session, one task at a time.

Templates live in `${CLAUDE_PLUGIN_ROOT}/templates/`. Read them and instantiate them, replacing every `{{...}}` placeholder, when you write real files into the project.

0a. Style for user-facing text

**Scope boundary:** this rule governs CCF-generated text meant for the human reader (the decisions summary, the plan and task files this command writes, explanations shown 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:.

0. Classify the project

Scan `cwd` read-only (Glob `**/*` excluding `node_modules` and `.git`; check for `package.json`, `src/`, an existing `CLAUDE.md`). Classify the project as **EMPTY** (nothing substantial yet) or **EXISTING** (has code), then run the matching branch below.

Reference: folding the testing answers into `testing.md.tmpl`

Both A3 and B3 instantiate this template, so the fold lives here once. `grill-me` only ASKS about testing; `/ccf:init` is what WRITES the answers, which makes this step deterministic rather than a judgment call.

• Always fill `{{TEST_FRAMEWORK}}` / `{{TEST_CMD}}` / `{{TEST_LOCATION}}` / `{{COVERAGE_TARGET}}`. In A3 they come from the interview answers; in B3 from the test setup the analyzers observed and the interview confirmed.
• Discipline opt-in **ON** → set `{{TEST_MATRIX_REQUIRED}}` to `yes`, keep the "Test design discipline" block, fill `{{INTEGRATION_TEST_SCOPE}}` / `{{E2E_TEST_SCOPE}}` (from the answers, or from the codebase's existing test layers, or from sensible per-app-type defaults), and set `{{TEST_GATE_ENFORCEMENT}}` to `prompt-only` or `stop-hook` per the enforcement answer.
• Enforcement `stop-hook` → also generate the project's own `.claude/hooks/` gate, stripping the `.tmpl` suffix on each instantiated file:
• `templates/root/.claude/hooks/test-gate.mjs.tmpl` → `.claude/hooks/test-gate.mjs`
• `templates/root/.claude/hooks/hooks.json.tmpl` → `.claude/hooks/hooks.json`
• `templates/root/.claude/hooks/lib/test-gate-core.mjs` → `.claude/hooks/lib/test-gate-core.mjs`, copied VERBATIM (it carries no `.tmpl` suffix and no placeholders). This lib is required, because `test-gate.mjs` does `import { shouldBlockStop } from "./lib/test-gate-core.mjs"` and omitting the lib makes the hook crash with module-not-found.
• The registration entry in `hooks.json` is itself the on/off toggle for the gate; there is no flag for it in `settings.json`.
• Discipline opt-in **OFF** → delete the whole "Test design discipline" block from the instantiated file (heading, body and the template's HTML comment), per that comment, leaving no empty heading and no unfilled `{{...}}`, and generate none of the hook files.

---

Branch A — EMPTY project

A1. Interview (grill-me)

Invoke the `grill-me` skill via the Skill tool, passing `init` as the argument. It walks the project decision tree **one question at a time** (exploring the repo and git history to self-answer first, and recommending an answer for each) and returns the collected decisions.

Synthesize the result into a **decisions summary** and present it for the user to confirm.

A2. Best-practice grounding

Consult the docs for every chosen design pattern, DB design and framework before you write the spec, so the spec cites a source instead of your memory. Delegate to `ccf-best-practice-researcher` via Task **with `run_in_background: false`** (since Claude Code v2.1.198 a Task spawn omitting that flag defaults to background, which would let A3 start writing the spec before the researcher's report exists), or c