all-for-claudecode 2.12.0 → 2.14.0

package/skills/pr-comment/SKILL.md

@@ -16,6 +16,10 @@ model: sonnet
 > Analyzes a PR and posts a structured review comment to GitHub.
 > Reuses existing triage reports when available. Asks for user confirmation before posting.
 
+## Pre-fetch
+
+!`gh pr view $0 --json number,title,headRefName,author,body,additions,deletions,changedFiles,labels,reviewDecision,state,url 2>/dev/null || echo "PR_FETCH_FAILED"`
+
 ## Arguments
 
 - `$ARGUMENTS` — PR number (required), with optional severity filter
@@ -23,71 +27,53 @@ model: sonnet
   - `42 --severity critical,warning` — Only include Critical and Warning findings
   - `42 --severity critical` — Only include Critical findings
 
-Parse the arguments:
+Parse:
 1. Extract the PR number (first numeric argument)
-2. Extract `--severity` filter if present (comma-separated list of: `critical`, `warning`, `info`)
-3. If no PR number is found, ask the user: "Which PR number should I review?"
+2. Extract `--severity` filter if present (comma-separated: `critical`, `warning`, `info`)
+3. If no PR number found, ask the user: "Which PR number should I review?"
 
 ## Execution Steps
 
 ### 1. Collect PR Information
 
-```bash
-gh pr view {number} --json number,title,headRefName,author,body,additions,deletions,changedFiles,labels,reviewDecision,state
-```
+Use the pre-fetched PR metadata. If the pre-fetch returned `PR_FETCH_FAILED`, output `[afc:pr-comment] Error: PR not found or gh not available.` and abort.
 
+Fetch the diff:
 ```bash
 gh pr diff {number}
 ```
 
-Verify the PR exists and is open. If closed/merged, inform the user and ask whether to proceed anyway.
+Verify the PR is open. If closed/merged, inform the user and ask whether to proceed anyway.
 
 ### 2. Check for Existing Triage Report
 
-Look for a recent triage report that covers this PR:
-
 ```bash
 ls -t .claude/afc/memory/triage/*.md 2>/dev/null | head -5
 ```
 
-If a report exists from today, search it for `PR #{number}` analysis. If found, reuse that analysis as the basis for the review instead of re-analyzing from scratch.
+If a report from today contains `PR #{number}` analysis, reuse it as the review basis instead of re-analyzing from scratch.
 
 ### 3. Analyze PR (if no triage data available)
 
-If no existing triage report covers this PR, perform a focused review of the diff.
-
-Examine the diff from the following perspectives (abbreviated from review.md):
-
-#### A. Code Quality
-- Style compliance, naming conventions, unnecessary complexity
-
-#### B. Architecture
-- Layer violations, boundary crossings, structural concerns
+Review the diff using perspectives A–E from [review/perspectives.md](../review/perspectives.md):
 
-#### C. Security
-- XSS, injection, sensitive data exposure, auth issues
+- **A. Code Quality** — style compliance, naming, unnecessary complexity
+- **B. Architecture** — layer violations, boundary crossings, structural concerns
+- **C. Security** — XSS, injection, sensitive data exposure, auth issues
+- **D. Performance** — latency concerns, unnecessary computation, resource leaks
+- **E. Maintainability** — function/file size, naming clarity, readability
 
-#### D. Performance
-- Latency concerns, unnecessary computation, resource leaks
-
-#### E. Maintainability
-- Function/file size, naming clarity, readability
-
-Classify each finding with a severity:
-- **Critical (C)** — Must fix before merge. Bugs, security vulnerabilities, data loss risks.
-- **Warning (W)** — Should fix. Code quality issues, potential problems, maintainability concerns.
-- **Info (I)** — Nice to have. Suggestions, minor improvements, style preferences.
+Classify each finding:
+- **Critical (C)** — Must fix before merge: bugs affecting users, security vulnerabilities, data loss risks
+- **Warning (W)** — Should fix: code quality issues, potential problems, maintainability concerns
+- **Info (I)** — Nice to have: suggestions, minor improvements, style preferences
 
 ### 4. Apply Severity Filter
 
-If `--severity` was specified, filter findings to only include the specified severity levels.
-
-Default (no filter): include all severity levels.
+If `--severity` was specified, filter findings to only the listed levels. Default: include all.
 
 ### 5. Generate Review Comment
 
