Brutal Honesty Review

Brutal Honesty Review

<default_to_action> When brutal honesty is needed: 1. CHOOSE MODE: Linus (technical), Ramsay (standards), Bach (BS detection) 2. VERIFY CONTEXT: Senior engineer? Repeated mistake? Critical bug? Explicit request? 3. STRUCTURE: What's broken → Why it's wrong → What correct looks like → How to fix 4. ATTACK THE WORK, not the worker 5. 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 </default_to_action>

Quick Reference Card

When to Use

Three Modes

---

The Criticism Structure

## What's Broken
[Surgical description - specific, technical]

## Why It's Wrong
[Technical explanation, not opinion]

## What Correct Looks Like
[Clear model of excellence]

## How to Fix It
[Actionable steps, specific to context]

## Why This Matters
[Impact if not fixed]

---

Mode Examples

Linus Mode: Technical Precision

**Problem**: Holding database connection during HTTP call

"This is completely broken. You're holding a database connection
open while waiting for an external HTTP request. Under load, you'll
exhaust the connection pool in seconds.

Did you even test this with more than one concurrent user?

The correct approach is:
1. Fetch data from DB
2. Close connection
3. Make HTTP call
4. Open new connection if needed

This is Connection Management 101. Why wasn't this caught in review?"

Ramsay Mode: Standards-Driven Quality

**Problem**: Tests only verify happy path

"Look at this test suite. 15 tests, 14 happy path scenarios.
Where's the validation testing? Edge cases? Failure modes?

This is RAW. You're testing if code runs, not if it's correct.

Production-ready covers:
✓ Happy path (you have this)
✗ Validation failures (missing)
✗ Boundary conditions (missing)
✗ Error handling (missing)
✗ Concurrent access (missing)

You wouldn't ship code with 12% coverage. Don't merge tests
with 12% scenario coverage."

Bach Mode: BS Detection

**Problem**: ISTQB certification required for QE roles

"ISTQB tests if you memorized terminology, not if you can test software.

Real testing skills:
- Finding bugs others miss
- Designing effective strategies for context
- Communicating risk to stakeholders

ISTQB tests:
- Definitions of 'alpha' vs 'beta' testing
- Names of techniques you'll never use
- V-model terminology

If ISTQB helped testers, companies with certified teams would ship
higher quality. They don't."

---

Assessment Rubrics

Code Quality (Linus Mode)

Test Quality (Ramsay Mode)

BS Detection (Bach Mode)

---

Agent Integration

// Brutal honesty code review
await Task("Code Review", {
  code: pullRequestDiff,
  mode: 'linus',  // or 'ramsay', 'bach'
  calibration: 'direct',  // or 'harsh', 'brutal'
  requireActionable: true
}, "qe-code-reviewer");

// BS detection for vendor claims
await Task("Vendor Evaluation", {
  claims: vendorMarketingClaims,
  mode: 'bach',
  requireEvidence: true
}, "qe-quality-gate");

---

Agent Coordination Hints

Memory Namespace

