# Thanos > 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). - Skill: `thanospapage/thanos` (Agent Skill) - Install (CLI): `npx skillmds@latest add thanospapage/thanos` - Raw SKILL.md: https://api.skillmd.com/api/skills/thanospapage/thanos/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Product & Planning - Author: thanospapage (https://skillmd.com/u/thanospapage) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/thanospapage/thanos --- # /thanos Usage: `/thanos ` ## 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 | Section | 23+ requires | |---|---| | **1 Loop** | one of the four loop types named; scope named; why; a testable stop condition; rejected-alternatives table | | **2 Prompt** | one fenced block; loop invocation on line one (none if turn-based); turn cap on `/goal`; no human turn except as the stop condition; ≥1 skill inline; every criterion grounded (observed or executor-built); every deliverable covered; `Do not:` with ≥3 items | | **3 Skills** | ≥2 skills, ≥1 tagged `verify`; security skill whenever the task publishes data or handles keys; missing-verifier flag + sketch | | **4 Model** | a real model from the current lineup with a reason; split per role when the loop mixes routine and judgment | ## 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. | Loop | Triggered by | Stops when | Best for | |---|---|---|---| | **Turn-based** | a user prompt | Claude judges it done | one-off tasks; exploring, deciding | | **Goal-based** (`/goal`) | a manual prompt | goal met OR max turns | verifiable exit criteria — you know what done looks like | | **Time-based** (`/loop`, `/schedule`) | a time interval | you cancel, or the work completes | recurring work; watching external systems (CI, reviews, queues) | | **Proactive** | an event or schedule, no human live | each run exits at its goal; routine runs until turned off | steady streams of well-defined work: triage, migrations, upgrades | 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 | Work | Model | |---|---| | Routine / mechanical iterations, recurring runs | Haiku 4.5 | | Standard single-domain work | Sonnet 5 | | Architecture, judgment (privacy, money, irreversible), review | Opus 5 | - 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): | Loop | Verdict | |---|---| | Goal-based | Rejected — no machine-decidable done state | ### Section 2 — Optimized prompt **One fenced block, ready to paste**, containing: 1. Line one = `/goal …, stop after N tries` · `/loop ` · `/schedule : ` — 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 | Skill | Role | |---|---| | `` | verify / risk / domain / process | 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 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: ; 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`.