all-for-claudecode 2.0.0 → 2.2.0

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

@@ -2,6 +2,13 @@
 name: afc:plan
 description: "Implementation design"
 argument-hint: "[additional context or constraints]"
+allowed-tools:
+  - Read
+  - Glob
+  - Grep
+  - Write
+  - WebSearch
+  - WebFetch
 model: sonnet
 ---
 # /afc:plan — Implementation Design
@@ -19,7 +26,12 @@ model: sonnet
 
 ## 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
 
@@ -32,6 +44,10 @@ model: sonnet
 3. Read full **spec.md**
 4. Read **.claude/afc/memory/principles.md** (if present)
 5. Read **CLAUDE.md** project context
+6. **Memory loading** (skip gracefully if directories are empty or absent):
+   - **Quality history**: if `.claude/afc/memory/quality-history/*.json` exists, load recent entries and display trend: "Last {N} pipelines: avg critic_fixes {X}, avg ci_failures {Y}". Use trends to inform risk assessment.
+   - **Decisions**: if `.claude/afc/memory/decisions/` exists, load ADR entries and check for conflicts with the current feature's design direction.
+   - **Reviews**: if `.claude/afc/memory/reviews/` exists, scan for recurring finding patterns (same file/category appearing in 2+ reviews). Flag as known risk areas.
 
 ### 2. Clarification Check
 
@@ -78,6 +94,10 @@ Collect all results and record in `.claude/afc/specs/{feature}/research.md`:
 **Source**: {URL or file path}
 ```
 
+#### Step 4: Persist (long-term memory)
+Copy research findings to `.claude/afc/memory/research/{feature}.md` for cross-session reuse.
+Future pipelines can reference prior research to avoid redundant investigation.
+
 ### 4. Phase 1 — Write Design
 
 Create `.claude/afc/specs/{feature}/plan.md`. **Must** follow the structure below:
@@ -89,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
@@ -111,17 +125,32 @@ Create `.claude/afc/specs/{feature}/plan.md`. **Must** follow the structure belo
 |-------|------|------|
 | {entities/features/widgets/shared} | {path} | {description} |
 
-### State Management Strategy
+### State Management Strategy (omit if not applicable)
 {what combination of Zustand store / React Query / Context is used where}
 
-### API Design
+### API Design (omit if not applicable)
 {plan for new API endpoints or use of existing APIs}
 
 ## File Change Map
-{list of files to change/create. for each file:}
-| File | Action | Description |
-|------|--------|-------------|
-| {path} | create/modify/delete | {summary of change} |
+
+| File | Action | Description | Depends On | Phase |
+|------|--------|-------------|------------|-------|
+| {path} | create/modify/delete | {summary} | {file(s) or "—"} | {1-N} |
+
+> - **Depends On**: list file(s) that must be created/modified first (enables dependency-aware task generation in /afc:implement).
+> - **Phase**: implementation phase number. Same-phase + no dependency + different file = parallelizable.
+
+## Implementation Context
+
+> Auto-generated section for implementation agents. Compress to under 500 words.
+> This section travels with every sub-agent prompt during /afc:implement.
+
+- **Objective**: {1-sentence feature purpose from spec Overview}
+- **Key Constraints**: {NFR summaries + spec Constraints section, compressed}
+- **Critical Edge Cases**: {top 3 edge cases from spec, 1 line each}
+- **Risk Watchpoints**: {top risks from Risk & Mitigation table}
+- **Must NOT**: {explicit prohibitions — from spec constraints, principles.md, or CLAUDE.md}
+- **Acceptance Anchors**: {key acceptance criteria from spec that implementation must satisfy}
 
 ## Risk & Mitigation
 | Risk | Impact | Mitigation |
@@ -129,19 +158,26 @@ Create `.claude/afc/specs/{feature}/plan.md`. **Must** follow the structure belo
 | {risk} | {H/M/L} | {approach} |
 
 ## Alternative Design
+### Approach 0: No Change (status quo)
+{Why might the current state be sufficient? What is the cost of doing nothing?}
+{If no change is clearly inferior: state specific reason — "Status quo lacks X, which is required by FR-001"}
+{If no change is viable: recommend it — avoid implementing for the sake of implementing}
+
 ### Approach A: {chosen approach name}
 {Brief description — this is the approach detailed above}
 
 ### Approach B: {alternative approach name}
 {Brief description of a meaningfully different approach}
 
-| Criterion | Approach A | Approach B |
-|-----------|-----------|-----------|
-| Complexity | {evaluation} | {evaluation} |
-| Risk | {evaluation} | {evaluation} |
-| Maintainability | {evaluation} | {evaluation} |
+| Criterion | No Change | Approach A | Approach B |
+|-----------|-----------|-----------|-----------|
+| Complexity | None | {evaluation} | {evaluation} |
+| Risk | None | {evaluation} | {evaluation} |
+| Maintainability | Current | {evaluation} | {evaluation} |
+| Justification | {why not enough} | {why this} | {why this} |
 
-**Decision**: Approach {A/B} — {1-sentence rationale}
+**Decision**: Approach {0/A/B} — {1-sentence rationale}
+{If Approach 0 chosen: abort plan, report: "No implementation needed — current state satisfies requirements."}
 
 ## Phase Breakdown
 ### Phase 1: Setup
@@ -161,34 +197,62 @@ Create `.claude/afc/specs/{feature}/plan.md`. **Must** follow the structure belo
 
 > **Always** read `${CLAUDE_PLUGIN_ROOT}/docs/critic-loop-rules.md` first and follow it.
 
-Run the critic loop until convergence. Safety cap: 7 passes.
+Run the critic loop until convergence. Safety cap: 5 passes.
 
 | Criterion | Validation |
 |-----------|------------|
 | **COMPLETENESS** | Are all requirements (FR-*) from spec.md reflected in the plan? |
 | **FEASIBILITY** | Is it compatible with the existing codebase? Are dependencies available? |
 | **ARCHITECTURE** | Does it comply with {config.architecture} rules? |
+| **CROSS_CONSISTENCY** | Spec↔Plan cross-artifact validation (see checklist below) |
 | **RISK** | Are there any unidentified risks? Additionally, if `.claude/afc/memory/retrospectives/` directory contains files from previous pipeline runs, load each file and check whether the current plan addresses the patterns recorded there. Tag matched patterns with `[RETRO-CHECKED]`. |
 | **PRINCIPLES** | Does it not violate the MUST principles in principles.md? |
 
+**CROSS_CONSISTENCY checklist** (mandatory, check all 5):
+1. **Entity coverage**: every entity in spec.md `Key Entities` table appears in at least one File Change Map row. Report: `{M}/{N} entities covered`.
+2. **NFR traceability**: every NFR-* in spec.md has a corresponding Architecture Decision, Risk mitigation, or Implementation Context entry. Report: `{M}/{N} NFRs traced`.
+3. **Terminology consistency**: same concept uses the same name in spec and plan. Flag any drift (e.g., spec says "user profile", plan says "account settings").
+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.`
 
