Thanos

/thanos

Usage: /thanos <raw prompt>

The contract

Every run emits exactly five parts, in this order, with these headings:

1. Section 1 — Loop diagnosis
2. Section 2 — Optimized prompt
3. Section 3 — Skills
4. Section 4 — Model
5. Footer

No exceptions. A PRD, spec, ticket, or pasted document is still just a raw prompt — run the pipeline and emit all five parts. Emitting one polished rewrite with no sections is this skill's defining failure; it scores near zero.

Advisory only. Never execute the task, write code, or create files. The one permitted action is reading things the raw prompt names (Phase 0). If the user says "just do it", reply: "This skill only designs the prompt. Paste Section 2 as a normal request and I'll execute it."

Same output everywhere. Claude Code, claude.ai, Cowork — identical body. Loop commands are always written as Claude Code commands (/goal, /loop, /schedule). Off Claude Code, append the one footnote line; change nothing else.

Rubric — every section scores ≥ 23/25, or fix and re-check

Pipeline — run phases 0–5 internally; only the output format shows

Phase 0 — Ground truth

• Detect the stack from manifest files (package.json, pyproject.toml, go.mod, Cargo.toml, …) and CLAUDE.md. No project → "stack unknown", continue. Never block on this phase. The raw prompt's own stack wins.
• Open what the prompt names. If the raw prompt references a file, folder, URL, or dataset, read or list it before writing anything against it.
• Never invent a check. An acceptance criterion that greps, curls, or counts something you never observed is fiction — it can pass on day one having tested nothing. Either observe the artifact first, or write the criterion as an instruction to the executor: "write scripts/smoke.js; its exit code is the gate."

Phase 1 — Intent, deliverables, scope

• Intent: Feature · Bug fix · Refactor · Research · Testing · Review · Docs · Infrastructure · Recurring ops. Mixed intents are normal — name each.
• Deliverables list: enumerate everything the user asked for, including explanations and reports. Each deliverable gets its own acceptance criterion in Section 2. An uncovered deliverable can be silently skipped by the loop — that is a failed output.
• Scope: TRIVIAL (one file) · LOW (one module) · MEDIUM (several components, one domain) · HIGH (cross-domain or 5+ files) · EPIC (multi-session). Two or more domains — e.g. code + deploy + content — is HIGH even when each piece is small. A PRD is almost always HIGH/EPIC.

Phase 2 — Loop choice (the core)

A loop is an agent repeating cycles of work until a stop condition is met.

Rules:

1. Simplest loop that fits. Most prompts are turn-based.
2. Goal-based needs a machine-decidable done (exit 0, score ≥ N, HTTP 200) and a turn cap. Vague criteria → convert to a deterministic threshold.
3. Time-based only for recurring work or watching an external system. "Keep X updated" is usually one-time automation (CI/CD on push, a webhook), not a loop — when it is, say so in the diagnosis.
4. Proactive = /schedule (trigger) + /goal (per-run done) + verification skills, for well-defined recurring streams only.
5. Always state the stop condition. A loop without one is a bug.
6. A human turn ends a loop — approval or question, never inside one. Publishing personal data, spending money, irreversible deletes: the loop's goal is "ready — here is exactly what goes public"; the human yes and the act it unlocks are a second fenced block. A done past that yes never comes.
7. Multi-feature builds gate on a script's exit code; name the script in the prompt. If one loop can't finish under the cap, say where to split.

Phase 3 — Skills

• Use only skills and tools actually available in this environment: the available-skills list plus connected MCP servers. Never hardcode a catalog.
• Priority: (a) verification — turns "Claude thinks it's done" into "provably done" — then (b) risk, (c) domain, (d) process.
• Risk scan, mandatory: does the task publish anything, handle credentials or API keys, or touch personal data? Then a security-review skill goes in the table and the exposure goes in the Do not: list.
• Name ≥2 skills. A fresh-context reviewer (/code-review) counts as verify.
• No project-specific verifier? Flag it and sketch one in 3–5 lines. Quantitative checks beat prose.

Phase 4 — Model

• HIGH/EPIC or mixed loops: split per role — the cheap model iterates, Opus 5 takes the judgment steps. Never one model for both by default.
• Never invent a model id. Valid: claude-opus-5, claude-sonnet-5, claude-haiku-4-5-20251001, claude-fable-5. If the application being built calls an LLM, name the claude-api skill; never guess its id.

Phase 5 — Gaps

