Impl Review

Implement Review Feedback

Checkout a PR's branch, implement the reviewer's feedback, run preflight checks,

commit, and push.

Arguments

• <pr-number> (required) — The PR number in brave/brave-core to implement

review feedback for.

Confirmation

Always ask for user confirmation before implementing changes, before

committing/pushing, and before posting comments on GitHub.

Steps

1. Parse Arguments

Extract the PR number from the arguments. It must be a numeric value. If no PR

number is provided, ask the user for one.

2. Fetch PR Details

gh pr view $PR_NUMBER --repo brave/brave-core --json headRefName,title,body,state,files,baseRefName

Extract:

• Branch name (headRefName) — the branch to checkout
• Title — for context
• State — must be OPEN (abort if closed/merged)
• Base branch — for understanding the diff context
• Changed files — to understand what the PR modifies

If the PR is not open, inform the user and stop.

3. Fetch Review Comments

Fetch review data from the PR:

gh api repos/brave/brave-core/pulls/$PR_NUMBER/reviews --paginate
gh api repos/brave/brave-core/pulls/$PR_NUMBER/comments --paginate
gh api repos/brave/brave-core/issues/$PR_NUMBER/comments --paginate

This provides:

• Reviews (approve/request changes/comment)
• Inline code review comments (with file paths and line numbers)
• Issue-level discussion comments

4. Analyze Review Feedback

Parse the review comments to understand what changes are requested:

• Identify actionable feedback — Focus on explicit change requests from

reviewers. Ignore:

• Approvals without change requests
• Informational comments that don't require action
• Comments that have already been addressed (check commit timestamps vs

comment timestamps)

Questions are not change requests. When a comment is phrased as a

question, answer the question first. Do not make code changes in response to

it unless the reviewer or requester explicitly asks for a change.

• Categorize each requested change:

• Which file(s) need modification
• What specific change is requested
• Whether it affects production code, test code, or both

• Present the plan:

• How many review comments were found
• Which are actionable vs already addressed
• Which comments are questions, the proposed answer for each one, and which

question comments (if any) also contain an explicit change request

• What changes you plan to make for each
• Ask for user confirmation before proceeding with implementation

• Answer questions before implementation:

• For question-only comments, post the answer immediately and do not make

code changes

• If a question also contains an explicit change request (for example, "Could

you change X?"), post the answer first, then follow the normal

implementation confirmation flow for the requested change

5. Checkout the Branch

git fetch origin
git checkout <headRefName>
git pull origin <headRefName>

Ensure you're on the correct branch and up to date with the remote.

6. Implement Changes

CRITICAL: Only make changes the reviewer explicitly asks for.

• Do NOT make any additional changes — no "while I'm here" cleanups, no extra

refactoring, no renaming things the reviewer didn't mention

• If the reviewer asks you to fix one thing, fix exactly that one thing and

nothing else

• Every extra change risks introducing issues and makes the reviewer's job

harder

• Read the full source files for context before making changes (don't just look

at the diff)

• Apply the same coding standards as the rest of the codebase

7. Run Preflight Checks

Invoke the preflight skill to validate all changes:

/preflight

This runs: best practices check, format, gn_check, presubmit, build, and

affected tests.

If preflight fails:

• Fix the issues it identifies
• Re-run preflight until it passes
• All fixes should still be scoped to the review feedback (don't fix unrelated

issues)

8. Commit and Push

Before committing, show the user a summary of all changes (files modified, diff

stats) and ask for confirmation. If the user rejects, stop without committing.

ALWAYS create a NEW separate commit — never amend existing commits.

git add <changed-files>
git commit -m "$(cat <<'EOF'
Address review: <brief description of changes>
EOF
)"
git push

Commit message guidelines:

• Start with "Address review:" prefix
• Briefly describe what feedback was addressed
• Keep under 72 characters for subject line
• DO NOT include any Co-Authored-By line
• DO NOT use --no-verify or --no-gpg-sign flags

If multiple logical units of review feedback were addressed, consider separate

commits for each.

9. Post PR Comment

Show the draft comment to the user and ask for confirmation before posting. If

the user rejects, skip posting.

If question answers were already posted before implementation, do not duplicate

them in the final summary comment; briefly reference that they were answered and

summarize only the implemented changes.

Post a summary comment on the PR:

gh pr comment $PR_NUMBER --repo brave/brave-core --body "$(cat <<'EOF'
Fixed: <description of what was changed>

<For each review point addressed, briefly note what was done>
EOF
)"

10. Report Summary

Output a summary to the user:

• PR number and title
• Number of review comments addressed
• What changes were made
• Preflight result (pass/fail)
• Commit SHA
• Link to the PR

Important Rules

• Questions first — Answer comments phrased as questions before taking

action; do not change code unless the reviewer or requester explicitly asks

• Minimal changes — Only implement what reviewers explicitly ask for
• New commits only — Never amend; separate commits let reviewers track what

changed

• No attribution — No Co-Authored-By lines in commits
• User confirmation — Present the plan before implementing, confirm before

committing, and confirm before posting summary comments; question answers do

not require confirmation

• Preflight required — All changes must pass preflight before pushing

Example Usage

/impl-review 12345

Asks for confirmation before implementing, committing, and posting.