all-for-claudecode 2.0.0 → 2.2.0

package/commands/implement.md

@@ -6,8 +6,8 @@ argument-hint: "[task ID or phase specification]"
 
 # /afc:implement — Execute Code Implementation
 
-> Executes tasks from tasks.md phase by phase.
-> Uses native task orchestration with dependency-aware scheduling. Swarm mode activates for >5 parallel tasks per phase.
+> Executes implementation phase by phase with dependency-aware scheduling.
+> Generates tasks.md automatically from plan.md if absent. Swarm mode activates for >5 parallel tasks per phase.
 
 ## Arguments
 
@@ -19,7 +19,12 @@ argument-hint: "[task ID or phase specification]"
 
 ## Config Load
 
-**Always** read `.claude/afc.config.md` first (read manually if not auto-loaded above). Abort if config file is missing.
+**Always** read `.claude/afc.config.md` first (read manually if not auto-loaded above).
+
+If config file is missing:
+1. Ask the user: "`.claude/afc.config.md` not found. Run `/afc:init` to set up the project?"
+2. If user accepts → run `/afc:init`, then **restart this command** with the original `$ARGUMENTS`
+3. If user declines → **abort**
 
 ## Execution Steps
 
@@ -35,23 +40,66 @@ git tag -f afc/pre-implement
 - Tag is automatically overwritten on the next `/afc:implement` run
 - Skip if running inside `/afc:auto` pipeline (the `afc/pre-auto` tag already exists)
 
+**Standalone safety activation** (skip if inside `/afc:auto`):
+If no active pipeline state exists, activate it for the duration of this command:
+```bash
+"${CLAUDE_PLUGIN_ROOT}/scripts/afc-pipeline-manage.sh" start {feature-name-from-plan.md}
+"${CLAUDE_PLUGIN_ROOT}/scripts/afc-pipeline-manage.sh" phase implement
+```
+This enables Stop Gate and CI Gate hooks during standalone implementation. Release on completion (Step 7) or failure rollback.
+
 ### 1. Load Context
 
 1. **Current branch** → `BRANCH_NAME`
 2. Load the following files from `.claude/afc/specs/{feature}/`:
-   - **tasks.md** (required) — abort if missing: "tasks.md not found. Run `/afc:tasks` first."
-   - **plan.md** (required) — abort if missing
+   - **plan.md** (required) — abort if missing: "plan.md not found. Run `/afc:plan` first."
    - **spec.md** (for reference)
    - **research.md** (if present)
-3. Parse tasks.md:
+   - **tasks.md** (if present — may be generated in Step 1.3)
+3. **Recent changes**: run `git log --oneline -20` to understand what changed recently (context for implementation)
+4. **Smoke test**: run `{config.gate}` before starting implementation:
+   - If it fails → diagnose before implementing (existing code is broken — fix first or report to user)
+   - If it passes → baseline confirmed, proceed
+
+### 1.3. Task List Generation (if tasks.md absent)
+
+If `.claude/afc/specs/{feature}/tasks.md` does not exist, generate it from plan.md:
+
+1. **Parse plan.md File Change Map**: extract files, actions, descriptions, `Depends On`, `Phase`
+2. **Generate tasks.md**:
+   - Convert each row to task format: `- [ ] T{NNN} {[P]} {description} \`{file}\` {depends: [TXXX]}`
+   - Assign `[P]` to tasks in the same Phase with no file dependency overlap
+   - Map `Depends On` column to `depends: [TXXX]` references
+   - Include phase gate validation task per phase
+   - Include coverage mapping at the bottom:
+     - FR/NFR → tasks (every FR-*/NFR-* maps to at least one task)
+     - Entity → tasks (every spec Key Entity maps to at least one task)
+     - Constraint → tasks (every spec Constraint is addressed by at least one task)
+3. **Validate** (script-based, no critic loop):
+   ```bash
+   "${CLAUDE_PLUGIN_ROOT}/scripts/afc-dag-validate.sh" .claude/afc/specs/{feature}/tasks.md
+   "${CLAUDE_PLUGIN_ROOT}/scripts/afc-parallel-validate.sh" .claude/afc/specs/{feature}/tasks.md
+   ```
+4. If validation fails → fix tasks.md and re-validate (max 2 attempts)
+5. Save to `.claude/afc/specs/{feature}/tasks.md`
+
+If tasks.md already exists (e.g., from standalone `/afc:tasks` run): use as-is, skip generation.
+
+### 1.5. Parse Task List
+
+1. Parse tasks.md:
    - Extract each task's ID, [P] marker, [US*] label, description, file paths, `depends:` list
    - Group by phase
    - Build dependency graph (validate DAG — abort if circular)
    - Identify already-completed `[x]` tasks
