all-for-claudecode 2.6.0 → 2.7.1

package/.claude-plugin/marketplace.json

@@ -6,14 +6,14 @@
   },
   "metadata": {
     "description": "Automated pipeline for Claude Code — spec → plan → implement → review → clean",
-    "version": "2.6.0"
+    "version": "2.7.1"
   },
   "plugins": [
     {
       "name": "afc",
       "source": "./",
       "description": "Automated pipeline for Claude Code. Automates the full development cycle: spec → plan → implement → review → clean.",
-      "version": "2.6.0",
+      "version": "2.7.1",
       "category": "automation",
       "tags": ["pipeline", "automation", "spec", "plan", "implement", "review", "critic-loop"]
     }

package/.claude-plugin/plugin.json

@@ -1,11 +1,12 @@
 {
   "name": "afc",
-  "version": "2.6.0",
+  "version": "2.7.1",
   "description": "Automated pipeline for Claude Code. Automates the full development cycle: spec → plan → implement → review → clean.",
   "author": { "name": "jhlee0409", "email": "relee6203@gmail.com" },
   "homepage": "https://github.com/jhlee0409/all-for-claudecode",
   "repository": "https://github.com/jhlee0409/all-for-claudecode",
   "license": "MIT",
   "keywords": ["pipeline", "automation", "spec", "plan", "implement", "review", "critic-loop"],
-  "commands": "./commands/"
+  "commands": "./commands/",
+  "hooks": "./hooks/hooks.json"
 }

package/README.md

@@ -108,6 +108,7 @@ Performance: ✓ no N+1 queries
 | `/afc:implement` | Execute code implementation with CI gates |
 | `/afc:test` | Test strategy planning and test writing |
 | `/afc:review` | Code review with architecture/security scanning |
+| `/afc:clean` | Pipeline artifact cleanup and codebase hygiene |
 | `/afc:research` | Technical research with persistent storage |
 | `/afc:debug` | Bug diagnosis and fix |
 | `/afc:init` | Project setup — detects stack and generates config |
@@ -171,7 +172,7 @@ Every hook fires automatically — no configuration needed after install.
 | `Notification` | Desktop alerts (macOS/Linux) |
 | `TaskCompleted` | CI gate (shell) + acceptance criteria verification (LLM) |
 | `SubagentStop` | Tracks subagent completion in pipeline log |
-| `UserPromptSubmit` | Injects Phase/Feature context + drift checkpoint during active pipeline |
+| `UserPromptSubmit` | **Inactive**: detects intent keywords and suggests matching afc skill. **Active**: injects Phase/Feature context + drift checkpoint at threshold prompts |
 | `PermissionRequest` | Auto-allows CI commands during implement/review |
 | `ConfigChange` | Audits/blocks settings changes during active pipeline |
 | `TeammateIdle` | Prevents Agent Teams idle during implement/review |
@@ -259,7 +260,7 @@ No. Pure markdown commands + bash hook scripts. No npm packages are imported at
 Debug-based RCA: traces the error, forms a hypothesis, applies a targeted fix. Halts after 3 failed attempts with full diagnosis.
 
 ### Can I run individual phases?
-Yes. Each phase has its own command (`/afc:spec`, `/afc:plan`, `/afc:implement`, `/afc:review`). `/afc:auto` runs them all.
+Yes. Each phase has its own command (`/afc:spec`, `/afc:plan`, `/afc:implement`, `/afc:review`, `/afc:clean`). `/afc:auto` runs them all.
 
 ### What are Critic Loops?
 Convergence-based quality checks after each phase. They evaluate output against criteria and auto-fix issues until stable. 4 verdicts: PASS, FAIL, ESCALATE (asks user), DEFER.

package/agents/afc-architect.md

@@ -7,7 +7,7 @@ tools:
   - Grep
   - Glob
   - Bash
-  - Task
+  - Agent
   - WebSearch
 model: sonnet
 memory: project

package/agents/afc-impl-worker.md

@@ -32,6 +32,14 @@ The orchestrator pre-assigns tasks to you via the prompt. Do NOT self-claim task
    - Gate command result
 5. Do NOT call TaskList or TaskUpdate — the orchestrator handles task state management
 
+## Cross-Phase Awareness
+
+When implementing tasks that call functions modified in a previous phase:
+- Read the callee's current implementation (it may have changed in the previous phase)
+- Verify that your call pattern is compatible with the callee's actual behavior (side effects, return values, error handling)
+- If `{config.test}` is available, run it after completing tasks that depend on cross-phase changes
+- If no E2E/integration tests are configured, note in your output: "⚠ Cross-phase dependency on {function} — no E2E verification available"
+
 ## Rules
 
 - Always read existing files before modifying them

package/agents/afc-security.md

@@ -6,7 +6,7 @@ tools:
   - Grep
   - Glob
   - Bash
-  - Task
+  - Agent
   - WebSearch
 disallowedTools:
   - Write

package/commands/analyze.md

@@ -1,6 +1,6 @@
 ---
 name: afc:analyze
-description: "General-purpose code and component analysis"
+description: "General-purpose code and component analysis — use when the user asks to analyze code, trace a flow, audit consistency, understand how something works, or inspect components"
 argument-hint: "<analysis target or question>"
 user-invocable: true
 context: fork

package/commands/architect.md

@@ -1,6 +1,6 @@
 ---
 name: afc:architect
-description: "Architecture analysis and design advice"
+description: "Architecture analysis and design advice — use when the user asks about architecture, system design, layer boundaries, or wants structural design review"
 argument-hint: "[analysis target or design question]"
 context: fork
 agent: afc-architect
@@ -59,6 +59,17 @@ Task("analyze features/timeline", subagent_type: Explore)
 Task("analyze widgets/timeline", subagent_type: Explore)
 ```
 
+**Cross-Module Import Chain Verification** (after Explore agents return):
+
+When parallel Explore agents are used, the orchestrator must verify cross-module boundaries that no single agent can see:
+
+1. From each agent's dependency map, extract **outbound imports** that cross module boundaries
+2. For each cross-module import chain (e.g., widget → feature → shared), read the actual import statements at the boundary files
+3. Verify against {config.architecture} rules: does the full chain respect layer direction, not just each module's internal imports?
+4. Report any cross-module violations not surfaced by individual agents
+
+Do not trust agent-summarized import relationships for cross-boundary chains — re-read the boundary files directly.
+
 ### 3. Write Analysis
 
 Structure analysis results and **print to console**:

package/commands/auto.md

@@ -1,6 +1,6 @@
 ---
 name: afc:auto
-description: "Full auto pipeline"
+description: "Full auto pipeline — use when the user asks to run the full afc pipeline automatically or automate the spec-to-clean cycle"
 argument-hint: "[feature description in natural language]"
 ---
 

package/commands/checkpoint.md

@@ -1,6 +1,6 @@
 ---
 name: afc:checkpoint
-description: "Save session state"
+description: "Save session state — use when the user asks to save progress, checkpoint the session, or preserve current work state"
 argument-hint: "[checkpoint message]"
 model: haiku
 allowed-tools:

package/commands/clarify.md

@@ -1,6 +1,6 @@
 ---
 name: afc:clarify
-description: "Resolve spec ambiguities"
+description: "Resolve spec ambiguities — auto-triggered when requirements are unclear to ask clarifying questions before proceeding"
 argument-hint: "[focus area: security, performance, UI flow]"
 user-invocable: false
 allowed-tools:

package/commands/clean.md

@@ -0,0 +1,126 @@
+---
+name: afc:clean
+description: "Pipeline artifact cleanup and codebase hygiene — use when the user asks to clean up artifacts, remove pipeline files, or finalize after implementation"
+argument-hint: "[feature name — defaults to current pipeline feature]"
+model: haiku
+---
+
+# /afc:clean — Pipeline Cleanup
+
+> Runs the clean phase independently: artifact cleanup, dead code scan, CI verification, memory update, and pipeline flag release.
+> Equivalent to Phase 5 of `/afc:auto`. Use after manually running spec/plan/implement/review phases.
+
+## Arguments
+
+- `$ARGUMENTS` — (optional) Feature name to clean up. Defaults to the currently active pipeline feature.
+
+## Prerequisites
+
+- Pipeline must be active (`afc_state_is_active`) OR a feature name must be provided
+- If pipeline is active, the current phase should be `review` or later
+
+## Execution Steps
+
+### 1. Resolve Feature
+
+```bash
+"${CLAUDE_PLUGIN_ROOT}/scripts/afc-pipeline-manage.sh" phase clean
+```
+
+- If pipeline is active: read feature from state
+- If `$ARGUMENTS` provides a feature name: use that (for manual cleanup without active pipeline)
+- If neither: exit with error — `"No active pipeline and no feature specified. Usage: /afc:clean [feature-name]"`
+
+Set `PIPELINE_ARTIFACT_DIR` = `.claude/afc/specs/{feature}/`
+
+### 2. Artifact Cleanup (scope-limited)
+
+- **Delete only the `.claude/afc/specs/{feature}/` directory created by the current pipeline**
+- If other `.claude/afc/specs/` subdirectories exist, **do not delete them** (only inform the user of their existence)
+- Do not leave pipeline intermediate artifacts in the codebase
+
+### 3. Dead Code Scan
+
+- Detect unused imports from the implementation process (check with `{config.ci}`)
+- Remove empty directories from moved/deleted files
+- Detect unused exports (re-exports of moved code from original locations etc.)
+
+### 4. Final CI Gate
+
+- Run `{config.ci}` final execution
+- Auto-fix on failure (max 2 attempts)
+
+### 5. Memory Update
+
+- Reusable patterns found during pipeline -> record in `.claude/afc/memory/`
+- If there were `[AUTO-RESOLVED]` items -> record decisions in `.claude/afc/memory/decisions/`
+- **If retrospective.md exists** -> record as patterns missed by the Plan phase Critic Loop in `.claude/afc/memory/retrospectives/` (reuse as RISK checklist items in future runs)
+- **If review-report.md exists** -> copy to `.claude/afc/memory/reviews/{feature}-{date}.md` before .claude/afc/specs/ deletion
+- **If research.md exists** and was not already persisted in Plan phase -> copy to `.claude/afc/memory/research/{feature}.md`
+- **Agent memory consolidation**: check each agent's MEMORY.md line count -- if either exceeds 100 lines, invoke the respective agent to self-prune:
+  ```
+  Task("Memory cleanup: afc-architect", subagent_type: "afc:afc-architect",
+    prompt: "Your MEMORY.md exceeds 100 lines. Read it, prune old/redundant entries, and rewrite to under 100 lines following your size limit rules.")
+  ```
+  (Same pattern for afc-security if needed. Skip if both are under 100 lines.)
+- **Memory rotation**: for each memory subdirectory, check file count and prune oldest files if over threshold:
+  | Directory | Threshold | Action |
+  |-----------|-----------|--------|
+  | `quality-history/` | 30 files | Delete oldest files beyond threshold |
+  | `reviews/` | 40 files | Delete oldest files beyond threshold |
+  | `retrospectives/` | 30 files | Delete oldest files beyond threshold |
+  | `research/` | 50 files | Delete oldest files beyond threshold |
+  | `decisions/` | 60 files | Delete oldest files beyond threshold |
+  - Sort by filename ascending (oldest first), delete excess
+  - Log: `"Memory rotation: {dir} pruned {N} files"`
+  - Skip directories that do not exist or are under threshold
+
+### 6. Quality Report
+
+Generate `.claude/afc/memory/quality-history/{feature}-{date}.json` with pipeline metrics (if pipeline was active):
+```json
+{
+  "feature": "{feature}",
+  "date": "{YYYY-MM-DD}",
+  "totals": { "changed_files": N }
+}
+```
+Create `.claude/afc/memory/quality-history/` directory if it does not exist.
+
+### 7. Checkpoint Reset
+
+Clear `.claude/afc/memory/checkpoint.md` **and** `~/.claude/projects/{ENCODED_PATH}/memory/checkpoint.md` (pipeline complete = session goal achieved; `ENCODED_PATH` = project path with `/` replaced by `-`).
+
+### 8. Timeline Finalize
+
+```bash
+"${CLAUDE_PLUGIN_ROOT}/scripts/afc-pipeline-manage.sh" log pipeline-end "Pipeline complete: {feature}"
+```
+
+### 9. Release Pipeline Flag
+
+```bash
+"${CLAUDE_PLUGIN_ROOT}/scripts/afc-pipeline-manage.sh" end
+```
+
+- Stop Gate Hook deactivated
+- Change tracking log deleted
+- Safety tag removed (successful completion)
+- Phase rollback tags removed (handled automatically by pipeline end)
+
+### 10. Output Summary
+
+```
+Clean complete: {feature}
+├─ Artifacts: {N} files deleted from .claude/afc/specs/{feature}/
+├─ Dead code: {N} items removed
+├─ CI: PASSED
+├─ Memory: {N} files persisted, {N} rotated
+└─ Pipeline flag: released
+```
+
+## Notes
+
+- This command is safe to run multiple times (idempotent -- skips already-deleted artifacts)
+- If no pipeline is active and no feature is specified, the command exits with an informative error
+- When run standalone (not as part of auto), the quality report captures only the information available at clean time

package/commands/consult.md

@@ -1,6 +1,6 @@
 ---
 name: afc:consult
-description: "Expert consultation — get advice from backend, infra, PM, design, marketing, legal, security, or tech advisor specialists"
+description: "Expert consultation — use when the user asks for expert advice, wants to consult a specialist, or needs domain-specific guidance on backend, infra, PM, design, marketing, legal, or tech decisions"
 argument-hint: "[domain?] \"[question]\" [brief|deep]"
 model: sonnet
 ---

package/commands/debug.md

@@ -1,6 +1,6 @@
 ---
 name: afc:debug
-description: "Bug diagnosis and fix"
+description: "Bug diagnosis and fix — use when the user reports a bug, error, crash, exception, broken behavior, or something not working and wants root-cause analysis and a targeted fix"
 argument-hint: "[bug description, error message, or reproduction steps]"
 allowed-tools:
   - Read

package/commands/doctor.md

@@ -1,6 +1,6 @@
 ---
 name: afc:doctor
-description: "Diagnose project health and plugin setup"
+description: "Diagnose project health and plugin setup — use when the user asks for a health check, wants to diagnose project issues, or verify plugin installation"
 argument-hint: "[--verbose]"
 allowed-tools:
   - Read

package/commands/ideate.md

@@ -1,6 +1,6 @@
 ---
 name: afc:ideate
-description: "Explore and structure a product idea"
+description: "Explore and structure a product idea — use when the user wants to brainstorm, ideate, explore what to build, or create a product brief from a rough concept"
 argument-hint: "[rough idea or problem statement]"
 allowed-tools:
   - Read

package/commands/implement.md

@@ -1,6 +1,6 @@
 ---
 name: afc:implement
-description: "Execute code implementation"
+description: "Execute code implementation — use when the user asks to implement a feature, execute a planned refactor, modify code from a plan, or build something"
 argument-hint: "[task ID or phase specification]"
 ---
 
@@ -271,7 +271,7 @@ When a worker agent returns an error:
 
 #### Phase Completion Gate (3 steps)
 
-> **Always** read `${CLAUDE_PLUGIN_ROOT}/docs/phase-gate-protocol.md` first and perform the 3 steps (CI gate → Mini-Review → Auto-Checkpoint) in order.
+> **Always** read `${CLAUDE_PLUGIN_ROOT}/docs/phase-gate-protocol.md` first and perform the 3–4 steps (CI gate → Mini-Review → Integration/E2E Gate (conditional) → Auto-Checkpoint) in order.
 > Cannot advance to the next phase without passing the gate. Abort and report to user after 3 consecutive CI failures.
 
 After passing the gate, create a phase rollback point:
@@ -320,6 +320,7 @@ After CI passes, run a convergence-based Critic Loop to verify design alignment
 - **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.
+- **SIDE_EFFECT_SAFETY**: For tasks that changed call order, error handling, or state flow: verify that callee behavior is compatible with the new call pattern. Provide "{M} of {N} behavioral changes 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?"

package/commands/init.md

@@ -1,6 +1,6 @@
 ---
 name: afc:init
-description: "Project initial setup"
+description: "Project initial setup — use when the user asks to set up the project, initialize afc, configure the plugin, or detect the tech stack"
 argument-hint: "[additional context]"
 allowed-tools:
   - Read
@@ -260,6 +260,7 @@ User-only (not auto-triggered — inform user on request):
 - `afc:checkpoint` — inform user when session save is requested
 - `afc:resume` — inform user when session restore is requested
 - `afc:principles` — inform user when project principles management is requested
+- `afc:clean` — inform user when pipeline cleanup is requested (artifact cleanup, dead code scan, pipeline flag release)
 - `afc:triage` — inform user when parallel PR/issue triage is requested
 - `afc:pr-comment` — inform user when posting PR review comments to GitHub is requested
 - `afc:release-notes` — inform user when generating release notes from git history is requested

package/commands/launch.md

@@ -1,6 +1,6 @@
 ---
 name: afc:launch
-description: "Generate release artifacts"
+description: "Generate release artifacts — use when the user asks to prepare a release, bump version, publish a package, or create release tags"
 argument-hint: "[version tag or 'auto']"
 allowed-tools:
   - Read

package/commands/plan.md

@@ -1,6 +1,6 @@
 ---
 name: afc:plan
-description: "Implementation design"
+description: "Implementation design — use when the user asks to plan, design an implementation, create a file change map, or figure out how to implement something"
 argument-hint: "[additional context or constraints]"
 allowed-tools:
   - Read

package/commands/pr-comment.md

@@ -1,6 +1,6 @@
 ---
 name: afc:pr-comment
-description: "Post PR review comments to GitHub"
+description: "Post PR review comments to GitHub — use when the user asks to comment on a PR, post review feedback, or submit structured PR review comments"
 argument-hint: "<PR number> [--severity critical,warning,info]"
 allowed-tools:
   - Read

package/commands/principles.md

@@ -1,6 +1,6 @@
 ---
 name: afc:principles
-description: "Manage project principles"
+description: "Manage project principles — use when the user asks to add, remove, or view project coding principles and conventions"
 argument-hint: "[action: add, remove, init]"
 allowed-tools:
   - Read

package/commands/qa.md

@@ -1,6 +1,6 @@
 ---
 name: afc:qa
-description: "Project quality audit — detect gaps between structure and runtime behavior"
+description: "Project quality audit — use when the user asks for a quality audit, QA check, test confidence assessment, or wants to detect gaps in error handling and code health"
 argument-hint: "[scope: all, tests, errors, coverage, or specific concern]"
 user-invocable: true
 context: fork

package/commands/release-notes.md

@@ -1,6 +1,6 @@
 ---
 name: afc:release-notes
-description: "Generate user-facing release notes from git history"
+description: "Generate user-facing release notes from git history — use when the user asks to write release notes, summarize changes between versions, or generate a changelog"
 argument-hint: "[v1.0.0..v2.0.0 | v2.0.0 | --post]"
 allowed-tools:
   - Read

package/commands/research.md

@@ -1,6 +1,6 @@
 ---
 name: afc:research
-description: "Technical research"
+description: "Technical research — use when the user asks to research a topic, investigate a technology, compare libraries, or explore options before deciding"
 argument-hint: "[research topic]"
 allowed-tools:
   - Read
@@ -51,6 +51,16 @@ Source priority:
 2. **Codebase** (existing patterns in the current project)
 3. **Community** (GitHub Issues, blogs)
 
+### 3.5. Reconcile Findings
+
+After parallel agents return, the orchestrator checks for conflicts between sources:
+
+1. Compare codebase agent findings (current usage patterns) against web agent findings (official docs, latest versions)
+2. If a codebase pattern conflicts with official documentation (e.g., deprecated API, changed behavior in newer version):
+   - Flag the conflict explicitly in Findings rather than silently adopting one source
+   - Note: "Current codebase uses {pattern} but official docs recommend {alternative} since {version/date}"
+3. If no conflicts → proceed to Summarize
+
 ### 4. Summarize Conclusions
 
 ```markdown

package/commands/resume.md

@@ -1,6 +1,6 @@
 ---
 name: afc:resume
-description: "Restore session"
+description: "Restore session — use when the user asks to resume a previous session, restore saved state, or continue where they left off"
 argument-hint: "[no arguments]"
 model: haiku
 allowed-tools:

package/commands/review.md

@@ -1,6 +1,6 @@
 ---
 name: afc:review
-description: "Code review"
+description: "Code review — use when the user asks to review code, analyze a PR diff, do a code review, or evaluate code quality and correctness"
 argument-hint: "[scope: file path, PR number, or staged]"
 allowed-tools:
   - Read
@@ -51,6 +51,23 @@ If config file is missing:
 
 Choose review orchestration based on the number of changed files:
 
+**Pre-scan: Call Chain Context** (for Parallel Batch and Review Swarm modes only):
+
+Before distributing files to review agents, collect cross-boundary context:
+
+1. For each changed file, identify **outbound calls** to other changed files (imports + function calls)
+2. For each outbound call target, extract: function signature + 1-line side-effect summary (e.g., "mutates playlist state", "triggers async cascade")
+3. Include this context in each review agent's prompt:
+   ```
+   ## Cross-File Context
+   This file calls:
+   - `deleteVideo()` in api/videos.ts → internally auto-advances to next video if current is deleted
+   - `getNextVideo()` in api/playlist.ts → pops pending keyword queue first, falls back to normal next
+   Review findings should account for these behaviors.
+   ```
+
+For Direct review mode (≤5 files): skip pre-scan — orchestrator already has full context.
+
 #### 5 or fewer files: Direct review
 Review all files directly in the current context (no delegation).
 
@@ -152,6 +169,31 @@ For each changed file, examine from the following perspectives:
 - Open/Closed principle adherence where applicable
 - Future modification cost — would a reasonable feature request require rewriting or only extending?
 
+### 3.5. Cross-Boundary Verification
+
+After individual/parallel reviews complete, the **orchestrator** performs a cross-boundary check on behavioral findings:
+
+1. **Filter**: From all collected findings, select those involving:
+   - Call order changes (function A now calls B before C)
+   - Error handling modifications (try/catch scope changes, error propagation changes)
+   - State mutation changes (new writes to shared state, removed cleanup)
+
+2. **Verify**: For each behavioral finding rated Critical or Warning:
+   - Read the **callee's implementation** (the function/method being called)
+   - Check: does the callee's internal behavior (side effects, state changes, return values) actually conflict with the change?
+   - If no conflict → downgrade: Critical → Info, Warning → Info (append "verified: no cross-boundary impact")
+   - If confirmed conflict → keep severity, enrich description with callee behavior details
+
+3. **Output**: Append verification summary before Review Output:
+   ```
+   Cross-Boundary Check: {N} behavioral findings verified
+   ├─ Confirmed: {M} (severity kept)
+   ├─ Downgraded: {K} (false positive — callee compatible)
+   └─ Skipped: {J} (no behavioral change)
+   ```
+
+This step runs in the orchestrator context (not delegated), as it requires reading code across file boundaries that individual review agents cannot see.
+
 ### 4. Review Output
 
 ```markdown
@@ -197,6 +239,7 @@ Run the critic loop until convergence. Safety cap: 5 passes.
 |-----------|------------|
 | **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 |
+| **SIDE_EFFECT_AWARENESS** | For findings involving call order changes, error handling modifications, or state mutation changes: did the reviewer verify the callee's internal behavior? If a Critical finding assumes a side effect without reading the target implementation → auto-downgrade to Info with note "cross-boundary unverified". Provide "{M} of {N} behavioral findings verified" count. |
 | **PRECISION** | Are the findings actual issues, not false positives? |
 
 **On FAIL**: auto-fix and continue to next pass.

package/commands/security.md

@@ -1,6 +1,6 @@
 ---
 name: afc:security
-description: "Security scan (read-only)"
+description: "Security scan (read-only) — use when the user asks for a security scan, security review, vulnerability check, or threat assessment"
 argument-hint: "[scan scope: file/directory path or full]"
 context: fork
 agent: afc-security
@@ -46,11 +46,52 @@ For dependency audit command: infer from `packageManager` field in `package.json
 ### 2. Agent Teams (if more than 10 files)
 
 Use parallel agents for wide-scope scans:
+
+**Pre-scan: Data Flow Context** (before distributing to agents):
+
+1. For each changed file, identify **input entry points** (user input, API params, URL params, form data) and **sanitization calls** (validation, escaping, encoding)
+2. Trace input flow across changed files: where does user input enter? Where is it sanitized? Where is it consumed?
+3. Include this context in each agent's prompt:
+   ```
+   ## Data Flow Context
+   Input flows relevant to your scan scope:
+   - User input enters via `req.body` in api/routes.ts → sanitized by `validateInput()` in shared/validation.ts → consumed in features/user.ts
+   - URL params enter via `req.params` in api/routes.ts → NO sanitization found → used in features/search.ts
+   Account for these flows when assessing injection/XSS severity.
+   ```
+
 ```
-Task("Security scan: src/features/", subagent_type: general-purpose)
-Task("Security scan: src/shared/api/", subagent_type: general-purpose)
+Task("Security scan: src/features/", subagent_type: general-purpose,
+  prompt: "... {include Data Flow Context} ...")
+Task("Security scan: src/shared/api/", subagent_type: general-purpose,
+  prompt: "... {include Data Flow Context} ...")
 ```
 
+For scans with ≤10 files: skip pre-scan — orchestrator has full context.
+
+### 2.5. Cross-Boundary Verification
+
+After parallel agent results are collected, the **orchestrator** performs cross-boundary verification on injection/vulnerability findings:
+
+1. **Filter**: From all findings, select those involving:
+   - Injection vulnerabilities (SQL, command, XSS) where input origin is in another agent's scan scope
+   - Authentication/authorization checks where the guard is in a different directory slice
+   - Sensitive data exposure where the data source and the exposure point are in different slices
+
+2. **Verify**: For each Critical or High finding:
+   - Read the **upstream code** (where input enters or is sanitized)
+   - Check: is the input actually sanitized before reaching the flagged consumption point?
+   - If sanitized → downgrade: Critical → Low, High → Low (append "verified: input sanitized at {location}")
+   - If NOT sanitized → keep severity, enrich with full data flow path
+
+3. **Output**: Append verification summary before Output Results:
+   ```
+   Cross-Boundary Check: {N} injection/vulnerability findings verified
+   ├─ Confirmed: {M} (severity kept — no upstream sanitization)
+   ├─ Downgraded: {K} (false positive — sanitized upstream)
+   └─ Skipped: {J} (single-file scope, no cross-boundary flow)
+   ```
+
 ### 3. Security Check Items
 
 #### A. Injection (A03:2021)

package/commands/spec.md

@@ -1,6 +1,6 @@
 ---
 name: afc:spec
-description: "Generate feature specification"
+description: "Generate feature specification — use when the user asks to write a spec, define requirements, create acceptance criteria, or specify a feature"
 argument-hint: "[feature description in natural language]"
 allowed-tools:
   - Read

package/commands/tasks.md

@@ -1,6 +1,6 @@
 ---
 name: afc:tasks
-description: "Task decomposition"
+description: "Task decomposition — auto-invoked during implement phase to break down plan into executable tasks with dependency tracking"
 argument-hint: "[constraints/priority directives]"
 user-invocable: false
 allowed-tools:

package/commands/test.md

@@ -1,6 +1,6 @@
 ---
 name: afc:test
-description: "Test strategy planning and test writing"
+description: "Test strategy planning and test writing — use when the user asks to write tests, add test coverage, improve coverage, create unit/integration/e2e tests, or plan a testing strategy"
 argument-hint: "[target: file path, feature name, or coverage]"
 allowed-tools:
   - Read

package/commands/triage.md

@@ -1,6 +1,6 @@
 ---
 name: afc:triage
-description: "Parallel triage of open PRs and issues"
+description: "Parallel triage of open PRs and issues — use when the user asks to triage PRs, review open issues, or prioritize the backlog of pull requests and issues"
 argument-hint: "[scope: --pr, --issue, --all (default), or specific numbers]"
 allowed-tools:
   - Read
@@ -145,6 +145,20 @@ Task("Deep triage PR #{number}", subagent_type: "afc:afc-pr-analyst",
 
 If `--deep` flag was specified, run Phase 2 for **all** PRs regardless of Phase 1 classification.
 
+### 3.5. Cross-PR Coupling Detection
+
+After Phase 1 (and Phase 2 if applicable) results are collected, detect file-level coupling between PRs:
+
+1. Extract changed file lists from each PR's diff (already available from Phase 1 agent outputs)
+2. For each file, check if it appears in multiple PRs' changed file lists
+3. If shared files are found, annotate affected PRs with a coupling flag:
+   ```
+   COUPLING: PR #{A} and PR #{B} both modify src/shared/utils.ts
+   ```
+4. Include coupling information in the consolidated report's Priority Actions table and per-PR details
+
+This helps identify merge-order dependencies and potential conflict risks that no single-PR agent can detect.
+
 ### 4. Consolidate Triage Report
 
 Merge Phase 1 and Phase 2 results into a single report:

package/commands/validate.md

@@ -1,6 +1,6 @@
 ---
 name: afc:validate
-description: "Artifact consistency validation (read-only)"
+description: "Artifact consistency validation (read-only) — auto-invoked to verify spec, plan, and task artifacts are consistent with each other"
 argument-hint: "[validation scope: spec-plan, tasks-only]"
 user-invocable: false
 context: fork

package/docs/phase-gate-protocol.md

@@ -1,6 +1,6 @@
-# Phase Completion Gate (3 Steps)
+# Phase Completion Gate (3–4 Steps)
 
-After each Phase completes, perform **3-step verification** sequentially:
+After each Phase completes, perform **3–4 step verification** sequentially (Step 2.5 is conditional):
 
 ## Step 1. CI Gate
 
@@ -29,6 +29,17 @@ Quantitatively inspect changed files within the Phase against `{config.code_styl
 - If issues found → fix immediately, then re-run CI Gate (Step 1)
 - If no issues → `✓ Phase {N} Mini-Review passed`
 
+## Step 2.5. Integration/E2E Gate (conditional)
+
+When the phase contains **behavioral changes** (call order modifications, error handling changes, state mutation changes — not pure additions or style fixes):
+
+1. Check if `{config.test}` includes integration or E2E tests
+2. If yes → run `{config.test}` and verify pass
+3. If fail → debug-based RCA (same protocol as Step 1)
+4. If `{config.test}` is empty or has no E2E coverage → skip with note: `⚠ No E2E test configured — behavioral changes not integration-tested`
+
+This gate is skipped for phases with only additive changes (new files, new functions with no existing callers).
+
 ## Step 3. Auto-Checkpoint
 
 After passing the Phase gate, automatically save session state:

package/hooks/hooks.json

@@ -1,4 +1,5 @@
 {
+  "description": "Event hooks for the all-for-claudecode pipeline — CI gates, safety guards, context injection, and workflow automation",
   "hooks": {
     "SessionStart": [
       {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "all-for-claudecode",
-  "version": "2.6.0",
+  "version": "2.7.1",
   "description": "Claude Code plugin that automates the full dev cycle — spec, plan, implement, review, clean.",
   "bin": {
     "all-for-claudecode": "bin/cli.mjs"

package/schemas/hooks.schema.json

@@ -6,6 +6,10 @@
   "required": ["hooks"],
   "additionalProperties": false,
   "properties": {
+    "description": {
+      "type": "string",
+      "description": "Human-readable description of the hook configuration"
+    },
     "hooks": {
       "type": "object",
       "patternProperties": {

package/schemas/plugin.schema.json

@@ -45,9 +45,13 @@
       "type": "string",
       "description": "Path to commands directory"
     },
+    "agents": {
+      "type": "string",
+      "description": "Path to agents directory"
+    },
     "hooks": {
       "type": "string",
-      "description": "Path to hooks directory"
+      "description": "Path to hooks configuration file"
     }
   }
 }

package/scripts/afc-user-prompt-submit.sh

@@ -2,9 +2,8 @@
 set -euo pipefail
 
 # UserPromptSubmit Hook: Two modes of operation:
-# 1. Pipeline INACTIVE: No action (routing handled by CLAUDE.md intent-based skill table)
+# 1. Pipeline INACTIVE: Detect user intent from prompt and inject specific skill routing hint
 # 2. Pipeline ACTIVE: Inject Phase/Feature context + drift checkpoint at thresholds
-# Exit 0 immediately if no action needed (minimize overhead)
 
 # shellcheck source=afc-state.sh
 . "$(dirname "$0")/afc-state.sh"
@@ -15,30 +14,116 @@ cleanup() {
 }
 trap cleanup EXIT
 
-# Consume stdin (required -- pipe breaks if not consumed)
-cat > /dev/null
+# Read stdin (contains user prompt JSON)
+INPUT=$(cat)
 
-# --- Branch: Pipeline INACTIVE → no action needed ---
-# Routing is handled by CLAUDE.md intent-based skill routing table.
-# The main model classifies user intent natively — no hook-level keyword matching.
+# --- Branch: Pipeline INACTIVE -> intent-based skill routing ---
+# The model has CLAUDE.md routing table but static instructions lose effectiveness
+# as context grows. Reading the actual prompt and suggesting a SPECIFIC skill
+# is far more actionable than a generic "check routing table" reminder.
 if ! afc_state_is_active; then
+
+  # Extract prompt text from stdin JSON
+  USER_TEXT=""
+  if command -v jq >/dev/null 2>&1; then
+    USER_TEXT=$(printf '%s' "$INPUT" | jq -r '.prompt // empty' 2>/dev/null || true)
+  else
+    # shellcheck disable=SC2001
+    # Note: sed fallback truncates at first embedded escaped quote — acceptable for keyword matching
+    USER_TEXT=$(printf '%s' "$INPUT" | sed 's/.*"prompt"[[:space:]]*:[[:space:]]*"//;s/".*//' 2>/dev/null || true)
+  fi
+
+  # Skip if prompt is already an explicit slash command
+  if printf '%s' "$USER_TEXT" | grep -qE '^\s*/afc:' 2>/dev/null; then
+    exit 0
+  fi
+
+  # Normalize: lowercase + truncate for matching
+  LOWER=$(printf '%s' "$USER_TEXT" | tr '[:upper:]' '[:lower:]' | cut -c1-500)
+
+  # Early exit for empty prompts (context-only messages, malformed JSON)
+  if [ -z "$LOWER" ]; then
+    if command -v jq >/dev/null 2>&1; then
+      jq -n --arg c "[afc] If this request matches an afc skill, invoke it via Skill tool. See CLAUDE.md routing table." \
+        '{"hookSpecificOutput":{"additionalContext":$c}}'
+    else
+      printf '{"hookSpecificOutput":{"additionalContext":"[afc] If this request matches an afc skill, invoke it via Skill tool. See CLAUDE.md routing table."}}\n'
+    fi
+    exit 0
+  fi
+
+  # Intent detection: priority-ordered if/elif chain.
+  # Each pattern targets strong-signal phrases to minimize false positives.
+  # The model retains final authority — this is a hint, not enforcement.
+  SKILL=""
+  # High confidence: distinctive multi-word or rare keywords
+  if printf '%s' "$LOWER" | grep -qE '(bug|broken|debug|not working|crash|exception)' 2>/dev/null; then
+    SKILL="afc:debug"
+  elif printf '%s' "$LOWER" | grep -qE '(code review|pr review)' 2>/dev/null; then
+    SKILL="afc:review"
+  elif printf '%s' "$LOWER" | grep -qE '(write test|add test|test coverage|improve coverage)' 2>/dev/null; then
+    SKILL="afc:test"
+  elif printf '%s' "$LOWER" | grep -qE '(security scan|security review|security audit|vulnerabilit)' 2>/dev/null; then
+    SKILL="afc:security"
+  elif printf '%s' "$LOWER" | grep -qE '(architecture|architect|system design)' 2>/dev/null; then
+    SKILL="afc:architect"
+  elif printf '%s' "$LOWER" | grep -qE '(doctor|health check|diagnose.*project)' 2>/dev/null; then
+    SKILL="afc:doctor"
+  elif printf '%s' "$LOWER" | grep -qE '(quality audit|qa audit|project quality)' 2>/dev/null; then
+    SKILL="afc:qa"
+  elif printf '%s' "$LOWER" | grep -qE '(new release|version bump|changelog|publish.*package)' 2>/dev/null; then
+    SKILL="afc:launch"
+  # Medium confidence: still distinctive but broader
+  elif printf '%s' "$LOWER" | grep -qE '(specification|requirements|acceptance criteria)' 2>/dev/null; then
+    SKILL="afc:spec"
+  elif printf '%s' "$LOWER" | grep -qE '(brainstorm|ideate|what to build|product brief)' 2>/dev/null; then
+    SKILL="afc:ideate"
+  elif printf '%s' "$LOWER" | grep -qE '(expert advice)' 2>/dev/null; then
+    SKILL="afc:consult"
+  elif printf '%s' "$LOWER" | grep -qE '(analyz|trace.*flow|how does.*work)' 2>/dev/null; then
+    SKILL="afc:analyze"
+  elif printf '%s' "$LOWER" | grep -qE '(research|investigat|compare.*lib)' 2>/dev/null; then
+    SKILL="afc:research"
+  # Lower confidence: common verbs
+  elif printf '%s' "$LOWER" | grep -qE '(implement|add feature|refactor|modify.*code)' 2>/dev/null; then
+    SKILL="afc:implement"
+  elif printf '%s' "$LOWER" | grep -qE '(review)' 2>/dev/null; then
+    SKILL="afc:review"
+  elif printf '%s' "$LOWER" | grep -qE '(spec[^a-z]|spec$)' 2>/dev/null; then
+    SKILL="afc:spec"
+  elif printf '%s' "$LOWER" | grep -qE '(plan[^a-z]|plan$)' 2>/dev/null; then
+    SKILL="afc:plan"
+  fi
+
+  # Build output (no TASK HYGIENE in inactive mode — stop-gate handles cleanup scope)
+  if [ -n "$SKILL" ]; then
+    HINT="[afc:route -> ${SKILL}] Detected intent from user prompt. Invoke /${SKILL} via Skill tool."
+  else
+    HINT="[afc] If this request matches an afc skill, invoke it via Skill tool. See CLAUDE.md routing table."
+  fi
+
+  if command -v jq >/dev/null 2>&1; then
+    jq -n --arg c "$HINT" '{"hookSpecificOutput":{"additionalContext":$c}}'
+  else
+    printf '{"hookSpecificOutput":{"additionalContext":"%s"}}\n' "$HINT"
+  fi
   exit 0
 fi
 
-# --- Branch: Pipeline ACTIVE → existing Phase/Feature context ---
+# --- Branch: Pipeline ACTIVE -> existing Phase/Feature context ---
 
-# Read Feature/Phase + JSON-safe processing (strip special characters)
+# Read Feature/Phase + JSON-safe processing (strip special characters + newlines)
 FEATURE="$(afc_state_read feature || echo '')"
-FEATURE="$(printf '%s' "$FEATURE" | tr -d '"' | cut -c1-100)"
+FEATURE="$(printf '%s' "$FEATURE" | tr -d '"\n\r' | cut -c1-100)"
 PHASE="$(afc_state_read phase || echo 'unknown')"
-PHASE="$(printf '%s' "$PHASE" | tr -d '"' | cut -c1-100)"
+PHASE="$(printf '%s' "$PHASE" | tr -d '"\n\r' | cut -c1-100)"
 
 # Increment per-phase prompt counter + pipeline-wide total
 CALL_COUNT=$(afc_state_increment promptCount 2>/dev/null || echo 0)
 afc_state_increment totalPromptCount >/dev/null 2>&1 || echo "[afc:prompt-submit] totalPromptCount increment failed" >&2
 
 # Build context message
-CONTEXT="[Pipeline: ${FEATURE}] [Phase: ${PHASE}]"
+CONTEXT="[Pipeline: ${FEATURE}] [Phase: ${PHASE}] [TASK HYGIENE: Mark completed tasks via TaskUpdate(status: completed) -- do not leave stale tasks]"
 
 # Drift checkpoint: inject plan constraints at every N prompts during implement/review
 # AFC_DRIFT_THRESHOLD sourced from afc-state.sh (SSOT)
@@ -53,7 +138,7 @@ fi
 
 # Output additionalContext to stdout (injected into Claude context)
 # Use jq for safe JSON encoding; printf fallback strips remaining quotes
-if command -v jq &> /dev/null; then
+if command -v jq >/dev/null 2>&1; then
   jq -n --arg c "$CONTEXT" '{"hookSpecificOutput":{"additionalContext":$c}}'
 else
   SAFE_CONTEXT="${CONTEXT//\\/\\\\}"

package/scripts/session-start-context.sh

@@ -30,9 +30,11 @@ ENCODED_PATH="${PROJECT_PATH//\//-}"
 MEMORY_DIR="$HOME/.claude/projects/$ENCODED_PATH/memory"
 CHECKPOINT="$MEMORY_DIR/checkpoint.md"
 OUTPUT=""
+PIPELINE_ACTIVE=0
 
 # 1. Check for active pipeline
 if afc_state_is_active; then
+  PIPELINE_ACTIVE=1
   FEATURE=$(afc_state_read feature || true)
   OUTPUT="[AFC PIPELINE ACTIVE] Feature: $FEATURE"
 
@@ -77,17 +79,18 @@ if [ -f "$PLUGIN_ROOT/package.json" ]; then
   fi
 fi
 
-# 2. Check if checkpoint exists (project-local first, fallback to auto-memory)
+# 2. Auto-memory checkpoint cleanup (prevent stale context pollution)
+# Auto-memory files are auto-loaded into every conversation by Claude Code.
+# Stale checkpoints from previous sessions can confuse the model.
+# Only remove auto-memory when project-local copy also exists (prevents stranded checkpoint data loss).
 LOCAL_CHECKPOINT="$PROJECT_DIR/.claude/afc/memory/checkpoint.md"
-CHECKPOINT_FILE=""
-if [ -f "$LOCAL_CHECKPOINT" ]; then
-  CHECKPOINT_FILE="$LOCAL_CHECKPOINT"
-elif [ -f "$CHECKPOINT" ]; then
-  CHECKPOINT_FILE="$CHECKPOINT"
+if [ "$PIPELINE_ACTIVE" -eq 0 ] && [ -f "$CHECKPOINT" ] && [ -f "$LOCAL_CHECKPOINT" ]; then
+  rm -f "$CHECKPOINT"
 fi
 
-if [ -n "$CHECKPOINT_FILE" ]; then
-  RAW_LINE=$(grep 'Auto-generated:' "$CHECKPOINT_FILE" 2>/dev/null || echo "")
+# 3. Check if project-local checkpoint exists (for user notification only)
+if [ -f "$LOCAL_CHECKPOINT" ]; then
+  RAW_LINE=$(grep 'Auto-generated:' "$LOCAL_CHECKPOINT" 2>/dev/null || echo "")
   FIRST_LINE=$(printf '%s\n' "$RAW_LINE" | head -1)
   CHECKPOINT_DATE="${FIRST_LINE##*Auto-generated: }"
   if [ -n "$CHECKPOINT_DATE" ]; then
@@ -99,7 +102,7 @@ if [ -n "$CHECKPOINT_FILE" ]; then
   fi
 fi
 
-# 3. Check for safety tag
+# 4. Check for safety tag
 HAS_SAFETY_TAG=$(cd "$PROJECT_DIR" 2>/dev/null && git tag -l 'afc/pre-*' 2>/dev/null | head -1 || echo "")
 if [ -n "$HAS_SAFETY_TAG" ]; then
   if [ -n "$OUTPUT" ]; then