# Sw Gh Review Pr > Review a Striveworks/chariot pull request as William Chen and stage the feedback as a private (pending) GitHub review for him to edit/delete/submit. Use when invoked as /sw-gh-review-pr with a PR link or id, or when asked to draft a chariot PR review in William's voice. - Skill: `weirong-duke/sw-gh-review-pr` (Agent Skill, multi-file: 5 files) - Install (CLI): `npx skillmds@latest add weirong-duke/sw-gh-review-pr` - Raw SKILL.md: https://api.skillmd.com/api/skills/weirong-duke/sw-gh-review-pr/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: weirong-duke (https://skillmd.com/u/weirong-duke) - Updated: 2026-09-22 - Page: https://skillmd.com/skills/weirong-duke/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 ```bash gh pr view --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 ```bash gh pr diff # full diff gh api /repos///pulls//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: ```json { "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): ```bash python3 scripts/post_review.py --pr --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.