-4. **Recent changes**: run `git log --oneline -20` to understand what changed recently (context for implementation)
-5. **Smoke test**: run `{config.gate}` before starting implementation:
-   - If it fails → diagnose before implementing (existing code is broken — fix first or report to user)
-   - If it passes → baseline confirmed, proceed to implementation
+2. Load **Implementation Context** section from plan.md (used in sub-agent prompts)
+
+### 1.5. Retrospective Check
+
+If `.claude/afc/memory/retrospectives/` exists, load and check:
+- Were there implementation issues in past pipelines (e.g., file conflicts, unexpected dependencies, CI failures after parallel execution)?
+- Flag similar patterns in the current task list. Warn before implementation begins.
+- Skip gracefully if directory is empty or absent.
 
 ### 2. Check Progress
 
@@ -72,7 +120,7 @@ Execute each phase in order. Choose the orchestration mode based on the number o
 |---------------------|------|----------|
 | 0 | Sequential | Execute tasks one by one |
 | 1–5 | Parallel Batch | Launch Task() calls in parallel (current batch approach) |
-| 6+ | Swarm | Create task pool → spawn worker agents that self-organize |
+| 6+ | Swarm | Create task pool → orchestrator pre-assigns tasks to worker agents |
 
 #### Sequential Mode (no P marker)
 
@@ -82,70 +130,136 @@ Execute each phase in order. Choose the orchestration mode based on the number o
 
 #### Parallel Batch Mode (1–5 [P] tasks)
 
-- Verify **no file overlap** (downgrade to sequential if overlapping)
-- Register all phase tasks via TaskCreate:
-  ```
-  TaskCreate({ subject: "T003: Create UserService", description: "..." })
-  TaskCreate({ subject: "T004: Create AuthService", description: "..." })
-  ```
-- Set up dependencies via TaskUpdate:
-  ```
-  TaskUpdate({ taskId: "T004", addBlockedBy: ["T002"] })  // if T004 depends on T002
-  ```
-- Launch parallel sub-agents for unblocked [P] tasks in a **single message** (auto-parallel):
-  ```
-  Task("T003: Create UserService", subagent_type: "general-purpose",
-    prompt: "Implement the following task:\n\n## Task\n{description}\n\n## Related Files\n{file paths}\n\n## Plan Context\n{relevant section from plan.md}\n\n## Rules\n- {config.code_style}\n- {config.architecture}\n- Follow CLAUDE.md and afc.config.md")
-  Task("T004: Create AuthService", subagent_type: "general-purpose", ...)
-  ```
-- Read each agent's returned output and verify completion
-- Mark TaskUpdate(status: "completed") for each finished task
-- Any newly-unblocked tasks from dependency resolution → launch next batch
+**Pre-validation**: Verify no file overlap (downgrade to sequential if overlapping).
+
+**Step 1 — Register**: Create tasks for the current phase only (phase-locked registration):
+```
+TaskCreate({ subject: "T003: Create UserService", description: "..." })
+TaskCreate({ subject: "T004: Create AuthService", description: "..." })
+TaskUpdate({ taskId: "T004", addBlockedBy: ["T002"] })  // if T004 depends on T002
+```
+
+**Step 2 — Launch unblocked [P] tasks in a single message** (Claude Code executes multiple Task() calls in a single message concurrently, up to ~10):
+```
+Task("T003: Create UserService", subagent_type: "afc:afc-impl-worker",
+  isolation: "worktree",
+  prompt: "Implement the following task:
+
+  ## Task
+  {task ID}: {description} — `{file path}`
+
+  ## Implementation Context
+  {paste full ## Implementation Context section from plan.md}
+
+  ## Plan Context
+  {relevant Phase section from plan.md for this task}
+
+  ## Rules
+  - {config.code_style} and {config.architecture}
+  - Follow CLAUDE.md and afc.config.md
+
+  ## Output
+  Return a structured summary (max 2000 chars):
+  - Files changed: {list}
+  - Key decisions: {any design choices made}
+  - Issues: {blockers or concerns, if any}
+  - Verification: {config.gate} result")
+Task("T004: Create AuthService", subagent_type: "afc:afc-impl-worker", isolation: "worktree", ...)
+```
+
+**Step 3 — Collect results and advance**: After all parallel agents return:
+1. Read each agent's returned output and verify completion
+2. Mark `TaskUpdate(status: "completed")` for each finished task
+3. **Manually check for newly-unblocked tasks**: Call `TaskList`, inspect `blockedBy` lists — if all blockers are now completed, the task is unblockable. (Note: auto-unblocking is only guaranteed in Agent Teams mode; in sub-agent mode, the orchestrator must poll and check manually.)
+4. If newly-unblockable tasks exist → launch next batch (repeat Step 2)
+5. If no more pending tasks remain → phase complete
+
+**Failure Recovery** (per-task, not per-batch):
+1. Identify the failed task from the agent's error return
+2. Reset: `TaskUpdate(taskId, status: "pending")`
+3. Track: `TaskUpdate(taskId, metadata: { retryCount: N })`
+4. If retryCount < 3 → re-launch in the next batch round (not immediately — wait for current batch to finish)
+5. If retryCount >= 3 → mark as failed, report: `"T{ID} failed after 3 attempts: {last error}"`
+6. Continue with remaining tasks — a single failure does not block the entire phase
 
 #### Swarm Mode (6+ [P] tasks)
 
