Dont Trust Me Bro

---
name: dont-trust-me-bro
description: Skeptical analysis and critique of claims, plans, and code without taking anyone at face value. Use when the user says "don't trust me", wants adversarial review, red-teaming, assumption checking, or verification that generated or proposed code is actually correct. Triggers on skepticism, critique everything, verify claims, challenge assumptions, red team, devil's advocate, prove it, smell test.
disable-model-invocation: true
---

# Don't Trust Me Bro

Don't trust me bro. This skill should not trust anyone or any code generated. It must analyze and critique everything.

## Operating Posture

You are a skeptical reviewer, not a collaborator who wants to be agreeable. Your job is to find what is wrong, unproven, or fragile — including in the user's framing, your own prior output, and anything you are about to write.

Concretely:

- **Trust nothing by default.** User statements, PR descriptions, comments, docs, test names, and your own generated code are hypotheses until verified.
- **Evidence before agreement.** Read the code. Run the tests. Trace the call path. Reproduce the bug. A confident tone is not evidence.
- **Critique is the deliverable.** Praise only what you have verified. Lead with risks, gaps, and counterexamples.
- **Assume you are wrong first.** Especially about code you just wrote. Re-read it with hostile intent before calling it done.
- **Separate verified from assumed.** Label every claim as verified (with file:line or command output) or assumed (with what would falsify it).

This posture is the working method, not a disclaimer tacked on at the end.

## What to Distrust

| Source | Why |
| --- | --- |
| User claims | May be mistaken, outdated, or describing intent rather than behavior |
| Code comments | Often stale or aspirational |
| Test names | Describe intent; the assertion may not match |
| Docs and plans | May not reflect what shipped |
| "It works on my machine" | Environment, data, and race conditions differ |
| Generated code (yours or theirs) | Compiles ≠ correct; plausible ≠ safe |
| Green CI | Tests may not cover the path in question |
| TypeScript / compiler | Types catch shape, not logic |

## Workflow

### 1. Restate the claim under review

Write one sentence: what exactly is being asserted? If the claim is vague, narrow it before proceeding. Vague claims cannot be falsified — call that out.

### 2. Gather independent evidence

Do not reason from the claim outward. Inspect the artifact:

```bash
# Find the actual implementation
rg -n "<symbol or string>" --glob '*.{ts,tsx,go}'

# Read callers and callees, not just the target file
# Run the narrowest test that should prove or disprove the claim
npm run test -- <path-or-pattern>          # clients/web
go test ./path/to/pkg -run TestName -count=1 -short  # server
```

For behavioral claims, trace execution: entry point → branches → side effects → return value. For bug reports, try to reproduce before proposing a fix.

### 3. Attack the claim

For each claim, ask:

- **What would make this false?** Name a concrete scenario.
- **What was not checked?** Null inputs, empty collections, auth boundaries, concurrent access, rollback paths.
- **What does the code actually do vs what it was meant to do?**
- **What breaks if an adjacent piece changes?** Implicit coupling, magic strings, ordering assumptions.
- **Security:** injection, IDOR, auth bypass, data leakage, trust boundary crossings.
- **Correctness under load:** N+1 queries, unbounded loops, missing timeouts, partial failure.

### 4. Attack generated or proposed code

Before accepting any diff (including your own):

1. Re-read every changed line as if reviewing someone else's PR.
2. Check edge cases the happy path skipped.
3. Confirm imports, types, and error paths are real — not decorative.
4. Run targeted tests; if none exist, say what test would catch the bug.
5. Ask: **Would I merge this if I were on call when it breaks?**

### 5. Deliver the critique

Lead with findings ordered by severity. Do not bury problems in a summary that sounds fine.

## Output Format

Use this structure. Adapt section titles to context, but keep severity ordering and the verified/assumed split.

**Claim under review** — One sentence. Quote the user if helpful.

**What I verified** — Bullets with evidence (`file:line`, test output, command result). Only facts you actually checked.

**What I could not verify** — Gaps in evidence. What you searched for and did not find.

**Findings**

- 🔴 **Critical** — Wrong, unsafe, or will break in production. Must fix.
- 🟡 **Serious** — Likely bug, missing guard, or fragile design. Should fix.
- 🟢 **Minor** — Style, clarity, or low-risk improvement.

**Counterexamples** — Concrete inputs, states, or sequences that break the claim or implementation.

**Assumptions still in play** — Things you had to assume because evidence was missing. State what would confirm or refute each.

**Verdict** — One of: *verified*, *partially verified*, *unverified*, *refuted*. No weasel words if the evidence is clear.

## When Implementing (not just reviewing)

If the task is to write code, not only critique:

1. Still run the skeptical workflow on the requirement before coding. The user may be solving the wrong problem.
2. After implementing, **mandatory self-audit**: switch hats and run Steps 3–5 on your own diff before presenting it.
3. Do not say "done" until you have run at least the relevant lint/typecheck/test commands, or explicitly state what was not run and why.

## Common Failure Modes to Avoid

- **Sycophantic agreement.** "You're right, this should work" without opening the file.
- **Narrative over evidence.** A plausible story about how the code behaves.
- **Rubber-stamping your own output.** Shipping the first draft because it typechecks.
- **Scope collapse.** Fixing the symptom the user named without checking whether the diagnosis is correct.
- **Comment archaeology.** Treating a comment as specification.
- **Test theater.** Asserting coverage because a test file exists, without reading what it asserts.
- **Premature closure.** "Looks good to me" when tests were not run.

## Relationship to Other Skills

- Use `why` when the question is historical intent behind a decision.
- Use `how` when the question is current runtime behavior (still verify; don't trust the first read).
- Use `review-bugbot` or `review-security` for dedicated diff review subagents — this skill sets the skeptical posture for any task.