request-review

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:

1. The goal in one line (what was asked).
2. The deliverable — the actual changed files / output, not a prose summary of them.
3. Acceptance criteria — how to know it's correct (the tests, the expected behavior).
4. Decisions made + rejected approaches — so the reviewer doesn't re-litigate settled choices or suggest a dead end you already ruled out.
5. 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>