19-address-pr-review

name: 19-address-pr-review description: > Works through pull request review findings one-by-one or in batches: triages GitHub review comments (including 18-pr-review output), confirms fix approach with the user, applies TDD for blockers, commits atomically, replies and resolves threads, pushes, watches CI, and offers 18-pr-review re-run. Never merges. Use when the user asks to address PR review feedback, fix review comments, or remediate findings after 18-pr-review. disable-model-invocation: true

19 — Address PR Review

On-demand Phase G follow-up to 18-pr-review: turn posted review findings into scoped fixes on the PR branch.

GitHub commands: reference.md
Preamble: pipeline-preamble.md
Cross-cutting: considerations.md, ci-after-push, bug-investigation (🔴 TDD)
State agent: workflow-state-manager — mandatory read/update

Never merge. User merges manually after re-review passes.

When to use

Prerequisites

1. gh CLI authenticated (gh auth status).
2. PR exists with review comments or a prior 18-pr-review cycle.
3. Checkout access — agent can gh pr checkout and commit on the PR head branch.
4. workflow-state.yaml exists — warn and proceed without state writes if missing (user may waive).

Interactive questions (required)

Every user-facing gate must use AskQuestion. Do not expect inline chat replies for gates.

First option = recommendation; last = Let me explain / provide more context.

State management

1. Invoke workflow-state-manager read_context + skill_id: 19-address-pr-review.
2. After Phase 0, agent update → new pr_remediation_cycles[] entry status: in_progress.
3. Link linked_review_cycle_id when a matching pr_review_cycles[] entry exists (same PR number).
4. After each finding: append to cycle findings[] with status (fixed | deferred | wont_fix).
5. On completion, agent update → status: completed, counts, head SHA after push.

Schema: reference.md §workflow-state.yaml schema.

Workflow

Phase 0 — Intake

1. AskQuestion: How to identify the PR?
2. Resolve metadata: gh pr view — number, URL, head, base, checks.
3. gh pr checkout <number> (unless already on PR head).
4. Fetch findings — all unresolved review input (reference.md §Fetch findings):
   • Inline review comments on open threads
   • Review bodies with 🔴 / 🟡 markers (including 18-pr-review posts)
   • Classify each item: blocker (🔴, REQUEST_CHANGES, or labeled blocking) vs advisory (🟡)
5. AskQuestion: Resume prior cycle or start new?
6. Present numbered backlog; note already-resolved threads (skip).

Phase 1 — Session scope

1. AskQuestion: Blockers only · blockers then advisories · pick specific IDs.
2. Default order: all blockers first, then batch advisories by file or theme (max ~5 per batch).

Phase 2 — Remediate (per item or batch)

Blockers (one at a time):

1. Show finding: path, line, comment body, reviewer.
2. AskQuestion: Proposed fix approach · won't fix · defer.
3. If won't fix or defer → draft GitHub reply; resolve thread only when user confirms on close-out for won't-fix with rationale.
4. If fix:
   • TDD when finding is a defect (logic bug, regression, security issue): follow bug-investigation — repro test in tests/bugs/, red → green, one bug per test module.
   • Non-defect blockers (spec/checklist/hygiene): fix in place; add/adjust tests only when behavior changed.
5. Local checks on touched paths (reference.md §Local verification).
6. Atomic commit — one finding per commit unless user approved a batch in Phase 1.
7. AskQuestion: Confirm resolution matches intent?
8. GitHub: reply on thread citing commit SHA; resolve thread when fix is complete (reference.md §Resolve threads).

Advisories (batched):

1. Present batch (same file or theme).
2. AskQuestion: Fix batch · skip batch · pick subset.
3. Fix without mandatory repro tests unless behavior change warrants tests.
4. One commit per approved batch; reply per thread or one summary reply if threads are linked.

Do not push until Phase 3 unless user explicitly requests push after a single finding.

Phase 3 — Push and CI

1. AskQuestion: Push now?
2. git push to PR head remote.
3. Watch CI: bash scripts/ci/watch_github_ci.sh <head-ref> (ci-after-push).
4. If CI fails on changes in scope → fix in loop (AskQuestion before out-of-scope CI/workflow edits).
5. Record ci_status on cycle.

Phase 4 — Close out

1. workflow-state-manager update — complete pr_remediation_cycles[].
2. Chat summary: PR URL, fixed / deferred / won't-fix counts, commit SHAs, CI status.
3. AskQuestion: Run 18-pr-review now?
4. Do not merge.

Severity and scope rules

When disagreeing with a comment: won't fix path — AskQuestion, then reply with evidence; do not resolve thread unless user treats comment as satisfied.

Output rules

Anti-patterns

• Merging the PR
• Fixing without Phase 2 AskQuestion on approach
• One giant commit for unrelated findings
• Skipping CI watch after push
• Changing CI workflows to greenwash unrelated failures
• Auto-starting after 18-pr-review without user invoking 19-address-pr-review
• Resolving GitHub threads before user confirms resolution