Session critique
Skill SamyakJhaveri/loam/cultivation/marketplace/team-deliberation/skills/session-critique
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).From its SKILL.md
npx -y skills add SamyakJhaveri/loam --skill session-critiqueAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
5.6 KB, ~1.2k tokens by cl100k_base, as published. Nobody here has run it
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
/validatedirectly - 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)
TeamCreate(team_name="session-critique")- Create tasks with
TaskCreatefor each work unit - Spawn advisor (Opus) FIRST — use
advisor-prompt.mdfrom/agent-teamskill - Wait for "ADVISOR READY"
- Spawn workers with filled prompts from teammates.md
- Every
Agentcall MUST includeteam_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.
What ships with it: 1 file
4.6 KB alongside SKILL.md
- teammates.md4.6 KB