all-for-claudecode 2.11.0 → 2.13.0

package/skills/resolve/SKILL.md

@@ -0,0 +1,245 @@
+---
+name: afc:resolve
+description: "Analyze and address LLM review comments on PR — use when the user asks to resolve, fix, or respond to bot review comments (CodeRabbit, Copilot, Codex) on a pull request"
+argument-hint: "<PR URL, owner/repo#number, #number, or number>"
+allowed-tools:
+  - Read
+  - Grep
+  - Glob
+  - Bash
+  - Edit
+  - Write
+  - AskUserQuestion
+model: sonnet
+---
+
+# /afc:resolve — LLM Review Comment Resolution
+
+> Collects LLM bot review comments (CodeRabbit, Copilot, Codex, etc.) from a PR, classifies each as VALID/NOISE/DISCUSS, applies fixes for VALID items, and asks the user about DISCUSS items.
+> Creates a single commit with all fixes and outputs a summary report.
+
+## Arguments
+
+- `$ARGUMENTS` — (required) One of:
+  - PR number: `456` or `#456`
+  - GitHub URL: `https://github.com/owner/repo/pull/456`
+  - Cross-repo: `owner/repo#456`
+
+## Execution Steps
+
+### 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:
+- Output: `[afc:resolve] Error: GitHub CLI (gh) is not installed or not authenticated. Install from https://cli.github.com/ and run 'gh auth login'.`
+- **Abort immediately.**
+
+### 2. Parse Input
+
+Determine the input format and extract owner, repo, and PR number:
+
+1. **GitHub URL** (`https://github.com/{owner}/{repo}/pull/{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** (`456` or `#456`):
+   - Strip leading `#` if present
+   - Set `GH_REPO_FLAG=""` (use current repo from git remote)
+
+### 3. Collect Review Comments
+
+Collect all review comments from the PR:
+
+```bash
+gh pr view {number} {GH_REPO_FLAG} --json reviews,comments,url,title,headRefName
+```
+
+Additionally, collect inline review comments:
+
+```bash
+gh api repos/{owner}/{repo}/pulls/{number}/comments --paginate
+```
+
+If `--repo` flag was not used, derive owner/repo from `gh repo view --json owner,name`.
+
+If API call fails → output the error and **abort**.
+
+### 4. Filter Bot Comments
+
+Identify LLM bot comments by checking the comment author's login:
+
+**Known bot patterns**:
+- `coderabbitai[bot]` — CodeRabbit
+- `copilot[bot]` or `github-copilot[bot]` — GitHub Copilot
+- `codex[bot]` — Codex
+- Any login ending with `[bot]` — generic bot detection
+
+**Filter rules**:
+- Keep only comments where the author matches a bot pattern
+- Discard all human reviewer comments (MVP scope)
+- If an inline comment is marked as `outdated` by GitHub → tag as `[OUTDATED]`
+
+If 0 bot comments found:
+- Output: `No LLM bot review comments found on PR #{number}.`
+- **Exit gracefully** (success, not error).
+
+### 5. Classify Each Comment
+
+For each bot comment, analyze the content and classify:
+
+| Classification | Criteria | Action |
+|---------------|----------|--------|
+| **VALID** | Real bug, security issue, clear improvement, correct suggestion with code context | Auto-fix |
+| **NOISE** | Style preference difference, intentional design choice, false positive, already addressed | Skip |
+| **DISCUSS** | Architecture decision needed, tradeoff exists, multiple valid approaches, no code `path`/`position` (non-code feedback) | Ask user |
+
+**Classification guidelines**:
+- If the comment points to a concrete bug (null check, off-by-one, resource leak) → **VALID**
+- If the comment is about naming convention or style that differs from project rules → **NOISE**
+- If the comment suggests a refactor with pros/cons → **DISCUSS**
+- If multiple bots give conflicting advice on the same line → **DISCUSS**
+- If the comment is on an `[OUTDATED]` diff → **NOISE** (code already changed)
+
+Also collect from each comment:
+- `file_path`: the file the comment targets
+- `line`: the line number (if available)
+- `suggestion`: the suggested change (if available)
+- `body`: the full comment text
+
+### 6. Present Classification Summary
+
+Before making any changes, present the classification to the user:
+
+```
+PR #{number}: {title}
+Branch: {headRefName}
+
+Bot comments: {total_count} ({bot_names})
+
+VALID ({count}):
+  1. [{bot}] {file}:{line} — {1-line summary of issue}
+  2. [{bot}] {file}:{line} — {1-line summary of issue}
+
+NOISE ({count}):
+  1. [{bot}] {file}:{line} — {reason for skipping}
+
+DISCUSS ({count}):
+  1. [{bot}] {file}:{line} — {question for user}
+```
+
+### 7. Handle DISCUSS Items
+
+For each DISCUSS item, present to the user:
+
+```
+[DISCUSS #{n}] {bot_name} on {file}:{line}
+
+Comment:
+> {original comment text, truncated to 500 chars}
+
+Target code:
+> {relevant code snippet, 5 lines context}
+
+If applied: {description of what would change}
+Tradeoff: {why this is not a clear-cut decision}
+
+Options:
+  1. Apply — treat as VALID, fix the code
+  2. Skip — treat as NOISE, record skip reason
+  3. Defer — skip for now, revisit later
+```
+
+Wait for user response. Reclassify based on choice:
+- `Apply` → move to VALID list
+- `Skip` → move to NOISE list with user's reason
+- `Defer` → keep as DISCUSS in report
+
+### 8. Apply VALID Fixes
+
+For each VALID comment (including user-accepted DISCUSS items):
+
+1. **Read the target file** before modifying
+2. **Identify the exact location** from the comment's `file_path` and `line`
+3. **Apply the fix** using Edit tool:
+   - If the bot provided a specific code suggestion → apply it
+   - If the bot described the issue without a suggestion → implement the fix based on the description
+4. **Verify** the fix doesn't break the immediate surrounding code context
+
+If the target file is in a dirty state (uncommitted changes unrelated to this PR):
+- Warn user: `{file} has uncommitted changes not related to this PR. Proceed?`
+- If user declines → skip this fix, note in report
+
+If the target file was deleted in the PR branch:
+- Skip, note `[FILE DELETED]` in report
+
+### 9. Commit Changes
+
+**Before committing**, show the user a summary of all changes:
+
+```
+Changes to commit:
+  {file1}: {description of change}
+  {file2}: {description of change}
+  Total: {N} files changed
+
+Proceed with commit? (y/n)
+```
+
+**Wait for user confirmation** before committing. This is a safety requirement.
+
+**Commit strategy**:
+- If VALID items ≤ 9: single commit
+- If VALID items ≥ 10: group by file/module into 2-3 commits
+
+**Commit message format** (single commit):
+```
+resolve LLM review comments on #{number}
+
+- fix: {description} ({bot_name})
+- fix: {description} ({bot_name})
+- skip: {reason} (NOISE, {count} items)
+```
+
+Do **NOT** push automatically. The user decides when to push.
+
+### 10. Output Report
+
+```
+Resolve complete
+├─ PR: #{number} — {title}
+├─ Bot comments: {total} ({bot_names})
+├─ VALID: {count} (applied)
+├─ NOISE: {count} (skipped)
+├─ DISCUSS: {count} (applied: {n}, skipped: {n}, deferred: {n})
+├─ Commit: {hash} ({files_changed} files, +{additions}/-{deletions})
+└─ Push: not pushed (run 'git push' when ready)
+```
+
+If no VALID items were found (all NOISE/DISCUSS-skipped):
+```
+Resolve complete
+├─ PR: #{number} — {title}
+├─ Bot comments: {total} ({bot_names})
+├─ VALID: 0
+├─ NOISE: {count}
+├─ DISCUSS: {count} (all skipped/deferred)
+└─ No changes made
+```
+
+## Notes
+
+- **MVP scope**: Only bot comments are analyzed. Human reviewer comments are ignored. Use `afc:review` for human-initiated code review.
+- **No auto-push**: Changes are committed but never pushed automatically. The user controls when to push.
+- **User confirmation required**: All code changes must be confirmed by the user before committing (NFR-003 safety requirement).
+- **Not part of auto pipeline**: This is a standalone skill invoked manually.
+- **Idempotency**: Re-running on the same PR will skip comments that have already been addressed (the code diff won't match the bot's original concern).
+- **Relationship to other skills**: `afc:review` does full code review. `afc:pr-comment` posts review comments. `afc:resolve` addresses existing bot comments. They are complementary.

package/skills/review/SKILL.md

@@ -276,7 +276,7 @@ If `.claude/afc/memory/retrospectives/` directory exists, load the **most recent
 
 ### 6. Critic Loop
 
-> **Always** read `${CLAUDE_PLUGIN_ROOT}/docs/critic-loop-rules.md` first and follow it.
+> **Always** read `${CLAUDE_SKILL_DIR}/../../docs/critic-loop-rules.md` first and follow it.
 
 Run the critic loop until convergence. Safety cap: 5 passes.
 

package/skills/setup/SKILL.md

@@ -0,0 +1,219 @@
+---
+name: afc:setup
+description: "Global CLAUDE.md configuration — use when the user asks to set up afc routing in their global config, update the AFC block version, or resolve routing conflicts"
+argument-hint: "[--force]"
+allowed-tools:
+  - Read
+  - Write
+  - Bash
+  - Glob
+model: sonnet
+---
+
+# /afc:setup — Global CLAUDE.md Configuration
+
+> Manages the all-for-claudecode routing block in `~/.claude/CLAUDE.md`.
+> Handles injection, updates, conflict detection, and legacy migration of the AFC block.
+> This is a **global config** operation — it modifies `~/.claude/CLAUDE.md`, NOT project files.
+> For project-local setup (config, rules, profile), use `/afc:init` instead.
+
+This skill is a **prompt-only skill** — there is no bash script.
+All steps below are instructions for the LLM to execute directly using its allowed tools.
+
+## Arguments
+
+- `$ARGUMENTS` — (optional) flags:
+  - `--force` — skip conflict prompts and use coexistence mode
+
+## Execution Steps
+
+### 1. Version Resolution
+
+Read `${CLAUDE_SKILL_DIR}/../../package.json` and extract the `"version"` field. Use this value as `{PLUGIN_VERSION}` throughout.
+
+### 2. Check Current State
+
+Read `~/.claude/CLAUDE.md`. If file does not exist, create it with an empty body and proceed to Step 5.
+
+Check for:
+- `<!-- AFC:START -->` marker → existing AFC block found
+- `<!-- SELFISH:START -->` marker → legacy v1.x block found
+- Neither → fresh install
+
+**If existing AFC block found:**
+- Extract version from `<!-- AFC:VERSION:X.Y.Z -->`
+- If version matches `{PLUGIN_VERSION}`: print `AFC block already up to date (v{PLUGIN_VERSION})` and **stop**
+- If version differs: proceed to Step 3 (will replace)
+
+**If legacy SELFISH block found:**
+- Remove entire `<!-- SELFISH:START -->` ~ `<!-- SELFISH:END -->` block
+- Print: `Removed legacy SELFISH block`
+- Proceed to Step 3
+
+### 3. Conflict Pattern Scan
+
+Search `~/.claude/CLAUDE.md` for routing conflicts. **IMPORTANT: EXCLUDE content inside any marker blocks (`<!-- *:START -->` ~ `<!-- *:END -->`). Only scan unguarded content outside marker blocks.** Other tools (OMC, etc.) manage their own blocks — their internal agent names are not conflicts.
+
+**A. Marker Block Detection**
+- Regex: `<!-- ([A-Z0-9_-]+):START -->` ~ `<!-- \1:END -->`
+- Record all found block names and line ranges
+- **Strip these ranges from the scan target** — only scan lines NOT inside any marker block
+
+**B. Agent Routing Conflict Detection**
+In the **unguarded** (non-marker-block) content only, find directives containing these keywords:
+- `executor`, `deep-executor` — conflicts with afc:implement
+- `code-reviewer`, `quality-reviewer`, `style-reviewer`, `api-reviewer`, `security-reviewer`, `performance-reviewer` — conflicts with afc:review
+- `debugger` (in agent routing context) — conflicts with afc:debug
+- `planner` (in agent routing context) — conflicts with afc:plan
+- `analyst`, `verifier` — conflicts with afc:validate
+- `test-engineer` — conflicts with afc:test
+
+**C. Skill Routing Conflict Detection**
+In the **unguarded** content only, find these patterns:
+- Another tool's skill trigger table (e.g., tables like `| situation | skill |`)
+- `delegate to`, `route to`, `always use` + agent name combinations
+- Directives related to `auto-trigger`, `intent detection`, `intent-based routing`
+
+**D. Legacy Block Detection**
+Previous versions without markers or with old branding:
+- `## all-for-claudecode Auto-Trigger Rules`
+- `## all-for-claudecode Integration`
+- `<selfish-pipeline>` / `</selfish-pipeline>` XML tags
+
+### 4. Report Conflicts and User Choice
+
+**No conflicts found** → proceed directly to Step 5
+
+**Conflicts found** (skip if `--force` flag present — default to coexistence):
+
+```
+CLAUDE.md Scan Results
+├─ Tool blocks found: {block name list} (lines {range})
+├─ Agent routing conflicts: {conflict count}
+│   e.g., "executor" (line XX) ↔ afc:implement
+│   e.g., "code-reviewer" (line XX) ↔ afc:review
+└─ Skill routing conflicts: {conflict count}
+```
+
+Ask user:
+
+> "Directives overlapping with afc were found. How would you like to proceed?"
+>
+> 1. **afc-exclusive mode** — Adds override rules in the AFC block to cover conflicting directives.
+>    Does not modify other tools' marker block contents.
+> 2. **coexistence mode** — Adds only the AFC block without overrides.
+>    Since it's at the end of the file, afc directives will likely take priority.
+> 3. **manual cleanup** — Shows the conflict list only and stops.
+
+Based on choice:
+- **Option 1**: AFC block includes explicit override rules (see conflict-overrides section below)
+- **Option 2**: AFC block added without overrides (base template as-is)
+- **Option 3**: Print conflict list only and abort without modifying CLAUDE.md
+
+### 5. Inject AFC Block
+
+Add the following block at the **very end** of `~/.claude/CLAUDE.md` (later-positioned directives have higher priority).
+
+Replace existing AFC block if present, otherwise append.
+If legacy block (`## all-for-claudecode Auto-Trigger Rules` etc.) exists, remove it then append.
+
+```markdown
+<!-- AFC:START -->
+<!-- AFC:VERSION:{PLUGIN_VERSION} -->
+<afc-pipeline>
+IMPORTANT: For requests matching the afc skill routing table below, always invoke the corresponding skill via the Skill tool. Do not substitute with other agents or tools.
+
+## Skill Routing
+
+Classify the user's intent and route to the matching skill. Use semantic understanding — not keyword matching.
+
+| User Intent | Skill | Route When |
+|-------------|-------|------------|
+| Full lifecycle | `afc:auto` | User wants end-to-end feature development, or the request is a non-trivial new feature without an existing plan |
+| Specification | `afc:spec` | User wants to define or write requirements, acceptance criteria, or success conditions |
+| Design/Plan | `afc:plan` | User wants to plan HOW to implement before coding — approach, architecture decisions, design |
+| Implement | `afc:implement` | User wants specific code changes with a clear scope: add feature, refactor, modify. Requires existing plan or precise instructions |
+| Review | `afc:review` | User wants code review, PR review, or quality check on existing/changed code |
+| Debug/Fix | `afc:debug` | User reports a bug, error, or broken behavior and wants diagnosis and fix |
+| Test | `afc:test` | User wants to write tests, improve coverage, or verify behavior |
+| Validate | `afc:validate` | User wants to check consistency or validate existing pipeline artifacts |
+| Analyze | `afc:analyze` | User wants to understand, explore, or audit existing code without modifying it |
+| QA Audit | `afc:qa` | User wants project quality audit, test confidence check, or runtime quality gaps |
+| Research | `afc:research` | User wants deep investigation of external tools, libraries, APIs, or technical concepts |
+| Ideate | `afc:ideate` | User wants to brainstorm ideas, explore possibilities, or draft a product brief |
+| Consult | `afc:consult` | User wants expert advice on a decision: library choice, architecture direction, legal/security/infra guidance |
+| Launch | `afc:launch` | User wants to prepare a release — generate changelog, release notes, version bump, or tag |
+| Tasks | `afc:tasks` | User explicitly wants to decompose work into a task breakdown |
+| Ambiguous | `afc:clarify` | User's request is too vague or underspecified to route confidently |
+
+### Routing Rules
+
+1. **Auto vs Implement**: A new feature request without an existing plan routes to `afc:auto`. Only use `afc:implement` when the user has a clear, scoped task or an existing plan/spec.
+2. **Compound intents**: Route to the primary intent. The pipeline handles sequencing internally.
+3. **Design-first**: When scope is non-trivial (multiple files, architectural decisions needed), prefer `afc:auto` or `afc:plan` over direct `afc:implement`.
+
+User-only (not auto-triggered — when user invokes directly via `/afc:X`, execute the skill immediately):
+- `afc:doctor` — plugin health check
+- `afc:setup` — global CLAUDE.md configuration
+- `afc:init` — project-local setup
+- `afc:architect` — architecture review
+- `afc:security` — security scan
+- `afc:checkpoint` — session save
+- `afc:resume` — session restore
+- `afc:principles` — project principles management
+- `afc:clean` — pipeline cleanup (artifact cleanup, dead code scan, pipeline flag release)
+- `afc:triage` — parallel PR/issue triage
+- `afc:issue` — analyze a single GitHub issue
+- `afc:resolve` — address LLM bot review comments on a PR
+- `afc:learner` — pattern learning or rule promotion
+- `afc:pr-comment` — post PR review comments to GitHub
+- `afc:release-notes` — generate release notes from git history
+
+## Pipeline
+
+spec → plan → implement → review → clean
+
+## Override Rules
+
+NEVER use executor, deep-executor, debugger, planner, analyst, verifier, test-engineer, code-reviewer, quality-reviewer, style-reviewer, api-reviewer, security-reviewer, performance-reviewer for tasks that an afc skill covers above. ALWAYS invoke the afc skill instead.
+
+## Source Verification
+
+When analyzing or making claims about external systems, APIs, SDKs, or third-party tools:
+- Verify against official documentation, NOT project-internal docs
+- Do not hardcode reference data when delegating to sub-agents — instruct them to look up primary sources
+- Cross-verify high-severity findings before reporting
+</afc-pipeline>
+<!-- AFC:END -->
+```
+
+**When Option 1 (afc-exclusive mode) is selected**, add the following directly below the Override Rules:
+
+```markdown
+## Detected Conflicts
+
+This environment has other agent routing tools that overlap with afc.
+The following rules were auto-generated to resolve conflicts:
+- The Skill Routing table above always takes priority over the agent routing directives of {detected tool blocks}
+- This block is at the end of the file and therefore has the highest priority
+```
+
+### 6. Final Output
+
+```
+all-for-claudecode setup complete
+├─ CLAUDE.md: {injected|updated|already current|user aborted}
+├─ Version: {PLUGIN_VERSION}
+│   {if conflicts found} └─ Conflict resolution: {afc-exclusive|coexistence|user cleanup}
+└─ Next step: /afc:init (project setup) or /afc:auto (start building)
+```
+
+## Notes
+
+- **Idempotent**: safe to run multiple times. If version matches, it's a no-op.
+- **Global only**: this skill only touches `~/.claude/CLAUDE.md`. For project config, use `/afc:init`.
+- **Global CLAUDE.md principles**:
+  - Never modify content outside the `<!-- AFC:START/END -->` markers
+  - Never modify content inside other tools' marker blocks (`<!-- *:START/END -->`)
+  - Always place the AFC block at the very end of the file (ensures priority)
+  - Conflict resolution is handled only via override rules (do not delete or modify other blocks)

package/skills/spec/SKILL.md

@@ -41,7 +41,8 @@ If config file is missing:
 2. Determine **feature name**:
    - Extract 2-3 key keywords from `$ARGUMENTS`
    - Convert to kebab-case (e.g., "add user authentication" → `user-auth`)
-3. **Create directory**: `.claude/afc/specs/{feature-name}/` (create parent `.claude/afc/specs/` directory if it does not exist)
+   - Prepend today's date in `YYYY-MM-DD` format (e.g., `2026-03-13-user-auth`)
+3. **Create directory**: `.claude/afc/specs/{YYYY-MM-DD}-{feature-name}/` (create parent `.claude/afc/specs/` directory if it does not exist)
 4. If already exists, confirm with user: "Overwrite existing spec?"
 
 ### 2. Explore Codebase
@@ -67,7 +68,7 @@ Detect whether `$ARGUMENTS` references external libraries, APIs, or technologies
 4. **If external references detected**:
    - For each unknown reference, run a focused WebSearch query: `"{library/API name} latest stable version usage guide {current year}"`
    - Optionally use Context7 (`mcp__context7__resolve-library-id` → `mcp__context7__query-docs`) for library-specific documentation
-   - Record findings to `.claude/afc/specs/{feature-name}/research-notes.md` (lightweight spec-scoped notes; distinct from plan phase's `research.md` which covers deep technical research)
+   - Record findings to `.claude/afc/specs/{YYYY-MM-DD}-{feature-name}/research-notes.md` (lightweight spec-scoped notes; distinct from plan phase's `research.md` which covers deep technical research)
    - Also use findings inline as context for spec writing
    - Tag each researched item in spec with `[RESEARCHED]` for traceability
 
@@ -75,7 +76,7 @@ Detect whether `$ARGUMENTS` references external libraries, APIs, or technologies
 
 ### 3. Write Spec
 
-Create `.claude/afc/specs/{feature-name}/spec.md` following the template in `${CLAUDE_SKILL_DIR}/spec-template.md`. Read it first, then generate the spec using that structure.
+Create `.claude/afc/specs/{YYYY-MM-DD}-{feature-name}/spec.md` following the template in `${CLAUDE_SKILL_DIR}/spec-template.md`. Read it first, then generate the spec using that structure.
 
 ### 3.5. Inline Clarification (standalone mode only)
 
@@ -98,7 +99,7 @@ If `.claude/afc/memory/retrospectives/` directory exists, load the **most recent
 
 ### 5. Critic Loop
 
-> **Always** read `${CLAUDE_PLUGIN_ROOT}/docs/critic-loop-rules.md` first and follow it.
+> **Always** read `${CLAUDE_SKILL_DIR}/../../docs/critic-loop-rules.md` first and follow it.
 
 Run the critic loop until convergence. Safety cap: 5 passes.
 
@@ -127,7 +128,7 @@ When not running inside `/afc:auto`, save progress for `/afc:resume`:
 
 ```
 Spec generated
-├─ .claude/afc/specs/{feature-name}/spec.md
+├─ .claude/afc/specs/{YYYY-MM-DD}-{feature-name}/spec.md
 ├─ User Stories: {count}
 ├─ Requirements: FR {count}, NFR {count}
 ├─ Research: {N} external references researched / skipped (all internal)

package/skills/tasks/SKILL.md

@@ -80,8 +80,8 @@ Decompose tasks per Phase defined in plan.md.
 1. **1 task = 1 file** principle (where possible)
 2. **Same file = sequential**, **different files = [P] candidate**
 3. **Explicit dependencies**: Use `depends: [T001, T002]` to declare blocking dependencies. Tasks without `depends:` and with [P] marker are immediately parallelizable.
-4. **[P] physical validation**: Before finalizing tasks.md, run `"${CLAUDE_PLUGIN_ROOT}/scripts/afc-parallel-validate.sh" .claude/afc/specs/{feature}/tasks.md` to verify no file path overlaps exist among [P] tasks within the same phase. Fix any conflicts before proceeding.
-5. **Dependency graph must be a DAG**: no circular dependencies allowed. **Mandatory validation**: run `"${CLAUDE_PLUGIN_ROOT}/scripts/afc-dag-validate.sh" .claude/afc/specs/{feature}/tasks.md` before output. Abort if cycle detected.
+4. **[P] physical validation**: Before finalizing tasks.md, run `"${CLAUDE_SKILL_DIR}/../../scripts/afc-parallel-validate.sh" .claude/afc/specs/{feature}/tasks.md` to verify no file path overlaps exist among [P] tasks within the same phase. Fix any conflicts before proceeding.
+5. **Dependency graph must be a DAG**: no circular dependencies allowed. **Mandatory validation**: run `"${CLAUDE_SKILL_DIR}/../../scripts/afc-dag-validate.sh" .claude/afc/specs/{feature}/tasks.md` before output. Abort if cycle detected.
 6. **Test tasks**: Include a verification task for each testable unit
 7. **Phase gate**: Add a `{config.gate}` validation task at the end of each Phase
 
@@ -93,14 +93,14 @@ If `.claude/afc/memory/retrospectives/` directory exists, load the **most recent
 
 ### 4. Critic Loop
 
-> **Always** read `${CLAUDE_PLUGIN_ROOT}/docs/critic-loop-rules.md` first and follow it.
+> **Always** read `${CLAUDE_SKILL_DIR}/../../docs/critic-loop-rules.md` first and follow it.
 
 Run the critic loop until convergence. Safety cap: 5 passes.
 
 | Criterion | Validation |
 |-----------|------------|
 | **COVERAGE** | Are all files in plan.md's File Change Map included in tasks? Are all FR-* in spec.md covered? |
-| **DEPENDENCIES** | Is the dependency graph a valid DAG? Do [P] tasks within the same phase have no file overlaps? Are all `depends:` targets valid task IDs? For physical validation of [P] file overlaps, reference the validation script: `"${CLAUDE_PLUGIN_ROOT}/scripts/afc-parallel-validate.sh"` can be called with the tasks.md path to verify no conflicts exist. |
+| **DEPENDENCIES** | Is the dependency graph a valid DAG? Do [P] tasks within the same phase have no file overlaps? Are all `depends:` targets valid task IDs? For physical validation of [P] file overlaps, reference the validation script: `"${CLAUDE_SKILL_DIR}/../../scripts/afc-parallel-validate.sh"` can be called with the tasks.md path to verify no conflicts exist. |
 
 **On FAIL**: auto-fix and continue to next pass.
 **On ESCALATE**: pause, present options to user, apply choice, resume.

package/skills/test/SKILL.md

@@ -93,7 +93,7 @@ Confirm strategy with user before proceeding.
 
 ### 4. Critic Loop
 
-> **Always** read `${CLAUDE_PLUGIN_ROOT}/docs/critic-loop-rules.md` first and follow it.
+> **Always** read `${CLAUDE_SKILL_DIR}/../../docs/critic-loop-rules.md` first and follow it.
 
 Run the critic loop until convergence. Safety cap: 5 passes.
 

package/skills/triage/SKILL.md

@@ -33,7 +33,7 @@ model: sonnet
 Run the metadata collection script:
 
 ```bash
-"${CLAUDE_PLUGIN_ROOT}/scripts/afc-triage.sh" "$ARGUMENTS"
+"${CLAUDE_SKILL_DIR}/../../scripts/afc-triage.sh" "$ARGUMENTS"
 ```
 
 This returns JSON with PR/issue metadata. If the script is not available, fall back to direct `gh` commands: