Review target: GitHub pull request 1715.

Gather this target's diff with (instead of any local git diff):

1. gh pr view 1715 --json title,body,author,baseRefName,headRefName,state,additions,deletions,changedFiles,labels for context
2. gh pr diff 1715 for the unified diff

The PR's diff is the only review scope — local working-tree changes are out of scope. When you need surrounding code, Read the files in this checkout if it matches the PR's branch, otherwise fetch file contents via gh.

Analyze the changes and provide a thorough code review that includes:

• An overview of what the PR does
• Analysis of code quality and style
• Specific suggestions for improvements
• Any potential issues or risks

Keep your review concise but thorough. Focus on:

• Code correctness
• Following project conventions
• Performance implications
• Test coverage
• Security considerations

Format your review with clear sections and bullet points.

check computermode PR feedback, it is very valuable, follow her recomendations and also, fix main conflicts

Base directory for this skill: /Users/gtrrz-victor/.claude/skills/review-pr-feedback

Review PR Feedback

Walk every unresolved review thread on the PR for the current branch. For each thread, decide whether it's actionable, fixable, or needs the user's input. Apply fixes, post a reply explaining what changed, and resolve the thread.

Step 1: Locate the PR

1. If 1715 is a number, use that PR.
2. Otherwise resolve from the current branch:
3. If there is no PR for the current branch, stop and tell the user.

Step 2: List every review thread (resolved status + bodies)

GitHub's REST endpoints don't expose isResolved, so use GraphQL:

Also pull issue-level comments for context:

Save the GraphQL result so you can reference thread IDs and the first comment's databaseId (used as the reply parent below).

Step 3: Triage and group threads

For each thread that is not already isResolved:

• Read the body fully — bot comments (Cursor Bugbot, Copilot, etc.) are often long and the actionable bit is buried after metadata.
• Classify as one of:
  • Easy fix — uncontroversial, narrow scope (e.g. "use f.Reader instead of f.Contents", "add validation", "fix typo"). Just do it.
  • Already fixed — earlier commits on the branch already addressed the concern. Don't re-fix; reply explaining where it landed.
  • Outdated/no longer applies — code shape changed. Reply briefly noting the current state and resolve.
  • Needs decision — design tradeoff, scope question, or "won't fix" candidate. Hold for the user.
• For threads marked isOutdated: still address them; outdated ≠ irrelevant, GitHub just collapsed them because the underlying line moved.

Skip resolved threads silently — those have already been handled.

Step 4: Ask the user about the hard ones

Before applying any fixes that involve a tradeoff or non-trivial scope, batch the open questions into a single AskUserQuestion call. Group easy-fix threads as one question ("OK to apply these N small fixes and resolve?" with options for "do all", "do some", "skip"). Keep questions short and include enough context that the user doesn't have to scroll back.

If a thread reports a security or correctness concern that needs a real investigation (e.g. "race condition under concurrent X"), surface that explicitly rather than treating it as easy.

Step 5: Apply fixes

Make the code changes, then run before pushing:

Fix any linter/test fallout from the changes. Don't push if anything is red.

If a nolint directive becomes "unused" after a config change, decide between adding the type to the linter allowlist (preferred for stable cases) or removing the directive — never both.

Step 6: Commit and push

Stage only the files you changed (never git add -A). Use one commit per logical group; e.g. one for the "easy fixes" batch, one per substantial change. Commit messages focus on why, not what. Reference PR threads by topic, not by GitHub numeric ID — those don't render anywhere useful.

Push:

Step 7: Reply on each thread + resolve

Use the first comment's databaseId as the parent, not the thread ID:

Reply guidelines:

• Cite the commit hash that addressed the concern: Fixed in abc1234.
• Summarize what changed in one sentence — the reviewer doesn't need a detailed explanation, just enough to verify.
• For "won't fix" replies, give the rationale once, briefly. Don't argue.

Step 8: Final sweep

After resolving everything you can, re-run the GraphQL query to confirm:

Report to the user:

• Number of threads addressed (with one-line summary each)
• Number deferred and why
• Final commit hash + PR URL

Rules

• Never resolve a thread without posting a reply first. The reply is the audit trail.
• Don't --force push.
• Don't bypass the build/lint/test gate to land "review fixes" — broken main is worse than slow review cycles.
• If a reviewer's concern is wrong, explain why in the reply and resolve. Don't leave open threads festering.
• If you genuinely can't tell what a thread is asking for, ask the user — don't guess and resolve.

try it again