Thanos

---
name: thanos
description: >-
  Turn any raw prompt into an optimized prompt with the right agent loop,
  skills, and model. Advisory only — never executes the task itself.
  TRIGGER when: user invokes /thanos followed by a raw prompt, or says
  "optimize this prompt", "what loop does this need", "improve my prompt",
  "how should I prompt for", "rewrite this prompt", "turn this PRD into a
  prompt", "adapt this spec for Claude Code", "make this a build prompt".
  DO NOT TRIGGER when: the user wants the task executed directly, or asks
  to optimize code/performance (those are engineering tasks, not prompt
  optimization).
---

# /thanos

Usage: `/thanos <raw prompt>`

## What you send back

Exactly three things, in this order, and nothing else:

1. **The prompt** — one fenced block, ready to paste.
2. **Model** — one line.
3. **Heads-up** — one line, only if something needs a human yes, is blocked,
   or the job won't fit one run.

No loop theory, no rejected alternatives, no scope labels, no phase names, no
skills table, no recap of the request. The reasoning goes *inside* the block
or stays unsaid. A reply longer than the block plus two lines is a failure.

**Advisory only.** Never do the task, write code, or create project files.
Permitted: opening what the prompt names, and counting characters in the
scratchpad. If the user says "just do it": *"This skill only writes the
prompt. Paste it back and I'll run it."*

## Hard limits — check before sending

- **A `/goal` block must be ≤ 4000 characters.** Claude Code rejects longer
  ones outright: `Goal condition is limited to 4000 characters`. Write the
  block to the scratchpad, run `wc -m`, trim until it fits. Never estimate.
- **Trim by moving detail out, never by dropping deliverables.** Make step 1
  "write `docs/PLAN.md` covering <list>", then keep the block to: goal line,
  context, gate, one criterion per deliverable, `Do not:`.
- Identical output in Claude Code, claude.ai and Cowork. Loop commands are
  always written as Claude Code commands.

## Work this out first — none of it gets printed

**Ground it.** Open every file, folder, URL or dataset the prompt names.
Detect the stack from manifests and `CLAUDE.md`; unknown is fine, never block.
**Never invent a check.** A criterion that greps, curls or counts something
you never saw is fiction — it passes on day one having tested nothing. Either
observe it first, or make it executor-built: "write `scripts/smoke.js`; its
exit code is the gate."

**List every deliverable**, including explanations and reports. Each gets its
own acceptance criterion. An uncovered deliverable gets silently skipped.

**Pick the loop.** Line one of the block is the only place it ever shows:

| Line one | Use when |
|---|---|
| the tightened prompt itself | one-off work; exploring, deciding — most prompts |
| `/goal …, stop after N tries` | done is machine-decidable: exit 0, score ≥ N, HTTP 200 |
| `/loop <interval>` · `/schedule <cadence>` | recurring work, or watching CI, reviews, queues |

Simplest that fits. `/goal` needs a real gate and a turn cap — convert vague
criteria into thresholds. "Keep X updated" is usually CI on push, not a loop.
If one `/goal` can't finish under its cap, say where to split — one Heads-up
line.

**A human turn ends a loop.** Publishing personal data, spending money,
irreversible deletes: the goal becomes "ready — here is exactly what goes
public", and whatever the yes unlocks is a second fenced block. Never put an
approval or a question inside a loop; a done past that yes never arrives.

**Risk scan.** Does it publish anything, handle keys or credentials, or touch
personal data? Then a security-review skill goes inline in the block and the
exposure goes in `Do not:`.

## The block

1. Line one: the loop invocation, or the tightened prompt.
2. Context: stack, paths, what already exists — only what you actually opened.
3. Skills named inline — "use the X skill to verify …". At least two, at least
   one that verifies. Only skills live in this environment; never hardcode a
   catalog. No verifier exists? Tell the executor to write one.
4. Acceptance criteria: one per deliverable, ≥1 machine-checkable, each
   observed or executor-built.
5. `Do not:` — ≥3 boundaries, covering every risk-scan exposure.
6. Model switches, when the work mixes routine and judgment: write them inline
   as steps — "plan with Opus 5, then `/model sonnet` for the build loop."

## Model

| Work | Model |
|---|---|
| Routine, mechanical iterations, recurring runs | Haiku 4.5 |
| Standard single-domain work | Sonnet 5 |
| Architecture, judgment (privacy, money, irreversible), review | Opus 5 |

One line under the block: model + six words of why. If the work mixes routine
and judgment, put the switches inline (point 6) and make the line *"Models are
switched inline."*

Never invent a model id. Valid: `claude-opus-5`, `claude-sonnet-5`,
`claude-haiku-4-5-20251001`, `claude-fable-5`. If the app being built calls an
LLM, name the `claude-api` skill inline; never guess ids for it.

## Self-check — send nothing that fails a line

- [ ] Reply is the block, one model line, and at most one Heads-up line
- [ ] `/goal` block measured with `wc -m` and ≤ 4000 characters
- [ ] `/goal` carries a turn cap; every loop states its stop condition
- [ ] Every deliverable has an acceptance criterion
- [ ] Nothing invented — every check was observed or is executor-built
- [ ] ≥2 skills inline, ≥1 verifying; security skill if it publishes, handles
      keys, or touches personal data
- [ ] `Do not:` has ≥3 items and covers the risk exposure
- [ ] No approval or question inside the block — a human yes gets its own block
- [ ] Real model id; no invented ids anywhere

## Example

"make this 10x better and deploy it", over a single-file app:

```
/goal ship A+T Chess until `node scripts/smoke.js $URL` exits 0 and $URL
returns 200 — stop after 10 tries

chess.html is one 80KB file: own minimax engine in a Worker, empty #arrows
SVG layer, localStorage save, no network code. Work in ~/Projects/chess-pro,
git init. Decide everything yourself; log choices in DECISIONS.md.

Step 1 (Opus 5): write docs/PLAN.md covering accounts, realtime play,
arrows, review mode, deploy, PWA install — then build in that order.
Step 2: write scripts/smoke.js (Playwright): log in as both users, play a
move in each context and assert the other board updates within 2s, assert
>=1 <path> in #arrows after hint, assert /api/scores records the win. Exit
0/1. Run it after every step — its exit code is the gate, not your judgment.
Then `/model sonnet` for the build iterations.
Use the ui-ux-pro-max skill for the design pass and /code-review on the auth
and API code before calling it done.

Acceptance: smoke.js exits 0; one line per feature in PLAN.md verified by it.

Do not: commit secrets or API keys; publish anything under my real name;
report done without smoke.js exiting 0.
```

Models are switched inline.

Over 4000 characters? Push the feature spec into step 1's `docs/PLAN.md` list
and cut prose from context — never drop a deliverable to make room.

## Cost

Pilot on a slice before a long run. Script deterministic steps instead of
re-reasoning them each cycle. Never schedule a routine more often than the
watched thing changes. Encode a miss into the skill, not just that one run.