| name | review |
| description | Use when reviewing code, reviewing UI, requesting review, handling review feedback, running QA, or triaging issues and PRs. |
Review
Evaluate work and handle feedback without mixing review with implementation or
branch completion.
Boundary
Review owns evaluation, QA, triage, and feedback handling. Use finish after
work is verified and the branch needs PR, merge, cleanup, or handoff.
Process
- Identify what kind of review is being requested.
- Pick the smallest fitting reference:
two-axis-review for reviewing changes since a fixed point against standards and spec.
requesting-code-review when completed work needs an independent review.
receiving-code-review when evaluating review feedback before applying it.
qa for conversational QA that files issues.
triage for categorizing and preparing issues or external PRs.
- Lead with findings, ordered by severity, with file and line references when
reviewing code.
- Separate confirmed issues from questions, assumptions, and residual risks.
- Do not implement fixes unless the user explicitly asks for the review
feedback to be applied.
Specialist Branches
web-design-guidelines for UI, UX, accessibility, or web interface review.
hallmark for visual design quality review or anti-generic UI checks.
landing-page-conversion for landing-page conversion review.
web-animation-design for motion quality review.
vercel-react-best-practices for React or Next.js performance review.
vercel-composition-patterns for React component API review.
prompt-architect for prompt review.
Completion
Done when findings, open questions, and residual risks are clearly separated,
or when review feedback has been technically evaluated and the next phase is
build or finish.