meta

Use this skill to WRITE terse technical documents. Trigger when asked to write, draft, summarize, present, or update a spec, design doc, RFC, brainstorming/exploration summary, or a decision log of options considered — e.g. "write the spec for…", "draft a design doc…", "write up the options we considered…", "present the brainstorming results…", "summarize the exploration we did…" — even if the user never says "concise". Produce short plain sentences, bullets over prose, no filler; caveman-simple but technically precise. NOT for normal conversation, code, or commit/jira messages, and NOT for reviewing or auditing an already-written doc for clarity or bloat (that's meta:wittgenstein).

Use whenever the plan is to spawn, fan out, or parallelize agents — ANY multi-agent work, not just when models are mentioned. Triggers: "spawn/kick off subagents", "a bunch of agents in parallel", fleets that audit/comb/sweep/hunt across files, verify or skeptic stages, reviewer fan-outs, loop-until-done runs, authoring or editing a Workflow script (agent()/parallel()/pipeline()), or writing agent-definition frontmatter. Every spawned agent must get an EXPLICIT model tier assigned BEFORE it launches: reserve expensive head models for a small bounded set of final judges/synthesizers; mid-tier for judgment (review, verify, hunt); cheap tier for mechanical sweeps (grep, list, count, rename). Activate even when the user says nothing about models or cost — an omitted model silently inherits the pricey session model, and fan-out multiplies that waste by the agent count.

Use this skill to author a brand-new skill FROM SCRATCH — deciding its plugin/domain, folder name, file placement, and writing its SKILL.md, frontmatter, and initial metadata.yaml sidecar. Triggers for "create/add/write a new skill for X", "where does the SKILL.md go", "what's the naming convention or folder structure for a new skill", or "what goes in the description frontmatter" — including standing up a NEW domain plugin with its plugin.json, and choosing between a marketplace skill and one local to a single repo. This is about scaffolding a NOT-YET-EXISTING skill's structure and location, NOT about tuning, evaluating, or fixing an EXISTING skill's trigger behavior (skill-creator), and NOT about refreshing an EXISTING skill's metadata.yaml after its body/tools/scripts/hooks changed — that is the separate `meta:update-skill` skill. Also NOT for ordinary code, components, or config in a project. If the skill already exists, use `meta:update-skill` or `skill-creator` instead.

The Razor. Invoke before creating ANY new entity — file, folder, module, class, function, component, hook, util, type, prop, variant, config key, abstraction layer, doc, or top-level category — in ANY language or stack. Not domain-specific. If you are about to bring a new thing into existence, OCKHAM speaks first.

Use when you need to know whether a skill's `description` actually makes Claude reach for it — scoring an existing skill's trigger accuracy before shipping it, after editing its description, or when someone reports that a skill "never triggers" and you need to find out why. Also use to read a score you already have: what a miss means, and what a should-not-trigger query that fired means. Do NOT use to REWRITE a skill's description or body (use `meta:update-skill` — measuring is this skill's job, rewriting is that one's), and never measure with skill-creator's `run_eval`/`run_loop`, which produces systematic false zeros.

SOLID is the design law for all code — SRP/OCP/LSP/ISP/DIP plus DRY, KISS, YAGNI. Activate at DESIGN time and whenever writing, editing, or reviewing code in ANY language or stack — ESPECIALLY when a class, function, hook, route, or method does several things (fetches + formats + writes, or auth + validation + DB in one method) and you're weighing whether to split it; a switch or if-chain keeps growing with new cases; you're deciding how one module should depend on or import another; or designing an interface or extension point. Pairs with meta:ockham (whether an entity should exist at all) — SOLID governs how the entities that DO exist are structured.

Use when you're about to attack a LARGE batch of items the same expensive way — a repo-wide sweep for dead code, unused exports, or bugs; a big multi-file diff to review; dozens of call sites to migrate; a fleet of skills, files, or docs to audit or read; every TODO to classify; hundreds of failing tests to work through. Any "do X across the whole repo / all of them / everything" request where the set is too big to give each item full attention. Instead of paying deep cost on every item, first run one CHEAP shallow pass over ALL of them to sort into skip vs. worth-it, then spend the expensive deep pass only on the shortlist. Invoke at planning time, before touching the first item. NOT for a single file or function (just do it), NOT for picking a model tier (meta:model-routing), NOT for a plain parallel spawn with no sorting step.

Use when a skill ALREADY EXISTS and something about it needs changing: its body, its `description` or boundary wording, a missing `## Contract` or acceptance criteria, or a `metadata.yaml` sidecar that no longer matches what the skill does after its allowed-tools, bundled scripts or hooks changed. Noticing that something no longer matches belongs here too — checking whether a sidecar still agrees with reality, auditing a skill against the house standard, judging that a description reads like a workflow summary — and so does the rewrite that follows. Do NOT use to author a skill that does not exist yet (use `meta:new-skill`). `meta:skill-eval` owns exactly one action, RUNNING a trigger evaluation and scoring it; a review lens only REPORTS a defect. Deciding what is wrong and changing the files is this skill.

Clarity gate for an already-written spec, plan, design doc/note, or RFC — a reviewer persona, not a writing guide. Activate to REVIEW or AUDIT such a doc (often under docs/superpowers/specs or docs/superpowers/plans) when checking whether a non-technical manager or reader could follow it; when it feels padded, wordy, or has grown long; when a section is a wall of prose or full of undefined jargon; or when the decision is buried at the end and should lead — then fix it in place. NOT for WRITING or drafting a doc from scratch (that's meta:lean-writing — wittgenstein reviews one that already exists), and NOT for chat, code, comments, commit messages, jira, or READMEs.