-When a phase has more than 5 parallelizable tasks, use the **self-organizing swarm pattern**:
+When a phase has more than 5 parallelizable tasks, use the **orchestrator-managed swarm pattern**.
 
-1. **Create task pool**: Register ALL phase tasks via TaskCreate with full descriptions
-2. **Set up dependency graph**: Use TaskUpdate(addBlockedBy) for every `depends:` declaration
-3. **Spawn N worker agents** (N = min(5, unblocked task count)):
-   ```
-   Task("Swarm Worker 1", subagent_type: "general-purpose",
-     prompt: "You are a swarm worker. Your job:
-     1. Call TaskList to find available tasks (status: pending, no blockedBy, no owner)
-     2. Claim one by calling TaskUpdate(taskId, status: in_progress, owner: worker-1)
-     3. Read TaskGet(taskId) for full description
-     4. Implement the task following the plan and code style rules
-     5. Mark complete: TaskUpdate(taskId, status: completed)
-     6. Repeat from step 1 until no tasks remain
-     7. Exit when TaskList shows no pending tasks
-
-     ## Rules
-     - {config.code_style} and {config.architecture}
-     - Always read files before modifying
-     - Follow CLAUDE.md and afc.config.md")
-   ```
-4. **Wait for all workers to exit** — workers naturally terminate when the pool is empty
-5. **Verify**: check TaskList for any incomplete tasks → re-spawn workers if needed
+> **Key constraint**: Claude Code's TaskUpdate uses **last-write-wins** with local file locking only. Multiple sub-agents calling TaskUpdate on the same task simultaneously can cause lost writes. The orchestrator must mediate task assignment to prevent collisions.
+
+**Step 1 — Register current-phase tasks only** (phase-locked):
+```
+// Register ONLY this phase's tasks — never register future phases
+TaskCreate({ subject: "T007: Create ComponentA", description: "..." })
+TaskCreate({ subject: "T008: Create ComponentB", description: "..." })
+// ... for all tasks in this phase
+TaskUpdate({ taskId: "T008", addBlockedBy: ["T006"] })  // if dependency exists
+```
+
+**Step 2 — Orchestrator assigns tasks** (no self-claiming):
+Instead of workers self-claiming (race-prone), the **orchestrator pre-assigns** tasks:
+```
+// Orchestrator assigns: each worker gets a unique, non-overlapping task set
+Task("Worker 1: T007, T009, T011", subagent_type: "afc:afc-impl-worker",
+  isolation: "worktree",
+  prompt: "Implement these tasks in order:
+  1. T007: {description} — `{file path}`
+  2. T009: {description} — `{file path}`
+  3. T011: {description} — `{file path}`
+
+  ## Implementation Context
+  {paste full ## Implementation Context section from plan.md}
+
+  For each task:
+  - Read the target file before modifying
+  - Implement following plan.md design
+  - Verify with {config.gate} after each task
+
+  ## Rules
+  - {config.code_style} and {config.architecture}
+  - Follow CLAUDE.md and afc.config.md
+
+  ## Output
+  Return a structured summary per task (max 2000 chars total):
+  - Files changed, key decisions, issues encountered per task.")
+
+Task("Worker 2: T008, T010, T012", subagent_type: "afc:afc-impl-worker", isolation: "worktree", ...)
+```
 
