all-for-claudecode 2.13.0 → 2.14.0

package/skills/init/SKILL.md

@@ -12,159 +12,111 @@ model: sonnet
 
 # /afc:init — Project Initial Setup
 
-> Creates project-local configuration files for the all-for-claudecode plugin.
-> Analyzes the project structure and generates config, rules, and profile.
-> This is a **project-local** operation — it only creates files under `.claude/`.
-> For global `~/.claude/CLAUDE.md` setup, use `/afc:setup` instead.
+> Creates project-local configuration files (`.claude/afc.config.md`, `.claude/rules/afc-project.md`, `.claude/afc/project-profile.md`).
+> **Project-local only** — never touches `~/.claude/CLAUDE.md`. For global routing setup use `/afc:setup`.
 
-## Important
-
-This skill is a **prompt-only skill** — there is NO `afc-init.sh` script.
-All steps below are instructions for the LLM to execute directly using its allowed tools (Read, Write, Bash, Glob).
-Do NOT attempt to run a shell script for this skill.
+## Project State (auto-loaded)
+!`ls .claude/afc.config.md .claude/rules/afc-project.md .claude/selfish.config.md .claude/.selfish-* 2>/dev/null | head -20 || echo "[no existing afc files]"`
 
 ## Arguments
 
-- `$ARGUMENTS` — (optional) Additional context or hints for project analysis
+- `$ARGUMENTS` — (optional) additional context or hints for project analysis
 
 ## Execution Steps
 
-### 1. Legacy Migration Check
-
-Before anything else, detect and migrate v1.x (selfish-pipeline) artifacts:
-
-**A. Config file migration**
-- If `.claude/selfish.config.md` exists AND `.claude/afc.config.md` does NOT exist:
-  - Rename: `mv .claude/selfish.config.md .claude/afc.config.md`
-  - Print: `Migrated: selfish.config.md → afc.config.md`
-- If both exist: print warning, keep `afc.config.md`, skip migration
+### 1. Legacy Migration (v1.x → v2.x)
 
-**B. State file migration**
-- Glob `.claude/.selfish-*` — if any found:
-  - Rename each: `.selfish-{x}` → `.afc-{x}`
-  - Print: `Migrated: {count} state files (.selfish-* → .afc-*)`
+Detect and migrate `selfish-pipeline` artifacts in one pass:
 
-**C. Artifact directory migration**
-- If `.claude/selfish/` exists AND `.claude/afc/` does NOT exist:
-  - Rename: `mv .claude/selfish .claude/afc`
-  - Print: `Migrated: .claude/selfish/ → .claude/afc/`
+- `.claude/selfish.config.md` exists, `afc.config.md` does not → rename to `afc.config.md`
+- `.claude/.selfish-*` files found → rename each to `.afc-{x}`
+- `.claude/selfish/` exists, `.claude/afc/` does not → rename to `.claude/afc/`
+- `git tag -l 'selfish/*'` → rename known patterns to `afc/` equivalent, delete the rest
 
-**D. Git tag cleanup**
-- Check `git tag -l 'selfish/*'`
-- If any found:
-  - Known patterns (`selfish/pre-*`, `selfish/phase-*`): rename to `afc/` equivalent (`git tag afc/... selfish/... && git tag -d selfish/...`)
-  - All remaining `selfish/*`: delete (`git tag -d`)
-- Print: `Migrated: {renamed} renamed, {deleted} deleted`
+Print a single migration summary line. If nothing to migrate, skip silently.
 
 ### 2. Check for Existing Config
 
-If `.claude/afc.config.md` already exists:
-- Ask user: "Config file already exists. Do you want to overwrite it?"
+If `.claude/afc.config.md` already exists and this is NOT a migration:
+- Ask user: "Config file already exists. Overwrite?"
 - If declined: **abort**
 
 ### 3. Analyze Project Structure
 
