PR Comment Resolution
Work from the live PR and current branch. Treat each review thread as a decision record, not a checklist.
Workflow
- Fetch the PR metadata, review summaries, issue comments, inline comments, and review-thread resolution state. Use GitHub CLI/API tools when available.
- Classify each unresolved thread:
- Implement: a concrete bug, missing test, or low-risk improvement that matches the PR scope.
- Push back: a suggestion that is incorrect, redundant, expands scope, conflicts with a contract, or lacks enough value.
- Clarify: a genuine product or design decision that needs user direction.
- Read the relevant local instructions and inspect the actual code path before deciding. Do not accept a comment purely because it sounds reasonable.
- Present a concise recommendation when user direction is needed. Otherwise, implement the approved changes tightly; do not refactor unrelated code to satisfy a small comment.
- Add the smallest behaviour-level regression where a comment exposes a gap. Prefer an existing test file and test the boundary that proves the contract, not just schema acceptance or a mocked layer.
- Follow repository formatting, build, type-check, lint, and focused-test requirements. Report existing warnings separately from new failures.
- Commit and push before marking an implementation comment done, unless the user explicitly asks not to publish changes.
- Reply in each relevant thread:
- For completed work, use
Done. if the user requests terse acknowledgement; otherwise say what changed and where.
- For pushback, give a short evidence-based reason and state the retained behaviour.
- Do not claim a fix is done until it is pushed and verified.
- Resolve only the threads the user authorizes. After resolving, re-query thread state and confirm that no intended unresolved threads remain.
Decision Rules
- Preserve intentional distinctions such as omitted versus explicit-clear values, client validation versus persistence behaviour, and optional draft fields versus submitted fields.
- Do not turn a reviewer request into a broad architectural rewrite unless the evidence requires it.
- Prefer a direct reply over a code change when the current implementation already expresses the intended contract.
- If a review summary requests testing but has no inline thread, leave a general PR comment acknowledging the completed test work when the user asks for every comment to be answered.
GitHub Operations
Use the GitHub API/CLI to retrieve both inline comments and review-thread state; a PR can be approved while still having unresolved threads.
For mutations:
- Reply to an inline comment using the comment's
in_reply_to identifier.
- Resolve review threads by their GraphQL thread identifiers, not their REST comment IDs.
- Re-query after mutations. Treat a successful request as insufficient until the visible thread state confirms it.
Handoff
State the pushed commit, implemented changes, pushbacks, verification commands/results, and remaining threads. Link changed files when useful.
1---2name: pr-comment-resolution3description: Address review feedback on an existing GitHub pull request. Use when Codex needs to inspect PR comments, decide which suggestions to implement or push back on, make and verify scoped fixes, reply in the relevant threads, and resolve addressed review threads.4---56# PR Comment Resolution78Work from the live PR and current branch. Treat each review thread as a decision record, not a checklist.910## Workflow11121. Fetch the PR metadata, review summaries, issue comments, inline comments, and review-thread resolution state. Use GitHub CLI/API tools when available.132. Classify each unresolved thread:14 - **Implement**: a concrete bug, missing test, or low-risk improvement that matches the PR scope.15 - **Push back**: a suggestion that is incorrect, redundant, expands scope, conflicts with a contract, or lacks enough value.16 - **Clarify**: a genuine product or design decision that needs user direction.173. Read the relevant local instructions and inspect the actual code path before deciding. Do not accept a comment purely because it sounds reasonable.184. Present a concise recommendation when user direction is needed. Otherwise, implement the approved changes tightly; do not refactor unrelated code to satisfy a small comment.195. Add the smallest behaviour-level regression where a comment exposes a gap. Prefer an existing test file and test the boundary that proves the contract, not just schema acceptance or a mocked layer.206. Follow repository formatting, build, type-check, lint, and focused-test requirements. Report existing warnings separately from new failures.217. Commit and push before marking an implementation comment done, unless the user explicitly asks not to publish changes.228. Reply in each relevant thread:23 - For completed work, use `Done.` if the user requests terse acknowledgement; otherwise say what changed and where.24 - For pushback, give a short evidence-based reason and state the retained behaviour.25 - Do not claim a fix is done until it is pushed and verified.269. Resolve only the threads the user authorizes. After resolving, re-query thread state and confirm that no intended unresolved threads remain.2728## Decision Rules2930- Preserve intentional distinctions such as omitted versus explicit-clear values, client validation versus persistence behaviour, and optional draft fields versus submitted fields.31- Do not turn a reviewer request into a broad architectural rewrite unless the evidence requires it.32- Prefer a direct reply over a code change when the current implementation already expresses the intended contract.33- If a review summary requests testing but has no inline thread, leave a general PR comment acknowledging the completed test work when the user asks for every comment to be answered.3435## GitHub Operations3637Use the GitHub API/CLI to retrieve both inline comments and review-thread state; a PR can be approved while still having unresolved threads.3839For mutations:4041- Reply to an inline comment using the comment's `in_reply_to` identifier.42- Resolve review threads by their GraphQL thread identifiers, not their REST comment IDs.43- Re-query after mutations. Treat a successful request as insufficient until the visible thread state confirms it.4445## Handoff4647State the pushed commit, implemented changes, pushbacks, verification commands/results, and remaining threads. Link changed files when useful.
dejanvasic85