theo-mode

---
name: theo-mode
description: >
  Push the model hard, Theo (t3dotgg) style. Use when the user says "theo mode",
  "push it", "go hunting", "slop audit", "find slop", "perf hunt", "find performance wins",
  "improve agent dx", "what do you need to verify your work", "audit open PRs",
  "triage issues", "close stale PRs", "let it merge", "take over this PR/branch",
  "this is stuck in a loop". Accepts one argument: slop | perf | dx | prs | merge | takeover.
  With no argument, shows the menu and picks the best fit for the repo.
---

# Theo Mode

Six ways to push a strong coding agent past "answer the question", adapted from
Theo's (t3dotgg) field notes. Each mode is its own skill; this one is the menu.

Arguments: `/theo-mode <mode>` where mode is one of:

| arg        | skill            | what it does                                                        |
|------------|------------------|---------------------------------------------------------------------|
| `slop`     | `/theo-mode:slop-audit`    | Hunt useless tests, pointless wrappers, dead abstractions. Delete.  |
| `perf`     | `/theo-mode:perf-hunt`     | Find real performance wins, make hard cuts, prove them with numbers.|
| `dx`       | `/theo-mode:agent-dx`      | Ask what the agent needs to verify its own work, then build it.     |
| `prs`      | `/theo-mode:pr-audit`      | Triage open PRs/issues: merge easy wins, close the dead ones.       |
| `merge`    | `/theo-mode:let-it-merge`  | Verify to a fixed bar, then merge without a human in the loop.      |
| `takeover` | `/theo-mode:takeover`      | Take over stuck work. Allowed to throw it away and start fresh.     |

## How to dispatch

1. If an argument was given, invoke the matching skill with the Skill tool
   (`theo-mode:slop-audit`, etc.), passing any remaining arguments through. If
   the Skill tool is unavailable, read `skills/<name>/SKILL.md` under this
   skill's base directory and follow it. Do not summarize it back to the user;
   start working.
2. If no argument was given, spend at most a minute looking at the repo
   (`git log --oneline -20`, open PR count via `gh pr list`, test dir size) and
   recommend ONE mode with a one-line reason. Then run it unless the user objects.

## Rules that apply in every mode

**Verify, don't narrate.** Every mode ends with evidence: a passing test run, a
benchmark table, a merged PR URL, a screenshot. "Should work" is not a result.

**Cost guardrails.** Theo's disclaimer: he is not responsible for surprise bills.
Neither is this skill. So:
- State scope before you start: how many files, PRs, or benchmarks you intend
  to touch. If it is more than ~30 items, batch it and report after each batch.
- Do not spawn subagents unless the user asked for parallelism. One agent
  reading carefully beats ten agents skimming.
- Never re-run an expensive command (full test suite, full build, benchmark)
  more than needed to prove the point. Cache results in a `NOTES.md` scratch
  file in the repo root (gitignored) and reuse them.
- Stop and report when the remaining work is repetitive and mechanical. The
  user can say "keep going".

**Destructive actions need a plan first.** Closing PRs, force-pushing, deleting
branches, merging to main: list exactly what you will do, then do it. Do not
ask permission item by item, but do give the user one chance to veto the list.

**Ship or say why not.** Finish the mode. If part of it is blocked, finish the
rest and name the blocker in one sentence.