shipping-pr-reviews

Shipping PR Reviews

Two phases: ship the working changes to a PR, then run a dynamic workflow that reviews the diff, verifies findings, and fixes the real ones. The user invoking this skill is the opt-in to launch a workflow; the approval card still shows before it runs.

When to use this

Use after a change is implemented and the build/tests pass, when the user wants it on a PR with a multi-agent review-and-fix pass. For a quick local review without a PR or custom script, the built-in /code-review (add --fix to apply findings, ultra for a deeper cloud review) is lighter — mention it if that's all they need.

Workflow

Ship + Review Progress:
- [ ] 1. Pre-flight: clean state, build/tests green
- [ ] 2. Push to a PR (branch, commit, push, open PR)
- [ ] 3. Launch the review-and-fix dynamic workflow over the PR diff
- [ ] 4. Apply confirmed fixes; push them to the PR
- [ ] 5. Report what was confirmed, fixed, and skipped

1. Pre-flight

• Confirm you're in a git repo and the build/tests/linters pass. Don't ship broken code for review.
• Check git status and the current branch. Note the base branch (usually the default branch) — the review compares the PR diff against it.

2. Push to a PR

Pushing and opening a PR are outward-facing — confirm before the first push unless the user already told you to ship. Steps and exact commands are in references/pr-push.md:

• If on the default branch, create a feature branch first.
• Stage and commit with a descriptive message (include the required co-author trailer).
• Push the branch and open the PR with gh pr create. Surface the PR URL.

3. Launch the review-and-fix workflow

Write and run a dynamic workflow over the PR diff. Adapt the ready-made script in references/review-fix-workflow.md. It:

• Reviews the diff across independent dimensions (correctness, security, error handling, tests, performance) — one agent per dimension, in parallel.
• Verifies each finding adversarially — independent skeptics try to refute it; findings that don't survive are dropped, so you fix real bugs, not noise.
• Fixes each confirmed finding in its own agent. Fix agents that touch an external library MUST pull current docs via Context7 (mcp__context7__resolve-library-id → mcp__context7__query-docs) before writing code, and cite the confirmed version in a comment.

Scale the review to the request: a few dimensions and single-vote verify for "review this", a larger finder pool and 3-vote adversarial verify for "thoroughly review".

4. Apply fixes and push

Workflow agents run with their own context, so collect the confirmed findings + the fixes the workflow produced, make sure the working tree has them, re-run build/tests, then commit and push to the same PR branch.

5. Report

Post a summary (and/or PR comment) listing: findings confirmed, fixes applied, findings skipped as false positives, and any finding that couldn't be verified (e.g. an agent hit an error) — call those out as unverified rather than fixed.

Key rules

• Never ship red. Build/tests must pass before the PR and again after fixes.
• One PR, one branch. Push fixes to the same branch, not a new PR.
• Verify before fixing. Only fix findings that survive adversarial verification; report the rest instead of acting on them.
• Fresh docs for fixes. Every library-touching fix agent carries the Context7 mandate, same as in orchestrating-subagents.
• Confirm outward actions. Get a go-ahead before the first push/PR unless the user already said to ship.