all-for-claudecode 2.13.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

@@ -1,7 +1,7 @@
 ---
 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>"
+argument-hint: "<PR number or URL>"
 allowed-tools:
   - Read
   - Grep
@@ -15,231 +15,148 @@ 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.
+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) One of:
-  - PR number: `456` or `#456`
-  - GitHub URL: `https://github.com/owner/repo/pull/456`
-  - Cross-repo: `owner/repo#456`
+- `$ARGUMENTS` — (required) Any format that identifies a PR (number, URL, cross-repo, etc.)
 
-## Execution Steps
+## 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"`
 
-### 1. Prerequisites Check
+## Execution Steps
 
-Verify `gh` CLI is available and authenticated:
+### 1. Prerequisites
 
 ```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:
+Fails → `[afc:resolve] Error: gh CLI not installed or not authenticated.` → **abort**.
 
-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. Identify PR
 
-2. **Cross-repo** (`{owner}/{repo}#{number}`):
-   - Split on `#` — left part is `owner/repo`, right part is number
-   - Set `GH_REPO_FLAG="--repo {owner}/{repo}"`
+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`.
 
-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
-```
+If "PR Context" above shows `PR_FETCH_FAILED`, parse `$ARGUMENTS` manually and retry.
 
-Additionally, collect inline review comments:
+### 3. Collect Review Data
 
 ```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**.
+Also fetch review threads for resolve (Step 8). See [graphql.md](graphql.md) for the query.
 
 ### 4. Filter Bot Comments
 
-Identify LLM bot comments by checking the comment author's login:
+Keep only comments from authors whose login ends with `[bot]`. Tag `outdated` comments as `[OUTDATED]`.
 
-**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
+0 bot comments → `No LLM bot review comments found on PR #{number}.` → **exit**.
 
-**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]`
+### 5. Check Working Tree
 
-If 0 bot comments found:
-- Output: `No LLM bot review comments found on PR #{number}.`
-- **Exit gracefully** (success, not error).
+```bash
+git status --porcelain
+```
 
-### 5. Classify Each Comment
+Dirty → list files, ask user to confirm before proceeding.
 
-For each bot comment, analyze the content and classify:
+### 6. 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 |
+Read each comment's target file (±10 lines context), then classify:
 
-**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)
+| 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 |
 
-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
+**Key: when in doubt, classify as DISCUSS. Be conservative with VALID.**
 
-### 6. Present Classification Summary
+### 7. Present Summary
 
-Before making any changes, present the classification to the user:
+**MUST output before any code changes:**
 
 ```
 PR #{number}: {title}
 Branch: {headRefName}
+Bot comments: {total} ({bot_names})
 
-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}
+VALID ({n}):  1. [{bot}] {file}:{line} — {summary}
+NOISE ({n}):  1. [{bot}] {file}:{line} — {skip reason}
+DISCUSS ({n}): 1. [{bot}] {file}:{line} — {question}
 ```
 
-### 7. Handle DISCUSS Items
+### 8. Handle DISCUSS
 
-For each DISCUSS item, present to the user:
+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
 
-```
-[DISCUSS #{n}] {bot_name} on {file}:{line}
+### 9. Apply Fixes
 
-Comment:
-> {original comment text, truncated to 500 chars}
+For each VALID item:
+1. Read target file
+2. Apply minimal fix via Edit
+3. Verify modified area
 
-Target code:
-> {relevant code snippet, 5 lines context}
+**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.
 
-If applied: {description of what would change}
-Tradeoff: {why this is not a clear-cut decision}
+### 10. Resolve Threads on GitHub
 
-Options:
-  1. Apply — treat as VALID, fix the code
-  2. Skip — treat as NOISE, record skip reason
-  3. Defer — skip for now, revisit later
-```
+See [graphql.md](graphql.md) for the mutation.
 
-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
+| 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 |
 
-### 8. Apply VALID Fixes
+GraphQL failure → warn, **do not abort**.
 
-For each VALID comment (including user-accepted DISCUSS items):
+### 11. Commit
 
-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
+No fixes applied → skip to Step 12.
 
-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
+Show summary + resolved thread count → **wait for user confirmation** (NFR-003).
 
-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.
+Do **NOT** push.
+
+### 12. Output Report
 
-### 10. Output Report
+**MUST always output**, even if interrupted:
 
 ```
 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})
+├─ 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)
 ```
 
-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
-```
+## 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
 
-- **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.
+- 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