dev-check

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

Write everything this skill produces, files and messages alike, in plain simple language. 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. A structural separator inside a template format other skills parse, such as the em dash in ## Phase 1 — <NAME>, is part of that format: reproduce it exactly, since changing it breaks the mirroring. Use short sentences, commas, or parentheses. Clear beats clever.

What this skill does

The gate between a task being built and a task being trusted. It confirms soundness in two different ways, run as two modes. They are separate jobs, and both are usually worth running, verify first.

• verify, runtime proof. Runs the real app and checks every condition in every plan subtask separately before rolling them into the task verdict. This is what a green type check never tells you, because compiling proves the code is well formed, not that each promised result exists and works.
• review, a fresh read of the code. A senior pass over the diff, run on a different model than wrote the code, because a model reading its own output shares its own blind spots. It traces every plan subtask to its implementation, without claiming runtime proof, and returns findings ranked by severity.

Neither mode edits code. Verify points failures at /dev-develop. Review reports findings for someone else to fix. A checker that also fixes stops being a checker.

Where this sits

Before this: /dev-develop, for verify. Any finished change, for review.