wm

Design the work before any code exists — the spec corpus and the component taxonomy. Owns the spec pipeline (new, todo, revise, prototype), the spec contract and its artifacts (spec.md, the ledger, thoughts/, the todos/ TODO-N.md + TODO-N.agent.md pair, GLOSSARY.md), and the brick roster: the closed set of component types (command, service, flow, gateway, server / consumer, policy, scheduler, wiring) with the metric and common structure of each. Load it when the `code` skill routes to new, todo, revise, or prototype, when typing a component, or when deciding whether a component owns one responsibility or two.

Manage spec writing, implementation, and bug fixing.

Write the message of one commit — the subject line, and above all the body: the cause that forced the change, the goal the change reaches, and the decision it took when a real choice existed. Load it before every `git commit`, amend, or message rewrite in the wm flow (`impl`, `auto`, `fix`, `squash`), and any time a commit message is written from a diff.

Research phase before implementation — subcommand router. Given entry points (files, symbols, urls), spawn one subagent per entry point in parallel and write refactor-oriented research artifacts into `<notes-dir>/research/`. Use when the user says "dive", "explore", "research these entry points", or provides a list of files/symbols to investigate before a task. Invoke as `/dive <docs|workflow|unknowns|explain|explain-diff>` (default `docs`).

The `docs` route of `/dive` — write markdown research artifacts, one per entry point, graded against the 6-step chain, and converge until nothing new surfaces. Loaded by the `dive` router; it fans out `explorer` agents to write and `explore-critic` agents to grade.

The coding half of the wm flow — every operation that writes source or git history: execute one TODO increment by increment (impl), run the whole ledger unattended (auto), close a gap in the thought and then the code (fix), distill a fixup trail and squash-merge (squash), and the commit rules all three share (commit). Load it when the `code` skill routes to impl, auto, fix, squash, or commit, or when writing code against a TODO body. The message text itself: `commit-message`.

Judge a test set by breaking the code it covers — apply one small behavior-changing edit at a time (a **mutant**) to the source the diff touched, re-run the tests that cover it, and report every mutant the suite let live. A survivor names the assertion nobody wrote. Runs as a batch of `mutation-tester` agents, one per changed source file, each in its own git worktree so the working tree is never mutated. No external mutation tool: the model writes the edit. Load it from the `mutation` gate of `review:ref-gates.md`, or whenever a diff's tests look green but untested.

Attack every name in the code — variables, types, functions, methods, parameters, fields, constants — and reject any that reads unclearly without surrounding context or leans on technical/implementation terms instead of domain (DDD ubiquitous) language. Use during code review, before approving a diff, or when the user says "pedant", "review the naming", "check the names", "are these names clear". Surfaces names that hide a bug or let a reviewer approve one.

Use whenever a doc comment or code comment is being written or rewritten for any reason — a content fix, a stale-reference removal, a rename follow-up — not only when a style gate flagged it. Triggers before committing a comment edit in a codebase with written comment-style caps (a word-count cap per sentence or per symbol doc, an em-dash rule, a one-fact-per-sentence rule).

Red-Green-Refactor cycle for bug fixes. Before fixing a bug, first write a failing test that reproduces it (Red), then make the minimal change to pass (Green), then clean up the code (Refactor). Use on any bug fix, error correction, failing test repair, or when user says "fix this bug".

The judging half of the wm flow — subcommand router. Every operation that reads code and rules on it without writing any: the gate chain over one implemented TODO (todo), and the same gates over a loose diff, branch, PR, or working tree with no TODO pair (diff). Owns which gate judges what, which agent runs it, and at which model tier. Invoke as `/review <todo|diff>` (default `diff`); `/code review` is the same skill under its old name. Never edits source and never commits.

Use when choosing a name that a person or a grep must land on later — a type, function, method, field, constant, file, module, package, test, metric, event, feature flag, error code, or the name of an app or directory being renamed — and when writing the doc line under a new public symbol or building a string literal from parts. Covers one term per concept, domain words over technical ones, 2–4 word public names, one concept per file, naming a file after its concept and never a role (`types`, `utils`, `helpers`, `config`), keeping metric and event strings whole, and a unique literal prefix on every error and log message. Triggers on "what should I call this", "rename this", "where should this file go", "add a new module", "align the terminology", or a name you are about to commit. Judging the names a finished diff already declares is `pedant`, not this skill.

Build and measure the human's understanding of a codebase and a branch change, step by step across sessions. Owns the stateful workspace `<notes-dir>/teach/` — the mission, the numbered HTML lessons, the reference sheets, the learning records that set the level of the next session — and the graded quiz that checks what landed. Read-only over project source. Load it when the `code` skill routes to teach or quiz, or when asked to teach, onboard, quiz, or walk a person through this codebase.

One entry point for all testing work. Use when the user wants to design a test strategy (pairwise tiering across unit/integration/manual), enumerate scenarios before implementation, audit/score an existing test set for missed cases and readability, apply black-box techniques (equivalence partitioning, boundary values, decision tables, state transition, state-combination, property-based over a whole input domain), write BDD Given/When/Then scenarios, drive a feature/bug-fix spec-before-code (TDD), test a harness plugin in isolation, or run the verify phase where the user reviews an implementation. Invoke as `/test-suite <subcommand>`.

This skill should be used when a skill, agent, or plan refers to a "thought", a "thought graph", a "thoughts/" note, or an instruction to "record each decision as a thought" — e.g. the code skill's spec notes or the hunch skill's decision chain — or when the user asks what a thought is. Defines the concept (the atom of reasoning); each consumer keeps its own format.

Answer "why is it this way?" about anything a spec corpus produced — an Outcome, a Components split, a Surface shape, a constraint row, an Autotest level set to none, a line of shipped code. Spawns one subagent that searches `<notes-dir>/thoughts/` and returns a short decision trace. Load it whenever a decision behind a TODO, a spec, or a diff has to be defended, changed, or superseded — `impl:sub-fix.md` Step 1, `arch:sub-revise.md`, a reviewer arguing with an approved shape, or the user asking "why did we do X".