all-for-claudecode 2.12.0 → 2.14.0

package/skills/triage/SKILL.md

@@ -14,9 +14,15 @@ model: sonnet
 
 # /afc:triage — PR & Issue Triage
 
-> Collects open PRs and issues, analyzes them in parallel, and produces a priority-ranked triage report.
+> Collects open PRs and issues, analyzes them in parallel batch, and produces a priority-ranked triage report.
 > Uses lightweight analysis first (no checkout), then selective deep analysis with worktree isolation for PRs that require build/test verification.
 
+## Pre-fetched Context
+
+!`gh pr list --json number,title,headRefName,author,labels,additions,deletions,changedFiles,createdAt,updatedAt,reviewDecision,isDraft --limit 50 2>/dev/null || echo "PR_FETCH_FAILED"`
+
+!`gh issue list --json number,title,labels,author,createdAt,updatedAt,comments --limit 50 2>/dev/null || echo "ISSUE_FETCH_FAILED"`
+
 ## Arguments
 
 - `$ARGUMENTS` — (optional) Triage scope
@@ -30,64 +36,28 @@ model: sonnet
 
 ### 1. Collect Targets
 
-Run the metadata collection script:
+Use the pre-fetched context above. If fetch failed, fall back to:
 
 ```bash
 "${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:
-
-```bash
-# PRs
-gh pr list --json number,title,headRefName,author,labels,additions,deletions,changedFiles,createdAt,updatedAt,reviewDecision,isDraft --limit 50
-
-# Issues
-gh issue list --json number,title,labels,author,createdAt,updatedAt,comments --limit 50
-```
+Apply `$ARGUMENTS` filtering: skip irrelevant items based on `--pr`, `--issue`, or specific numbers.
 
-### 2. Phase 1 — Lightweight Parallel Analysis (no checkout)
+### 2. Phase 1 — Lightweight Parallel Batch (no checkout)
 
-For each PR/issue, gather analysis data **without** checking out branches:
+Spawn all agents in a **single message** (parallel batch, max 5 concurrent).
 
-#### PR Analysis (parallel — one agent per PR, max 5 concurrent)
+#### PR Analysis
 
-Spawn parallel agents in a **single message**:
+See prompt template: [pr-analysis-prompt.md](./pr-analysis-prompt.md)
 
 ```
 Task("Triage PR #{number}: {title}", subagent_type: "general-purpose",
-  prompt: "Analyze this PR without checking out the branch.
-
-  PR #{number}: {title}
-  Author: {author}
-  Branch: {headRefName}
-  Changed files: {changedFiles}, +{additions}/-{deletions}
-  Labels: {labels}
-  Review status: {reviewDecision}
-  Draft: {isDraft}
-
-  Steps:
-  1. Run: gh pr diff {number}
-  2. Run: gh pr view {number} --comments
-  3. Analyze the diff for:
-     - What the PR does (1-2 sentence summary)
-     - 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
-
-  Output as structured text:
-  SUMMARY: ...
-  RISK: Critical|Medium|Low
-  COMPLEXITY: High|Medium|Low
-  NEEDS_DEEP: yes|no
-  DEEP_REASON: ... (if yes)
-  CONCERNS: ...
-  SUGGESTION: ...")
+  prompt: "<contents of pr-analysis-prompt.md with placeholders filled>")
 ```
 
-#### Issue Analysis (parallel — one agent per batch of 5 issues)
+#### Issue Analysis (batch of 5 per agent)
 
 ```
 Task("Triage Issues #{n1}-#{n5}", subagent_type: "general-purpose",
@@ -95,15 +65,15 @@ Task("Triage Issues #{n1}-#{n5}", subagent_type: "general-purpose",
   {issue list with titles, labels, comment count}
 
   For each issue:
-  1. Read issue body and comments: gh issue view {number} --comments
+  1. gh issue view {number} --comments
   2. Classify:
-     - 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.
+     - Type: Bug|Feature|Enhancement|Question|Maintenance (adapt to project labels)
+     - Priority: P0 (blocking/critical) | P1 (high impact) | P2 (normal) | P3 (low/nice-to-have)
+     - Effort: Small|Medium|Large
      - Related PRs (if any mentioned)
   3. One-line summary
 
-  Output as structured text per issue:
+  Output per issue:
   ISSUE #{number}: {title}
   TYPE: ...
   PRIORITY: P0|P1|P2|P3
@@ -114,9 +84,9 @@ Task("Triage Issues #{n1}-#{n5}", subagent_type: "general-purpose",
 
 ### 3. Phase 2 — Selective Deep Analysis (worktree, optional)
 
-From Phase 1 results, identify PRs where `NEEDS_DEEP: yes`.
+From Phase 1, identify PRs where `NEEDS_DEEP: yes`.
 
-For each deep-analysis PR, spawn a **worktree-isolated agent**:
+For each, spawn a worktree-isolated agent (max 3 concurrent):
 
 ```
 Task("Deep triage PR #{number}", subagent_type: "afc:afc-pr-analyst",
@@ -127,11 +97,10 @@ Task("Deep triage PR #{number}", subagent_type: "afc:afc-pr-analyst",
   Phase 1 concerns: {concerns from Phase 1}
 
   Steps:
-  1. Checkout the PR branch: gh pr checkout {number}
-  2. Run project CI/test commands if available (from .claude/afc.config.md or CLAUDE.md)
-  3. Check for type errors, lint issues, test failures
-  4. Analyze architectural impact
-  5. Report findings
+  1. gh pr checkout {number}
+  2. Run CI commands from .claude/afc.config.md or CLAUDE.md
+  3. Check type errors, lint issues, test failures
+  4. Report architectural impact
 
   Output:
   BUILD_STATUS: pass|fail|skip
@@ -141,28 +110,14 @@ Task("Deep triage PR #{number}", subagent_type: "afc:afc-pr-analyst",
   RECOMMENDATION: merge|request-changes|needs-discussion")
 ```
 
-**Important**: Launch at most 3 worktree agents concurrently to avoid resource contention.
-
-If `--deep` flag was specified, run Phase 2 for **all** PRs regardless of Phase 1 classification.
+If `--deep` flag 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.
+See: [coupling-detection.md](./coupling-detection.md)
 
 ### 4. Consolidate Triage Report
 
-Merge Phase 1 and Phase 2 results into a single report:
-
 ```markdown
 # Triage Report
 
@@ -176,7 +131,7 @@ Merge Phase 1 and Phase 2 results into a single report:
 
 | # | Title | Risk | Complexity | Status | Action |
 |---|-------|------|------------|--------|--------|
-| {sorted by: Critical first, then by staleness} |
+| {sorted: Critical first, then by staleness} |
 
 ### PR Details
 
@@ -195,25 +150,23 @@ Merge Phase 1 and Phase 2 results into a single report:
 
 | Priority | # | Title | Type | Effort | Related PR |
 |----------|---|-------|------|--------|------------|
-| {sorted by priority, then by creation date} |
+| {sorted by priority, then creation date} |
 
 ## Summary
 
-- **Immediate attention**: {list of Critical PRs and P0 issues}
+- **Immediate attention**: {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 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.}
+- **Stale items**: {items with no meaningful activity relative to project cadence}
 ```
 
 ### 5. Save Report
 
-Save the triage report:
-
 ```
 .claude/afc/memory/triage/{YYYY-MM-DD}.md
 ```
 
-If a previous triage report exists for today, overwrite it.
+Overwrite if a report for today already exists.
 
 ### 6. Final Output
 
@@ -229,8 +182,8 @@ Triage complete
 
 ## Notes
 
-- **Read-only**: Triage does not modify any code, merge PRs, or close issues.
-- **Rate limits**: `gh` API calls are rate-limited. For repos with 50+ open items, consider using `--pr` or `--issue` to reduce scope.
-- **Worktree cleanup**: Worktree agents auto-clean on completion. If a worktree is left behind, use `git worktree prune`.
-- **NEVER use `run_in_background: true` on Phase 1 Task calls**: agents must run in foreground so results are collected before consolidation. Phase 2 worktree agents also run in foreground.
-- **Parallel limits**: Phase 1 — max 5 concurrent agents. Phase 2 — max 3 concurrent worktree agents.
+- **Read-only**: Does not modify code, merge PRs, or close issues.
+- **Rate limits**: For repos with 50+ open items, use `--pr` or `--issue` to reduce scope.
+- **Worktree cleanup**: Worktree agents auto-clean on completion. If left behind: `git worktree prune`.
+- **NEVER use `run_in_background: true`** on Phase 1 or Phase 2 Task calls — results must be collected before consolidation.
+- **Parallel limits**: Phase 1 — max 5 concurrent (parallel batch). Phase 2 — max 3 concurrent worktree agents.

package/skills/triage/coupling-detection.md

@@ -0,0 +1,13 @@
+# 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 (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:
+   ```
+   COUPLING: PR #{A} and PR #{B} both modify {path/to/file}
+   ```
+4. Include coupling annotations in the Priority Actions table and per-PR details
+
+This identifies merge-order dependencies and potential conflict risks that no single-PR agent can detect.

package/skills/triage/pr-analysis-prompt.md

@@ -0,0 +1,46 @@
+# PR Analysis Prompt Template
+
+Use this prompt for each Phase 1 parallel batch agent:
+
+```
+Analyze this PR without checking out the branch.
+
+PR #{number}: {title}
+Author: {author}
+Branch: {headRefName}
+Changed files: {changedFiles}, +{additions}/-{deletions}
+Labels: {labels}
+Review status: {reviewDecision}
+Draft: {isDraft}
+
+Steps:
+1. Run: gh pr diff {number}
+2. Run: gh pr view {number} --comments
+3. Analyze the diff for:
+   - What the PR does (1-2 sentence summary)
+   - Risk level (see rubric below)
+   - Complexity (see rubric below)
+   - Whether build/test verification is needed (yes/no + reason)
+   - Potential issues or concerns (max 3)
+   - Suggested reviewers or labels if obvious
+
+Risk rubric:
+- Critical: changes trust boundaries, auth, data integrity, or core business logic with outage/breach potential
+- High: significant blast radius — broad API changes, DB schema, cross-service contracts
+- Medium: localized impact — single service/module, recoverable if broken
+- Low: isolated, low blast radius — docs, tests, UI copy, config flags
+
+Complexity rubric:
+- High: multiple distinct concerns, crosses architectural boundaries, understanding one change requires another
+- Medium: moderate cross-cutting, single domain with some interdependencies
+- Low: single-concern, self-contained, easy to review independently
+
+Output as structured text:
+SUMMARY: ...
+RISK: Critical|High|Medium|Low
+COMPLEXITY: High|Medium|Low
+NEEDS_DEEP: yes|no
+DEEP_REASON: ... (if yes)
+CONCERNS: ...
+SUGGESTION: ...
+```

package/skills/validate/SKILL.md

@@ -13,78 +13,33 @@ model: sonnet
 
 # /afc:validate — Artifact Consistency Validation
 
-> Validates consistency and quality across spec.md, plan.md, and tasks.md.
-> **Read-only** — does not modify any files.
+> Validates consistency across spec.md, plan.md, and tasks.md. **Read-only** — does not modify files.
 
-## Arguments
-
-- `$ARGUMENTS` — (optional) limit validation scope (e.g., "spec-plan", "tasks-only")
+## Project Config (auto-loaded)
+!`cat .claude/afc.config.md 2>/dev/null || echo "[CONFIG NOT FOUND — run /afc:init first]"`
 
-## Config Load
-
-**Always** read `.claude/afc.config.md` first. This file contains free-form markdown sections:
-- `## Architecture` — architecture pattern, layers, import rules (primary reference for this command)
-- `## Code Style` — language, naming conventions, lint rules
-- `## Project Context` — framework, state management, testing, etc.
+## Arguments
 
-If config file is missing: read `CLAUDE.md` for architecture info. Assume "Layered Architecture" if neither source has it.
+- `$ARGUMENTS` — (optional) limit validation scope (`spec-plan`, `tasks-only`)
 
 ## Execution Steps
 
 ### 1. Load Artifacts
 
 From `.claude/afc/specs/{feature}/`:
-- **spec.md** (required)
-- **plan.md** (required)
-- **tasks.md** (if present)
-- **research.md** (if present)
-- **context.md** (if present — written by auto pipeline Phase 2)
+- **spec.md** (required), **plan.md** (required)
+- **tasks.md**, **research.md**, **context.md** (load if present)
 
 Warn about missing files but proceed with what is available.
+If config is missing: use `CLAUDE.md` for architecture info; assume "Layered Architecture" as fallback.
 
 ### 2. Run Validation
 
-Validate across 6 categories:
-
-#### A. Duplication Detection (DUPLICATION)
-- Similar requirements within spec.md
-- Overlapping tasks within tasks.md
-
-#### B. Ambiguity Detection (AMBIGUITY)
-- Unmeasurable adjectives ("appropriate", "fast", "good")
-- Residual TODO/TBD/FIXME markers
-- Incomplete sentences
-
-#### C. Coverage Gaps (COVERAGE)
-- spec → plan: Are all FR-*/NFR-* reflected in the plan?
-- plan → tasks: Are all items in the plan's File Change Map present in tasks?
-- spec → tasks: Are all requirements mapped to tasks?
-- spec → context.md (if present): Are all FR-*/NFR-*/SC-* items from spec.md copied into context.md's Acceptance Criteria section? (AC completeness check)
+Run all 6 categories defined in [`validation-categories.md`](./validation-categories.md).
 
-#### D. Inconsistencies (INCONSISTENCY)
-- Terminology drift (different names for the same concept)
-- Conflicting requirements
-- Mismatches between technical decisions in plan and execution in tasks
+If `$ARGUMENTS` specifies a scope (e.g., `spec-plan`), run only the relevant categories.
 
-#### E. Principles Compliance (PRINCIPLES)
-- Validate against MUST principles in .claude/afc/memory/principles.md if present
-- Potential violations of {config.architecture} rules
-
-#### F. Unidentified Risks (RISK)
-- Are there risks not identified in plan.md?
-- External dependency risks
-- Potential performance bottlenecks
-
-### 3. Severity Classification
-
-| Severity | Criteria |
-|----------|----------|
-| **CRITICAL** | Principles violation, core feature blocker, security issue |
-| **HIGH** | Duplication/conflict, untestable, coverage gap |
-| **MEDIUM** | Terminology drift, ambiguous requirements |
-| **LOW** | Style improvements, minor duplication |
-
-### 4. Output Results (console)
+### 3. Output Results
 
 ```markdown
 ## Consistency Analysis Results: {feature name}
@@ -93,7 +48,6 @@ Validate across 6 categories:
 | ID | Category | Severity | Location | Summary | Recommended Action |
 |----|----------|----------|----------|---------|-------------------|
 | A-001 | COVERAGE | HIGH | spec FR-003 | No mapping in tasks | Add task |
-| A-002 | AMBIGUITY | MEDIUM | spec NFR-001 | "quickly" is unmeasurable | Add numeric threshold |
 
 ### Coverage Summary
 | Mapping | Coverage |
@@ -103,14 +57,22 @@ Validate across 6 categories:
 | spec → tasks | {N}% |
 
 ### Metrics
-- Total requirements: {N}
-- Total tasks: {N}
+- Total requirements: {N} / Total tasks: {N}
 - Issues: CRITICAL {N} / HIGH {N} / MEDIUM {N} / LOW {N}
 
 ### Next Steps
 {Concrete action proposals for CRITICAL/HIGH issues}
 ```
 
+### 4. After Validation Fails
+
+If CRITICAL or HIGH issues are found:
+1. Return the findings table to the calling skill (spec/plan/tasks/implement)
+2. The calling skill is responsible for fixing the reported issues before proceeding
+3. To re-validate after fixes: re-invoke `/afc:validate` with the same scope
+
+If only MEDIUM/LOW issues: proceed is safe; issues are advisory.
+
 ### 5. Final Output
 
 ```
@@ -122,6 +84,6 @@ Analysis complete
 
 ## Notes
 
-- **Read-only**: Do not modify any files. Report only.
-- **Avoid false positives**: Do not over-flag ambiguity. Consider context.
-- **Optional**: Not required in the pipeline. Can proceed plan → implement directly.
+- **Read-only**: Report only, no file writes.
+- **Avoid false positives**: Do not over-flag ambiguity — consider context.
+- **Optional in pipeline**: Not required. Can proceed plan → implement directly.

package/skills/validate/validation-categories.md

@@ -0,0 +1,39 @@
+# /afc:validate — Validation Categories
+
+## A. Duplication Detection (DUPLICATION)
+- Similar requirements within spec.md
+- Overlapping tasks within tasks.md
+
+## B. Ambiguity Detection (AMBIGUITY)
+- Unmeasurable adjectives ("appropriate", "fast", "good")
+- Residual TODO/TBD/FIXME markers
+- Incomplete sentences
+
+## C. Coverage Gaps (COVERAGE)
+- spec → plan: Are all FR-*/NFR-* reflected in the plan?
+- plan → tasks: Are all items in plan's File Change Map present in tasks?
+- spec → tasks: Are all requirements mapped to tasks?
+- spec → context.md (if present): Are all FR-*/NFR-*/SC-* items copied into context.md's Acceptance Criteria section?
+
+## D. Inconsistencies (INCONSISTENCY)
+- Terminology drift (different names for the same concept)
+- Conflicting requirements
+- Mismatches between technical decisions in plan and execution in tasks
+
+## E. Principles Compliance (PRINCIPLES)
+- Validate against MUST principles in `.claude/afc/memory/principles.md` if present
+- Potential violations of `{config.architecture}` rules
+
+## F. Unidentified Risks (RISK)
+- Risks not identified in plan.md
+- External dependency risks
+- Potential performance bottlenecks
+
+## Severity Classification
+
+| Severity | Criteria |
+|----------|----------|
+| **CRITICAL** | Principles violation, core feature blocker, security issue |
+| **HIGH** | Duplication/conflict, untestable, coverage gap |
+| **MEDIUM** | Terminology drift, ambiguous requirements |
+| **LOW** | Style improvements, minor duplication |