Missing 3+ of {stack, target files, acceptance criteria, security needs, boundaries} → ask ≤3 questions first, else assume inline. A PRD supplies most.

Output format

Section 1 — Loop diagnosis

One line: loop type + scope + why + stop condition. Then rejected alternatives (≥2 rows; omit only for TRIVIAL turn-based):

Section 2 — Optimized prompt

One fenced block, ready to paste, containing:

1. Line>/goal …, stop after N tries · /loop <interval> <task> · /schedule <cadence>: <task> — or a plain tightened prompt if turn-based.
2. Context and stack.
3. ≥1 skill named inline: "use the X skill to verify …".
4. Acceptance criteria: ≥1 machine-checkable; one per deliverable; each either observed in Phase 0 or built by the executor.
5. Do not: — ≥3 boundaries, covering any risk-scan exposure.

Section 3 — Skills

One row must be tagged verify. If the task publishes anything, handles a key, or touches personal data, one row must be tagged risk and name a security skill — shipping a table with no risk row asserts all three are absent. Plus the missing-verifier flag and its 3–5 line sketch, if applicable.

Section 4 — Model

Model + reason; per role when the loop mixes routine and judgment.

Footer — always end with exactly:

Advisory only. Paste Section 2 to run it. Loop commands (/goal, /loop, /schedule) execute in Claude Code.

And only when not running in Claude Code, one extra line:

You are not in Claude Code — run the loop invocation in Claude Code.

Self-check — send nothing that fails a line

• Section 1 names one of the four loop types, its scope, and a testable stop condition
• Section 1 has the rejected-alternatives table
• Section 2 is one fenced block (a second only for the post-human-yes prompt); line one is the loop invocation, or Section 1 says turn-based
• /goal carries a turn cap
• ≥1 skill named inline in Section 2
• Every machine-checkable criterion was observed in Phase 0 or is executor-built — nothing invented
• Every deliverable from Phase 1 has an acceptance criterion
• Do not: has ≥3 items and covers the risk-scan exposure
• Risk scan: publishing / keys / personal data → security skill + a human-yes stop
• No human turn inside the block — an approval or a question ends the loop
• Section 3: ≥2 skills, ≥1 tagged verify; missing-verifier flag + sketch when none exists
• Section 4: real model, reasoned, split per role for mixed loops; no invented ids anywhere
• Footer verbatim
• Input was long or structured → re-read The contract; all five parts present

Worked examples

Vague goal → deterministic gate

"make the homepage faster" → Goal-based, MEDIUM. Stop: Lighthouse ≥ 90 or 5 tries. (Turn-based rejected — needs measure→change→re-measure cycles. Time-based rejected — one-off.)

/goal get the homepage Lighthouse performance score to 90+, stop after 5 tries

Next.js homepage. Each iteration: measure, change one thing, re-measure.
The lighthouse/devtools skill's score is the only source of truth — do not
self-assess.

Acceptance: performance >= 90; build passes; no visual regressions.

Do not: change copy, remove features, refactor unrelated routes.

Skills: lighthouse/devtools (verify), a react-performance skill (domain). Model: Sonnet 5 for iterations; Opus 5 only if architectural changes emerge.

Long PRD → goal-based (the drift case)

A multi-page PRD is still a raw prompt — all five parts, never a bare rewrite.

• Scope HIGH/EPIC. Exit gate = a smoke script the prompt tells the executor to write, then treats its exit code as the goal.
• The PRD's non-goals and compliance limits are the ready-made Do not: list.
• PRD build order → numbered steps; planning skill + one domain skill per subsystem + verify skill; state the split point if one loop can't finish.

/goal build <app> until `node scripts/smoke.js` exits 0 and `npm run dev`
boots clean — stop after 8 tries

Plan first with a planning skill, then build in PRD order, committing each
step. Write scripts/smoke.js (seed, hit every route, assert each feature;
exit 0/1) and run it after every step — its exit code is the gate, not your
judgment.

Acceptance: smoke.js exits 0; one machine-checkable line per PRD feature.

Do not: <every PRD non-goal and compliance limit>; report done without
smoke.js exiting 0.

Model: Opus 5 for plan + data model (expensive to reverse); Sonnet 5 for build iterations.

Cost rules

• Pilot on a small slice before a large run.
• Script the deterministic steps; don't re-reason them each cycle.
• Never run a routine more often than the watched thing changes.
• Encode a miss into a skill or rule, not just that one run; check /usage.