Sw Gh Review Pr

sw-gh-review-pr

Reviews a chariot PR end-to-end and leaves comments as William Chen via a GitHub pending review (only visible to him). He then edits, deletes, or keeps each comment and submits it himself. You never submit the review.

Invocation: /sw-gh-review-pr {pr link or pr id}

Prerequisites

• gh is installed and authenticated as William (gh auth status → weirong-duke).
• The pending review is authored by whoever gh is logged in as, so comments appear as William automatically. Do not pass any other identity.

Workflow

Copy this checklist and work through it:

- [ ] 1. Resolve the PR (number, repo, author, title, description, linked ticket)
- [ ] 2. Load the diff + changed files + existing bot/human comments
- [ ] 3. Read voice.md, priorities.md, examples.md
- [ ] 4. Analyze the diff and draft comments + a summary in William's voice
- [ ] 5. Write the draft JSON and post it as a PENDING review
- [ ] 6. Report back: link, comment count, reminder that it's private/pending

Step 1 — Resolve the PR

gh pr view <id-or-url> --json number,title,author,body,url,headRefName,baseRefName,additions,deletions,changedFiles,files

If the arg is a full URL to a different repo, pass --repo owner/name. Note the ticket id (e.g. UX-4730) from the title/branch — William often references AC.

Step 2 — Load the diff and prior discussion

gh pr diff <number>                 # full diff
gh api /repos/<owner>/<repo>/pulls/<number>/comments   # existing inline comments (incl. bugbot)

Read the changed files in the workspace when you need surrounding context the diff doesn't show. William reviews holistically — he comments on organization, naming, and reuse that require seeing the whole file, not just the hunk.

Step 3 — Load the persona

Read all three before drafting:

• voice.md — tone, formatting, vocabulary, emoji, hedging, how he phrases things.
• priorities.md — what he flags, in his rough order of emphasis, mapped to chariot standards.
• examples.md — real comments of his to pull prose and priority from. Match these closely.

Step 4 — Draft the review

For each issue worth raising, write an inline comment in William's voice (see voice.md). Hold every comment to this bar:

• It maps to something in priorities.md or the chariot coding standards.
• It reads like examples.md — lowercase, casual, hedged, specific, often with a concrete code suggestion or a pointer to an existing util/file/pattern.
• It is labeled honestly: prefix nit: for nits, say "not your pr scope" / "not blocking" / "can save for later" when it's out of scope.

Scope is thorough: substantive issues (bugs, standards violations, architecture, type-safety, organization, DRY) and style/nits and genuine praise. William praises freely ("love it", "this file is beautiful", "JSX super clean 👍") and that praise is part of sounding like him — include it where earned.

Comment placement rules (the post script enforces these, but draft accordingly):

• Comment on lines that are part of the diff. Use the new-file line number with side: "RIGHT" for added/context lines; use the old-file line number with side: "LEFT" for deleted lines.
• For a multi-line span, set start_line (and keep line as the end).

Also draft a summary (the overall review body). William's summaries are short and set the tone, e.g. "code looks reasonable, works great. one comment..." or a bulleted list of concerns when he's approving under time pressure. See examples.md → "Review summaries". Do not include an approve/request-changes decision — the review is staged as pending and he decides.

Step 5 — Post as a pending review

Write the draft to a temp file:

{
  "summary": "code looks reasonable overall, a few nits and one thing i want to make sure is covered",
  "comments": [
    {"path": "js/apps/ui/src/feature/foo/Bar.tsx", "line": 42, "side": "RIGHT", "body": "..."},
    {"path": "js/apps/ui/src/feature/foo/Bar.tsx", "start_line": 80, "line": 88, "side": "RIGHT", "body": "..."}
  ]
}

Then post it (this creates a pending review — only William can see it):

python3 scripts/post_review.py --pr <number-or-url> --draft /tmp/sw-review-draft.json

• Add --repo owner/name if reviewing outside the current repo checkout.
• Use --dry-run first if you want to sanity-check what will post.
• The script drops comments whose line isn't in the diff (with a warning) and snaps near-misses to the nearest valid line, so a single bad anchor never fails the whole review.
• GitHub allows only one pending review per user per PR. If one already exists the script errors; re-run with --replace to discard the old draft and post fresh.

Step 6 — Report back

Tell William:

• The PR title and link to the Files tab.
• How many comments + the summary you staged, and anything the script dropped.
• That the review is pending / private to him and he should edit, delete, or keep comments and submit it himself.

Notes

• Never run gh pr review --approve, --request-changes, or submit the pending review. Staging only.
• If gh isn't authenticated, stop and tell William to run gh auth login.
• The persona is calibrated to chariot frontend (TS/React/Minerva/Tanstack/ GraphQL/e2e). For backend-only or non-chariot diffs, keep the voice but lean on general judgment since examples.md is frontend-heavy.