-Compose the review comment in this format:
-
 ```markdown
 ## AFC Code Review — PR #{number}
 
@@ -119,8 +105,7 @@ Compose the review comment in this format:
 *Reviewed by [all-for-claudecode](https://github.com/anthropics/claude-code)*
 ```
 
-If there are zero findings after filtering, the comment should be:
-
+If zero findings after filtering:
 ```markdown
 ## AFC Code Review — PR #{number}
 
@@ -132,12 +117,15 @@ No issues found. Code looks good!
 
 ### 6. Preview and Confirm
 
-Display the full review comment to the user in the console.
+Display the full review comment to the user.
+
+Determine the review event:
 
-Then determine the review event based on the actual severity and context of findings:
-- **REQUEST_CHANGES**: Use when findings indicate genuine risk to production code — bugs that would affect users, security vulnerabilities, or architectural violations that would be costly to fix later. A Critical finding in test code or documentation alone does not warrant blocking the PR.
-- **COMMENT**: Use when findings are improvements or concerns that the author should consider but that don't pose immediate risk. Also appropriate when Critical findings are in non-production code (tests, docs, config) or when the author has already acknowledged the concern in PR discussion.
-- **APPROVE**: Use when no findings exist, or when all findings are informational and the code is ready to merge.
+| Event | When to use |
+|-------|-------------|
+| **REQUEST_CHANGES** | Critical findings in production code that pose genuine risk to users: bugs affecting functionality, security vulnerabilities, or architectural violations costly to fix post-merge. A Critical finding limited to test/docs/config alone does NOT qualify. |
+| **COMMENT** | Findings are improvements the author should consider but don't block merging. Also when Critical findings are in non-production code, or the author has already acknowledged the concern in PR discussion. |
+| **APPROVE** | No findings, or all findings are informational and code is ready to merge. |
 
 Tell the user:
 ```
@@ -145,15 +133,13 @@ Review event: {APPROVE|COMMENT|REQUEST_CHANGES}
 Findings: Critical {N} / Warning {N} / Info {N}
 ```
 
-Ask the user to confirm using AskUserQuestion with these options:
+Ask for confirmation (AskUserQuestion):
 1. **Post as-is** — Post the review comment to GitHub
-2. **Edit first** — Let me modify the comment before posting (user provides edits, then re-confirm)
+2. **Edit first** — Let me modify the comment before posting
 3. **Cancel** — Do not post anything
 
 ### 7. Post to GitHub
 
-On approval, write the review comment to a temp file and post via `--body-file` (avoids shell escaping issues with markdown):
-
 ```bash
 tmp_file=$(mktemp)
 cat > "$tmp_file" << 'REVIEW_EOF'
@@ -170,12 +156,13 @@ PR review posted
 ├─ PR: #{number} ({title})
 ├─ Event: {APPROVE|COMMENT|REQUEST_CHANGES}
 ├─ Findings: Critical {N} / Warning {N} / Info {N}
