| name | shipping-pr-reviews |
| description | Push the current changes to a pull request, then launch a dynamic workflow that reviews the PR diff, adversarially verifies each finding, and fixes the confirmed ones, pushing the fixes back to the PR. Use when the user wants to "push to a PR and review", "open a PR then review and fix findings", "ship and review", or run a multi-agent review-and-fix pass over a branch. Pairs with orchestrating-subagents (which implements the change first). |
| disable-model-invocation | true |
| license | MIT |
| metadata | {"author":"tylergibbs","version":"1.0.0"} |
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.