-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:
-
-| 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)
-
-> These detection rules are starting-point heuristics, not definitive. If a project uses a tool not listed here, the model should still detect it from context (e.g., `bun.lockb` for Bun, `deno.lock` for Deno). Always confirm the detected setup with the user before proceeding.
-
-**Step 2. Framework Detection**
-- Determine from `package.json` dependencies/devDependencies:
-
-| 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
-
-> This list covers common frameworks but is not exhaustive. For unlisted frameworks, infer from package.json dependencies, project structure, and configuration files. Present the detection result to the user for confirmation.
-
-**Step 3. Architecture Detection**
-- Analyze directory structure:
-  - FSD: If the project's src/ directory contains a combination of FSD-characteristic directories (`features/`, `entities/`, `shared/`, `widgets/`, `pages/`, `processes/`, `app/`), assess whether the project follows FSD principles. Variant FSD structures (e.g., using `processes/` instead of `pages/`) should also be detected. Confirm with the user if the detection is uncertain.
-  - `src/domain/`, `src/application/`, `src/infrastructure/` → Clean Architecture
-  - `src/modules/` → Modular
-  - Other → Layered
-- `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
+Use `$ARGUMENTS` as additional context. Detection heuristics are in [`reference.md`](./reference.md) — consult it for package manager, framework, architecture, and tool detection tables.
+
+1. Read `package.json` → extract CI scripts, detect package manager from lockfile
+2. Detect framework from `package.json` deps
+3. Detect architecture from directory structure + `tsconfig.json` paths
+4. Detect state/styling/testing/linter/DB tools
+5. Read 2–3 code samples to verify naming patterns
+
+> Detection is best-effort. Present results to user for confirmation before writing files.
 
 ### 4. Generate Config File
 
-Generate `.claude/afc.config.md` in **free-form markdown** format:
+Write `.claude/afc.config.md` based on template at `${CLAUDE_SKILL_DIR}/../../templates/afc.config.template.md`:
 
-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
+1. **CI Commands** — YAML block with `ci`, `gate`, `test` keys (scripts parse this; format is fixed)
+2. **Architecture** — detected pattern, layers, import rules, path aliases (free-form prose)
+3. **Code Style** — language, strictness, naming, lint rules (free-form prose)
+4. **Project Context** — framework, state, styling, testing, DB, risks (free-form prose)
 
-Reference `${CLAUDE_SKILL_DIR}/../../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`.
+No YAML blocks except CI Commands. Use `TODO: Adjust for your project` for unresolved items.
 
 ### 4.5. Generate Project Rules File
 
-Generate `.claude/rules/afc-project.md` — a concise summary of project rules that Claude Code auto-loads for all conversations and sub-agents.
-
-1. Create `.claude/rules/` directory if it does not exist
-2. If `.claude/rules/afc-project.md` already exists:
-   - If it contains `<!-- afc:auto-generated` marker: overwrite silently (auto-generated file, safe to regenerate)
-   - If it does NOT contain the marker: ask user "Project rules file exists (user-managed). Overwrite with auto-generated version?" — skip if declined
-3. Reference `${CLAUDE_SKILL_DIR}/../../templates/afc-project.template.md` for section structure
-4. Fill in from the analysis performed in Step 3:
-   - **Architecture**: pattern, key layers, import rules, path alias — concise bullet points
-   - **Code Style**: language, naming conventions, lint rules — concise bullet points
-   - **Project Context**: framework, state management, styling, testing, DB/ORM — concise bullet points
-5. Include `<!-- afc:auto-generated — do not edit manually; regenerate with /afc:init -->` as the first line
-6. Keep total length **under 30 lines** (excluding the marker comment) — rules only, no explanations
-7. Save to `.claude/rules/afc-project.md`
-8. Print: `Project rules: .claude/rules/afc-project.md (auto-loaded by Claude Code)`
+Write `.claude/rules/afc-project.md` (auto-loaded by Claude Code for all sub-agents):
+
+1. Create `.claude/rules/` if not present
+2. If file exists with `<!-- afc:auto-generated` marker → overwrite silently
+3. If file exists without marker → ask user before overwriting
+4. Use template `${CLAUDE_SKILL_DIR}/../../templates/afc-project.template.md`
+5. First line: `<!-- afc:auto-generated — do not edit manually; regenerate with /afc:init -->`
+6. Max 30 lines (excluding marker) — bullets only, no explanations
 
 ### 4.6. Generate Project Profile
 
-Generate `.claude/afc/project-profile.md` for expert consultation agents:
+Write `.claude/afc/project-profile.md` for expert consultation agents:
+
+1. Create `.claude/afc/` if not present
+2. If file already exists → skip (do not overwrite)
+3. Fill Stack/Architecture/Domain from Step 3 analysis; leave Team/Scale/Constraints as placeholders
+4. Use template `${CLAUDE_SKILL_DIR}/../../templates/project-profile.template.md`
+
+### 4.7. Update CLAUDE.md with Compact Instructions
+
+Append a `# Compact instructions` section to the project's `CLAUDE.md` (create if not present):
+
+1. Check if `CLAUDE.md` already contains `# Compact instructions` → if yes, skip silently
+2. Append the following block to `CLAUDE.md`:
+
+```markdown
+# Compact instructions
+When compacting, always preserve:
+- Active pipeline feature name and current phase
+- File Change Map from plan.md (file paths + task assignments)
+- All unresolved ESCALATE items with their options
+- context.md contents (spec summary + plan decisions + advisor results)
+- Changed files list and CI/test pass/fail status
+- Current task progress (completed/total)
+```
+
+This ensures auto-compact retains critical pipeline state.
+
+### 4.8. Recommend Context Window Configuration
+
+If the project CLAUDE.md does not already contain auto-compact configuration guidance, append:
+
+```markdown
+# Context window configuration (recommended)
+# Add to .claude/settings.json or .claude/settings.local.json:
+# { "env": { "CLAUDE_CODE_AUTO_COMPACT_WINDOW": "500000" } }
+# This treats the window as 500k for compaction — the remaining 500k is reserve headroom.
+# Combined with the compact instructions above, this gives you full control over when compaction happens.
+```
 