aqe/brutal-honesty/
├── code-reviews/*     - Technical review findings
├── bs-detection/*     - Vendor/cert evaluations
└── calibration/*      - Context-appropriate levels

Fleet Coordination

const reviewFleet = await FleetManager.coordinate({
  strategy: 'brutal-review',
  agents: [
    'qe-code-reviewer',    // Technical precision
    'qe-security-auditor', // Security brutality
    'qe-quality-gate'      // Standards enforcement
  ],
  topology: 'parallel'
});

---

Related Skills

• code-review-quality - Diplomatic version
• context-driven-testing - Foundation for Bach mode
• sherlock-review - Evidence-based investigation

---

Remember

Brutal honesty eliminates ambiguity but has costs. Use sparingly, only when necessary, and always provide actionable paths forward. Attack the work, never the worker.

The Brutal Honesty Contract: Get explicit consent. "I'm going to give unfiltered technical feedback. This will be direct, possibly harsh. The goal is clarity, not cruelty."

Brutal Honesty Review Skill

Overview

A QE skill that delivers unvarnished technical criticism combining three legendary personas:

• Linus Torvalds: Surgical technical precision
• Gordon Ramsay: Standards-driven quality assessment
• James Bach: BS detection in testing practices

Purpose

Unlike diplomatic reviews, this skill eliminates ambiguity about technical standards. It dissects why something is wrong, explains the correct approach, and has zero patience for repeated mistakes or sloppy thinking.

When to Use

✅ Appropriate:

• Senior engineers wanting unfiltered feedback
• Repeated architectural mistakes
• Critical bugs requiring immediate attention
• Evaluating vendor claims/certifications
• Teams explicitly requesting no-BS feedback

❌ Inappropriate:

• Junior developers' first contributions
• Demoralized teams
• Public forums (avoid humiliation)
• When psychological safety is low

Three Modes

1. Linus Mode (Technical Precision)

Focus on code correctness, performance, concurrency, and architecture.

Example:

"This is completely broken. You're holding the lock during I/O, which means every thread serializes. Did you even test under load? The correct approach is..."

2. Ramsay Mode (Standards-Driven Quality)

Compare reality against clear excellence model using concrete metrics.

Example:

"Look at this! 12 tests and 10 are just checking if variables exist. Where's the business logic coverage? This is RAW. Don't merge it."

3. Bach Mode (BS Detection)

Question certifications, best practices, and vendor hype.

Example:

"This certification teaches scripts, not thinking. Does it help testers find bugs faster? No. It helps the cert body make money."

Quick Start

Using the Skill

Invoke the skill when you need brutal honesty:

Use brutal-honesty-review skill in Linus mode to review this code:
[paste code]

Using Assessment Scripts

# Assess code quality (Linus Mode)
./scripts/assess-code.sh src/myfile.js

# Assess test quality (Ramsay Mode)
./scripts/assess-tests.sh tests/

Files Included

brutal-honesty-review/
├── SKILL.md                          # Main skill instructions
├── README.md                         # This file
├── resources/
│   ├── review-template.md            # Template for structured reviews
│   └── assessment-rubrics.md         # Scoring rubrics for all modes
└── scripts/
    ├── assess-code.sh                # Automated code quality check
    └── assess-tests.sh               # Automated test quality check

Assessment Rubrics

Code Quality (Linus Mode)

Threshold: Minimum "Passing" on ALL to merge.

Test Quality (Ramsay Mode)

Threshold: Minimum "Acceptable" on ALL to merge.

BS Detection (Bach Mode)

Red flags:

• Cargo cult practices (no context)
• Certification theater (filters thinkers)
• Vendor lock-in (solves own problem)
• False automation (still needs humans)
• Checkbox quality (compliance, not outcomes)
• Hype cycle (10x claims without proof)

Green flag test: "Does this help testers/developers do better work in THIS context?"

Examples

Example 1: Linus Mode - Concurrency Bug

Problem: Holding DB connection during HTTP call

Brutal Honesty:

"This is completely broken. You're holding a database connection open while waiting for an HTTP request. Under load, you'll exhaust the connection pool in seconds. Did you test with >1 user? The correct approach: 1) Fetch data, 2) Close connection, 3) Make HTTP call."

Example 2: Ramsay Mode - Weak Tests

Problem: 15 tests, all happy path

Brutal Honesty:

"Look at this test suite. 15 tests, 14 are happy path. Where's validation? Where are edge cases? This is RAW. You're testing if code runs, not if it's correct. You have 35% coverage. Production needs 80%+. Don't merge this."

Example 3: Bach Mode - Certification Theater

Problem: Required ISTQB certification

Brutal Honesty:

"ISTQB tests if you memorized terminology, not if you can test software. Real skills: finding bugs, designing strategies, communicating risk. ISTQB tests: definitions, model names, checkbox thinking. If it helped, ISTQB-certified teams would ship higher quality. They don't."

Calibration Guide

Harshness Levels

Level 1 - Direct: For experienced engineers

"This approach is flawed because..."

Level 2 - Harsh: For repeated mistakes

"We've discussed this pattern three times. Why is it back?"

Level 3 - Brutal: For critical issues or willful ignorance

"This is negligent. You're exposing user data because..."

Context Matters

Before being brutal, verify: 1. Audience maturity: Can they handle directness? 2. Relationship capital: Have you earned harsh feedback rights? 3. Actionability: Can they actually fix this? 4. Intent: Helping or venting?

Philosophy

Why Brutal Honesty Works

1. Eliminates Ambiguity: No confusion about technical standards 2. Scales Teaching: Public technical breakdown teaches entire team 3. Cuts Through BS: Exposes cargo cult practices and vendor hype

The Costs

1. Relationship Damage: Harsh criticism without trust destroys collaboration 2. Chills Participation: Fear stops newcomers from contributing 3. Burnout: Constant harshness is exhausting

The Contract

Before using brutal honesty, establish explicit contract:

"I'm going to give unfiltered technical feedback. This will be direct, possibly harsh. Goal is clarity, not cruelty. I'll explain: 1) What's wrong, 2) Why, 3) What correct looks like, 4) How to fix. Want diplomatic instead?"

Get explicit consent first.

Integration with Agentic QE Fleet

This skill extends the QE skill set:

• Complements: code-review-quality, context-driven-testing
• Contrasts with: Diplomatic, constructive review approaches
• Use when: Technical precision and BS-cutting are priorities
• Avoid when: Building confidence or psychological safety

Related Skills

• code-review-quality - Diplomatic code review
• context-driven-testing - Foundation for BS detection
• tdd-london-chicago - Systematic quality approach
• exploratory-testing-advanced - Critical thinking in testing

License

MIT - Part of Agentic QE Fleet

Contributing

Found this too harsh? Good. Found this too soft? You're Linus Torvalds.

Submit issues if the skill produces ineffective criticism (not actionable, personal attacks, wrong context).

---

Remember: Brutal honesty is a tool, not a personality. Use it when it helps, not when it harms.

Assessment Rubrics for Brutal Honesty Reviews

Code Quality Rubric (Linus Mode)

Correctness

Performance

Error Handling

Concurrency Safety

Testability

Maintainability

Passing Threshold: Minimum 🟡 on ALL criteria Ship-Ready: Minimum 🟢 on Correctness, Performance, Error Handling

---

Test Quality Rubric (Ramsay Mode)

Coverage

Edge Case Testing

Test Clarity

Speed

Stability

Isolation

Merge Threshold: Minimum 🟡 on ALL criteria Production-Ready: Minimum 🟢 on Coverage, Stability, Isolation

---

BS Detection Rubric (Bach Mode)

Red Flags in Testing Practices

Green Flag Test

Ask these questions about any practice/tool/certification:

1. Does this help testers/developers do better work in THIS context?

• If yes → Worth considering
• If no → BS alert

2. Who benefits economically from this?

• Vendor/Consultant more than users → BS alert
• Users demonstrably benefit → Potentially useful

3. Can you measure the impact?

• Measurable outcomes → Worth evaluating
• Vague claims → BS alert

4. Does this promote thinking or compliance?

• Critical thinking → Good
• Checkbox compliance → BS alert

5. What happens if you don't adopt this?

• Concrete negative consequence → Worth considering
• FOMO, vendor says so → BS alert

---

Calibration Matrix

When to Be Brutal

When to Dial Back

---

Scoring Guide

Overall Code Review Score (Linus Mode)

Score = (Correctness × 3) + (Performance × 2) + (Error Handling × 3) +
        (Concurrency × 2) + (Testability × 1) + (Maintainability × 1)

Maximum: 60 points (all Excellent)
Passing: 36 points (all Passing)
Failing: <36 points

Harshness Level:
- 0-24 points: 🔴 Brutal ("This is fundamentally broken")
- 25-35 points: 🟡 Harsh ("Multiple issues need addressing")
- 36-48 points: 🟢 Direct ("Some improvements needed")
- 49-60 points: ⚪ Professional ("Minor suggestions")

Test Suite Score (Ramsay Mode)

Score = (Coverage × 3) + (Edge Cases × 3) + (Clarity × 1) +
        (Speed × 1) + (Stability × 3) + (Isolation × 1)

Maximum: 60 points (all Michelin Star)
Merge Threshold: 36 points (all Acceptable)
Failing: <36 points

Harshness Level:
- 0-24 points: 🔴 Brutal ("This is RAW. Don't serve it.")
- 25-35 points: 🟡 Harsh ("You know what good looks like.")
- 36-48 points: 🟢 Direct ("Close, but needs refinement.")
- 49-60 points: ⚪ Professional ("Well done, minor polish.")

BS Detection Score (Bach Mode)

Red Flags: Count from BS Detection Rubric
Green Flags: Passes all 5 Green Flag Tests

Score = (Green Flags × 20) - (Red Flags × 10)

Maximum: 100 (all green flags, no red flags)
Acceptable: 50+ (more green than red)
BS Alert: <50 (more red than green)

Harshness Level:
- Negative score: 🔴 Brutal ("This is harmful")
- 0-40: 🟡 Harsh ("This is questionable")
- 41-70: 🟢 Direct ("Some concerns")
- 71-100: ⚪ Professional ("Reasonable approach")

---

Example Assessments

Code Review Example (Linus Mode)

Code: Database query in HTTP handler without connection pooling

Assessment:

• Correctness: 🔴 Failing (connection leak)
• Performance: 🔴 Failing (O(n) connections)
• Error Handling: 🟡 Passing (has try/catch)
• Concurrency: 🔴 Failing (connection exhaustion)
• Testability: 🟡 Passing (can mock)
• Maintainability: 🟡 Passing (clear intent)

Score: (0×3) + (0×2) + (1×3) + (0×2) + (1×1) + (1×1) = 5/60

Harshness: 🔴 Brutal

Feedback:

"This is fundamentally broken. You're creating a new database connection

for every HTTP request without pooling. Under load, you'll exhaust

connections in seconds. Did you even test this with concurrent users?

>

Use a connection pool. This is Database 101."

---

Test Suite Example (Ramsay Mode)

Tests: 15 tests, all happy path, no edge cases

Assessment:

• Coverage: 🔴 Raw (35% branch)
• Edge Cases: 🔴 Raw (none tested)
• Clarity: 🟡 Acceptable (clear names)
• Speed: 🟢 Michelin (fast)
• Stability: 🟢 Michelin (no flakes)
• Isolation: 🟡 Acceptable (independent)

Score: (0×3) + (0×3) + (1×1) + (2×1) + (2×3) + (1×1) = 9/60

Harshness: 🔴 Brutal

Feedback:

"Look at this. You've got 15 tests and 14 of them are happy path.

Where's the validation testing? Where's the error handling?

>

This is RAW. You're testing if the code runs, not if it's correct.

Don't merge this."

---

BS Detection Example (Bach Mode)

Claim: "Our AI-powered test automation eliminates manual testing"

Assessment:

• Red Flags: Hype Cycle, Magic Tool Thinking, False Automation
• Green Flags: 0/5 (fails all tests)

Score: (0×20) - (3×10) = -30/100

Harshness: 🔴 Brutal

Feedback:

"This is vendor hype. 'AI-powered' doesn't eliminate the need for humans

to define test oracles, handle edge cases, or investigate failures.

>

The real question: Does this tool help YOUR testers on YOUR product

in YOUR context? If you can't answer specifically, you're buying hype."

Brutal Honesty Review Template

Review Type

• [ ] Linus Mode (Technical Precision)
• [ ] Ramsay Mode (Standards-Driven Quality)
• [ ] Bach Mode (BS Detection)

---

What's Broken

[Surgical description of the problem - be specific, not vague]

Evidence:

[Code snippet, claim, or practice being reviewed]

---

Why It's Wrong

[Technical/logical explanation - facts, not opinions]

Fundamental Issue:

• Root cause:
• Why this matters:
• When it breaks:

---

What Correct Looks Like

[Clear model of excellence - show, don't just tell]

Best Practice:

[Example of correct approach]

Why This Works:

• Reason 1:
• Reason 2:
• Reason 3:

---

How to Fix It

[Actionable steps - specific to context]

1. Immediate Fix:

   [Command or code change]

2. Verify Fix:

   [How to test the fix]

3. Prevent Recurrence:

• [ ] Add test coverage
• [ ] Update documentation
• [ ] Review similar code

---

Why This Matters

Impact if Not Fixed:

• [ ] Security vulnerability
• [ ] Performance degradation
• [ ] Data corruption
• [ ] User experience failure
• [ ] Technical debt
• [ ] Team velocity reduction

Priority: 🔴 Critical | 🟡 High | 🟢 Medium | ⚪ Low

---

Harshness Calibration

Audience: [Junior/Mid/Senior] Context: [First offense/Repeated mistake/Critical bug] Delivery: [Private/Team review/Public]

Tone Level:

• [ ] Level 1 - Direct (experienced engineers)
• [ ] Level 2 - Harsh (repeated mistakes)
• [ ] Level 3 - Brutal (critical issues/willful ignorance)

---

Follow-Up

• [ ] Reviewed by recipient
• [ ] Fix implemented
• [ ] Tests added
• [ ] Documentation updated
• [ ] Knowledge shared with team