{"slug": "review-with-me-a-claude-code-skill-for-reviewing-a-pr-together-runs-code-review", "title": "review-with-me — a Claude Code skill for reviewing a PR together: runs /code-review held back, quizzes you on the diff, then reconciles and posts the surviving findings as inline comments", "summary": "A developer created review-with-me, a Claude Code skill that runs an automated code review in the background, quizzes the human on the diff, and then reconciles the findings with the human's answers before posting approved inline PR comments. The skill ensures the human understands the change before any findings are revealed, with each comment requiring explicit approval.", "body_md": "| name | review-with-me |\n|---|---|\n| description | Review a PR together — runs /code-review in the background with findings held back, quizzes you on the mechanism, callsites, and edge cases while you read the diff yourself, then reveals the findings, reconciles them against your answers, and posts the ones that survive as inline PR comments you approve one at a time. Use for \"review this PR with me\", \"quiz me on PR N\", \"/review-with-me 371\". |\n\nA PR review is finished when the human understands the change, not when a tool prints findings. This skill runs the automated review and the human's own read in parallel, tests the human's understanding before showing any findings, and only then writes comments.\n\n`/review-with-me [target] [--effort=<level>] [--no-post]`\n\n`target`\n\n— PR number, PR URL, branch name, or a path. Empty means the current diff.`--effort=<low|medium|high|max>`\n\n— passed to`/code-review`\n\n. Default`high`\n\n.`--no-post`\n\n— never post to GitHub. Print the final comment set instead.\n\n**No spoilers before the quiz.** From the moment the review agent launches until the quiz is graded, do not print findings, a diff summary, a bug list, a risk list, or a \"here is what this PR does\" paragraph. Status lines only. The quiz is worthless if you answer it first.**Write the answer key before you ask.** Every quiz question gets its correct option and its`file:line`\n\nevidence recorded in the notes file*before*the question is asked. Grading against a key written afterwards is rationalization.**One question, one verifiable answer.** A quiz option is correct because the code says so, not because it sounds sensible. If you cannot point at a line, cut the question.**The human's findings count.** They are reading the PR too. Anything they surface enters the comment set on equal footing with the agent's findings.**Every comment is approved before it is posted.** No batch post without a per-comment pass.\n\nEstablish what is being reviewed and whether posting is possible.\n\n```\ngh pr view <target> --json number,title,headRefName,baseRefName,url,state\ngh pr diff <target> --name-only\n```\n\nIf the target is a branch or path with no PR, set `--no-post`\n\nbehavior for Phase 8 and say so once,\nat the start. Create the notes file at `<scratchpad>/review-with-me-<target>.md`\n\n— it holds the\nanswer key, the held findings, and the comment set, so a context compaction does not lose them.\n\nSpawn one subagent so its findings land in the agent's context, not the terminal:\n\n```\nAgent(\n  subagent_type: \"general-purpose\",\n  description: \"held code review\",\n  prompt: \"Invoke the code-review skill: Skill(skill: 'code-review', args: '<target> <effort>').\n           Follow it fully. Do NOT call ReportFindings — the findings must not render in the host\n           UI. Return the findings as markdown: one block per finding with severity, file:line,\n           a one-sentence claim, and a concrete failure scenario (inputs/state -> wrong result).\n           Rank most severe first. Return the empty list if nothing survives verification.\"\n)\n```\n\nTell the user one line: the review is running and its findings are held until the quiz.\n\nImmediately post the hand-off (Phase 3) so the human starts reading, then study the diff yourself:\n`gh pr diff`\n\n, read the changed files whole, and follow the changed symbols out to their callsites.\nYou are looking for the questions, not for a summary.\n\nDraft 6–10 questions across three bands:\n\n**Mechanism and edge cases**— what the changed code does at a boundary, on the failure path, on the second call, when the input is zero/empty/max, when two effects race.**Callsites and blast radius**— who calls the changed function, which caller now behaves differently, and which parallel implementation was*not*updated (the mirror file, the other language's port, the cached copy, the test fixture).**Findings-derived traps**— one question per significant held finding, built so that the intuitive-but-wrong answer is exactly the bug the review found. These are the highest-value questions: a wrong answer means the human would have merged the bug.\n\nQuestion craft:\n\n- Options must be mutually exclusive and all plausible. An option nobody would pick teaches nothing.\n- Prefer \"what happens when…\" over \"what does this function do\". Behavior, not description.\n- Quote the relevant snippet in the option\n`preview`\n\nwhen the question turns on exact code. - Never signal the answer through option length, hedging, or ordering.\n\nWrite each question, its correct option, and its `file:line`\n\nevidence to the notes file now.\n\nPost a short block:\n\n```\nPR #<n> <title> — <k> files, +<a>/-<d>\nReview running in the background. Findings held.\nRead the diff, then say \"ready\" and I will quiz you.\n```\n\nThen wait. If they ask a factual question while reading (where does X live, what is Y), answer it plainly — that is reading support, not a spoiler. Refuse only the direct asks: \"what did you find\", \"are there bugs\", \"what should I look at\".\n\nAsk in rounds of 3–4 questions with `AskUserQuestion`\n\n. The tool always offers \"Other\", so the human\ncan type a real answer instead of picking one; treat a correct free-text answer as correct even when\nit does not match an option.\n\nAfter each round, grade against the key:\n\n**Correct**— one line confirming it, with the`file:line`\n\n.**Wrong or partial**— state the actual behavior, cite the line, and say what the wrong answer would imply if it were true. No softening, no \"great question\".\n\nEscalate: if a round is clean, make the next round harder — go to the interaction between two changes rather than either one alone. If a round exposes a gap, spend the next round in that area until the model of the code is right. Stop after two rounds if both are clean; the human understands the change and further quizzing is friction.\n\nThen ask what *they* found. Record it in the notes file before revealing anything.\n\nNow show the held findings, sorted into three groups:\n\n**You caught this**— the finding, plus the answer or note that showed they had it. Confirms the read; needs no discussion.** New**— the finding, its failure scenario, and the quiz answer it contradicts if there is one.** You found this, the review did not**— their findings, restated as claims about the code.\n\nFor each finding state the confidence honestly. A finding the agent marked plausible-but-unverified is labeled as such; do not launder it into a certainty because it is now on a list.\n\nDiscuss. The human refutes what they can. Drop a finding the moment the refutation holds — say \"dropped, you are right that X\" and move on, no defense of a dead finding. Keep a finding when the refutation does not actually address the failure scenario, and say which part is unaddressed.\n\nVerify anything still contested against the code rather than arguing from the diff. The output of this phase is a final list: each surviving finding with an agreed severity and an agreed fix.\n\nFor each surviving finding, draft the inline comment and show it for approval:\n\n```\n[3/5] programs/velocity/src/controller/position.rs:412\n\n  The credit can fail after the debit lands. A failed credit leaves the user\n  debited and nobody paid. Claim the credit first, then apply the debit.\n\n  [approve / edit / drop]\n```\n\nLoop until every comment is approved, edited, or dropped. Apply edits verbatim — an edited comment is the human's words, not a starting point to re-polish.\n\nComment style — these are read months later by people who were not here:\n\n- State the fact about the code, then the reason it matters. Then stop.\n- No second person, no first person, no reference to this conversation or to the review.\n- Active voice, simple tenses, one idea per sentence, under 20 words a sentence.\n- A comment that only says \"this is wrong\" is not finished. Name the failure.\n- Respect any repo\n`CLAUDE.md`\n\nrules on comment style; they win over this list.\n\nWith `--no-post`\n\nor no PR, print the final set and stop.\n\nOtherwise post all comments as one review, so the PR gets one notification instead of `n`\n\n:\n\n```\n# payload: {\"event\":\"COMMENT\",\"body\":\"<optional summary>\",\"comments\":[\n#   {\"path\":\"...\",\"line\":412,\"side\":\"RIGHT\",\"body\":\"...\"}, ...]}\ngh api --method POST repos/<owner>/<repo>/pulls/<n>/reviews --input <scratchpad>/review.json\n```\n\nGitHub rejects a comment on a line outside the diff. On rejection, retry that one comment against\nthe nearest changed line in the same hunk, and if that fails too, roll it into a single top-level\ncomment (`gh pr comment`\n\n) that carries the `file:line`\n\nin its text. Report which comments landed\ninline and which did not.\n\nClose with the PR URL, the count posted, and the count dropped during Phase 6.", "url": "https://wpnews.pro/news/review-with-me-a-claude-code-skill-for-reviewing-a-pr-together-runs-code-review", "canonical_source": "https://gist.github.com/ChewingGlass/9a380da5d5a69a540b56d6449556ac5b", "published_at": "2026-08-14 19:45:28+00:00", "updated_at": "2026-08-15 10:42:28.317572+00:00", "lang": "en", "topics": ["developer-tools", "ai-tools", "artificial-intelligence"], "entities": ["Claude Code", "GitHub"], "alternates": {"html": "https://wpnews.pro/news/review-with-me-a-claude-code-skill-for-reviewing-a-pr-together-runs-code-review", "markdown": "https://wpnews.pro/news/review-with-me-a-claude-code-skill-for-reviewing-a-pr-together-runs-code-review.md", "text": "https://wpnews.pro/news/review-with-me-a-claude-code-skill-for-reviewing-a-pr-together-runs-code-review.txt", "jsonld": "https://wpnews.pro/news/review-with-me-a-claude-code-skill-for-reviewing-a-pr-together-runs-code-review.jsonld"}}