-└─ URL: {PR URL from gh pr view}
+└─ URL: {PR URL}
 ```
 
 ## Notes
 
 - **User confirmation required**: Never post to GitHub without explicit user approval.
-- **Idempotent**: Running multiple times on the same PR creates additional review comments (GitHub does not deduplicate).
-- **Respects existing reviews**: This command does not dismiss or override other reviewers' reviews.
-- **Rate limits**: Uses a single `gh pr review` call. No rate limit concerns for normal usage.
+- **Verify after posting**: After `gh pr review` completes, confirm success by checking the exit code. If it fails, report the error and suggest manual posting.
+- **Idempotent**: Multiple runs create additional review comments (GitHub does not deduplicate).
+- **Respects existing reviews**: Does not dismiss or override other reviewers' reviews.
+- **Perspectives reference**: Full criteria for A–H in [review/perspectives.md](../review/perspectives.md). This skill uses A–E only (focused on PR-level review, not full pipeline review).

package/skills/principles/SKILL.md

@@ -23,14 +23,9 @@ model: sonnet
   - `remove {number}`: remove a principle
   - `init`: interactive initial setup
 
-## Config Load
+## Project Config (auto-loaded)
 
-**Always** read `.claude/afc.config.md` first.
-
-If config file is missing:
-1. Ask the user: "`.claude/afc.config.md` not found. Run `/afc:init` to set up the project?"
-2. If user accepts → run `/afc:init`, then **restart this command** with the original `$ARGUMENTS`
-3. If user declines → **abort**
+!`cat .claude/afc.config.md 2>/dev/null || echo "[CONFIG NOT FOUND] .claude/afc.config.md not found. Create it with /afc:init."`
 
 ## Execution Steps
 
@@ -108,4 +103,5 @@ Collect principles interactively:
 - **Persistent storage**: Saved to .claude/afc/memory/principles.md and maintained across sessions.
 - **Auto-referenced**: Automatically loaded and validated by /afc:plan and /afc:architect.
 - **Keep it concise**: Keep principles concise and actionable. If the list grows long enough that principles start overlapping or becoming too granular, suggest consolidation. The goal is a set of principles that can be held in working memory — typically under 15, but the right number depends on the project's complexity.
+- **Verify after change**: After adding or removing a principle, re-read `principles.md` to confirm the version was bumped correctly and no formatting issues were introduced.
 - **Avoid duplication with CLAUDE.md**: Do not re-register rules already present in CLAUDE.md as principles.

package/skills/qa/SKILL.md

@@ -26,12 +26,9 @@ model: sonnet
   - `coverage` — categories A + D (Test Confidence + API & Contract Safety)
   - Or a free-form concern (e.g., "are error messages user-friendly", "check for dead exports")
 
-## Config Load
+## Project Config (auto-loaded)
 
-**Always** read `.claude/afc.config.md` first — needed for CI Commands (YAML: ci, gate, test).
-Architecture, Code Style, and Project Context are auto-loaded via `.claude/rules/afc-project.md`.
-
-If config file is missing: read `CLAUDE.md` for project info. Proceed without config if neither exists.
+!`cat .claude/afc.config.md 2>/dev/null || echo "[CONFIG NOT FOUND] Proceeding without config — read CLAUDE.md for project info."`
 
 ## Audit Categories
 
@@ -90,15 +87,7 @@ Checks:
 
 ## Execution Steps
 
-### 1. Load Config
-
-Read `.claude/afc.config.md` (or fallback to `CLAUDE.md`). Extract:
-- Test command (`{config.test}`)
-- CI/gate commands (`{config.ci}`, `{config.gate}`)
-- Architecture layers (`{config.architecture}`)
-- Code style rules (`{config.code_style}`)
-
-### 2. Parse Scope
+### 1. Parse Scope
 
 Interpret `$ARGUMENTS` to determine which categories to run:
 

package/skills/release-notes/SKILL.md

@@ -31,15 +31,15 @@ Parse the arguments:
    - If single version: use `{version}..HEAD`
    - If empty: auto-detect with `git describe --tags --abbrev=0`
 
+## Git Context (auto-loaded)
+
+!`git describe --tags --abbrev=0 2>/dev/null || echo "[NO_TAGS]"`
+!`git log $(git describe --tags --abbrev=0 2>/dev/null || echo "")..HEAD --pretty=format:"%H %s" --no-merges 2>/dev/null || git log --pretty=format:"%H %s" --no-merges`
+
 ## Execution Steps
 
 ### 1. Determine Range
 
-```bash
-# Auto-detect last tag if no range specified
-git describe --tags --abbrev=0 2>/dev/null
-```
-
 - If a tag is found, set `from_tag` to that tag, `to_tag` to HEAD
 - If no tags exist, inform the user: "No tags found. Include all commits? (y/n)"
 - If a `to_tag` is specified (not HEAD), verify it exists: `git rev-parse --verify {to_tag} 2>/dev/null`
@@ -220,4 +220,5 @@ To publish these notes as a GitHub Release, run again with --post flag.
 - **Conventional Commits aware**: Projects using conventional commits get better categorization. Projects without them still get reasonable results via heuristic matching.
 - **Contributor attribution**: Best effort. GitHub username resolution requires `gh` CLI and repository access.
 - **User confirmation required**: `--post` always asks for explicit approval before publishing to GitHub.
+- **Verify after publishing**: After `gh release create` completes, verify success by checking the exit code and output URL. If it fails, report the error and suggest manual creation.
 - **Idempotent**: Running without `--post` is safe to repeat. With `--post`, GitHub Releases for existing tags will fail (GitHub does not allow duplicate release tags).

package/skills/resolve/SKILL.md

@@ -0,0 +1,162 @@
+---
+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 number or URL>"
+allowed-tools:
+  - Read
+  - Grep
+  - Glob
+  - Bash
+  - Edit
+  - Write
+  - AskUserQuestion
+model: sonnet
+---
+
+# /afc:resolve — LLM Review Comment Resolution
+
+Collects LLM bot review comments from a PR, classifies as VALID/NOISE/DISCUSS, fixes VALID items, resolves addressed threads on GitHub, and outputs a summary report.
+
+## Arguments
+
+- `$ARGUMENTS` — (required) Any format that identifies a PR (number, URL, cross-repo, etc.)
+
+## PR Context
+
+!`gh pr view $(echo "$ARGUMENTS" | grep -oE '[0-9]+' | head -1) --json url,title,headRefName,comments 2>/dev/null || echo "PR_FETCH_FAILED"`
+
+## Execution Steps
+
+### 1. Prerequisites
+
+```bash
+gh --version >/dev/null 2>&1 && gh auth status >/dev/null 2>&1
+```
+
+Fails → `[afc:resolve] Error: gh CLI not installed or not authenticated.` → **abort**.
+
+### 2. Identify PR
+
+Extract PR number from `$ARGUMENTS` by intent. If `owner/repo` info is included, use `--repo` flag. Otherwise derive via `gh repo view --json owner,name`.
+
+If "PR Context" above shows `PR_FETCH_FAILED`, parse `$ARGUMENTS` manually and retry.
+
+### 3. Collect Review Data
+
+```bash
+gh api repos/{owner}/{repo}/pulls/{number}/comments --paginate
+```
+
+Also fetch review threads for resolve (Step 8). See [graphql.md](graphql.md) for the query.
+
+### 4. Filter Bot Comments
+
+Keep only comments from authors whose login ends with `[bot]`. Tag `outdated` comments as `[OUTDATED]`.
+
+0 bot comments → `No LLM bot review comments found on PR #{number}.` → **exit**.
+
+### 5. Check Working Tree
+
+```bash
+git status --porcelain
+```
+
+Dirty → list files, ask user to confirm before proceeding.
+
+### 6. Classify
+
+Read each comment's target file (±10 lines context), then classify:
+
+| Class | When | Action |
+|-------|------|--------|
+| **VALID** | Objectively verifiable bug, single fix approach, resolvable within existing code | Fix |
+| **NOISE** | Style preference, intentional design, false positive, `[OUTDATED]` | Skip |
+| **DISCUSS** | Requires judgment (new dependency, tradeoff, threshold, API change, etc.) | Ask |
+
+**Key: when in doubt, classify as DISCUSS. Be conservative with VALID.**
+
+### 7. Present Summary
+
+**MUST output before any code changes:**
+
+```
+PR #{number}: {title}
+Branch: {headRefName}
+Bot comments: {total} ({bot_names})
+
+VALID ({n}):  1. [{bot}] {file}:{line} — {summary}
+NOISE ({n}):  1. [{bot}] {file}:{line} — {skip reason}
+DISCUSS ({n}): 1. [{bot}] {file}:{line} — {question}
+```
+
+### 8. Handle DISCUSS
+
+Each item → present comment, target code (5 lines), tradeoff → ask user:
+1. Apply → move to VALID
+2. Skip → move to NOISE
+3. Defer → stays DISCUSS
+
+### 9. Apply Fixes
+
+For each VALID item:
+1. Read target file
+2. Apply minimal fix via Edit
+3. Verify modified area
+
+**Feedback loop**: after all fixes, run project tests if available. If tests fail → diagnose and fix → rerun. Repeat until pass or user decides to stop.
+
+### 10. Resolve Threads on GitHub
+
+See [graphql.md](graphql.md) for the mutation.
+
+| Classification | Resolve? |
+|---------------|----------|
+| VALID (fixed) | Yes |
+| NOISE | Yes (user decided to skip) |
+| DISCUSS-Apply | Yes |
+| DISCUSS-Skip | Yes |
+| DISCUSS-Defer | **No** (revisit later) |
+| Already resolved | Skip |
+
+GraphQL failure → warn, **do not abort**.
+
+### 11. Commit
+
+No fixes applied → skip to Step 12.
+
+Show summary + resolved thread count → **wait for user confirmation** (NFR-003).
+
+```
+resolve LLM review comments on #{number}
+
+- fix: {description} ({bot_name})
+- skip: {reason} (NOISE, {count} items)
+```
+
+Do **NOT** push.
+
+### 12. Output Report
+
+**MUST always output**, even if interrupted:
+
+```
+Resolve complete
+├─ PR: #{number} — {title}
+├─ Bot comments: {total} ({bot_names})
+├─ VALID: {n} (applied)
+├─ NOISE: {n} (skipped)
+├─ DISCUSS: {n} (applied: {a}, skipped: {s}, deferred: {d})
+├─ Tests: {pass}/{total} passed
+├─ Threads resolved: {resolved}/{addressed}
+├─ Commit: {hash} ({files} files, +{add}/-{del})
+└─ Push: not pushed (run 'git push' when ready)
+```
+
+## Completion Guarantee
+
+MUST reach Step 12 before returning control. If user sends unrelated request mid-flow → output partial report with `[INTERRUPTED]` → then address new request.
+
+## Notes
+
+- Human comments are ignored (use `afc:review`). No auto-push. Thread resolution needs `repo` scope.
+- Idempotent: re-run skips already-addressed comments and resolved threads.

