all-for-claudecode 2.10.0 → 2.12.0

package/skills/setup/SKILL.md

@@ -0,0 +1,217 @@
+---
+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: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

@@ -53,7 +53,7 @@ Before writing the spec, understand the current project structure:
 3. Identify related type definitions, APIs, and components
 4. **Necessity & scope check** — evaluate whether the request warrants a full spec:
    - **Already exists?** If the feature substantially exists → report: "This feature appears to already exist at {path}." Ask user: enhance existing, replace entirely, or abort.
-   - **Over-scoped?** If `$ARGUMENTS` implies 10+ files or multiple unrelated concerns → warn and suggest splitting into separate specs.
+   - **Over-scoped?** If `$ARGUMENTS` implies multiple unrelated concerns or changes that span different architectural boundaries, warn and suggest splitting. Judge by the diversity and independence of concerns, not by file count — a well-organized feature touching many files in one module is fine, while a small change spanning security, database, and UI layers may be over-scoped.
    - **Trivial?** If the change is small enough to implement directly (typo, config value, single-line fix) → suggest: "This can be implemented directly without a full spec. Proceed with direct edit?"
    - If user chooses abort → end with `"No spec generated — {reason}."` and suggest the appropriate alternative.
 
@@ -98,7 +98,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.
 

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:
@@ -71,9 +71,8 @@ Task("Triage PR #{number}: {title}", subagent_type: "general-purpose",
   2. Run: gh pr view {number} --comments
   3. Analyze the diff for:
      - What the PR does (1-2 sentence summary)
-     - Risk level: Critical (core logic, auth, data, security-related config) / Medium (features, UI) / Low (docs, non-security config, tests)
-       NOTE: Config files that touch auth, security, permissions, secrets, or access control keywords are Critical, not Low
-     - Complexity: High (>10 files or cross-cutting) / Medium (3-10 files) / Low (<3 files)
+     - Risk level: Assess the actual impact of this PR on the system. Consider: does it change trust boundaries, data flows, or core business logic? Could a bug here cause data loss, security breach, or service outage? Rate risk based on potential blast radius, not file categories.
+     - Complexity: Assess the cognitive complexity of reviewing this PR. Consider: how many distinct concerns does it touch, does it cross architectural boundaries, does understanding one change require understanding another? Rate complexity based on review difficulty, not file count.
      - Whether build/test verification is needed (yes/no + reason)
      - Potential issues or concerns (max 3)
      - Suggested reviewers or labels if obvious
@@ -98,9 +97,9 @@ Task("Triage Issues #{n1}-#{n5}", subagent_type: "general-purpose",
   For each issue:
   1. Read issue body and comments: gh issue view {number} --comments
   2. Classify:
-     - Type: Bug / Feature / Enhancement / Question / Maintenance
-     - Priority: P0 (blocking) / P1 (important) / P2 (nice-to-have) / P3 (backlog)
-     - Estimated effort: Small (< 1 day) / Medium (1-3 days) / Large (3+ days)
+     - Type: Classify based on the issue's actual nature. The standard categories (Bug, Feature, Enhancement, Question, Maintenance) serve as defaults, but adapt to the project's own labeling conventions if they differ.
+     - Priority: Assess priority based on the issue's relationship to current work, user impact, and project goals — not by forcing into generic P0-P3 buckets. Consider: is this blocking other work? How many users are affected? Does it align with current priorities?
+     - Estimated effort: Estimate based on the actual scope of work required, considering project complexity and available context — not by rigid day-count buckets.
      - Related PRs (if any mentioned)
   3. One-line summary
 
@@ -203,7 +202,7 @@ Merge Phase 1 and Phase 2 results into a single report:
 - **Immediate attention**: {list of Critical PRs and P0 issues}
 - **Ready to merge**: {PRs with no concerns and passing checks}
 - **Needs discussion**: {PRs/issues requiring team input}
-- **Stale items**: {PRs/issues with no activity > 14 days}
+- **Stale items**: {PRs/issues with no meaningful activity for an extended period. Consider the project's typical development cadence — what counts as stale depends on the project's release cycle and activity patterns.}
 ```
 
 ### 5. Save Report