all-for-claudecode 2.1.0 → 2.2.1

package/commands/ideate.md

@@ -0,0 +1,191 @@
+---
+name: afc:ideate
+description: "Explore and structure a product idea"
+argument-hint: "[rough idea or problem statement]"
+allowed-tools:
+  - Read
+  - Write
+  - Glob
+  - Grep
+  - WebSearch
+  - WebFetch
+model: sonnet
+---
+
+# /afc:ideate — Explore and Structure a Product Idea
+
+> Transforms a rough idea, problem statement, or inspiration into a structured product brief (ideate.md).
+> This is a **pre-spec exploration** tool — use it when you don't yet know exactly what to build.
+> The output feeds directly into `/afc:spec` as input.
+
+## Relationship to Other Commands
+
+```
+afc:ideate (what to build?) → afc:spec (how to specify it) → afc:plan → afc:implement → ...
+```
+
+- **ideate** = "I have an idea but haven't decided the scope, audience, or approach yet"
+- **spec** = "I know what to build and need a formal specification"
+- ideate is **never** part of the auto pipeline — it's a standalone exploration tool
+
+## Arguments
+
+- `$ARGUMENTS` — (required) One of:
+  - Rough idea: `"real-time collaborative whiteboard"`
+  - Problem statement: `"users keep losing unsaved work when the browser crashes"`
+  - Reference URL: `"https://example.com/competitor-product"` (fetched and analyzed)
+  - File path: `"./meeting-notes.md"` (read and extracted)
+
+## Execution Steps
+
+### 1. Parse Input
+
+Determine the input type and extract raw content:
+
+1. **If `$ARGUMENTS` starts with `http://` or `https://`**:
+   - Fetch content via WebFetch
+   - Extract: product name, key features, target audience, value proposition
+   - Frame as: "Build something similar/better that addresses {gap}"
+
+2. **If `$ARGUMENTS` is a file path** (contains `/` or ends with `.md`/`.txt`):
+   - Read the file content
+   - Extract: action items, feature requests, pain points, user feedback
+   - Frame as: structured requirements from raw notes
+
+3. **Otherwise**: treat as a natural language idea/problem statement
+
+### 2. Market & Context Research
+
+Perform lightweight research to ground the idea in reality:
+
+1. **Competitive landscape** (WebSearch):
+   - Search: `"{core concept}" tool OR app OR service {current year}`
+   - Identify 3-5 existing solutions
+   - Note: what they do well, what gaps exist
+
+2. **Technology feasibility** (WebSearch, optional):
+   - If the idea involves unfamiliar tech: search for current state and constraints
+   - Tag findings with `[RESEARCHED]`
+
+3. **Target user validation**:
+   - Who would use this? Why? What's their current workaround?
+
+### 3. Explore Existing Codebase (if applicable)
+
+If running inside a project with source code:
+
+1. Check if any related functionality already exists (Glob/Grep)
+2. If found: note as "Existing foundation" — ideate around extending, not rebuilding
+3. If no codebase or greenfield: skip this step
+
+### 4. Write Product Brief
+
+Create `.claude/afc/ideate.md` (overwrite if exists after confirmation):
+
+```markdown
+# Product Brief: {idea name}
+
+> Created: {YYYY-MM-DD}
+> Status: Exploration
+> Input: {original $ARGUMENTS summary}
+
+## Problem Statement
+{What problem does this solve? Who has this problem? How painful is it?}
+{2-3 sentences, specific and measurable where possible}
+
+## Target Users
+
+### Primary Persona
+- **Who**: {role/demographic}
+- **Context**: {when/where they encounter the problem}
+- **Current workaround**: {what they do today}
+- **Pain level**: {High/Medium/Low — with justification}
+
+### Secondary Persona (if applicable)
+{same format}
+
+## Value Proposition
+{One sentence: "For {persona} who {need}, this {product} provides {benefit} unlike {alternatives}"}
+
+## Core Features (MoSCoW)
+
+### Must Have (MVP)
+1. {feature} — {why it's essential}
+2. {feature} — {why it's essential}
+3. {feature} — {why it's essential}
+
+### Should Have (v1.1)
+1. {feature} — {value added}
+
+### Could Have (future)
+1. {feature} — {potential value}
+
+### Won't Have (explicit scope cut)
+1. {feature} — {why excluded}
+
+## User Journey (primary flow)
+
+```mermaid
+graph LR
+    A[Entry Point] --> B[Core Action]
+    B --> C[Key Decision]
+    C --> D[Success State]
+    C --> E[Error/Edge Case]
+```
+
+{Describe the 3-5 step primary user flow in plain text as well}
+
+## Competitive Analysis
+
+| Aspect | {Competitor 1} | {Competitor 2} | This Product |
+|--------|---------------|---------------|-------------|
+| Core strength | {X} | {X} | {X} |
+| Key weakness | {X} | {X} | {X} |
+| Pricing | {X} | {X} | {X} |
+| Differentiator | — | — | {what makes this unique} |
+
+## Open Questions
+- {Decision that needs user input before proceeding to spec}
+- {Technical uncertainty that affects scope}
+- {Business assumption that should be validated}
+
+## Suggested Next Steps
+1. Resolve Open Questions above
+2. Run `/afc:spec {refined feature description}` to formalize as a specification
+3. {Any other recommended action}
+
+## Research Sources
+- [{source title}]({url}) — {what was learned}
+```
+
+### 5. Interactive Refinement
+
+After writing the initial brief, present key decisions to the user:
+
+1. **Scope check**: "The MVP has {N} features. Does this feel right, or should we cut/add?"
+2. **Persona validation**: "Is {persona} the right primary user?"
+3. **Open questions**: present the top 2 unresolved questions via AskUserQuestion
+
+Apply user feedback directly into ideate.md.
+
+### 6. Final Output
+
+```
+Ideation complete
+├─ .claude/afc/ideate.md
+├─ Personas: {count}
+├─ MVP features: {count}
+├─ Competitors analyzed: {count}
+├─ Open questions: {count}
+├─ Research sources: {count}
+└─ Next step: /afc:spec "{suggested feature description}"
+```
+
+## Notes
+
+- **This is exploration, not specification**. Do not write acceptance criteria, system requirements, or FR/NFR numbers — that belongs in `/afc:spec`.
+- **ideate.md lives at `.claude/afc/ideate.md`** (project-level, not feature-level) because ideation may span multiple features.
+- **Not part of the auto pipeline**. ideate is manually invoked when a developer needs to think through an idea before committing to a spec.
+- **One ideate.md per project** — overwrite on re-run (with confirmation). If you need to preserve a previous ideation, rename it first.
+- **Competitive analysis is lightweight** — 3-5 competitors max. Deep market research is not the goal; grounding the idea in reality is.
+- **Mermaid diagrams are optional** — only include if the user flow benefits from visualization. Do not force diagrams for simple concepts.

