skills(review-reviewers): require a named non-bot actor before calling output accepted

[tend-agent]

Problem

Step 2 asks the survey subagent whether each run's output was "accepted or rejected" but never says who has to do the accepting. Nothing in the prompt distinguishes a human merging a PR from the bot replying to its own review thread, so the subagent fills the gap with the most natural reading — a reply arrived, therefore someone accepted it — and reports a self-conversation as human acceptance.

That is the worst-shaped failure this skill has: it produces a false all-clear. A survey that credits the bot's own reply to a human doesn't add noise a later gate can filter, it removes the signal that would have sent the leg to Step 3.

Evidence

This leg (run 31081926964, target max-sixty/cargo-affected). The survey subagent reported PR #77 twice under "Runs with accepted output":

Outcome: ACCEPTED - human developer responded positively to feedback
Outcome: ACCEPTED - human developer incorporated feedback

and concluded PR 77: Developer accepted and incorporated bot feedback (2 cycles of acceptance). There is no developer. The PR is bot-authored and every actor on it is the bot:

$ gh api "repos/max-sixty/cargo-affected/pulls/77/comments?per_page=100" --jq '[.[].user.login] | unique'
["cargo-affected-bot"]

The same report also listed the PR author as cargo-affected-bot, so the contradiction was internal to the summary — the acceptance claim was reached without ever comparing the replying login against the bot's.

This is the fourth cheap-subagent mis-attribution recorded in the evidence gist, and the second of this specific sub-class (bot activity attributed to a human):

Occurrence	Shape
gist "Analysis-side", leg ending 07:5x	inline replies + commit 551e059 credited to "human applied suggested changes"
gist "Analysis-side", following leg	PR #54 bodies credited to a run that had not yet started
gist "Analysis-side", streak-break leg	fabricated no-op causes; window boundary ignored
this leg	bot's own reply chain on PR #77 reported as human acceptance

Prior legs' response was to stop delegating — ten consecutive legs record "this leg used no survey subagent". That is a per-leg workaround for a defect in the shared prompt, and it leaves the skill's stated default (Delegate all broad exploration to a cheap subagent) pointing at a step that mis-reports actors.

Fix

Three small changes to Step 2, all inside the prompt template:

• Require the subagent to name the login behind every acceptance/rejection signal, sourced from a single gh pr view --json number,state,author,mergedBy,reviews,comments,commits that covers all five actor surfaces — merge actor, reviews (with state), inline comments, conversation comments, and commits. A comments-only check can't source it: neither comments endpoint carries review records or the merge actor, so a maintainer merging a bot PR without commenting would come back as bot-only. Inline commenters need no separate call — every inline comment, including a standalone reply, belongs to a review record that reviews returns. The block notes that commits truncates at 100 (oldest-first) while comments and reviews paginate in full.
• Give bot-only threads their own report bucket (bot-only — no human signal) so they can't be silently filed under "accepted".
• Tell the main agent to verify actor attribution before it enters a finding, and to judge bot-only threads on content rather than treating the bucket as either outcome.

The rule is stated so it stays correct when the bot legitimately works on its own PR: bot-only is not a defect (a self-review followed by the author's fix is designed behavior), it just isn't acceptance. Nothing here discourages delegation — it fixes the instruction the delegation was missing.

Gate assessment

• Evidence level: High — consistent pattern across multiple sessions. 4 occurrences total, 2 in the human/bot sub-class this change addresses. High needs 2–3.
• Structural or stochastic: structural in the prompt. The subagent is never asked for actor identity, so no wording of the reply can be relied on to supply it; which specific claim it invents is stochastic, the omission is not.
• Change type: targeted fix — a missing requirement in an existing prompt, plus a report bucket. Normal bar, met.
• Passes both gates.

Second finding this leg did not pass and is recorded in the gist instead: the three-hop tend-mention chain on the same PR #77. That one is already fixed by open PR #849, and I've added this window's evidence there rather than opening a duplicate.

[tend-agent]

The rule is right, but the two queries handed to the subagent can't produce the login the report format now asks for. /pulls/<pr>/comments returns only inline review comments and /issues/<n>/comments only conversation comments — neither carries review records or the merge actor. So — bot reviewed, PR merged by <login> has no source, and the most common acceptance shape here (maintainer merges a bot PR without commenting) comes back as bot-only — no human signal. That flips the failure rather than closing it: instead of a false all-clear, a real acceptance gets filed as no-signal, and a human CHANGES_REQUESTED with no inline comments — the first entry in the negative-signal list just below — is invisible to both queries too.

Checked against this repo: #843 has inline=[tend-agent] conv=[] reviews=[tend-agent] yet merged_by: max-sixty; #844 has all three participant surfaces empty with the same merger. Both would report as bot-only under the block as written.

Second, smaller: the new bucket has no branch in the routing sentence. With bot-only populated and nothing concerning, neither "all outputs are accepted" nor "concerning outcomes exist" holds, so the leg has no stated destination — "judge them on content" resolves it in prose but the condition it feeds is still binary.

[max-sixty]

we can't do all of these with a single query?

[tend-agent]

Yes — one gh pr view carries all five surfaces, and it's now a single call in 04d9671:

gh -R $ARGUMENTS pr view <pr> --json number,state,author,mergedBy,reviews,comments,commits --jq '{
  pr: .number, state, author: .author.login, merged_by: .mergedBy.login,
  reviews: [.reviews[] | {login: .author.login, state}],
  logins: ([.mergedBy.login, .reviews[].author.login, .comments[].author.login,
            .commits[].authors[].login] | map(select(. != null and . != "")) | unique)
}'

