`get-reviews` agent skill for handling PR reviews

[2chanhaeng]

Background

When an AI agent helps resolve GitHub PR reviews on this repository, two problems consistently surface:

• Context overload. Raw gh pr view or GraphQL output dumps every review thread, comment chain, and bot noise into the agent's context window. The agent then tries to reason about all threads simultaneously, mixes them up, and loses precision on the specific change each review actually asks for.
• Loss of human oversight. Agents are good at proposing how to resolve a review, but only the contributor can authoritatively decide whether a review is correct, wrong, or needs discussion. Without an explicit checkpoint, the agent quickly slides into deciding-and-applying in one motion, and the contributor ends up reviewing the agent's commits after the fact rather than its judgement.

Proposal

Add a get-reviews skill that frames review handling around two principles:

1. Local, structured review management

Each review thread is materialized as its own file under plans/{PR_NUMBER}/reviews/{REVIEW_ID}.md, with frontmatter (review id, permalink, applied commit hashes) and fixed sections (Title, Summary, Judgement, Plans, Comments). Resolved reviews move to plans/{PR_NUMBER}/reviews/resolved/; long discussions expand into a subdirectory. This gives:

• A persistent local record that survives across agent sessions and isn't tied to whatever the agent happened to load into context at the time.
• A predictable file layout the contributor can navigate independently of the agent — open a review file, see exactly what's planned, what's applied, and what's pending.
• Stable identifiers (review id, databaseId-based permalinks) so commits can link back to the originating thread via #discussion_r{databaseId}.

2. Filtered context per review

Instead of feeding the agent the entire PR conversation, the skill fetches review threads through a focused GraphQL query (fetch_reviews.sh) that extracts only the fields the agent actually needs to reason about a single review: thread state, file/line, comment bodies, author, permalink. Each review file then becomes the agent's working context for that thread — bounded, self-contained, and aligned one-to-one with what's being resolved. Long-tail discussion or unrelated thread noise stays out of the prompt.

3. Mandatory contributor checkpoint

The Judgement step is explicitly handed back to the contributor, not decided by the agent alone. The agent drafts an initial classification — CORRECT / WRONG / PARTIAL / NEEDS EVALUATION / NEEDS DISCUSSION — and a corresponding Plans section, but the SKILL document instructs the agent to wait for the contributor to read, adjust, and confirm each review file before any code change or response comment is applied. Comment drafts follow the same rule: when a review was written in the contributor's native language, the agent prepares both the original-language and English versions and asks the contributor to verify the translation, rather than posting unverified English back to GitHub.

This turns the agent into a structured assistant for review work — one that organizes, summarizes, and proposes — while leaving authoritative judgement and external-facing communication with the contributor.

Components

• .agents/skills/get-reviews/SKILL.md — the workflow (fetch → organize → resolve), the file-layout convention, the judgement taxonomy, and the bilingual comment policy with the discrepancy-check requirement.
• .agents/skills/get-reviews/fetch_reviews.sh — the focused GraphQL query, with pagination support (first initially, after: $LAST_REVIEW_ID for incremental updates) so re-fetching a PR doesn't redo work or duplicate context.
• .agents/skills/get-reviews/review.md — the per-review file template, with section comments that prompt the agent to fill in Plans/Comments specifically and explicitly leave Judgement open for the contributor.

Out of scope

• Auto-resolving review threads on GitHub once a commit lands. The skill stops at preparing the local file and the response comment; marking the thread resolved on GitHub stays with the contributor.
• A fast path for accepting GitHub's "suggest a change" suggestions verbatim. The skill treats inline suggestions as ordinary review comments for now; a dedicated suggestion-accept flow can be added later if it earns its complexity.