---

name: adversarial-coach description: Adversarial implementation review based on Block's g3 dialectical autocoding research. Use when validating implementation completeness against requirements with fresh objectivity.

/coach - Adversarial Implementation Review

Usage

/coach [requirements-file]

• /coach - Infer requirements from context
• /coach requirements.md - Validate against specific file

Coach-Player Loop

You orchestrate this dialectical loop between implementing agent (player) and reviewer (coach):

1. You (player) implement features
2. /coach invokes adversarial review with independent evaluation of compliance to requirements
3. Coach returns: IMPLEMENTATION_APPROVED or specific fixes
4. Address feedback, loop until approved

Review Process

Step 1: Identify Requirements

Check (in order):

• Specified requirements file or issue/ticket mentioned
• requirements.md, REQUIREMENTS.md, SPEC.md, TODO.md
• Conversation context; ask user if nothing found

Step 2: Adversarial Review

Review with fresh objectivity - discard prior knowledge, don't rationalize shortcuts.

Check Category	Items
Requirements	Each item: implemented or missing with specific gap
Compilation	Compiles? Tests pass? Runs?
Common Gaps	Auth on endpoints, token refresh endpoint, HTTPS, bcrypt for passwords, error handling, input validation
Functional	Test actual flows (not just compilation), verify edge cases work
Test Coverage	Auth error cases (401/403), token expiry, invalid inputs, rate limits

Step 3: Return Verdict

If approved (>95% complete):

IMPLEMENTATION_APPROVED

- [Requirement 1]: Verified
- [Requirement 2]: Verified
- Compilation: Success
- Tests: All passing

If fixes needed:

REQUIREMENTS COMPLIANCE:
- [Requirement]: Implemented
- [Requirement]: Missing - [specific gap]

IMMEDIATE ACTIONS NEEDED:
1. [Specific fix with file/line if known]
2. [Specific fix]

Key Principles

Rigorous but fair:

• Catch real gaps (security, logic, data flow), not style preferences
• Functionality over aesthetics; always flag security issues (auth, crypto, validation)

Concise:

• Bullets, not essays; specific issues, not vague concerns
• No file contents or verbose analysis in output

Fresh context is your superpower:

• Review as if you've never seen this code; validate against requirements, not intentions

Magic Signal

IMPLEMENTATION_APPROVED = termination signal

Only use when: all requirements met, code compiles/runs, tests pass, no significant gaps.

If in doubt, don't approve.

Minimal Example

User: /coach SPEC.md

Claude:
REQUIREMENTS COMPLIANCE:
- User registration endpoint (bcrypt hashing)
- Login with JWT tokens
- Logout endpoint - not implemented
- Token refresh - missing /auth/refresh endpoint

IMMEDIATE ACTIONS NEEDED:
1. Add POST /auth/logout endpoint
2. Add POST /auth/refresh for token renewal
3. Add tests for 401 on expired tokens

---

User: [fixes] /coach SPEC.md

Claude:
IMPLEMENTATION_APPROVED
- All auth endpoints verified (register, login, logout, refresh)
- 18 tests passing including auth error cases

Research

• Paper: Adversarial Cooperation in Code Synthesis
• Implementation: g3
• Key insight: Discard implementing agent's self-report; perform independent evaluation against requirements.