agentleFS
weselbenweselben/RooForge/skills/pr-resolve/SKILL.md

pr-resolve

Skill4 starsChanged 3 months agoApache-2.0View on GitHub

Resolve PR review findings — reads caveman-review findings, dispatches one resolver subagent per finding group into its own worktree, commits under user's git identity, pushes to PR head branch, replies under each review thread with the resolving commit SHA. Triggers: \"resolve review comments\", \"fix PR feedback\", \"address review findings\".

1 other project uses a version of this.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

5 rules. About 0 are common, 4 are distinctive, and 1 is very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈4

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 1

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Done when: every thread has one reply, summary comment URL exists, worktrees removed.

    line 22
  2. Distinctive:

    Every resolver spawns inside its own worktree off PR head — never main checkout, never shared worktree.

    line 33
  3. Very specific:

    Does not produce findings — that is pr-review.

    line 42
  4. Distinctive:

    Does not resolve findings outside PR scope — out-of-scope gets a thread reply explaining why, not a commit.

    line 43
  5. Distinctive:

    Does not merge the PR — the user merges.

    line 44

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

pr-resolve — turn review findings into pushed commits

pr-resolve consumes what pr-review produces. Findings in, resolved threads out. Every resolver works in its own worktree off the PR head branch; every commit carries the user's git identity; every resolved finding gets a thread reply naming the commit SHA.

Leading word: triage. Each finding becomes resolve / skip / answer — never batched into the summary and left silent.

Steps

  1. WORKTREE — using-git-worktrees Step 0. If not isolated on PR head, create .worktrees/pr-<n>-resolve/ tracking PR head.
  2. COLLECT — gather actionable findings from inline review comments (gh api repos/{owner}/{repo}/pulls/<n>/comments --paginate --jq '.[] | select(.in_reply_to_id == null and .position != null) | {id, path, line, body, user, diff_hunk}', unresolved only). Group by file or concern. Triage: 🔴/🟡 → resolve; 🔵 nit → resolve if trivial else skip with reason; ❓ q → answer in thread.
  3. DISPATCH — swarm mode, one resolver subagent per group, each in its own worktree off PR head. Driven by scripts/resolve-loop.sh <findings-file> <worktree> [max_iter] (kimi -p via ../loops/scripts/run_loop.sh). Each resolver loads use-git-identity, conventional-commits, caveman-commit, verification-before-completion; sets repo-local identity before first commit. Cap 10 parallel.
  4. INTEGRATE — merge resolver branches into PR-head worktree (--no-ff), run test suite on merged result (verification-before-completion). Clean + green → continue. Red → one fix round through failing group, then report BLOCKED if still red.
  5. PUSH + REPLY — push PR head branch. For each resolved inline comment, post a thread reply: gh api repos/{owner}/{repo}/pulls/comments/<comment-id>/replies -f body="Resolved in <sha> — <one-line what changed>". For inline comments skipped with reason or answered ❓ questions, post the corresponding thread reply. One thread reply per inline comment. Finish with ONE summary top-level review body listing resolved/skipped/answered counts. Done when every inline thread has exactly one reply and the summary exists. Format the user-visible reply as: first line the PR URL as a Markdown link, second line the summary comment URL.
  6. CLEANUP — using-git-worktrees cleanup: git worktree remove + git branch -d. The -d refusal on unmerged branches is the safety check.

Done when: every thread has one reply, summary comment URL exists, worktrees removed.

Scripts — scripts/

ScriptRole
scripts/resolve-loop.sh <findings-file> <worktree> [max_iter]Swarm-mode. Renders templates/resolve-loop.md via ../loops/scripts/cavemanize.sh, drives ../loops/scripts/run_loop.sh.
scripts/templates/resolve-loop.mdThe kimi -p "" payload: MANDATORY FIRST skill loads, worktree confinement, DONE:/BLOCKED: contract.

Hard rules

  • Every resolver spawns inside its own worktree off PR head — never main checkout, never shared worktree.
  • Commits carry the user's identity (use-git-identity, repo-local config) — never agent, never bot.
  • One thread reply per finding, one summary comment per run. Threads are where the reviewer looks.
  • Findings format is caveman-review's contract; loop machinery is loops's. Load both.
  • Public GitHub text goes through ste100.
  • Push goes to PR head branch only. Never main, never a fork the user doesn't own.

Boundaries

  • Does not produce findings — that is pr-review.
  • Does not resolve findings outside PR scope — out-of-scope gets a thread reply explaining why, not a commit.
  • Does not merge the PR — the user merges.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.