-#### Swarm Worker Failure Recovery
+**Step 3 — Collect and reconcile**:
+1. Wait for all workers to return (foreground execution)
+2. Read results, mark `TaskUpdate(status: "completed")` for each finished task
+3. Call `TaskList` to check for remaining pending/blocked tasks
+4. If unblocked tasks remain → assign to new worker batch (repeat Step 2)
+5. If all tasks complete → phase done
 
-When a worker agent exits with error (non-zero return or timeout):
-1. Scan TaskList for tasks with status `in_progress` that have no active worker
-2. Reset each orphaned task: `TaskUpdate(taskId, status: "pending", owner: "")`
-3. Track retry count per task (max 2 retries)
-4. If a task fails 3 times → mark as `failed`, report to user: `"T{ID} failed after 3 attempts: {last error}"`
-5. Re-spawn replacement workers for remaining tasks
+**Worker count**: N = min(5, unblocked task count). Max 5 concurrent sub-agents per phase.
 
-> Workers should wrap their implement-complete loop in error handling so a single task failure doesn't crash the entire worker.
+**Task assignment strategy**: Round-robin by file path — each worker gets tasks targeting different files to maximize isolation. If a worker has multiple tasks, order them by `depends:` topology.
 
-> Swarm workers self-balance: fast workers claim more tasks. No batch boundaries needed.
+#### Swarm Failure Recovery
+
+When a worker agent returns an error:
+1. Identify which tasks the worker was assigned (from the pre-assigned list)
+2. Check which tasks the worker actually completed (from its result summary)
+3. Reset uncompleted tasks: `TaskUpdate(taskId, status: "pending")`
+4. Track retry count: `TaskUpdate(taskId, metadata: { retryCount: N })`
+5. If retryCount < 3 → reassign to next worker batch
+6. If retryCount >= 3 → mark as failed, report: `"T{ID} failed after 3 attempts: {last error}"`
+7. Continue with remaining tasks
+
+> Single task failure does not block the phase. The orchestrator reassigns failed tasks to subsequent batches.
 
 #### Dependency Resolution
 
-- Tasks with `depends: [T001, T002]` are registered via TaskUpdate(addBlockedBy: ["T001", "T002"])
-- When a dependency completes, blocked tasks are automatically unblocked
-- Phase order is always respected — all tasks in Phase N must complete before Phase N+1 begins
+- Tasks with `depends: [T001, T002]` are registered via `TaskUpdate(addBlockedBy: ["T001", "T002"])`
+- **Auto-unblocking is NOT guaranteed in sub-agent mode**. The orchestrator must:
+  1. After each batch completes, call `TaskList` to get current state
+  2. For each pending task, check if all `blockedBy` tasks are now completed
+  3. If all blockers resolved → task is eligible for the next batch
+- **Phase-locked registration**: Only register tasks for the current phase. Never register Phase N+1 tasks until Phase N is fully complete and its gate has passed. This prevents workers from claiming future-phase tasks.
+- **Cross-phase dependencies**: A Phase 2 task may `depends:` on a Phase 1 task. Since Phase 1 must complete before Phase 2 begins, this is always satisfied. Within the same phase, `depends:` creates intra-phase ordering.
 
 #### Phase Completion Gate (3 steps)
 