+### 5.5. ADR Recording (optional)
+
+When the `afc-architect` agent is available, invoke it to record architecture decisions:
+```
+Task("ADR: Record decisions for {feature}", subagent_type: "afc:afc-architect",
+  prompt: "Review the plan and record key architecture decisions to your persistent memory.
+  Plan sections: Architecture Decision + File Change Map.
+  Check for conflicts with existing ADRs. Return: { decisions_recorded: N, conflicts: [] }")
+```
+- If conflicts detected → warn user
+- If agent unavailable → skip (decisions still exist in plan.md for reference)
+
+### 5.6. Auto-Checkpoint (standalone only)
+
+When not running inside `/afc:auto`, save progress for `/afc:resume`:
+- Write/update `.claude/afc/memory/checkpoint.md` with: branch, last commit, feature name, current phase (plan complete), next step (`/afc:implement`)
+- Skip if running inside auto pipeline (auto manages its own checkpoints via phase transitions)
+
 ### 6. Final Output
 
 ```
 Plan generated
 ├─ .claude/afc/specs/{feature}/plan.md
 ├─ .claude/afc/specs/{feature}/research.md (if research was performed)
+├─ Implementation Context: generated ({W} words)
 ├─ Critic: converged ({N} passes, {M} fixes, {E} escalations)
-└─ Next step: /afc:tasks
+└─ Next step: /afc:implement (tasks generated automatically at implement start)
 ```
 
 ## Notes
 
+- **"No Change" is a valid outcome**: If Approach 0 (status quo) is the best option, recommend it. Do not implement for the sake of implementing.
 - Write plan.md to an **actionable level**. Vague expressions like "handle appropriately" are prohibited.
 - File paths in the File Change Map must be based on the **actual project structure** (no guessing).
 - Place files according to {config.architecture} rules; verify by checking existing codebase patterns.

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
@@ -26,7 +25,12 @@ model: haiku
 
 ## Config Load
 
