The-Ideal-Harness

brainstorming

Turn a vague request into an agreed design before any code is written. HARD GATE — produce a design and get explicit approval first; do not implement, scaffold, or edit until the user approves. Use whenever a request is non-trivial or under-specified.

caveman

Output-side token compression. Write terse, high-signal prose — drop articles, filler, and pleasantries — while keeping all technical substance, code, and errors verbatim. Use when output token volume matters and prose polish does not.

Web & Frontend Listed

design-critique

Pre-emit self-critique for UI/visual/design output (components, CSS, copy, layouts) — anti-slop gates, taste dials, and a design-token contract check, run BEFORE the work is shown, not after. Use whenever producing or editing anything with a visual/UX surface.

focus

Answer-first, structured output mode — lead with the action, number multi-step work, restate state across turns, suppress tangents. Use when the user wants to act on your answer immediately, not read around it. A different axis from caveman (structure/legibility, not token count) — combine freely with it.

grill-with-docs

Before brainstorming or coding, interrogate a vague request for scope/constraints AND ground it against real, current docs (not training-data memory) for any library or API it touches. Produces a CONTEXT.md the brainstorming/planning phase consumes. Use at the very start of any non-trivial task that names a library, framework, or external API.

session-observer

Watch this session for corrections, repeated patterns, and judgment calls, and record them as episodic observations for later human-reviewed skill/policy improvement. Use continuously during any non-trivial session, not as a one-shot invocation — the value is cumulative.

subagent-driven-development

Execute a multi-task plan as a controller that dispatches one fresh-context subagent per task, reviews each result against the spec, loops fixes, and tracks progress in a durable ledger. Use for any non-trivial build so the controller's context stays lean and every task is independently reviewed.

tdd

Write the failing test before the implementation, for a single piece of code — red, green, refactor. A finer grain than the ledger's task-level verify.command (subagent-driven-development); use this INSIDE an implementer's work on one task, not as a replacement for the ledger.

using-ideal-harness

Bootstrap skill for the Ideal Harness. Explains the installed modules and when to route to them. Injected at session start so the agent knows the harness is active.