@@ -180,9 +294,37 @@ After all tasks are complete:
 ```
 
 - **Pass**: output final report
-- **Fail**: attempt to fix errors (max 3 attempts)
+- **Fail**: **Debug-based RCA** (replaces blind retry):
+  1. Execute `/afc:debug` logic inline with the CI error output as input
+  2. Debug performs RCA: error trace → data flow → hypothesis → targeted fix
+  3. Re-run `{config.ci}` after fix
+  4. If debug-fix cycle fails 3 times → report to user with diagnosis details (not a simple fix)
+  5. This produces targeted fixes instead of blind retries
+
+### 6. Implement Critic Loop
+
+After CI passes, run a convergence-based Critic Loop to verify design alignment before reporting completion.
+
+> **Always** read `${CLAUDE_PLUGIN_ROOT}/docs/critic-loop-rules.md` first and follow it.
 
-### 6. Final Output
+**Critic Loop until convergence** (safety cap: 5):
+
+- **SCOPE_ADHERENCE**: Compare `git diff` changed files against plan.md File Change List. Flag any file modified that is NOT in the plan. Flag any planned file NOT modified. Provide "M of N files match" count.
+- **ARCHITECTURE**: Validate changed files against `{config.architecture}` rules (layer boundaries, naming conventions, import paths). Provide "N of M rules checked" count.
+- **CORRECTNESS**: Cross-check implemented changes against spec.md acceptance criteria (AC). Verify each AC has corresponding code. Provide "N of M AC verified" count.
+- **Adversarial 3-perspective** (mandatory each pass):
+  - Skeptic: "Which implementation assumption is most likely wrong?"
+  - Devil's Advocate: "How could this implementation be misused or fail unexpectedly?"
+  - Edge-case Hunter: "What input would cause this implementation to fail silently?"
+  - State one failure scenario per perspective. If realistic → FAIL + fix. If unrealistic → state quantitative rationale.
+- FAIL → auto-fix, re-run `{config.ci}`, and continue. ESCALATE → pause, present options, resume after response. DEFER → record reason, mark clean.
+
+### 7. Final Output
+
+**Standalone cleanup** (if pipeline was activated in Step 0):
+```bash
+"${CLAUDE_PLUGIN_ROOT}/scripts/afc-pipeline-manage.sh" end
+```
 
 ```
 Implementation complete
@@ -204,3 +346,6 @@ Implementation complete
 - **Real-time tasks.md updates**: mark checkbox on each task completion.
 - **Mode selection is automatic**: do not manually override. Sequential for non-[P], batch for ≤5, swarm for 6+.
 - **NEVER use `run_in_background: true` on Task calls**: agents must run in foreground so results are returned before the next step.
+- **No worker self-claiming**: In swarm mode, the orchestrator pre-assigns tasks to workers. Workers do NOT call TaskList/TaskUpdate to claim tasks — this avoids last-write-wins race conditions on TaskUpdate.
+- **Phase-locked registration**: Only register (TaskCreate) the current phase's tasks. Never pre-register future phases. This is the primary mechanism for phase boundary enforcement.
+- **Orchestrator polls for unblocking**: After each batch, the orchestrator calls TaskList and manually checks blockedBy status. Do not rely on automatic unblocking outside Agent Teams mode.

package/commands/init.md

@@ -1,8 +1,12 @@
 ---
 name: afc:init
 description: "Project initial setup"
-argument-hint: "[preset: nextjs-fsd | react-spa | express-api | monorepo]"
-disable-model-invocation: true
+argument-hint: "[additional context]"
+allowed-tools:
+  - Read
+  - Write
+  - Bash
+  - Glob
 model: haiku
 ---
 
@@ -13,9 +17,7 @@ model: haiku
 
 ## Arguments
 
-- `$ARGUMENTS` — (optional) Template preset name (e.g., `nextjs-fsd`)
-  - If not specified: analyzes project structure and auto-infers
-  - If preset specified: uses `${CLAUDE_PLUGIN_ROOT}/templates/afc.config.{preset}.md`
+- `$ARGUMENTS` — (optional) Additional context or hints for project analysis
 
 ## Execution Steps
 
@@ -50,74 +52,86 @@ If `.claude/afc.config.md` already exists:
 - Ask user: "Config file already exists. Do you want to overwrite it?"
 - If declined: **abort**
 
