/coach - Adversarial Implementation Review
Usage
CODEBLOCK0
- -
/coach - Infer requirements from context - INLINECODE1 - Validate against specific file
Coach-Player Loop
You orchestrate this dialectical loop between implementing agent (player) and reviewer (coach):
- 1. You (player) implement features
- INLINECODE2 invokes adversarial review with independent evaluation of compliance to requirements
- Coach returns:
IMPLEMENTATION_APPROVED or specific fixes - Address feedback, loop until approved
Review Process
Step 1: Identify Requirements
Check (in order):
- - Specified requirements file or issue/ticket mentioned
- INLINECODE4 ,
REQUIREMENTS.md, SPEC.md, INLINECODE7 - 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):
CODEBLOCK1
If fixes needed:
CODEBLOCK2
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
INLINECODE8 = termination signal
Only use when: all requirements met, code compiles/runs, tests pass, no significant gaps.
If in doubt, don't approve.
Minimal Example
CODEBLOCK3
Research
技能名称: adversarial-coach
详细描述:
/coach - 对抗性实现审查
用法
/coach [需求文件]
- - /coach - 从上下文中推断需求
- /coach requirements.md - 针对特定文件进行验证
教练-玩家循环
你编排实现代理(玩家)与审查者(教练)之间的辩证循环:
- 1. 你(玩家)实现功能
- /coach 调用对抗性审查,独立评估对需求的符合性
- 教练返回:IMPLEMENTATION_APPROVED 或具体修复建议
- 处理反馈,循环直至通过
审查流程
步骤 1:识别需求
检查(按顺序):
- - 指定的需求文件或提及的问题/工单
- requirements.md、REQUIREMENTS.md、SPEC.md、TODO.md
- 对话上下文;若未找到则询问用户
步骤 2:对抗性审查
以全新客观性进行审查——摒弃先验知识,不合理化捷径。
| 检查类别 | 项目 |
|---|
| 需求 | 每项:已实现或缺失,并指出具体差距 |
| 编译 |
能否编译?测试通过?运行正常? |
| 常见漏洞 | 端点认证、令牌刷新端点、HTTPS、bcrypt密码加密、错误处理、输入验证 |
| 功能 | 测试实际流程(不仅限于编译),验证边界情况是否正常 |
| 测试覆盖率 | 认证错误情况(401/403)、令牌过期、无效输入、速率限制 |
步骤 3:返回裁决
如果通过(完成度 > 95%):
IMPLEMENTATION_APPROVED
- - [需求1]: 已验证
- [需求2]: 已验证
- 编译:成功
- 测试:全部通过
如果需要修复:
需求符合性:
- - [需求]:已实现
- [需求]:缺失 - [具体差距]
需要立即执行的操作:
- 1. [具体修复,若已知则包含文件/行号]
- [具体修复]
关键原则
严格但公平:
- - 捕捉真实漏洞(安全性、逻辑、数据流),而非风格偏好
- 功能优先于美观;始终标记安全问题(认证、加密、验证)
简洁:
- - 使用要点而非长篇大论;指出具体问题而非模糊担忧
- 输出中不包含文件内容或冗长分析
全新上下文是你的超能力:
- - 如同从未见过此代码般进行审查;对照需求而非意图进行验证
魔法信号
IMPLEMENTATION_APPROVED = 终止信号
仅在以下情况使用:所有需求已满足、代码编译/运行正常、测试通过、无重大漏洞。
如有疑问,不予通过。
最小示例
用户:/coach SPEC.md
Claude:
需求符合性:
- - 用户注册端点(bcrypt哈希加密)
- 使用JWT令牌登录
- 登出端点 - 未实现
- 令牌刷新 - 缺少 /auth/refresh 端点
需要立即执行的操作:
- 1. 添加 POST /auth/logout 端点
- 添加 POST /auth/refresh 用于令牌续期
- 添加过期令牌返回401的测试
用户:[修复] /coach SPEC.md
Claude:
IMPLEMENTATION_APPROVED
- - 所有认证端点已验证(注册、登录、登出、刷新)
- 18个测试通过,包括认证错误情况
研究