Before any multi-step work with a stated goal — a feature, a bugfix spanning multiple files, a QA sweep, a doc draft + iterations, a multi-day investigation — create an ATO Mission instead of doing it via bare `ato dispatch` calls. A Mission persists the goal + the verifiable success criteria, lets the coordinator tick drive the work across days, captures every event in a structured audit trail (SQLite + markdown narrative), and integrates parallel agents' work via merge strategies. Complement to `ato-warroom` (the cross-family decision before you start) and `ato-review` (the post-code-diff review). Missions is where multi-step work LIVES; war-rooms are where decisions ABOUT it get made; reviews are where the resulting commits get vetted. Fires when: the work has more than one decision point, a verifiable end state, or runs across more than one session. Use it for any ATO development that doesn't fit in a single dispatch.
Before committing any non-trivial change, dispatch the diff to a reviewer runtime via ATO (`ato dispatch <reviewer> --session <id>`), parse the numbered/severity-tagged findings, apply or defer each one with a recorded justification, then commit. Fights the "build passes therefore ship it" failure mode — what Garry Tan calls the AI agent complexity ratchet. Place in the v2.16 stack: this skill is the LAST gate. `ato-warroom` decides the design; `ato-mission` runs the multi-step work and produces the diff; `ato-review` checks the diff before commit. When the review is part of a Mission, dispatch the review with `--require-tools read_file,grep,git_diff,git_log` so the reviewer can walk the source itself instead of reasoning from a paraphrase (PR-1.5 tool surface). Receipts land in `execution_logs` and the Mission narrative. Fires automatically before commits touching public surface (CLI subcommands, Tauri commands, MCP tools, schema migrations, security boundaries) or whenever a diff exceeds ~50 LOC of behavi
Before any material decision — code chunk, plan, strategy, design, scope cut, push to GitHub — convene a war-room. The session driver takes the CEO seat: frame the tradeoff, summon specialist seats from whatever agent roster the user has built, dispatch a cross-family voice via `ato dispatch` so priors actually disagree, decide. A failure-mode filter (wrong assumptions / overcomplexity / orthogonal edits / imperative-over-declarative — Karpathy's four are one good default, swap in your own) runs on every dispatch. Place in the v2.16 stack: war-rooms DECIDE before code starts; `ato-mission` EXECUTES the work between decisions (multi-step, goal-driven, persisted across days); `ato-review` VERIFIES the resulting commits. Use a war-room for the design verdict, hand the verdict to a Mission, review the merged result. Fires before: sending a code draft to the user as final, opening a PR, pushing to a remote-tracking branch, committing >50 LOC of behavior change, or delivering a plan or strategic recommendation as
Turn any installed skill (gstack, custom, third-party) into an ATO agent the user can summon into war-rooms. Reads a SKILL.md, extracts the persona, strips runtime boilerplate, and writes an agent file at `.claude/agents/<slug>.md` (project-scoped) or `~/.claude/agents/<slug>.md` (global). Prompts for a model roster (primary + 1-2 alts) so cross-family dispatch in war-rooms produces real disagreement. Companion to `ato-warroom` — that skill summons agents this skill creates. Use when asked "turn this skill into an agent", "register X as a war-room agent", or when scoping a new persona before a war-room runs.
Fast headless browser for QA testing and site dogfooding. Navigate any URL, interact with elements, verify page state, diff before/after actions, take annotated screenshots, check responsive layouts, test forms and uploads, handle dialogs, and assert element states. ~100ms per command. Use when you need to test a feature, verify a deployment, dogfood a user flow, or file a bug with evidence. Use when asked to "open in browser", "test the site", "take a screenshot", or "dogfood this".
Systematic debugging with root cause investigation. Four phases: investigate, analyze, hypothesize, implement. Iron Law: no fixes without root cause.
Design consultation: understands your product, researches the landscape, proposes a complete design system (aesthetic, typography, color, layout, spacing, motion), and generates font+color preview pages. Creates DESIGN.md as your project's design source of truth. For existing sites, use /plan-design-review to infer the system instead. Use when asked to "design system", "brand guidelines", or "create DESIGN.md".
Designer's eye QA: finds visual inconsistency, spacing issues, hierarchy problems, AI slop patterns, and slow interactions — then fixes them. Iteratively fixes issues in source code, committing each fix atomically and re-verifying with before/after screenshots. For plan-mode design review (before implementation), use /plan-design-review. Use when asked to "audit the design", "visual QA", "check if it looks good", or "design polish".