session-critique

name	session-critique
description	Use when a session's implementation work is complete and needs adversarial critique and code quality review before committing. Triggers — after multi-file changes, after feature implementation, before final commit on significant work, when independent review of own work is needed. NOT for single-file trivial edits (use /validate directly) or standard code review without fixes (use /multi-review).
auto-activate	false

ultrathink

Session Critique: Adversarial Review via Agent Team

Spawns an advisor-pattern agent team that adversarially reviews all work done in the current session, surfaces every finding for user approval, and applies only the fixes the user authorizes.

When to use

• Session produced multi-file changes that should be stress-tested
• You want adversarial self-critique + code quality review before committing
• Changes span documentation, skills, specs, or cross-cutting concerns
• You need independent verification that nothing was missed or mis-stated

When NOT to use

• Single-file trivial edit — run /validate directly
• Standard code review without fix authority — use /multi-review
• Only need diff/security/schema checks — use /validate quick
• Work is not yet complete — finish implementation first

Decision Authority

The user approves ALL non-trivial decisions. No teammate decides autonomously.

Teammates CAN without asking: read files, run verification commands, spawn subagents, report findings.

Teammates MUST escalate (via lead → user): applying any fix, dismissing any finding, resolving disagreements, any file content change.

Procedure

Phase 0: Scope Detection

# Find this session's commits
git log --oneline -10

# Get all changed files
git diff <first-session-commit>~1..HEAD --name-only

Split files into two ownership buckets (no overlap):

• Bucket A (self-critic): modifications of existing files
• Bucket B (code-reviewer): newly created files + CLAUDE.md/index files
• If split is unclear: ask the user

Phase 1: Team Design + User Approval

Present team design table to user. WAIT for approval before launching.

| Teammate      | Model  | Role                           | Owns        |
|---------------|--------|--------------------------------|-------------|
| advisor       | opus   | Strategic direction, read-only | All (read)  |
| self-critic   | opus | Adversarial self-review        | Bucket A    |
| code-reviewer | sonnet | Code quality + structural      | Bucket B    |

Cost: ~45-55% of all-Opus equivalent

Phase 2: Launch (advisor pattern)

1. TeamCreate(team_name="session-critique")
2. Create tasks with TaskCreate for each work unit
3. Spawn advisor (Opus) FIRST — use advisor-prompt.md from /agent-team skill
4. Wait for "ADVISOR READY"
5. Spawn workers with filled prompts from teammates.md
6. Every Agent call MUST include team_name

Phase A: Analysis (parallel, no edits)

Both workers analyze simultaneously. Advisor reviews as findings arrive. No files are modified. Output: two findings reports.

Workers consult advisor (Section 7 of teammate-prompt.md):

• Before starting: brief approach, wait for advisor approval
• At decision points: present options to advisor
• After 2 failed attempts: escalate to advisor
• After completing analysis: send findings to lead + advisor

Phase B: Decision Batch (user approves)

Lead collects all findings from both workers + advisor recommendations. Presents to user as a single numbered decision list:

=== SESSION REVIEW: DECISIONS NEEDED ===

Self-critic found N issues. Code-reviewer found M issues.

#1. [file:line] Issue description
    Recommendation: [A/B/C] because [reason]
    -> Approve fix? (A/B/C/skip)

#2. ...

Type approvals (e.g., "1A, 2B, 3-skip") or "approve all"

Phase C: Fix Execution (after approval only)

Workers apply ONLY approved fixes. Each fix verified before/after. Advisor reviews all applied changes (Phase 4 quality gate).

Phase D: Handback

Lead reverts any out-of-scope changes:

git diff --stat HEAD
git checkout HEAD -- <any-out-of-scope-file>

Presents final summary of all applied fixes to user. User runs /validate and commits at their own discretion.

Report Format (each worker sends to lead after Phase A)

## [Role] Findings (AWAITING APPROVAL)

### Issues Found: N
| # | File | Issue | Severity | Proposed Fix | Alternatives |
|---|------|-------|----------|-------------|-------------|
| 1 | ...  | ...   | low/med/high | [fix A] | [fix B], [skip] |

### Advisor consultations: N
### Subagent results: [agent: PASS/FAIL (N issues)]
### Cross-team issues flagged: [list if any]

Common Mistakes

Mistake	Prevention
Teammates fix files without user approval	Two-phase workflow: ANALYZE then FIX after approval
Teammates edit out-of-scope files	Explicit bucket ownership + lead reverts in Phase D
Advisor makes final calls instead of user	Decision authority rule: advisor recommends, user decides
Workers skip advisor consultation	Section 7 protocol: brief before starting, consult at decision points
Lead commits without user running /validate	Phase D hands back — user owns validation and commit

Red Flags — STOP and Escalate to User

• Worker editing a file before Phase B approval
• Worker dismissing a finding as "not worth fixing" without escalating
• Advisor approving fixes on user's behalf
• Any teammate contacting the user directly (all goes through lead)
• Out-of-scope files appearing in git diff --stat HEAD

See teammates.md for detailed worker specifications, skills, subagents, and audit checklists.