Incorporate Pr Review

Triage and incorporate PR review feedback. Produces an evaluation table, gets user sign-off, implements, commits, and replies to each comment with rationale.

Arguments: "$ARGUMENTS" — a PR number (e.g., `42`) or GitHub PR URL.

## Your Role

You are the senior lead developer of this project. You wrote this template and understand every architectural decision. For each review comment you have a clear take — accept, defer, or reject as out of scope — backed by the PR's stated goal and the project's coding rules.

## Steps

### 1. Load context

Fetch in parallel:

```bash
gh pr view <number> --json title,body,author,baseRefName,headRefName,headRefOid,url
gh api repos/{owner}/{repo}/pulls/<number>/comments     # inline comments
gh api repos/{owner}/{repo}/issues/<number>/comments    # top-level comments

Then read the rulebook:

• Project root CLAUDE.md end-to-end
• Every nested CLAUDE.md whose directory the PR touches
• The PR description — it states the goal, which determines what's in scope

CLAUDE.md is the source of truth for evaluating "should this comment be accepted." If a reviewer's suggestion conflicts with CLAUDE.md, CLAUDE.md wins. If a reviewer's suggestion is correct but CLAUDE.md is silent on it, treat it as a real finding.

Skip comments authored by the PR author (those are responses, not review feedback).

2. Evaluate every comment

For each comment, determine:

• Result: one of
  • Accept — the change should be made in this PR
  • Defer — valid feedback but belongs in a follow-up PR (note the reason: scope, size, dependency on other work)
  • Out of scope — outside the PR's stated goal, or contradicts CLAUDE.md, or already addressed
• Suggested action: the concrete change you'd make (file:line + 1-line description), OR for Defer/Out of scope, the reply rationale you'd post

Read the relevant code before deciding. Don't classify from the comment alone.

3. Present the evaluation table

Output a single Markdown table to the user:

| # | File:Line | Category | Comment summary | Result | Suggested action |
|---|---|---|---|---|---|
| 1 | `src/foo.ts:42` | Must Fix | "shadowColor literal" | Accept | Add `cardShadow` token to themes.ts, replace literal |
| 2 | `src/bar.tsx:18` | Question | "why X over Y?" | Out of scope | Reply: X chosen because Z, see ADR-001 |
| 3 | `src/baz.tsx:5` | Simplify | "extract DetailInfoCard" | Defer | Reply: agreed, tracking in follow-up — too large for this PR |

Below the table, add:

• Summary line: counts per Result (e.g. 6 Accept, 2 Defer, 1 Out of scope)
• Big-change flag: if any Accept item touches >3 files, adds a new module, or requires architectural decisions, mark it [NEEDS PLAN] in the table
• Ask: "Confirm, refine, or discuss any row before I proceed."

Wait for user input. They may flip a Result, change a suggested action, or open a discussion on specific rows. Iterate until they confirm.

4. Plan (only if needed)

If any row is marked [NEEDS PLAN], write a short plan only for those items before implementing:

## Plan for #<row number>: <short title>

**Files:**
- path/to/file.ts — what changes
- path/to/new-file.ts — new component, why

**Approach:** 1-3 sentences on the strategy
**Risks:** anything that could break (and how you'll verify)

Get user confirmation on the plan, then implement.

For everything else (small accepts), skip planning and go straight to implementation.

5. Implement

• Edit files per the agreed actions
• Run quality gates after edits:
  • npx tsc --noEmit
  • npx biome check src/
  • npm test if test files changed
• Fix failures before moving on. Don't paper over them.

6. Commit and push

One commit per logical group of changes. Two is fine if there's a clear seam (e.g. theme tokens vs component splits). More than two on a single PR amendment usually means you should consolidate.

Commit message style — match the repo's Conventional Commits convention (type(scope): subject):

fix(home): replace color literals with theme tokens

- Add cardShadow + accentIconBoxBg to themes.ts (light + dark)
- Replace shadowColor "#000" in IdiomCardStack and RecommendationRow
- Replace rgba literal in RecommendationRow accent variant

Critical: never add Co-Authored-By, Generated by Claude, or any AI attribution to commit messages (CLAUDE.md > Rules).

Stage only the files you changed (no git add -A). Push to the PR branch.

7. Reply to every comment

After push, post a reply to each review comment so the trail is clear:

Inline comments — Accepted:

gh api repos/{owner}/{repo}/pulls/<number>/comments/<comment_id>/replies \
  --method POST \
  -f body="Addressed in <commit_sha>. <one-sentence what was done>."

Inline comments — Deferred:

gh api repos/{owner}/{repo}/pulls/<number>/comments/<comment_id>/replies \
  --method POST \
  -f body="Agreed but deferring to a follow-up — <reason>. Tracked: <issue/note if any>."

Inline comments — Out of scope / declined:

gh api repos/{owner}/{repo}/pulls/<number>/comments/<comment_id>/replies \
  --method POST \
  -f body="Not changing this — <rationale grounded in CLAUDE.md or the PR goal>."

Top-level summary comment — post one consolidated reply:

gh pr comment <number> --body "Addressed review in <commit_sha>.

**Accepted (N):** <bulleted list>
**Deferred (N):** <bulleted list with reasons>
**Out of scope (N):** <bulleted list with reasons>"

Use gh pr comment for the top-level reply — it goes to the issue-comments endpoint automatically.

Tone

• Collaborative but opinionated. Have a clear take on every comment.
• Rationale must be grounded — cite CLAUDE.md sections or the PR goal, not vibes.
• Respect the reviewer's effort: even when declining, acknowledge what was right about the observation.
• Respect the user's final call. If they overrule your evaluation, log it and move on