-### 3. Preset Branch
+### 3. Analyze Project Structure
 
-#### A. Preset Specified (`$ARGUMENTS` provided)
-
-1. Verify `${CLAUDE_PLUGIN_ROOT}/templates/afc.config.{$ARGUMENTS}.md` exists
-2. If found: copy that file to `.claude/afc.config.md`
-3. If not found: print "Preset `{$ARGUMENTS}` not found. Available: {list}" then **abort**
-
-#### B. Auto-Infer (`$ARGUMENTS` not provided)
-
-Analyze project structure and auto-infer configuration:
+Analyze the project and auto-infer configuration. Use `$ARGUMENTS` as additional context if provided.
 
 **Step 1. Package Manager / Script Detection**
 - Read `package.json` → extract CI-related commands from `scripts` field
-- Determine package manager from lockfile (yarn.lock / pnpm-lock.yaml / package-lock.json)
-- Reflect detected scripts in `CI Commands` section
+- Determine package manager from lockfile:
+
+| Lockfile | Package Manager |
+|----------|----------------|
+| `pnpm-lock.yaml` | pnpm |
+| `yarn.lock` | yarn |
+| `bun.lockb` or `bun.lock` | bun |
+| `package-lock.json` | npm |
+
+- If no lockfile: check `packageManager` field in `package.json`
+- Non-JS projects: check `pyproject.toml` (Python), `Cargo.toml` (Rust), `go.mod` (Go)
 
 **Step 2. Framework Detection**
 - Determine from `package.json` dependencies/devDependencies:
-  - `next` → Next.js (App Router/Pages Router determined by presence of `app/` directory)
-  - `nuxt` → Nuxt
-  - `@sveltejs/kit` → SvelteKit
-  - `vite` → Vite
-  - etc.
+
+| Dependency | Framework |
+|-----------|-----------|
+| `next` | Next.js (App Router if `app/` dir exists, else Pages Router) |
+| `nuxt` | Nuxt |
+| `@sveltejs/kit` | SvelteKit |
+| `@remix-run/react` | Remix |
+| `astro` | Astro |
+| `@angular/core` | Angular |
+| `vite` (alone) | Vite SPA |
+| `hono` | Hono |
+| `fastify` | Fastify |
+| `express` | Express |
+
+- Non-JS: `pyproject.toml` → Django/FastAPI/Flask, `Cargo.toml` → Rust project, `go.mod` → Go project
 - Presence of `tsconfig.json` → TypeScript indicator
 
 **Step 3. Architecture Detection**
 - Analyze directory structure:
-  - `src/app/`, `src/features/`, `src/entities/`, `src/shared/` → FSD
+  - FSD: requires **at least 3** of `features/`, `entities/`, `shared/`, `widgets/`, `pages/` under `src/`
   - `src/domain/`, `src/application/`, `src/infrastructure/` → Clean Architecture
   - `src/modules/` → Modular
   - Other → Layered
-- `paths` in `tsconfig.json` → extract path_alias
-
-**Step 4. State Management Detection**
-- From dependencies:
-  - `zustand` → Zustand
-  - `@reduxjs/toolkit` → Redux Toolkit
-  - `@tanstack/react-query` → React Query
-  - `swr` → SWR
-  - `pinia` → Pinia
-
-**Step 5. Styling / Testing Detection**
-- `tailwindcss` → Tailwind CSS
-- `styled-components` → styled-components
-- `jest` / `vitest` / `playwright` → mapped respectively
-
-**Step 6. Code Style Detection**
-- Check `.eslintrc*` / `eslint.config.*` → identify lint rules
-- `strict` in `tsconfig.json` → strict_mode
+- `paths` in `tsconfig.json` → extract path alias
+
+**Step 4. State / Styling / Testing / DB Detection**
+- State management: `zustand`, `@reduxjs/toolkit`, `@tanstack/react-query`, `swr`, `pinia`, `jotai`, `recoil`
+- Styling: `tailwindcss`, `styled-components`, `@emotion/react`, `sass`, CSS Modules (check for `*.module.css`)
+- Testing: `jest`, `vitest`, `playwright`, `@testing-library/*`, `cypress`
+- Linter: `.eslintrc*` / `eslint.config.*` / `biome.json` / `biome.jsonc`
+- DB/ORM: `prisma` (check `prisma/schema.prisma`), `drizzle-orm`, `typeorm`, `@prisma/client`
+
+**Step 5. Code Style Detection**
+- Check linter config → identify key rules
+- `strict` in `tsconfig.json` → strict mode
 - Read 2-3 existing code samples to verify naming patterns
 
 ### 4. Generate Config File
 
