session-reviewlisted

# Session Review — the adversarial closing loop Stress-test a session's work **before it sets**, using reviewers who don't share your blind spots. You wrote the work, so you are the worst person to spot what you assumed. The loop ends in *action*: cheap-safe fixes applied immediately, the rest recorded as a measurable plan, and anything you disagree with explicitly challenged — not silently accepted, not silently dropped. Invocation is usually EXPLICIT (`/session-review`) — "review" is something the agent does natively, so don't expect auto-triggering; invoke it by name at session close. ## The loop ### 1. Assemble the brief (the load-bearing step) Write ONE self-contained markdown brief (e.g. to `/tmp/<repo>-session-review.md`). It is the only context the reviewers get. It must contain: - **An assigned role** that fits the work ("Principal Engineer" for a feature slice, "Security reviewer" for auth work) — the role is the lens. - **Project context** a stranger can follow, **the session goal**, and **what was built**, with concrete file:line references. - **The specific decision points you most want challenged** — and for anything that turns on CURRENT best practice, an explicit ask to web-check with sources. - **What to return** — a structured verdict with severity, file refs, a short MEASURABLE plan. Never let the brief be the reviewer's only window: tell the code-reader explicitly **"do not trust this summary — read the actual files."** Your summary is where you