-**Must** read `.claude/afc.config.md` first. Stop if the config file is not present.
+**Always** read `.claude/afc.config.md` first.
+
+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
 

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
@@ -60,7 +59,7 @@ Compare the checkpoint state against the current environment:
 ### Recommended Next Steps
 {recommended commands based on state}
 - Tasks in progress → resume `/afc:implement`
-- Plan complete → `/afc:tasks`
+- Plan complete → `/afc:implement` (tasks generated automatically at start)
 - Spec only → `/afc:plan`
 ```
 

package/commands/review.md

@@ -28,7 +28,12 @@ model: sonnet
 
 ## 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
 
@@ -58,21 +63,44 @@ Task("Review: {file3, file4}", subagent_type: "general-purpose")
 Read each agent's returned output, then write consolidated review.
 
 #### 11+ files: Review Swarm
-Create a review task pool and spawn self-organizing review workers:
-```
-// 1. Register each file as a review task via TaskCreate
-TaskCreate({ subject: "Review: src/auth/login.ts", description: "Review for quality, security, architecture, performance..." })
-TaskCreate({ subject: "Review: src/auth/session.ts", ... })
-// ... for all changed files
+Create a review task pool and spawn pre-assigned review workers:
+
+> **Note**: Unlike implement swarm (which prohibits self-claiming due to write conflicts), review workers use orchestrator pre-assignment by file group. This is safe because review is read-only — no write race conditions.
 
+```
+// 1. Group files into batches (2-3 files per worker)
 // 2. Spawn N review workers in a single message (N = min(5, file count / 2))
-Task("Review Worker 1", subagent_type: "general-purpose",
-  prompt: "You are a review worker. Loop: TaskList → claim pending → read file + diff → review → record findings → repeat until empty.
+Task("Review Worker 1: src/auth/login.ts, src/auth/session.ts", subagent_type: "general-purpose",
+  prompt: "Review the following files for quality, security, architecture, performance.
+  Files: src/auth/login.ts, src/auth/session.ts
   Review criteria: {config.code_style}, {config.architecture}, security, performance.
   Output findings as: severity (Critical/Warning/Info), file:line, issue, suggested fix.")
+Task("Review Worker 2: src/api/routes.ts, src/api/middleware.ts", subagent_type: "general-purpose", ...)
 ```
 Collect all worker outputs, then write consolidated review.
 
+### 2.5. Specialist Agent Delegation (optional, parallel)
+
+When the `afc-architect` and `afc-security` agents are available, delegate perspectives B and C for deeper analysis:
+
+```
+Task("Architecture Review", subagent_type: "afc:afc-architect",
+  prompt: "Review changed files for architecture compliance.
+  Files: {changed file list}
+  Rules: {config.architecture}
+  Return findings as: severity, file:line, issue, suggested fix.")
+
+Task("Security Review", subagent_type: "afc:afc-security",
+  prompt: "Scan changed files for security vulnerabilities.
+  Files: {changed file list}
+  Return findings as: severity, file:line, issue, suggested fix.")
+```
+
+- Launch both in a **single message** (parallel execution)
+- Merge agent findings into the consolidated review (Step 4)
+- Agents update their persistent memory automatically (ADR patterns, vulnerability patterns, false positives)
+- If agents are unavailable (e.g., standalone mode without plugin): fall back to direct review for B and C
+
 ### 3. Perform Review
 
 For each changed file, examine from the following perspectives:
@@ -83,25 +111,46 @@ For each changed file, examine from the following perspectives:
 - Duplicate code
 - Unnecessary complexity
 
-#### B. {config.architecture}
+#### B. {config.architecture} (agent-enhanced when available)
 - Layer dependency direction violations (lower→upper imports)
 - Segment rules (api/, model/, ui/, lib/)
 - Appropriate layer placement
+- **Agent bonus**: ADR conflict detection, cross-session pattern recognition
 
-#### C. Security
+#### C. Security (agent-enhanced when available)
 - XSS vulnerabilities (dangerouslySetInnerHTML, unvalidated user input)
 - Sensitive data exposure
 - SQL/Command injection
+- **Agent bonus**: false positive filtering, known vulnerability pattern matching
 
 #### D. Performance
-- Unnecessary re-renders (missing useCallback/useMemo)
-- Infinite loop potential (useEffect dependencies)
-- Large data processing
+- Startup/response latency concerns
+- Unnecessary computation or redundant operations
+- Resource management (memory, file handles, connections, subprocesses)
+- Framework-specific performance patterns (from Project Context)
 
 #### E. Project Pattern Compliance
