// Walk through unresolved GitHub PR review comments one by one, suggest fixes, and track resolution in a local file. Use when the user wants to address PR feedback.
| name | review-assistant |
| description | Walk through unresolved GitHub PR review comments one by one, suggest fixes, and track resolution in a local file. Use when the user wants to address PR feedback. |
| argument-hint | [PR number or URL, defaults to current branch] |
Walk through unresolved GitHub PR review comments one by one. Suggest fixes and track resolution locally.
<br />, between table cells, after sentence-ending punctuation).Execute the following MANDATORY steps before offering a suggestion, either one you generate, or one you pull from the comment:
Run these three commands in a single parallel batch:
# 1. Get owner/repo slug
git remote get-url origin | sed -E 's|.*github\.com[:/]||; s|\.git$||'
# 2. Get current branch
git branch --show-current
# 3. Check for rtk
which rtk 2>/dev/null && echo "rtk:yes" || echo "rtk:no"
If rtk is present, preface every subsequent gh command with rtk proxy to bypass output compression.
$ARGUMENTS is provided, use it directly as the PR number (skip this step).# Replace {owner}, {repo}, {owner_prefix}, {branch} with values from 1a
gh api "repos/{owner}/{repo}/pulls?head={owner_prefix}:{branch}&state=open" \
--jq '.[0] | {number, title}'
The {owner_prefix} is the part before / in the slug (e.g. adaptyteam from adaptyteam/adapty-docs).
Run these two in a single parallel batch once you have owner, repo, and PR number:
# Inline review threads (unresolved only)
gh api graphql -f query='
{
repository(owner: "{owner}", name: "{repo}") {
pullRequest(number: {number}) {
reviewThreads(first: 100) {
nodes {
isResolved
comments(first: 10) {
nodes {
path
line: originalLine
author { login }
createdAt
body
databaseId
}
}
}
}
}
}
}' --jq '.data.repository.pullRequest.reviewThreads.nodes[] | select(.isResolved == false) | .comments.nodes[] | {path, line, author: .author.login, date: .createdAt, body, id: .databaseId}'
# Top-level PR (issue) comments
gh api "repos/{owner}/{repo}/issues/{number}/comments?per_page=100" \
--jq '.[] | {author: .user.login, date: .created_at, body: .body, id: .id}'
The PR title comes from step 1b — no extra API call needed.
Before writing the tracking file, classify each comment by complexity:
Reorder all comments: Easy first, then Medium, then Hard. Number them in this new order.
(Comments are already sorted by complexity from Step 2.)
_temp/ exists and is gitignored (check .gitignore; add _temp/ if missing)._temp/pr-{number}-comments.md with all comments translated to English.Format:
# PR #{number}: {title}
{comment_count} comments from {authors}. Fetched {date}.
## Pending
---
### Comment 1 — {path}:{line} — {complexity} — {status}
**Author:** {author} | **Date:** {date} | **GitHub ID:** {id}
**Original ({detected_language}):**
> {original body}
**Translation:**
> {English translation}
**Deviations during resolution:**
---
## Applied
## Applied with deviations
{status} in the heading is either Pending, Applied, or Applied with Deviations.Applied and the Status field, but NEVER remove content. Move the comment to the "Applied" section of the file when resolved, with all the content intact.Applied with Deviations and the Status field, but NEVER remove content. Move the comment to the "Applied with Deviations" section at the bottom of the file when resolved, with all the content intact.Show:
Then show a table of all comments sorted by complexity:
| # | File:Line | Complexity | Summary |
|---|---|---|---|
| 1 | file.mdx:42 | Easy | Fix typo "recieve" → "receive" |
| 2 | file.mdx:78 | Easy | Revert link URL |
| 3 | file.mdx:120 | Medium | Rewrite intro for clarity |
| 4 | file.mdx:200 | Hard | Add missing section on callbacks |
The Summary column is a short (under 10 words) description of what the reviewer asks for.
If there are Easy comments, mention that batch-apply is available (see Step 6a).
Then say: "Ready to start with Comment 1. Say 'go' to begin, or 'batch' to batch-apply all Easy fixes."
Clear _temp/backups/ to remove stale backups from previous sessions.
Run git status and git log HEAD..@{u} (silently). Then:
For each comment, in complexity order (easiest first):
Gather context first, then present everything at once. Run all file reads and git commands BEFORE producing any output for the user. The user should see one uninterrupted block — not text interleaved with tool calls.
If the user says "batch" at the summary step, or asks to batch-apply during the walkthrough:
| # | File:Line | Current text | Suggested fix |
|---|---|---|---|
| 1 | file.mdx:42 | recieve | receive |
| 2 | file.mdx:78 | /old-link | /new-link |
Read context (silent, MANDATORY). Read the relevant section of the current file AND the original from main branch (git show main:{path}) around the commented line.
Check if already addressed (silent, MANDATORY). Compare the current working tree against what the reviewer asks for.
Fact-check (silent, MANDATORY). For EVERY suggestion, verify EVERY factual claim against other content in the project. For new features without existing documentation coverage, check the claim against other changes in the working branch. Do not assume something is true because it sounds plausible. If you cannot verify a claim, explicitly mention it as UNVERIFIED. This applies equally to the reviewer's claims and to anything you add yourself. Search the codebase for evidence before presenting.
Present everything in one block. Output all of the following together, with no tool calls in between:
End with: Apply / Skip / or discuss
Suggest. If the comment is NOT already addressed, then based on the comment:
Wait. Do not proceed until the user responds. Possible user responses:
Summarize deviations, if any. If the user does not follow the reviewer's suggestion 100% exactly, fill in the Deviations during resolution section. Write it as a conversational reply to the reviewer — as if the user is responding to their comment on GitHub. Explain what was kept, what changed, and why. Pull the reasoning from the user's conversation with you. Do not quote the article text — keep it focused on the "why." If part of the final result was already in the original PR submission (not a new change), say "I kept..." rather than presenting it as a modification.
Before the first edit to any file in a session, copy it to _temp/backups/{path}/{filename}.bak, preserving the directory structure to avoid name collisions (e.g., _temp/backups/src/content/docs/version-3.0/file.mdx.bak). Skip if a backup for this file already exists in _temp/backups/. Do not mention backups to the user unless they need to restore a file.
After you process all the comments, show:
Clean up _temp/backups/.
Use when adding support for a new locale/language to the Adapty docs site. Covers all hardcoded and dynamic locale registration points, translation commands, sitemap setup, Algolia search config, and the step-by-step order to follow.
Use when reviewing documentation from a product perspective — whether feature value is clear, onboarding flow makes sense, or technical descriptions align with real user experience. Does not check writing style.
Use when adding a new monthly section to src/content/docs/release-notes/whats-new.mdx — gathers commits to main over a date range, identifies user-facing updates worth featuring, confirms scope with the user, then drafts the section in the existing style.
Use when finishing work on a feature branch and wanting to promote it to develop (or another integration branch) while staying on the original branch. Handles commit, push, merge, push develop, and return.
Use when reviewing or writing MDX files in src/content/docs — proofreading, checking technical writing quality, verifying Simplified Technical English compliance, validating links and images, or drafting new doc content.
Use when documentation needs to be planned and written end-to-end — from a Jira task, feature spec, or verbal description through to a polished draft. Not for review-only or planning-only tasks.