@agentic-qe/v3 3.0.0-alpha.10

package/assets/skills/brutal-honesty-review/SKILL.md

@@ -0,0 +1,235 @@
+---
+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.0
+last_optimized: 2025-12-03
+dependencies: []
+quick_reference_card: true
+tags: [code-review, honesty, critical-thinking, technical-criticism, quality]
+---
+
+# 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
+| 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
+
+| Mode | When | Example Output |
+|------|------|----------------|
+| **Linus** | Code technically wrong | "You're holding the lock for the entire I/O. Did you test under load?" |
+| **Ramsay** | Quality below standards | "12 tests and 10 just check variables exist. Where's the business logic?" |
+| **Bach** | BS detection needed | "This cert tests memorization, not bug-finding. Who actually benefits?" |
+
+---
+
+## The Criticism Structure
+
+```markdown
+## 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
+
+```markdown
+**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
+
+```markdown
+**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
+
+```markdown
+**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)
+
+| Criteria | Failing | Passing | Excellent |
+|----------|---------|---------|-----------|
+| Correctness | Wrong algorithm | Works in tested cases | Proven across edge cases |
+| Performance | Naive O(n²) | Acceptable complexity | Optimal + profiled |
+| Error Handling | Crashes on invalid | Returns error codes | Graceful degradation |
+| Testability | Impossible to test | Can mock | Self-testing design |
+
+### Test Quality (Ramsay Mode)
+
+| Criteria | Raw | Acceptable | Michelin Star |
+|----------|-----|------------|---------------|
+| Coverage | <50% branch | 80%+ branch | 95%+ mutation tested |
+| Edge Cases | Only happy path | Common failures | Boundary analysis complete |
+| Stability | Flaky (>1% failure) | Stable but slow | Deterministic + fast |
+
+### BS Detection (Bach Mode)
+
+| Red Flag | Evidence | Impact |
+|----------|----------|--------|
+| Cargo Cult Practice | "Best practice" with no context | Wasted effort |
+| Certification Theater | Required cert unrelated to skills | Filters out thinkers |
+| Vendor Lock-In | Tool solves problem it created | Expensive dependency |
+
+---
+
+## Agent Integration
+
+```typescript
+// 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
+```typescript
+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](../code-review-quality/) - Diplomatic version
+- [context-driven-testing](../context-driven-testing/) - Foundation for Bach mode
+- [sherlock-review](../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."

package/assets/skills/brutal-honesty-review/resources/assessment-rubrics.md

@@ -0,0 +1,295 @@
+# Assessment Rubrics for Brutal Honesty Reviews
+
+## Code Quality Rubric (Linus Mode)
+
+### Correctness
+| Level | Criteria | Example |
+|-------|----------|---------|
+| 🔴 **Failing** | Wrong algorithm, logic errors, crashes | `null` pointer dereference, off-by-one errors |
+| 🟡 **Passing** | Works in tested cases, no obvious bugs | Handles expected inputs correctly |
+| 🟢 **Excellent** | Proven correct across edge cases | Property-based tests, formal verification |
+
+### Performance
+| Level | Criteria | Example |
+|-------|----------|---------|
+| 🔴 **Failing** | Naive O(n²) where O(n) exists | Nested loops for searchable data |
+| 🟡 **Passing** | Acceptable complexity for scale | O(n log n) for reasonable n |
+| 🟢 **Excellent** | Optimal algorithm + profiled | Cached, indexed, benchmarked |
+
+### Error Handling
+| Level | Criteria | Example |
+|-------|----------|---------|
+| 🔴 **Failing** | Crashes on invalid input | Uncaught exceptions, panics |
+| 🟡 **Passing** | Returns error codes/exceptions | `try/catch`, error returns |
+| 🟢 **Excellent** | Graceful degradation + logging | Circuit breakers, retry logic |
+
+### Concurrency Safety
+| Level | Criteria | Example |
+|-------|----------|---------|
+| 🔴 **Failing** | Race conditions, deadlocks | Shared mutable state, no locks |
+| 🟡 **Passing** | Thread-safe with locks | Proper mutex usage |
+| 🟢 **Excellent** | Lock-free or proven safe | Immutable data, atomic operations |
+
+### Testability
+| Level | Criteria | Example |
+|-------|----------|---------|
+| 🔴 **Failing** | Impossible to unit test | Hard-coded dependencies, global state |
+| 🟡 **Passing** | Can be tested with mocks | Dependency injection |
+| 🟢 **Excellent** | Self-testing design | Pure functions, property-based |
+
+### Maintainability
+| Level | Criteria | Example |
+|-------|----------|---------|
+| 🔴 **Failing** | "Clever" code, unclear intent | Obfuscated logic, magic numbers |
+| 🟡 **Passing** | Clear intent, reasonable | Named variables, comments |
+| 🟢 **Excellent** | Self-documenting + simple | Obvious code, minimal complexity |
+
+**Passing Threshold**: Minimum 🟡 on ALL criteria
+**Ship-Ready**: Minimum 🟢 on Correctness, Performance, Error Handling
+
+---
+
+## Test Quality Rubric (Ramsay Mode)
+
+### Coverage
+| Level | Criteria | Acceptable % |
+|-------|----------|--------------|
+| 🔴 **Raw** | Only happy path | <50% branch |
+| 🟡 **Acceptable** | Common failures covered | 80%+ branch |
+| 🟢 **Michelin Star** | Complete boundary analysis | 95%+ branch + mutation tested |
+
+### Edge Case Testing
+| Level | Criteria | Example |
+|-------|----------|---------|
+| 🔴 **Raw** | Only happy path tested | `test('adds 2+2')` |
+| 🟡 **Acceptable** | Common failures tested | Null, empty, invalid input |
+| 🟢 **Michelin Star** | Boundary analysis complete | Min/max values, overflow, underflow |
+
+### Test Clarity
+| Level | Criteria | Example |
+|-------|----------|---------|
+| 🔴 **Raw** | Unclear what's being tested | `test('test1')` |
+| 🟡 **Acceptable** | Clear test names | `test('handles null input')` |
+| 🟢 **Michelin Star** | Self-documenting test pyramid | Given-When-Then, BDD style |
+
+### Speed
+| Level | Criteria | Example |
+|-------|----------|---------|
+| 🔴 **Raw** | Minutes to run unit tests | Calls real database/network |
+| 🟡 **Acceptable** | <10s for unit tests | Mocked dependencies |
+| 🟢 **Michelin Star** | <1s, parallelized | Pure functions, in-memory |
+
+### Stability
+| Level | Criteria | Flake Rate |
+|-------|----------|------------|
+| 🔴 **Raw** | Flaky, timing-dependent | >1% failure rate |
+| 🟡 **Acceptable** | Stable but potentially slow | 0% flake, deterministic |
+| 🟢 **Michelin Star** | Deterministic + fast | 0% flake, <100ms per test |
+
+### Isolation
+| Level | Criteria | Example |
+|-------|----------|---------|
+| 🔴 **Raw** | Tests depend on each other | Shared state, execution order matters |
+| 🟡 **Acceptable** | Independent tests | Each test sets up own state |
+| 🟢 **Michelin Star** | Pure functions, no shared state | Immutable, stateless |
+
+**Merge Threshold**: Minimum 🟡 on ALL criteria
+**Production-Ready**: Minimum 🟢 on Coverage, Stability, Isolation
+
+---
+
+## BS Detection Rubric (Bach Mode)
+
+### Red Flags in Testing Practices
+
+| Red Flag | Evidence | Impact | Harshness Level |
+|----------|----------|--------|-----------------|
+| **Cargo Cult Practice** | "Best practice" with no context | Wasted effort, false confidence | 🟡 Harsh |
+| **Certification Theater** | Required cert unrelated to actual skills | Filters out critical thinkers | 🟢 Brutal |
+| **Vendor Lock-In** | Tool solves problem it created | Expensive dependency | 🟡 Harsh |
+| **False Automation** | "AI testing" still needs human verification | Automation debt | 🟡 Harsh |
+| **Checkbox Quality** | Compliance without outcome measurement | Audit passes, customers suffer | 🟢 Brutal |
+| **Hype Cycle** | Promises 10x improvement without evidence | Budget waste, disillusionment | 🟡 Harsh |
+| **Coverage Theater** | 100% coverage of trivial code | False sense of quality | 🟡 Harsh |
+| **Test Script Slavery** | Following test cases without thinking | Misses actual bugs | 🟢 Brutal |
+| **Magic Tool Thinking** | Tool will solve all problems | Dependency without skill growth | 🟡 Harsh |
+| **Certification Over Competence** | Hiring based on credentials, not ability | Weak team, strong resumes | 🟢 Brutal |
+
+### 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
+
+| Scenario | Linus | Ramsay | Bach | Notes |
+|----------|-------|--------|------|-------|
+| **Senior engineer, repeated mistake** | ✅ | ✅ | ✅ | They should know better |
+| **Critical security bug** | ✅ | ✅ | ❌ | Technical precision needed |
+| **Production incident** | ✅ | ✅ | ❌ | No time for sugar-coating |
+| **Vendor evaluating claims** | ❌ | ❌ | ✅ | BS detection prevents waste |
+| **Team explicitly requests no-BS** | ✅ | ✅ | ✅ | Permission granted |
+| **Certification/process evaluation** | ❌ | ❌ | ✅ | Bach's specialty |
+
+### When to Dial Back
+
+| Scenario | Instead Use | Reason |
+|----------|-------------|--------|
+| **Junior dev, first PR** | Constructive mentoring | Build confidence |
+| **Demoralized team** | Supportive guidance | Rebuild trust |
+| **Public forum** | Private feedback | Avoid humiliation |
+| **Unclear if fixable** | Collaborative problem-solving | Avoid frustration |
+| **Personal, not technical** | Empathy + support | Not a code issue |
+
+---
+
+## 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."

package/assets/skills/brutal-honesty-review/resources/review-template.md

@@ -0,0 +1,102 @@
+# 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**:
+   ```bash
+   [Command or code change]
+   ```
+
+2. **Verify Fix**:
+   ```bash
+   [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