skill: five check-writing rules earned from real runs

[chriscfellows]

Extends the check-writing guidance from #57 with lessons from swarm runs where the check passed work that was wrong, or reported too little for the retry to act on.

• Structure before text. A grep asserts nothing about a file that does not parse. On one run a component with useState spliced into a props type literal, a duplicated declaration and a deleted satisfied every grep written against it — each string it looked for was present in the wreckage. The typecheck arm was ordered last behind a fail-fast exit and never ran.
• Print every arm. The retry prompt is built from check output, so a fail-fast check is a one-defect retry: the worker fixes the arm it was shown and walks back into the others. Two attempts on that run reported one failure each. templates/repo-feature/checks/check_repo_feature.py already collects a fails list and prints all of them; the hand-written check did not follow it.
• Tripwire the build pipeline. Both check-gaming incidents seen here edited package.json scripts to post-process the artifact rather than changing the sources an added-line scan was watching.
• Frozen artifacts have chain of custody. A reviewer once silently fixed the frozen tests instead of returning FAIL.
• Baseline before spawning. Skipping ./ringer.py run --baseline once cost two full worker attempts (~7M tokens) against a check no model could satisfy.

Docs only, one file, no capability claims. Both references were checked against this repo rather than asserted: check_repo_feature.py does collect a fails list, and --baseline is a real flag.

Suite unchanged: Ran 254 tests, OK.

Claude-Session: https://claude.ai/code/session_01AVTYzUcjMokzMsyjABjUBF