-1. Create `.claude/afc/` directory if it does not exist
-2. If `.claude/afc/project-profile.md` already exists: skip (do not overwrite)
-3. If not exists: generate from the detected project information using `${CLAUDE_SKILL_DIR}/../../templates/project-profile.template.md` as the structure
-   - Fill in Stack, Architecture, and Domain fields from the analysis in Step 3
-   - Leave Team, Scale, and Constraints as template placeholders for user to fill
-4. Print: `Project profile: .claude/afc/project-profile.md (review and adjust team/scale/domain fields)`
+Note: This is informational only. Do NOT modify settings.json — just add as a comment in CLAUDE.md for user awareness.
 
 ### 5. Final Output
 
@@ -173,6 +125,7 @@ all-for-claudecode project init complete
 ├─ Config: .claude/afc.config.md
 ├─ Rules: .claude/rules/afc-project.md (auto-loaded)
 ├─ Profile: .claude/afc/project-profile.md
+├─ Compact instructions: CLAUDE.md updated
 ├─ Framework: {detected framework}
 ├─ Architecture: {detected style}
 ├─ Package Manager: {detected manager}
@@ -183,8 +136,5 @@ all-for-claudecode project init complete
 
 ## Notes
 
-- **Idempotent**: safe to run multiple times. Existing config prompts for overwrite confirmation; auto-generated rules are silently regenerated.
-- **Project-local only**: this skill only creates files under `.claude/`. It never touches `~/.claude/CLAUDE.md`. For global routing setup, use `/afc:setup`.
-- **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.
-- **`.claude/` directory**: Created automatically if it does not exist.
+- **Idempotent**: existing auto-generated rules are silently regenerated; config prompts for confirmation.
+- **Inference limits**: Auto-detection is best-effort — review and adjust after generation.

package/skills/init/reference.md