-- {config.state_management} usage patterns
-- Server/client state management patterns (see {config.state_management})
-- Component structure (Props type location, hook order)
+- {config.code_style} naming and structure conventions
+- {config.architecture} layer rules and boundaries
+- Framework-specific idioms and best practices (from Project Context)
+
+#### F. Reusability
+- Duplicate or near-duplicate logic across files
+- Opportunities to extract shared utilities or helpers
+- DRY principle adherence (same logic repeated in multiple places)
+- Appropriate abstraction level (not premature, not missing)
+
+#### G. Maintainability
+- Function/file size — can a developer or LLM understand each unit in isolation?
+- Naming clarity — do names reveal intent without requiring surrounding context?
+- Self-contained files — minimal cross-file dependencies for comprehension
+- Comments where logic is non-obvious (present where needed, absent where redundant)
+
+#### H. Extensibility
+- Can new variants or features be added without modifying existing code?
+- Are there clear extension points (configuration, plugin hooks, strategy patterns)?
+- Open/Closed principle adherence where applicable
+- Future modification cost — would a reasonable feature request require rewriting or only extending?
 
 ### 4. Review Output
 
@@ -146,7 +195,8 @@ Run the critic loop until convergence. Safety cap: 5 passes.
 
 | Criterion | Validation |
 |-----------|------------|
-| **COMPLETENESS** | Were all changed files reviewed? Are there any missed perspectives? |
+| **COMPLETENESS** | Were all changed files reviewed? Are there any missed perspectives (A through H)? |
+| **SPEC_ALIGNMENT** | Cross-check implementation against spec.md: (1) every SC (success criterion) is satisfied — provide `{M}/{N} SC verified` count, (2) every acceptance scenario (GWT) has corresponding code path, (3) no spec constraint is violated by the implementation |
 | **PRECISION** | Are the findings actual issues, not false positives? |
 
 **On FAIL**: auto-fix and continue to next pass.

package/commands/security.md

@@ -2,7 +2,6 @@
 name: afc:security
 description: "Security scan (read-only)"
 argument-hint: "[scan scope: file/directory path or full]"
-disable-model-invocation: true
 context: fork
 agent: afc-security
 allowed-tools:
@@ -27,16 +26,14 @@ model: sonnet
 
 ## Config Load
 
-Read the following settings from `CLAUDE.md` or `.claude/CLAUDE.md` at the project root and assign to the `config` variable:
+**Always** read `.claude/afc.config.md` first. This file contains free-form markdown sections:
+- `## Project Context` — framework, state management, testing, etc. (primary source for framework info)
+- `## Architecture` — architecture pattern, layers, import rules
+- `## Code Style` — language, naming conventions, lint rules
 
-```
-config.framework  = the framework used in the project
-                    (e.g., "Next.js", "Nuxt", "SvelteKit", "Express", "NestJS")
-                    → Framework specified in CLAUDE.md. Assume "unknown" if not present.
-config.auditCmd   = dependency audit command
-                    (e.g., "yarn audit", "npm audit", "pnpm audit")
-                    → Infer from the packageManager field in package.json or the lockfile.
-```
+If config file is missing: read `CLAUDE.md` for framework info. Assume "unknown" if neither source has it.
+
+For dependency audit command: infer from `packageManager` field in `package.json` or the lockfile (e.g., `npm audit`, `yarn audit`, `pnpm audit`).
 
 ## Execution Steps
 
@@ -67,7 +64,7 @@ Task("Security scan: src/shared/api/", subagent_type: general-purpose)
 - Session management vulnerabilities
 
 #### C. Sensitive Data Exposure (A02:2021)
-- `.env` values exposed to the client (check framework-specific public env variables for {config.framework})
+- `.env` values exposed to the client (check framework-specific public env variables from Project Context)
 - Sensitive information printed via console.log
 - Internal details exposed in error messages
 
@@ -108,7 +105,7 @@ Task("Security scan: src/shared/api/", subagent_type: general-purpose)
 - **Mitigation**: {how to fix}
 
 ### Dependency Audit
-{config.auditCmd} result summary — if executable
+{dependency audit command result summary — if executable}
 
 ### Recommended Actions
 {prioritized fix suggestions}
@@ -128,4 +125,4 @@ Security scan complete
 - **Read-only**: Does not modify code. Reports security issues only.
 - **Minimize false positives**: Account for React's default XSS defenses. Report only genuinely dangerous patterns.
 - **Handle sensitive data carefully**: Do not include actual token or password values in scan results.
-- **Consider context**: Reflect security specifics for the {config.framework} environment.
+- **Consider context**: Reflect security specifics for the project's framework environment (from Project Context).