-1. Generate config based on `${CLAUDE_PLUGIN_ROOT}/templates/afc.config.template.md`
-2. Fill in blanks with auto-inferred values
-3. For items that cannot be inferred: keep template defaults + mark with `# TODO: Adjust for your project`
-4. Save to `.claude/afc.config.md`
+Generate `.claude/afc.config.md` in **free-form markdown** format:
+
+1. **CI Commands** section: YAML code block with `ci`, `gate`, `test` keys (fixed format, scripts parse these)
+2. **Architecture** section: describe detected architecture style, layers, import rules, path aliases in free-form prose/lists
+3. **Code Style** section: describe detected language, strictness, naming conventions, lint rules in free-form prose/lists
+4. **Project Context** section: describe framework, state management, styling, testing, DB/ORM, risks, and any other relevant project characteristics in free-form prose/lists
+
+Reference `${CLAUDE_PLUGIN_ROOT}/templates/afc.config.template.md` for the section structure.
+Write sections as natural descriptions — **no YAML code blocks** except for CI Commands.
+For items that cannot be inferred: note `TODO: Adjust for your project` inline.
+Save to `.claude/afc.config.md`.
 
 ### 5. Scan Global CLAUDE.md and Detect Conflicts
 
 Read `~/.claude/CLAUDE.md` and analyze in the following order.
 
-#### Step 1. Check for Existing AFC or Legacy SELFISH Block
+#### Step 1. Check for Existing all-for-claudecode or Legacy SELFISH Block
 
 Check for presence of `<!-- AFC:START -->` or `<!-- SELFISH:START -->` marker.
 - If `<!-- AFC:START -->` found: replace with latest version (proceed to Step 3)
-- If `<!-- SELFISH:START -->` found (legacy v1.x): remove the entire `SELFISH:START` ~ `SELFISH:END` block, then proceed to inject new AFC block at Step 4. Print: `Migrated: SELFISH block → AFC block in ~/.claude/CLAUDE.md`
+- If `<!-- SELFISH:START -->` found (legacy v1.x): remove the entire `SELFISH:START` ~ `SELFISH:END` block, then proceed to inject new all-for-claudecode block at Step 4. Print: `Migrated: SELFISH block → all-for-claudecode block in ~/.claude/CLAUDE.md`
 - If neither found: proceed to Step 2
 
 #### Step 2. Conflict Pattern Scan
@@ -145,8 +159,8 @@ Find these patterns:
 
 **D. Legacy Block Detection**
 Previous versions without markers or with old branding:
-- `## All-for-ClaudeCode Auto-Trigger Rules`
-- `## All-for-ClaudeCode Integration`
+- `## all-for-claudecode Auto-Trigger Rules`
+- `## all-for-claudecode Integration`
 - `<!-- SELFISH:START -->` ~ `<!-- SELFISH:END -->` (v1.x block — should have been caught in Step 1, but double-check here)
 - `<selfish-pipeline>` / `</selfish-pipeline>` XML tags
 
@@ -170,25 +184,25 @@ Ask user:
 > "Directives overlapping with afc were found. How would you like to proceed?"
 >
 > 1. **afc-exclusive mode** — Adds afc override comments to conflicting agent routing directives.
->    Does not modify other tools' marker block contents; covers them with override rules in the AFC block.
+>    Does not modify other tools' marker block contents; covers them with override rules in the all-for-claudecode block.
 > 2. **coexistence mode** — Ignores conflicts and adds only the afc block.
 >    Since it's at the end of the file, afc directives will likely take priority, but may be non-deterministic on conflict.
 > 3. **manual cleanup** — Shows only the current conflict list and stops.
 >    User manually cleans up CLAUDE.md then runs init again.
 
 Based on choice:
-- **Option 1**: AFC block includes explicit override rules (activates `<conflict-overrides>` section from base template)
-- **Option 2**: AFC block added without overrides (base template as-is)
+- **Option 1**: all-for-claudecode block includes explicit override rules (activates `<conflict-overrides>` section from base template)
+- **Option 2**: all-for-claudecode block added without overrides (base template as-is)
 - **Option 3**: Print conflict list only and abort without modifying CLAUDE.md
 
-#### Step 4. Inject AFC Block
+#### Step 4. Inject all-for-claudecode Block
 
 **Version resolution**: Read `${CLAUDE_PLUGIN_ROOT}/package.json` and extract the `"version"` field. Use this value as `{PLUGIN_VERSION}` in the template below.
 
 Add the following block at the **very end** of the file (later-positioned directives have higher priority).
 
-Replace existing AFC block if present, otherwise append.
-If legacy block (`## All-for-ClaudeCode Auto-Trigger Rules` etc.) exists, remove it then append.
+Replace existing all-for-claudecode block if present, otherwise append.
+If legacy block (`## all-for-claudecode Auto-Trigger Rules` etc.) exists, remove it then append.
 
 ```markdown
 <!-- AFC:START -->
@@ -209,10 +223,12 @@ IMPORTANT: For requests matching the afc skill routing table below, always invok
 | Spec | `afc:spec` | spec, specification |
 | Tasks | `afc:tasks` | break down tasks, decompose |
 | Research | `afc:research` | research, investigate |
+| Ideate | `afc:ideate` | idea, brainstorm, what to build, product brief |
 | Ambiguous | `afc:clarify` | auto-triggered when requirements are unclear |
 | Full auto | `afc:auto` | do it automatically, auto-run |
 
 User-only (not auto-triggered — inform user on request):
+- `afc:launch` — inform user when release artifact generation is requested
 - `afc:doctor` — inform user when health check is requested
 - `afc:architect` — inform user when architecture review is requested
 - `afc:security` — inform user when security scan is requested
@@ -222,11 +238,11 @@ User-only (not auto-triggered — inform user on request):
 
 ## Pipeline
 
-spec → plan → tasks → implement → review → clean
+spec → plan → implement → review → clean
 
 ## Override Rules
 
-NEVER use executor, deep-executor, debugger, planner, analyst, verifier, test-engineer, code-reviewer, quality-reviewer, style-reviewer, api-reviewer, security-reviewer, performance-reviewer for tasks that a afc skill covers above. ALWAYS invoke the afc skill instead.
+NEVER use executor, deep-executor, debugger, planner, analyst, verifier, test-engineer, code-reviewer, quality-reviewer, style-reviewer, api-reviewer, security-reviewer, performance-reviewer for tasks that an afc skill covers above. ALWAYS invoke the afc skill instead.
 </afc-pipeline>
 <!-- AFC:END -->
 ```
@@ -247,7 +263,7 @@ The following rules were auto-generated to resolve conflicts:
 ### 6. Final Output
 
 ```
-All-for-ClaudeCode initialization complete
+all-for-claudecode initialization complete
 ├─ Config: .claude/afc.config.md
 ├─ Framework: {detected framework}
 ├─ Architecture: {detected style}
@@ -263,10 +279,9 @@ All-for-ClaudeCode initialization complete
 
 - **Overwrite caution**: If config file already exists, always confirm with user.
 - **Inference limits**: Auto-inference is best-effort. User may need to review and adjust.
-- **Preset path**: Presets are loaded from the `templates/` directory inside the plugin.
 - **`.claude/` directory**: Created automatically if it does not exist.
 - **Global CLAUDE.md principles**:
-  - Never modify content outside the `<!-- AFC:START/END -->` markers
+  - Never modify content outside the `<!-- AFC:START/END -->` markers (the `AFC` prefix in markers is a compact technical identifier)
   - Never modify content inside other tools' marker blocks (`<!-- *:START/END -->`)
-  - Always place the AFC block at the very end of the file (ensures priority)
+  - Always place the all-for-claudecode block at the very end of the file (ensures priority)
   - Conflict resolution is handled only via override rules (do not delete or modify other blocks)