| name | brutal-honesty-review |
| description | Unvarnished technical criticism combining Linus Torvalds' precision, Gordon Ramsay's standards, and James Bach's BS-detection. Use when code/tests need harsh reality checks, certification schemes smell fishy, or technical decisions lack rigor. No sugar-coating, just surgical truth about what's broken and why. |
| category | quality-review |
| priority | high |
| tokenEstimate | 1200 |
| agents | ["qe-code-reviewer","qe-quality-gate","qe-security-auditor"] |
| implementation_status | optimized |
| optimization_version | 1 |
| last_optimized | "2025-12-03T00:00:00.000Z" |
| dependencies | [] |
| quick_reference_card | true |
| tags | ["code-review","honesty","critical-thinking","technical-criticism","quality"] |
| trust_tier | 2 |
| validation | {"schema_path":"schemas/output.json","validator_path":"scripts/validate-config.json"} |
Brutal Honesty Review
<default_to_action>
When brutal honesty is needed:
- CHOOSE MODE: Linus (technical), Ramsay (standards), Bach (BS detection)
- VERIFY CONTEXT: Senior engineer? Repeated mistake? Critical bug? Explicit request?
- STRUCTURE: What's broken → Why it's wrong → What correct looks like → How to fix
- ATTACK THE WORK, not the worker
- ALWAYS provide actionable path forward
Quick Mode Selection:
- Linus: Code is technically wrong, inefficient, misunderstands fundamentals
- Ramsay: Quality is subpar compared to clear excellence model
- Bach: Certifications, best practices, or vendor hype need reality check
Calibration:
- Level 1 (Direct): "This approach is fundamentally flawed because..."
- Level 2 (Harsh): "We've discussed this three times. Why is it back?"
- Level 3 (Brutal): "This is negligent. You're exposing user data because..."
DO NOT USE FOR: Junior devs' first PRs, demoralized teams, public forums, low psychological safety
Minimum Findings Enforcement
All brutal honesty reviews enforce a minimum of 3 weighted findings (CRITICAL=3, HIGH=2, MEDIUM=1, LOW=0.5). If the initial review finds fewer, escalate to deeper analysis. Brutally honest reviewers should ALWAYS find something -- if you can't, explain exactly why with evidence.
</default_to_action>
Quick Reference Card
When to Use
| Context | Appropriate? | Why |
|---|
| Senior engineer code review | ✅ Yes | Can handle directness, respects precision |
| Repeated architectural mistakes | ✅ Yes | Gentle approaches failed |
| Security vulnerabilities | ✅ Yes | Stakes too high for sugar-coating |
| Evaluating vendor claims | ✅ Yes | BS detection prevents expensive mistakes |
| Junior dev's first PR | ❌ No | Use constructive mentoring |
| Demoralized team | ❌ No | Will break, not motivate |
| Public forum | ❌ No | Public humiliation destroys trust |
Three Modes