package/skills/resolve/graphql.md

@@ -0,0 +1,48 @@
+# GraphQL Queries for Thread Resolution
+
+## Fetch Review Threads
+
+```graphql
+query($owner: String!, $repo: String!, $pr: Int!) {
+  repository(owner: $owner, name: $repo) {
+    pullRequest(number: $pr) {
+      reviewThreads(first: 100) {
+        nodes {
+          id
+          isResolved
+          comments(first: 1) {
+            nodes { databaseId body author { login } path line }
+          }
+        }
+      }
+    }
+  }
+}
+```
+
+Usage:
+```bash
+gh api graphql -f query='...' -F owner='{owner}' -F repo='{repo}' -F pr={number}
+```
+
+## Resolve a Thread
+
+```graphql
+mutation($threadId: ID!) {
+  resolveReviewThread(input: {threadId: $threadId}) {
+    thread { id isResolved }
+  }
+}
+```
+
+Usage:
+```bash
+gh api graphql -f threadId='{thread_id}' -f query='...'
+```
+
+## Notes
+
+- REST API does NOT support thread resolution — GraphQL only
+- Requires `repo` scope on the GitHub token
+- Thread ID comes from the fetch query above (`nodes[].id`)
+- Already-resolved threads (`isResolved: true`) should be skipped

