docs: fold review-prs fixes from live runs into SKILL.md

Two live review-prs runs surfaced fixes:
- Merge conflicts move from the screen-out rules to a local-merge path
  in the Merge arm; 7/10 PRs conflicted only from the reform's stale
  bases, and one such PR had already been merged this way.
- Target use case is now resolved from the current README instead of
  stale diff context, since most PR bases no longer match live
  sections.
- Judge gets a third verdict: no fitting use case is a structure
  question, carried to Act for the maintainer to decide.
- Act's Close step gets a batching and checklist note, and the whole
  step gets an explicit completion criterion after a verdict nearly
  fell out of the question batches.
- Drop the "claude reviewed" label mechanism entirely: the fetch
  filter, the Park arm, and the labeled-open terminal state.

Co-Authored-By: Claude <noreply@anthropic.com>
This commit is contained in:
Vinta Chen
2026-08-16 21:18:30 +08:00
co-authored by Claude
parent f3062087f0
commit de4a7e6a36
+9 -7
View File
@@ -10,24 +10,26 @@ A PR review turns the open queue into terminal states: merged, closed, or explic
## 1. Fetch
Arguments name specific PRs; otherwise take the queue: `gh pr list --repo vinta/awesome-python --limit 10 --search '-label:"claude reviewed"' --json number,title,author,url,body,files,mergeable,mergeStateStatus`. Fetch all diffs in parallel: `gh pr diff <number> --repo vinta/awesome-python`.
Arguments name specific PRs; otherwise take the queue: `gh pr list --repo vinta/awesome-python --limit 10 --json number,title,author,url,body,files,mergeable,mergeStateStatus`. Fetch all diffs in parallel: `gh pr diff <number> --repo vinta/awesome-python`.
Sort the batch: entry additions continue; anything else (typo fixes, website changes, docs) is out of scope — report it under "needs human" and touch nothing, so it resurfaces every run until a human acts. Done when every PR is sorted and has its diff.
## 2. Screen
Apply the Automatic Rejection rules that the diff and PR metadata answer without judgment, plus merge conflicts (`mergeable`/`mergeStateStatus`). The recently-closed-duplicate rule needs a lookup: `gh pr list --repo vinta/awesome-python --state closed --search "<project name>" --limit 10`. A screened-out PR goes straight to step 4 as a close, with the rule it broke as its reason. Done when every surviving PR names its target use case.
Apply the Automatic Rejection rules that the diff and PR metadata answer without judgment. The recently-closed-duplicate rule needs a lookup: `gh pr list --repo vinta/awesome-python --state closed --search "<project name>" --limit 10`. A screened-out PR goes straight to step 4 as a close, with the rule it broke as its reason.
Resolve each survivor's target use case against the current README, since most diffs sit on stale bases and their context lines show sections that no longer exist. A merge conflict is a symptom of that stale base — it rides to the Merge arm, which absorbs it. Done when every surviving PR names its target use case.
## 3. Judge
Group survivors by target use case — PRs proposing entries for the same use case compete for the same slots, so they ride one invocation. Per group, invoke the audit-the-list skill with arguments in this shape: "Judge proposed entries <names, each with its PR number> for the <section — subcategory> use case. Evidence and Verdicts steps only; report the verdicts back. No preview page, no README changes, no commits." The verdict for each PR is merge or close, grounded in the fetched evidence; when the use case is at cap, a merge verdict names the entry that leaves. Done when every survivor holds a verdict with a reason.
Group survivors by target use case — PRs proposing entries for the same use case compete for the same slots, so they ride one invocation. Per group, invoke the audit-the-list skill with arguments in this shape: "Judge proposed entries <names, each with its PR number> for the <section — subcategory> use case. Evidence and Verdicts steps only; report the verdicts back. No preview page, no README changes, no commits." The verdict for each PR is merge or close, grounded in the fetched evidence; when the use case is at cap, a merge verdict names the entry that leaves. An entry no current use case fits is a third outcome — a structure question: carry it to Act with evidence attached, and the maintainer decides there (mint the subcategory and merge, close, or leave open). Done when every survivor holds a verdict with a reason.
## 4. Act
- **Close**: per closing PR, AskUserQuestion presenting the draft closing comment — the comment states the reason and links CONTRIBUTING.md. Arms: close with this comment, close without a comment, keep open. Then `gh pr close <number> --repo vinta/awesome-python --comment "<comment>"`, or a plain close.
- **Merge**: `gh pr merge <number> --repo vinta/awesome-python --merge`, then reconcile the section locally: `git pull`, remove the entry the verdict displaced, put the new entry at its Entry Ordering position, `make test`, commit, push. An add-only diff that displaces is the normal case — the removal is this step's job, not the contributor's.
- **Park**: any reviewed PR left open gets `gh pr edit <number> --repo vinta/awesome-python --add-label "claude reviewed"` so the next fetch skips it.
- **Close**: per closing PR, AskUserQuestion presenting the draft closing comment — the comment states the reason and links CONTRIBUTING.md. Batch up to 4 PRs per call and keep a checklist of which verdicts have been asked; answers often arrive as custom text, and that text is the decision. Arms: close with this comment, close without a comment, keep open. Then `gh pr close <number> --repo vinta/awesome-python --comment "<comment>"`, or a plain close.
- **Merge**: a clean PR merges with `gh pr merge <number> --repo vinta/awesome-python --merge`. A conflicted one merges locally: `git fetch origin pull/<number>/head`, `git merge FETCH_HEAD` with the standard `Merge pull request #<number> from <owner>/<headRef>` message, resolving the conflict by placing the entry correctly — GitHub still marks the PR merged and the contributor keeps credit. Either way, reconcile the section per CONTRIBUTING before pushing: remove the entry the verdict displaced, fix the new entry's display name and Entry Ordering position, `make test`, commit. An add-only diff that displaces is the normal case — the removal is this step's job, not the contributor's.
Done when every verdict has been adjudicated by the maintainer and its action executed. A kept-open PR resurfaces next run — that is its point.
## 5. Report
Summary table: PR, verdict, action taken, plus the needs-human list. Done when every fetched PR ends in exactly one state — merged with its section reconciled, closed, labeled and open, or flagged needs-human.
Summary table: PR, verdict, action taken, plus the needs-human list. Done when every fetched PR ends in exactly one state — merged with its section reconciled, closed, or left open (kept open, needs-human, or structure question pending).