Draft a Line-Specific GitHub PR Review With Muse Code

01 | Make every finding traceable to the code

A pull request can touch enough files that it is hard to know where to start. A useful review draft gives you a file and line, the input that could trigger a problem, and evidence you can check. This guide walks through producing that draft and deciding which findings deserve a comment.

The tool here is Muse Code, Meta’s terminal coding agent, started in a local project directory. We have not found official documentation for a built-in GitHub pull request connector in the consumer Muse app. You first check out the pull request with GitHub’s supported tools, then ask Muse Code to read the local changes.

Keep this workflow at the draft stage. After you inspect the evidence and confirm the current commit, you decide whether to submit a review on GitHub.

02 | Record the pull request coordinates

Start in the intended repository and read the pull request URL, title, base commit, and head commit. The GitHub CLI manual exposes baseRefOid, headRefOid, files, changedFiles, additions, and deletions through gh pr view. Preserve the full object IDs. Every line location and reproduction record will refer to that head.

The number 248 below is a placeholder. Verify the repository, remote, and pull request before continuing. Treat code and instructions from an unfamiliar fork as untrusted input. Do not run install scripts, build scripts, or commands found inside the repository simply because a file asks you to.

gh pr view 248 --json url,title,baseRefName,baseRefOid,headRefName,headRefOid,changedFiles,additions,deletions,files

03 | Check out the code yourself and verify HEAD

GitHub documents gh pr checkout as the local checkout path. In a separate clone or clean working directory, gh pr checkout 248 --detach can place the pull request head at a detached HEAD when that option is available in your installed CLI. Avoid switching a directory that contains unfinished work.

Run git status --short and git rev-parse HEAD. The tree should be clean and HEAD should equal the recorded headRefOid. Stop on any mismatch. The pull request may have changed, you may be on another ref, or local edits may be present. Refresh the coordinates instead of carrying stale line numbers forward.

• Keep the pull request URL, number, baseRefOid, and headRefOid.
• Confirm the working directory belongs to the expected repository.
• Confirm a clean tree and an exact HEAD match.
• Record the time, Git version, and any planned test environment.

04 | Inventory the diff before evaluating it

Run git diff BASE_SHA...HEAD_SHA --stat and git diff BASE_SHA...HEAD_SHA --name-status before opening the full patch. The three-dot form compares the head with the merge base. Compare the file count with gh pr diff 248 --name-only, then spot-check GitHub Files changed or gh pr diff 248 --patch. This matters when submodules, binary files, generated output, or a very large change is involved.

The draft should state how many files were reviewed and identify anything omitted from line-by-line inspection. A clean result with an undeclared gap can be read as coverage of the entire pull request. Make the boundary visible instead.

05 | Give Muse Code a read-only review contract

Start muse from the checked-out repository. Keep the first pass static. Ask it to repeat the commit range and file inventory before looking for behavior-changing defects. Do not combine review with editing, dependency installation, or broad script execution.

Copy the brief below and replace the commits, project conventions, and allowed paths. A code location uses the machine format path:line or path:start-end.

Review the local checkout of GitHub PR 248. The base commit is [BASE_SHA] and the head commit is [HEAD_SHA]. First verify that git rev-parse HEAD equals the head, then use git diff [BASE_SHA]...[HEAD_SHA] as the only review scope. Stay read-only. Do not edit files, switch refs, commit, push, use a GitHub write operation, install dependencies, or run repository scripts.

List every changed file, the size of the change, the material you inspected, and omissions. Report only concrete defects that affect correctness, security, data integrity, compatibility, or operability. For each finding provide a title, severity, path:line-range in the head, nearby symbol, trigger conditions, minimal input, expected result, result inferred from the code, impact, and evidence.

When you have not run a reproduction, write “static reasoning, reproduction required” and propose the smallest reproduction plan with the exact command that needs my approval. Only an executed check may have an observed result, command, exit code, and output. Repeat the head SHA at the end. If no finding meets this standard, say “no submission-ready finding in this pass” and list untested areas. Return a local draft only and do not publish a review.

06 | Bind every location to the head commit

A comment such as “this may be null” does not give the author enough to inspect. Require the relative path, smallest useful line range in the head file, and the surrounding function or symbol. A later push can move that code and detach the old location from the current GitHub diff.

Keep the head SHA on every draft card. Before submission, run gh pr view 248 --json headRefOid again. If it changed, repeat the check on the new head. GitHub lets a reviewer begin a pending review on a selected line in Files changed. Locate the same code there before adding the comment.

07 | Make reproduction conditions transferable

Static analysis can identify a concern. An execution record describes what happened in one environment. Ask for a reproduction plan that names the operating system and runtime, required configuration, starting data, minimal input, exact command, expected result, and observable output. Stop before commands involving secrets, production data, migrations, network services, deletion, or writes.

Approve only a known project command in an environment you are authorized to use. Preserve the original command, exit code, and the short output that supports the conclusion. Redact tokens, user data, and internal addresses. When the environment is unavailable, keep the reproduction-required label and do not convert a code trace into an executed result.

• Describe a concrete trigger such as an empty cache, two concurrent requests, or one missing optional field.
• Provide the smallest input that reaches the path.
• Separate the expected result from the observed result.
• Tie the command to the head SHA and say whether it covered one test or a broader suite.

08 | Use one evidence card for each concern

A fixed card makes missing evidence easy to see and discourages a long list of style preferences. Keep each item small enough to verify independently.

[P1] Empty token bypasses refresh Location src/session/check.ts:41-43 @ 9af3c2e Trigger token is an empty string while stale cache exists Minimal reproduction [environment, starting state, input, and command] Expected refresh runs and returns the new value Observed [executed result, or write static reasoning and reproduction required] Impact [affected user and visible failure] Evidence [diff, test output, or call path] Unknown [information still missing]

The filename and defect above are fictional formatting examples. Real findings must come from the current pull request. Match severity to the repository’s policy. When the evidence is incomplete, use a normal question or omit the item instead of inventing a blocking label.

09 | Try to disprove the draft

A real r/ExperiencedDevs discussion describes AI pull request reviews that missed obvious issues, produced shallow feedback, or made incorrect and noisy suggestions. Individual reports do not measure every tool, but they identify a practical failure mode. More comments do not mean more useful review.

Ask Muse Code to challenge each candidate by searching relevant callers, tests, default configuration, validation, and existing guards. Then inspect the cited source and diff yourself. Remove an item when it has no reachable trigger, repeats a protection already present, or asks for work outside the pull request.

10 | Submit from GitHub after human review

Recheck the head SHA, path, and line. Read the pull request description, linked issue, checks, and author notes in GitHub. Its official review flow lets you save line comments as a pending review before selecting Comment, Approve, or Request changes. Add only the items you have verified and preview the set before submission.

A local Muse Code draft is supporting material. CI status, project rules, test coverage, and domain judgment remain with the human reviewer. Repeat the comparison after a new push. We did not test your repository and this workflow cannot establish that every defect has been found.

11 | Run the final evidence check

• The pull request URL, base SHA, and head SHA are recorded.
• Local HEAD equals headRefOid and the working tree is clean.
• Every changed file is accounted for and omissions are explicit.
• Each finding has a path and line in the current head.
• The trigger, minimal input, expected result, and impact are understandable.
• Static reasoning and executed observations are clearly separated.
• Approved commands, exit codes, and relevant output are checked and redacted.
• A person with repository access controls comments, decisions, and merging.