The part I wasn't sure of was inline comments, since reviews and /pulls/<pr>/comments looked like separate surfaces. They aren't: every inline comment carries a pull_request_review_id, including a standalone reply posted through the replies endpoint, and each of those review records shows up in reviews. On this PR all five inline comments map onto the four review records gh pr view returns, so nothing is lost by dropping the separate call.

Checked against the two cases the earlier round turned on — #843 comes back merged_by: max-sixty, logins: ["max-sixty","tend-agent"] (real acceptance), and max-sixty/cargo-affected#77, the false all-clear this PR exists for, comes back logins: ["cargo-affected-bot"]. Also confirmed comments/reviews/commits paginate past 100 rather than truncating, so logins stays sound on a long thread.

Verification

Inline comments → review records on this PR:

$ gh api "repos/max-sixty/tend/pulls/864/comments?per_page=100" --jq '.[] | {id, user: .user.login, pull_request_review_id, in_reply_to_id}'
{"id":3726977948,"in_reply_to_id":null,"pull_request_review_id":4872393980,"user":"tend-agent"}
{"id":3726977955,"in_reply_to_id":null,"pull_request_review_id":4872393980,"user":"tend-agent"}
{"id":3727008234,"in_reply_to_id":3726977948,"pull_request_review_id":4872431767,"user":"tend-agent"}
{"id":3727008359,"in_reply_to_id":3726977955,"pull_request_review_id":4872431925,"user":"tend-agent"}
{"id":3740688673,"in_reply_to_id":null,"pull_request_review_id":4888824594,"user":"max-sixty"}

All four of those review IDs appear in gh pr view 864 --json reviews (as PRR_… node IDs), including 4872431767 / 4872431925, which were created implicitly by reply-only comments.

Outcome on the two decisive PRs:

$ ... pr view 843   → {"merged_by":"max-sixty","logins":["max-sixty","tend-agent"],"state":"MERGED"}
$ ... pr view 77 -R max-sixty/cargo-affected → {"merged_by":null,"logins":["cargo-affected-bot"],"state":"OPEN"}

Pagination, against a --paginated REST count on rust-lang/rust#137944: comments 210 vs 210, reviews 129 vs 129.

[tend-agent]

The single-query collapse works — I ran it against #843 and this PR and the projection is right. One claim in the prose beside it isn't: commits doesn't paginate, and that's the one surface where truncation would recreate the false all-clear this PR exists to prevent.

How I checked

gh pr view builds the commits selection as commits(first: 100) (api/query_builder.go, var prCommits), and pkg/cmd/pr/shared/finder.go only preloads further pages for reviews, comments, closingIssuesReferences, and statusCheckRollup — there is no preloadPrCommits.

Empirically, on a 950-commit PR:

$ gh -R NixOS/nixpkgs pr view 541843 --json commits --jq '.commits | length'
100
$ gh -R NixOS/nixpkgs pr view 541843 --json commits --jq '.commits[-1].oid'
e6b2583ec23ed8e6024ebb6a38541969c6a48c7e
$ gh -R NixOS/nixpkgs pr view 541843 --json headRefOid --jq .headRefOid
edc768bb34e2330a613a73af7f19df710cc63d7a

The connection is oldest-first, so the commits that get dropped are the newest — the "who pushed the follow-up" signal the rule above specifically asks for. A human pushing commit 101 to a long bot PR would come back logins: ["$BOT_LOGIN"].

reviews and comments do paginate as claimed; I confirmed the preload functions exist for both.