메뉴
Use when posting validated code review findings as GitHub PR line-level comments or a GitHub PR review after completing a review.
| name | add-pr-comments |
| description | Use when posting validated code review findings as GitHub PR line-level comments or a GitHub PR review after completing a review. |
Post validated code review findings from the current review as a GitHub PR review with line-level comments. Use this only after findings have been reviewed, deduplicated, and validated against the current diff.
Resolve the PR.
gh pr view --json number,headRefOid,url -q '{number: .number, sha: .headRefOid, url: .url}'Confirm review language.
Use the final finding list.
file:line or file:startLine-endLine), why it matters, and recommended fix.Classify findings.
file:line or file:startLine-endLine format.Filter and deduplicate.
low confidence findings unless severity is high or critical.Build the GitHub review payload.
gh repo view --json nameWithOwner -q .nameWithOwner/repos/{owner}/{repo}/pulls/{pr_number}/reviews.commit_id: HEAD commit SHA from step 1event: APPROVE for ready to approve, otherwise REQUEST_CHANGESbody: a short, plain-language summary of how the PR looks overall — the gist you'd give a teammate, not a formal reportcomments: line-anchored comments, each with:
path: relative file path from repo rootline: line number, or range end linestart_line: range start line, only for multi-line rangesside: RIGHTbody: formatted finding commentWrite each comment like a human reviewer, not a linter.
Talk to the author like a teammate. Lead with the problem in plain language, use contractions, and ask a question when you're genuinely unsure. Vary your openings — don't start every comment the same way. One or two sentences is usually enough; don't pad, and drop the rigid template and bracketed severity tags.
nit: or minor: for small stuff; for a blocker, just say it's a blocker and why.Examples:
name here — it's concatenated straight into the query, so a crafted value runs arbitrary SQL. Can we switch to a parameterized query? This one's a blocker."lib/date.js already exports a formatDate() that does this — worth importing it instead so we don't keep two copies in sync?"reduce could just be .flat()."Post the review.
gh api ... --input <payload-file>.Handle errors.
422: move comments that cannot be anchored to the diff into the review body, then retry.403 or 404: report that the gh token or user may lack write access.Report the result.
APPROVE or REQUEST_CHANGES.Use when reviewing branch or PR changes against a base branch for correctness, security, concurrency, architecture, maintainability, testing, and performance risks.
Applies Karl Popper’s critical rationalism to software engineering, programming, and product building by treating requirements, designs, implementations, and product ideas as falsifiable hypotheses. Emphasizes conjectures and refutations, explicit assumptions, fast error discovery, small risky experiments, observable failure signals, reversible designs, and iterative elimination of mistakes.
Interview the user relentlessly about a plan or design until reaching shared understanding, resolving each branch of the decision tree. Use when user wants to stress-test a plan, get grilled on their design.
Baseline coding behavior. Use before writing, reviewing, debugging, or refactoring code. Establishes ground rules for assumptions, simplicity, surgical edits, and verification.
Generate or check Codex CLI .codex-plugin/plugin.json and Gemini CLI gemini-extension.json manifests from a Claude Code .claude-plugin/plugin.json source manifest. Use when maintaining one plugin across Claude Code, Codex CLI, and Gemini CLI, syncing plugin metadata, preserving platform-specific manifest fields, or validating cross-platform plugin manifests before release.
Use when improving an article or long-form draft for structure, clarity, coherence, flow, readability, or prose quality while preserving meaning, accuracy, intent, and voice.