package/skills/resume/SKILL.md

@@ -17,15 +17,20 @@ allowed-tools:
 
 - `$ARGUMENTS` — (optional) none
 
+## Checkpoint State (auto-loaded)
+
+!`cat .claude/afc/memory/checkpoint.md 2>/dev/null || echo "[NO_CHECKPOINT]"`
+
 ## Execution Steps
 
 ### 1. Load Checkpoint
 
-Read `.claude/afc/memory/checkpoint.md`:
-- If not found: check **auto-memory fallback** — read `~/.claude/projects/{ENCODED_PATH}/memory/checkpoint.md` (where `ENCODED_PATH` = project path with `/` replaced by `-`):
-  - If fallback found: use it as the checkpoint source (auto-memory is written by `pre-compact-checkpoint.sh` during context compaction)
-  - If fallback also not found: output "No saved checkpoint found. Use `/afc:checkpoint` to create one, or checkpoints are created automatically on context compaction." then **stop**
-- If found: parse the full contents (extract branch, commit hash, pipeline feature, task progress, modified files)
+Use the pre-fetched checkpoint above. If it shows `[NO_CHECKPOINT]`:
+- Check auto-memory fallback: read `~/.claude/projects/{ENCODED_PATH}/memory/checkpoint.md`
+- If fallback also not found: output "No saved checkpoint found." then **stop**
+
+If checkpoint data was pre-fetched successfully:
+parse the full contents (extract branch, commit hash, pipeline feature, task progress, modified files).
 
 ### 2. Validate Environment