# Session Review > End-of-session adversarial review loop. Assemble the session's work into a role-assigned, self-contained brief, then run independent reviewers in parallel — an isolated code-reader (the idea-validator agent) that reads the ACTUAL files and web-checks technology currency, plus an external-family model if you have one — synthesize where they agree vs diverge, apply the cheap-safe fixes immediately, record a measurable plan for the rest, and CHALLENGE reviewer claims you disagree with (never blind-accept). Use at the close of a substantive coding or design session, when the user says "session review", "review my session", "stress-test this session", or types /session-review. Skip for trivial one-off edits. - Skill: `awrshift/session-review` (Agent Skill) - Install (CLI): `npx skillmds@latest add awrshift/session-review` - Raw SKILL.md: https://api.skillmd.com/api/skills/awrshift/session-review/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: AI & ML - Author: awrshift (https://skillmd.com/u/awrshift) - Updated: 2026-09-10 - Page: https://skillmd.com/skills/awrshift/session-review --- # 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/-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 your blind spots live. ### 2. Run the reviewers IN PARALLEL (same message) - **Reviewer A — the isolated code-reader.** Spawn `idea-validator` pointed at the brief AND the actual files, with the currency instruction: "web-check whether every library / runtime / pattern I chose is still the right choice this year, cite sources." Without that line it only verifies claims you explicitly made — dated tech slips through. - **Reviewer B — an external-family model** (if available), reviewing from the brief only. Different training distribution, different blind spots; lean on it for concept and tech-currency, not file-level facts. - One reviewer alone (A) is still a valid light review — note the absence and proceed. ### 3. Synthesize — agree vs diverge Where reviewers independently land on the same finding — high-confidence signal, promote it. Where they diverge — the highest-value rows: adjudicate on merits. On facts about the code the code-reader wins; **never count votes**. The full adjudication procedure — acceptance layers, the claim→check table, how a disputed finding is allowed to close — is `reference/orchestrator-fact-check.md`. ### 4. Act (the loop must end in action) - **Accept now:** cheap, safe, low-blast-radius fixes — apply this session, verify by artifact (typecheck / lint / tests), don't round toward success. - **Plan, measured:** larger items become backlog entries, each with a metric for the win. A plan item with no measurable outcome is a task for task's sake — drop it. - **Challenge:** for anything you disagree with, write back WHY. Holding your ground with a reason is the partnership — blind acceptance defeats the loop. ### 5. Measure the outcome Close with what the loop produced: findings found / applied / planned / challenged, what you had missed, what tech-currency facts updated. That's how you know it earned its tokens. ### 6. Retrospective on the machine (so quality compounds) Steps 1-5 review the WORK; this reviews the SYSTEM that produced it. Three questions, backed by what actually happened this session: - What foundation element (a rule, a MEMORY line, a handoff, a pattern) EARNED its keep — name the concrete moment. Keep those. - Where did the foundation give friction or a gap — stale, duplicated, missing? Fix/merge/prune. - How did the orchestration go — right agents, good-enough briefs, honest adjudication? (`reference/parallel-development.md` for the fan-out defaults and stop-conditions.) A CONFIRMED finding is worth a row in the findings-class registry, and a class recurring three times earns promotion into the cheapest layer that prevents it — `reference/review-loop.md`. Output: at most 1-3 minimal, evidence-backed adjustments, biased to **subtract before add**. "Keep doing" is a valid output — most sessions should change the foundation little. ## Guardrails - Never blind-accept. Rejecting a finding with a reason is a success, not a failure. - Separate "now" from "plan" by RISK, not importance — big-blast-radius changes at the end of a long session belong in the plan, done fresh. - Scale to the work: small session → light brief, single reviewer; architecture change → the full role-assigned, fact-checked, multi-reviewer pass.