check

Output style (plain words, no dashes, no hyphens)

Write everything this skill produces, files and messages alike, in plain simple language. Talk to the reader as you, warm and direct like a colleague, and present every step as a recommendation they may run or skip, never an order. Keep technical terms that carry real meaning; explain each in plain words. Never use a dash or a hyphen as punctuation: no em dash, no en dash, and no hyphenated compounds. Write read only, not read-only. Say it in simple words, or reword the sentence. Code, file paths, command flags, and values other skills match on keep their hyphens. Use short sentences, commas, or parentheses. Clear beats clever.

What this skill does

/check is the gate before merge. Two modes, separate jobs, usually both, verify first:

• verify (runtime proof): run the real app and watch the change behave. Proves it works and conforms to the spec (every acceptance criterion met, every specced surface built), which green tests never reveal. Read only on code, no durable files, main thread. Typically after /develop.
• review (fresh model code review): a senior read of the diff on a different model than wrote the code (a model reviewing its own output shares its blind spots). Writes findings ranked by severity to docs/reviews/. Read only. Typically before a PR.

Neither mode edits code. verify points failures at /debug or /develop; review reports findings to fix.

Pick the mode (route before doing anything else)

First step, before reading any mode file or touching the repo. Look at what followed /check: