--- 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.