@@ -0,0 +1,55 @@
+# /afc:init — Detection Reference
+
+## Package Manager Detection
+
+| Lockfile | Package Manager |
+|----------|----------------|
+| `pnpm-lock.yaml` | pnpm |
+| `yarn.lock` | yarn |
+| `bun.lockb` or `bun.lock` | bun |
+| `package-lock.json` | npm |
+| `deno.lock` | deno |
+
+Fallback: check `packageManager` field in `package.json`.
+Non-JS: `pyproject.toml` (Python), `Cargo.toml` (Rust), `go.mod` (Go).
+
+## Framework Detection
+
+Determine from `package.json` dependencies/devDependencies:
+
+| Dependency | Framework |
+|-----------|-----------|
+| `next` | Next.js (App Router if `app/` dir, 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, `go.mod` → Go.
+Unlisted: infer from project structure + confirm with user.
+
+## Architecture Detection
+
+| Pattern | Signals |
+|---------|---------|
+| FSD | `src/` contains ≥3 of: `features/`, `entities/`, `shared/`, `widgets/`, `pages/`, `app/` |
+| Clean Architecture | `src/domain/`, `src/application/`, `src/infrastructure/` |
+| Modular | `src/modules/` |
+| Layered | Default fallback |
+
+Also extract path aliases from `tsconfig.json` `paths`.
+
+## Tool Detection
+
+| Tool | Detection Signal |
+|------|-----------------|
+| State: zustand/redux/jotai/recoil/pinia/swr/react-query | `package.json` dep |
+| Styling: tailwindcss/styled-components/@emotion/sass | `package.json` dep; CSS Modules: `*.module.css` |
+| Testing: jest/vitest/playwright/cypress/@testing-library | `package.json` dep |
+| Linter: eslint/biome | `.eslintrc*`, `eslint.config.*`, `biome.json` |
+| DB/ORM: prisma/drizzle-orm/typeorm | `package.json` dep; prisma: check `prisma/schema.prisma` |

package/skills/issue/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: afc:issue
-description: "Analyze GitHub issue and create actionable document — use when the user asks to analyze a GitHub issue, understand an issue, or inspect a specific issue number"
+description: "Analyze GitHub issue and create actionable document — use when the user asks to analyze a GitHub issue, investigate a bug report, understand requirements from an issue, triage incoming requests, or inspect a specific issue number"
 argument-hint: "<GitHub issue URL, owner/repo#number, #number, or number>"
 allowed-tools:
   - Read
@@ -17,6 +17,10 @@ model: sonnet
 > Analyzes a single GitHub issue (title, body, labels, comments, attached images) and produces a structured analysis document.
 > Searches the codebase for related files and suggests the appropriate next afc skill (debug, spec, or auto).
 
+## Pre-fetch
+
+!`gh --version >/dev/null 2>&1 && gh auth status >/dev/null 2>&1 && echo "GH_OK" || echo "GH_UNAVAILABLE"`
+
 ## Arguments
 
 - `$ARGUMENTS` — (required) One of:
@@ -28,13 +32,7 @@ model: sonnet
 
 ### 1. Prerequisites Check
 
-Verify `gh` CLI is available and authenticated:
-
-```bash
-gh --version >/dev/null 2>&1 && gh auth status >/dev/null 2>&1
-```
-
-If either check fails:
+If the pre-fetch returned `GH_UNAVAILABLE`:
 - Output: `[afc:issue] Error: GitHub CLI (gh) is not installed or not authenticated. Install from https://cli.github.com/ and run 'gh auth login'.`
 - **Abort immediately.**
 
@@ -42,17 +40,9 @@ If either check fails:
 
 Determine the input format and extract owner, repo, and issue number:
 
-1. **GitHub URL** (`https://github.com/{owner}/{repo}/issues/{number}`):
-   - Extract owner, repo, number from URL path segments
-   - Set `GH_REPO_FLAG="--repo {owner}/{repo}"`
-
-2. **Cross-repo** (`{owner}/{repo}#{number}`):
-   - Split on `#` — left part is `owner/repo`, right part is number
-   - Set `GH_REPO_FLAG="--repo {owner}/{repo}"`
-
-3. **Local number** (`123` or `#123`):
-   - Strip leading `#` if present
-   - Set `GH_REPO_FLAG=""` (use current repo from git remote)
+1. **GitHub URL** (`https://github.com/{owner}/{repo}/issues/{number}`): extract from path, set `GH_REPO_FLAG="--repo {owner}/{repo}"`
+2. **Cross-repo** (`{owner}/{repo}#{number}`): split on `#`, set `GH_REPO_FLAG="--repo {owner}/{repo}"`
+3. **Local number** (`123` or `#123`): strip leading `#`, set `GH_REPO_FLAG=""` (use current repo from git remote)
 
 ### 3. Collect Issue Data
 
@@ -60,90 +50,79 @@ Determine the input format and extract owner, repo, and issue number:
 gh issue view {number} {GH_REPO_FLAG} --json number,title,body,labels,author,comments,createdAt,state,url
 ```
 
-If the command fails:
-- `Issue #{number} not found` → output error and **abort**
-- Other errors → output the gh error message and **abort**
+If the command fails → output error and **abort**.
 
-Parse the JSON response and extract:
-- `TITLE`, `BODY`, `LABELS`, `AUTHOR`, `COMMENTS`, `CREATED_AT`, `STATE`, `URL`
+Parse and extract: `TITLE`, `BODY`, `LABELS`, `AUTHOR`, `COMMENTS`, `CREATED_AT`, `STATE`, `URL`.
 
 ### 4. Analyze Attached Images
 
-Extract image URLs from the issue body:
-- Markdown images: `![alt]({url})`
-- HTML images: `<img src="{url}">`
-- **Skip** images inside code blocks (` ``` ` fences)
-
-For each extracted image URL:
-1. Attempt to fetch with WebFetch
-2. If successful: analyze the image content (error messages, UI screenshots, console output, stack traces)
-3. If fetch fails: record `[Image unavailable: {url}]`
+Extract image URLs from the issue body (skip images inside code block fences):
+- Markdown: `![alt]({url})`
+- HTML: `<img src="{url}">`
 
-Tag all image analysis results with `[Image Analysis]` to indicate AI interpretation.
+For each URL: fetch with WebFetch, analyze content (error messages, UI screenshots, console output, stack traces), tag results with `[Image Analysis]`. Record failures as `[Image unavailable: {url}]`.
 
-If no images found: note `No attached media found.`
+If no images: note `No attached media found.`
 
 ### 5. Analyze Comments
 
-If comments exist:
-- If more than 20 comments: analyze only the **most recent 20** and note `"Analyzed 20 of {N} comments (most recent)"`
-- Extract additional context from comments: reproduction steps, error logs, workarounds, maintainer responses, related issue/PR references
+If more than 20 comments: analyze only the **most recent 20** and note `"Analyzed 20 of {N} comments (most recent)"`.
+
+Extract: reproduction steps, error logs, workarounds, maintainer responses, related issue/PR references.
 
 ### 6. Search Codebase
 
-Extract keywords from the issue title, body, and comments:
+Extract keywords from title, body, and comments:
 - Error messages (quoted strings, stack trace patterns)
-- Function/class/module names
-- File paths mentioned
-- Technical terms specific to the project
+- Function/class/module names, file paths, project-specific technical terms
 
-For each keyword, search the codebase using Grep and Glob:
-- Record matching files with line numbers and relevance reason
-- If no matches found: note `No related code found in current codebase.`
+Search with Grep and Glob. Record matching files with line numbers and relevance reason. If no matches: `No related code found in current codebase.`
 
 ### 7. Classify Issue
 
-Based on the analysis, classify the issue:
+**Type** — choose the strongest matching signal:
 
-| Signal | Classification |
-|--------|---------------|
-| Error messages, stack traces, reproduction steps, "doesn't work", "broken" | **Bug Report** |
+| Signal | Type |
+|--------|------|
+| Error messages, stack traces, "broken", "doesn't work", reproduction steps | **Bug Report** |
 | "Add", "support", "new feature", "would be nice", "enhancement" | **Feature Request** |
 | "How to", "is it possible", "what is", "documentation" | **Question** |
 | "Improve", "refactor", "better", "optimize", existing feature modification | **Enhancement** |
 
-Assess severity:
-- **Critical**: Data loss, security vulnerability, crash, blocks usage
-- **High**: Major functionality broken, no workaround
-- **Medium**: Functionality issue with workaround, or significant UX problem
-- **Low**: Minor issue, cosmetic, or nice-to-have improvement
+**Severity** — based on production impact, not code location:
 
-Estimate scope:
-- **Small** (1-2 files): Typo, config change, simple bug fix
-- **Medium** (3-5 files): Feature addition, moderate refactor
-- **Large** (6+ files): Cross-cutting concern, architectural change
+| Level | Criteria |
+|-------|---------|
+| **Critical** | Data loss, security vulnerability, application crash, or complete feature unavailability with no workaround |
+| **High** | Core functionality broken; workaround exists but is painful or undocumented |
+| **Medium** | Non-critical functionality impacted; reasonable workaround available, or significant UX degradation |
+| **Low** | Cosmetic issue, minor UX friction, or improvement with no functional impact |
 
-### 8. Determine Next Step
+**Estimated Scope:**
 
-Based on classification:
+| Level | Criteria |
+|-------|---------|
+| **Small** | 1–2 files — typo, config change, isolated bug fix |
+| **Medium** | 3–5 files — feature addition, moderate refactor |
+| **Large** | 6+ files — cross-cutting concern, architectural change |
+
+### 8. Determine Next Step
 
 | Type | Suggested Next Step |
 |------|-------------------|
 | Bug Report | `/afc:debug "{issue title summary}"` |
 | Feature Request | `/afc:spec "{feature description}"` or `/afc:auto "{feature description}"` |
-| Question | `Reply to issue — provide answer or point to documentation` |
+| Question | Reply to issue — provide answer or point to documentation |
 | Enhancement | `/afc:spec "{enhancement description}"` |
-| Insufficient info | `Reply to issue — request: {specific missing information}` |
+| Insufficient info | Reply to issue — request: {specific missing information} |
 
 ### 9. Save Analysis Document
 
-Create directory if needed:
 ```bash
 mkdir -p .claude/afc/issues
 ```
 
-Check for existing analysis:
-- If `.claude/afc/issues/{number}-*.md` exists → ask user: "Overwrite existing analysis for issue #{number}?"
+If `.claude/afc/issues/{number}-*.md` exists → ask user: "Overwrite existing analysis for issue #{number}?"
 
 Generate slug from title: lowercase, replace non-alphanumeric with `-`, truncate to 40 chars.
 
@@ -160,24 +139,20 @@ Write to `.claude/afc/issues/{number}-{slug}.md`:
 
 ## Summary
 
-{2-4 sentence summary of what the issue is about and what it requires.
-Not just a restatement of the title — include context from body, comments, and images.}
+{2-4 sentence summary including context from body, comments, and images — not just a restatement of the title.}
 
 ## Attached Media Analysis
 
 {If images exist:}
 > [Image Analysis] Below is AI interpretation of attached media.
 
-- **Image 1** ({filename or "screenshot"}): {description of what the image shows — error messages, UI state, console output}
-- **Image 2**: ...
+- **Image 1** ({filename or "screenshot"}): {description}
 
 {If no images:}
 No attached media found.
 
 ## Codebase Impact
 
-{If related files found:}
-- `{path}:{line}` — {why this file is related}
 - `{path}:{line}` — {why this file is related}
 
 {If no related files:}
@@ -209,8 +184,8 @@ Issue analyzed
 
 ## Notes
 
-- **Read-only**: This skill does not modify any code. It only creates an analysis document.
-- **Image analysis is best-effort**: AI interpretation of screenshots may not be 100% accurate. The `[Image Analysis]` tag makes this explicit.
-- **Not part of auto pipeline**: This is a standalone skill invoked manually.
-- **Relationship to triage**: `afc:triage` handles bulk PR/issue analysis. `afc:issue` handles deep individual issue analysis. They are complementary.
-- **Comment limit**: Max 20 comments analyzed to keep context manageable. Most recent comments are prioritized as they often contain the most relevant information.
+- **Read-only**: Does not modify any code. Only creates an analysis document.
+- **Image analysis is best-effort**: AI interpretation of screenshots may be imprecise — `[Image Analysis]` tag makes this explicit.
+- **Not part of auto pipeline**: Standalone skill, invoked manually.
+- **Relationship to triage**: `afc:triage` handles bulk analysis; `afc:issue` handles deep individual analysis.
+- **Comment limit**: Max 20 comments analyzed (most recent prioritized).

package/skills/launch/SKILL.md

@@ -25,6 +25,11 @@ model: sonnet
   - `"auto"` — auto-detects version from package.json/Cargo.toml/pyproject.toml
   - Not specified: prompts for version
 
+## Git Context (auto-loaded)
+
+!`git describe --tags --abbrev=0 2>/dev/null || echo "[NO_TAGS]"`
+!`git log $(git describe --tags --abbrev=0 2>/dev/null || echo "")..HEAD --pretty=format:"%h %s" --no-merges 2>/dev/null || git log --pretty=format:"%h %s" --no-merges`
+
 ## Execution Steps
 
 ### 1. Detect Project Context

package/skills/learner/SKILL.md

@@ -73,31 +73,7 @@ For each candidate rule:
 
 ### 4. Present Suggestions
 
-Show clustered suggestions to user, most impactful first. Present the most impactful suggestions first. If there are many high-confidence patterns, present them all rather than artificially capping. If most are low-confidence, present fewer. Let relevance and confidence drive the count, not a fixed limit.
-
-```markdown
-## Learned Patterns ({N} pending, showing top {M})
-
-### 1. [Style] Prefer const over let
-- Detected: 3 times across 2 sessions
-- Confidence: HIGH
-- Proposed rule:
-  ```
-  Prefer `const` for variable declarations. Use `let` only when reassignment is required.
-  ```
-- Target: `.claude/rules/afc-learned.md` (universal)
-- [Approve] [Edit] [Skip] [Reject permanently]
-
-### 2. [Naming] No default exports in React components
-- Detected: 2 times (pipeline: auth-feature)
-- Confidence: HIGH
-- Proposed rule:
-  ```
-  In React component files (*.tsx), use named exports only. Avoid default exports.
-  ```
-- Target: `.claude/rules/afc-learned.md` (universal — scope expressed in prose)
-- [Approve] [Edit] [Skip] [Reject permanently]
-```
+Show clustered suggestions to user, most impactful first. Let relevance and confidence drive the count, not a fixed limit. See [suggestion-format.md](suggestion-format.md) for the presentation template.
 
 Wait for user response on each suggestion.
 

package/skills/learner/suggestion-format.md

@@ -0,0 +1,49 @@
+# Suggestion Presentation Format
+
+Present each clustered pattern suggestion in this format:
+
+```markdown
+## Learned Patterns ({N} pending, showing top {M})
+
+### 1. [{Rule type}] {Short title}
+- Detected: {count} times across {sessions} sessions
+- Confidence: {HIGH / MEDIUM / LOW}
+- Proposed rule:
+  ```
+  {Concise, actionable rule text}
+  ```
+- Target: `.claude/rules/afc-learned.md` ({scope: universal / file-type-specific})
+- [Approve] [Edit] [Skip] [Reject permanently]
+```
+
+## Example
+
+```markdown
+### 1. [Style] Prefer const over let
+- Detected: 3 times across 2 sessions
+- Confidence: HIGH
+- Proposed rule:
+  ```
+  Prefer `const` for variable declarations. Use `let` only when reassignment is required.
+  ```
+- Target: `.claude/rules/afc-learned.md` (universal)
+- [Approve] [Edit] [Skip] [Reject permanently]
+
+### 2. [Naming] No default exports in React components
+- Detected: 2 times (pipeline: auth-feature)
+- Confidence: HIGH
+- Proposed rule:
+  ```
+  In React component files (*.tsx), use named exports only. Avoid default exports.
+  ```
+- Target: `.claude/rules/afc-learned.md` (universal — scope expressed in prose)
+- [Approve] [Edit] [Skip] [Reject permanently]
+```
+
+## User Response Handling
+
+Wait for user response on each suggestion:
+- **Approve**: promote to rules file
+- **Edit**: user modifies the rule text, then promote
+- **Skip**: remove from queue, do not promote
+- **Reject permanently**: remove from queue + add to suppression list

package/skills/plan/SKILL.md

@@ -139,11 +139,7 @@ Run the critic loop until convergence. Safety cap: 5 passes.
 4. **Constraint propagation**: every item in spec.md `Constraints` section is addressed in Risk & Mitigation or Implementation Context `Must NOT`. Report: `{M}/{N} constraints propagated`.
 5. **Acceptance anchor alignment**: Implementation Context `Acceptance Anchors` faithfully reflect spec.md's acceptance scenarios (no omissions, no misinterpretations).
 
-**On FAIL**: auto-fix and continue to next pass.
-**On ESCALATE**: pause, present options to user, apply choice, resume.
-**On DEFER**: record reason, mark criterion clean, continue.
-**On CONVERGE**: `✓ Critic converged ({N} passes, {M} fixes, {E} escalations)`
-**On SAFETY CAP**: `⚠ Critic safety cap ({N} passes). Review recommended.`
+Follow verdict handling and output format per `docs/critic-loop-rules.md`.
 
 ### 5.5. ADR Recording (optional)