package/commands/implement.md

@@ -94,7 +94,7 @@ If tasks.md already exists (e.g., from standalone `/afc:tasks` run): use as-is,
    - Identify already-completed `[x]` tasks
 2. Load **Implementation Context** section from plan.md (used in sub-agent prompts)
 
-### 1.5. Retrospective Check
+### 1.7. 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)?
@@ -141,7 +141,7 @@ TaskUpdate({ taskId: "T004", addBlockedBy: ["T002"] })  // if T004 depends on T0
 
 **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-impl-worker",
+Task("T003: Create UserService", subagent_type: "afc:afc-impl-worker",
   isolation: "worktree",
   prompt: "Implement the following task:
 
@@ -164,7 +164,7 @@ Task("T003: Create UserService", subagent_type: "afc-impl-worker",
   - Key decisions: {any design choices made}
   - Issues: {blockers or concerns, if any}
   - Verification: {config.gate} result")
-Task("T004: Create AuthService", subagent_type: "afc-impl-worker", isolation: "worktree", ...)
+Task("T004: Create AuthService", subagent_type: "afc:afc-impl-worker", isolation: "worktree", ...)
 ```
 
 **Step 3 — Collect results and advance**: After all parallel agents return:
@@ -201,7 +201,7 @@ TaskUpdate({ taskId: "T008", addBlockedBy: ["T006"] })  // if dependency exists
 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-impl-worker",
+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}`
@@ -224,7 +224,7 @@ Task("Worker 1: T007, T009, T011", subagent_type: "afc-impl-worker",
   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-impl-worker", isolation: "worktree", ...)
+Task("Worker 2: T008, T010, T012", subagent_type: "afc:afc-impl-worker", isolation: "worktree", ...)
 ```
 
 **Step 3 — Collect and reconcile**:

package/commands/init.md

@@ -1,8 +1,7 @@
 ---
 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
@@ -18,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
 
@@ -55,64 +52,76 @@ 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
 
@@ -127,14 +136,15 @@ Check for presence of `<!-- AFC:START -->` or `<!-- SELFISH:START -->` marker.
 
 #### Step 2. Conflict Pattern Scan
 
-Search the entire CLAUDE.md for the patterns below. **Include content inside marker blocks (`<!-- *:START -->` ~ `<!-- *:END -->`) in the scan.**
+Search CLAUDE.md for the patterns below. **IMPORTANT: EXCLUDE content inside any marker blocks (`<!-- *:START -->` ~ `<!-- *:END -->`). Only scan unguarded content outside marker blocks.** Other tools (OMC, etc.) manage their own blocks — their internal agent names are not conflicts.
 
 **A. Marker Block Detection**
 - Regex: `<!-- ([A-Z0-9_-]+):START -->` ~ `<!-- \1:END -->`
 - Record all found block names and line ranges
+- **Strip these ranges from the scan target** — only scan lines NOT inside any marker block
 
 **B. Agent Routing Conflict Detection**
-Find directives containing these keywords:
+In the **unguarded** (non-marker-block) content only, find directives containing these keywords:
 - `executor`, `deep-executor` — conflicts with afc:implement
 - `code-reviewer`, `quality-reviewer`, `style-reviewer`, `api-reviewer`, `security-reviewer`, `performance-reviewer` — conflicts with afc:review
 - `debugger` (in agent routing context) — conflicts with afc:debug
@@ -143,7 +153,7 @@ Find directives containing these keywords:
 - `test-engineer` — conflicts with afc:test
 
 **C. Skill Routing Conflict Detection**
-Find these patterns:
+In the **unguarded** content only, find these patterns:
 - Another tool's skill trigger table (e.g., tables like `| situation | skill |`)
 - `delegate to`, `route to`, `always use` + agent name combinations
 - Directives related to `auto-trigger`, `intent detection`, `intent-based routing`
@@ -214,10 +224,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
@@ -268,7 +280,6 @@ 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 (the `AFC` prefix in markers is a compact technical identifier)

package/commands/launch.md

@@ -0,0 +1,181 @@
+---
+name: afc:launch
+description: "Generate release artifacts"
+argument-hint: "[version tag or 'auto']"
+allowed-tools:
+  - Read
+  - Write
+  - Edit
+  - Bash
+  - Glob
+  - Grep
+model: sonnet
+---
+
+# /afc:launch — Generate Release Artifacts
+
+> Generates release artifacts (CHANGELOG entry, README updates, GitHub Release notes) from git history and optional spec context.
+> This is a **standalone utility** — not part of the auto pipeline.
+> Works with or without a prior afc pipeline run.
+
+## Arguments
+
+- `$ARGUMENTS` — (optional) One of:
+  - Version tag: `"v2.2.0"` — uses this as the release version
+  - `"auto"` — auto-detects version from package.json/Cargo.toml/pyproject.toml
+  - Not specified: prompts for version
+
+## Execution Steps
+
+### 1. Detect Project Context
+
+1. **Version detection**:
+   - If `$ARGUMENTS` is a version string (matches `v?\d+\.\d+\.\d+`): use it
+   - If `$ARGUMENTS` = `"auto"`: read version from package.json → Cargo.toml → pyproject.toml → setup.py (first found)
+   - If not specified: check package.json etc. for current version, present to user, confirm or override
+
+2. **Previous version detection**:
+   ```bash
+   git describe --tags --abbrev=0 2>/dev/null || echo "none"
+   ```
+   - If a previous tag exists: diff range = `{previous_tag}..HEAD`
+   - If no tags: diff range = all commits (warn user: "No previous release tag found. Including all history.")
+
+3. **Changelog detection**:
+   - Check for existing: `CHANGELOG.md` → `CHANGES.md` → `HISTORY.md`
+   - If found: will prepend new entry
+   - If not found: will create `CHANGELOG.md`
+
+### 2. Gather Change Context
+
+Collect all available context for high-quality release notes:
+
+1. **Git history** (required):
+   ```bash
+   git log {previous_tag}..HEAD --pretty=format:"%h %s" --no-merges
+   ```
+
+2. **Changed files summary** (required):
+   ```bash
+   git diff --stat {previous_tag}..HEAD
+   ```
+
+3. **Spec context** (optional — enhances quality):
+   - Glob `.claude/afc/specs/*/spec.md` — if any exist, read Overview and User Stories sections
+   - This provides **intent context** that raw commit messages lack
+   - If no specs found: rely on git history only (still produces good output)
+
+4. **Review context** (optional):
+   - Glob `.claude/afc/memory/reviews/*` — if any exist from this version cycle, note key findings
+   - Skip if not found
+
+5. **Breaking change detection**:
+   - Grep commit messages for: `BREAKING`, `breaking change`, `!:` (conventional commits)
+   - Grep diffs for: deleted public exports, renamed public APIs, changed function signatures
+   - Flag any findings as breaking changes in the output
+
+### 3. Generate CHANGELOG Entry
+
+Prepend a new entry to the changelog file:
+
+1. **Duplicate check**: Grep the changelog for `## [{version}]`. If an entry for this version already exists:
+   - Ask user: "CHANGELOG already has an entry for {version}. (1) Overwrite (2) Abort"
+   - If overwrite: replace the existing entry (from `## [{version}]` to the next `## [` line)
+   - If abort: skip CHANGELOG generation
+
+2. Follow the existing format if one exists; otherwise use [Keep a Changelog](https://keepachangelog.com/) format:
+
+```markdown
+## [{version}] - {YYYY-MM-DD}
+
+### Added
+- {new features, described from user perspective}
+
+### Changed
+- {modifications to existing functionality}
+
+### Fixed
+- {bug fixes}
+
+### Removed
+- {removed features or deprecated items}
+
+### Breaking Changes
+- {if any — empty section omitted}
+```
+
+**Quality rules**:
+- Write from **user perspective**, not developer perspective ("Add dark mode support" not "Add ThemeProvider component")
+- Group related changes into single entries (don't list every file)
+- If spec context is available: use feature names from specs, not commit message fragments
+- Omit empty sections (if no fixes, don't include "### Fixed")
+
+### 4. Update README (conditional)
+
+Only update README if meaningful changes warrant it:
+
+1. **Check triggers**:
+   - New CLI commands or API endpoints added?
+   - Installation process changed?
+   - New dependencies or requirements?
+   - Feature that users need to know about?
+
+2. **If no triggers match**: skip README update entirely (print: "README: no updates needed")
+
+3. **If triggers match**: read current README, identify the relevant section, apply minimal targeted edit
+   - Do NOT rewrite the entire README
+   - Do NOT add badges, shields, or decorative elements
+   - Only update sections directly affected by changes
+
+### 5. Generate GitHub Release Notes
+
+Create `.claude/afc/release-notes.md` (draft for `gh release create`):
+
+```markdown
+# {version}
+
+{2-3 sentence summary of this release — what's the headline?}
+
+## Highlights
+
+- {top 1-3 user-facing changes, expanded with context}
+
+## What's Changed
+
+{CHANGELOG entry content, reformatted for GitHub}
+
+## Breaking Changes
+
+{if any — clear migration instructions}
+
+**Full Changelog**: {previous_tag}...{version}
+```
+
+### 6. Present Summary and Next Steps
+
+```
+Release artifacts generated: {version}
+├─ CHANGELOG.md: entry prepended ({N} items across {M} categories)
+├─ README.md: {updated section / no updates needed}
+├─ .claude/afc/release-notes.md: draft created
+├─ Breaking changes: {count or "none"}
+├─ Commits included: {N} (since {previous_tag})
+└─ Specs referenced: {N or "none (git-only mode)"}
+
+Next steps:
+  git add CHANGELOG.md README.md
+  git commit -m "docs: prepare release {version}"
+  git tag {version}
+  gh release create {version} --notes-file .claude/afc/release-notes.md
+```
+
+**Do NOT execute these commands automatically.** Present them for the user to review and run.
+
+## Notes
+
+- **Not part of the auto pipeline**. Launch is a standalone utility invoked when you're ready to release, not after every feature.
+- **Non-destructive**: only creates/edits CHANGELOG and README (conditionally). Does not push, tag, or create releases automatically.
+- **Git history is the source of truth**. Spec context enhances quality but is never required.
+- **Conventional Commits awareness**: if the project uses conventional commits (`feat:`, `fix:`, `chore:`), the generated CHANGELOG respects those categories.
+- **Idempotent**: running launch twice with the same version overwrites the release-notes.md draft and re-generates the CHANGELOG entry (warns before overwriting).
+- **No scope for `clean`**: release-notes.md in `.claude/afc/` is a draft file. The user decides whether to keep or delete it after the release.

package/commands/plan.md

@@ -109,13 +109,7 @@ Create `.claude/afc/specs/{feature}/plan.md`. **Must** follow the structure belo
 {summary of core requirements from spec + technical approach, 3-5 sentences}
 
 ## Technical Context
-{summary of project settings loaded from afc.config.md}
-- **Language**: {config.code_style.language}
-- **Framework**: {config.framework.name}
-- **State**: {config.state_management summary}
-- **Architecture**: {config.architecture.style}
-- **Styling**: {config.styling.framework}
-- **Testing**: {config.testing.framework}
+{Summarize key project settings from afc.config.md — Architecture, Code Style, and Project Context sections}
 - **Constraints**: {constraints extracted from spec}
 
 ## Principles Check

package/commands/principles.md

@@ -2,7 +2,6 @@
 name: afc:principles
 description: "Manage project principles"
 argument-hint: "[action: add, remove, init]"
-disable-model-invocation: true
 allowed-tools:
   - Read
   - Write

package/commands/resume.md

@@ -2,7 +2,6 @@
 name: afc:resume
 description: "Restore session"
 argument-hint: "[no arguments]"
-disable-model-invocation: true
 model: haiku
 allowed-tools:
   - Read
@@ -23,8 +22,8 @@ allowed-tools:
 ### 1. Load Checkpoint
 
 Read `.claude/afc/memory/checkpoint.md`:
-- If not found: output "No saved checkpoint found." then **stop**
-- If found: parse the full contents
+- If not found: output "No saved checkpoint found. Use `/afc:checkpoint` to create one, or checkpoints are created automatically on context compaction." then **stop**
+- If found: parse the full contents (extract branch, commit hash, pipeline feature, task progress, modified files)
 
 ### 2. Validate Environment
 
@@ -33,7 +32,10 @@ Compare the checkpoint state against the current environment:
 1. **Branch check**: Does the checkpoint branch match the current branch?
    - If different: warn + suggest switching
 2. **File state**: Have any files changed since the checkpoint?
-   - Check for new commits with `git log {checkpoint hash}..HEAD --oneline`
+   - First verify HEAD exists: `git rev-parse --verify HEAD 2>/dev/null`
+     - If HEAD does not exist (empty repo / no commits): report "No commits yet — cannot check changes since checkpoint." and skip this check
+   - If checkpoint hash is present and non-empty: `git log {checkpoint hash}..HEAD --oneline`
+   - If checkpoint hash is empty or missing: report "Checkpoint has no git reference — cannot diff." and skip this check
 3. **Feature directory**: Does .claude/afc/specs/{feature}/ still exist?
 
 ### 3. Report State

package/commands/review.md

@@ -127,12 +127,12 @@ For each changed file, examine from the following perspectives:
 - Startup/response latency concerns
 - Unnecessary computation or redundant operations
 - Resource management (memory, file handles, connections, subprocesses)
-- {config.framework}-specific performance patterns
+- Framework-specific performance patterns (from Project Context)
 
 #### E. Project Pattern Compliance
 - {config.code_style} naming and structure conventions
 - {config.architecture} layer rules and boundaries
-- {config.framework}-specific idioms and best practices
+- Framework-specific idioms and best practices (from Project Context)
 
 #### F. Reusability
 - Duplicate or near-duplicate logic across files