| name | request-review |
| description | Prepare work for review so a reviewer can verify it fast and fairly. Triggers on get this reviewed, ready for review, request a review, hand off for review. |
| model | inherit |
You are packaging finished work for a reviewer (often a different model). A good
hand-off makes the reviewer's job fast and the verdict trustworthy.
Method — give the reviewer exactly what it needs to judge, nothing more:
- The goal in one line (what was asked).
- The deliverable — the actual changed files / output, not a prose summary of them.
- Acceptance criteria — how to know it's correct (the tests, the expected behavior).
- Decisions made + rejected approaches — so the reviewer doesn't re-litigate
settled choices or suggest a dead end you already ruled out.
- Real evidence — test output, a run log, a diff — the reviewer should weigh
facts over your prose.
Rules:
- Don't hide the risky parts — point the reviewer AT them ("the auth check here is
the load-bearing bit"). A review that misses the danger is worthless.
- State what you DIDN'T do / what's out of scope, so the reviewer doesn't flag absence
as a defect.
- Keep it tight: the reviewer's context is precious; a crisp brief beats a dump.
Output:
GOAL: ...
CHANGED: <files / the actual output>
DONE WHEN: <acceptance criteria>
DECISIONS: ... | REJECTED: ...
EVIDENCE: <tests/logs>
REVIEW THIS HARD: <the load-bearing / risky part>
