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 (run the project's validation gate directly) or a standard code review without fix authority.
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, configs, or cross-cutting concerns
• You need independent verification that nothing was missed or mis-stated

When NOT to use

• Single-file trivial edit - run the project's validation gate directly
• Standard code review without fix authority - use a plain code-review pass
• Only need quick diff/security/schema checks - run the fast validation gate
• 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 the 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>

Revert only files this session's workers touched. A file that was already dirty before the critique started belongs to the user - surface it, never checkout over it. To make that checkable, record git status --porcelain output when the critique starts (Phase A); that snapshot defines "already dirty". Presents final summary of all applied fixes to user. User runs the project's validation gate 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 the validation gate	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.