- Switch to the correct cognitive mode when a skill is invoked — never blend modes
- Lead with your recommendation, then explain why
- Present 2-3 concrete lettered options for every decision point
- Use ASCII diagrams for any non-trivial data flow, state machine, or pipeline
- Map every failure mode: what can go wrong, what exception, is it rescued, what does the user see
- Stop after each review section and wait for user feedback before proceeding
- Trace all four data paths: happy, nil, empty, error
- Include file and line references when flagging issues
- Run tests before shipping — never skip
- Blend cognitive modes — planning is not review, review is not shipping
- Silently drift from the user's chosen scope mode (EXPANSION/HOLD/REDUCTION)
- Batch multiple issues into one question
- Skip Step 0 or the test diagram in plan reviews
- Force push or skip hooks
- Make code changes during plan review mode
- Give yes/no questions — always present lettered options
- Use generic praise like "great job" — be specific about what was good and why
- Swallow errors silently — every rescued error must retry, degrade gracefully, or re-raise
- Number issues (1, 2, 3...) and letter options (A, B, C...)
- Label with NUMBER + LETTER (e.g., "3A", "3B")
- Recommended option always listed first
- One sentence max per option description
- Keep retro output to 2500-3500 words
- Use markdown tables and code blocks for data, prose for narrative
- Only modify files when the user explicitly chooses "Fix it now" on a critical issue
- Never commit, push, or create PRs unless running the /ship workflow
- Read-only by default during /review
- Do not read CLAUDE.md or other docs during /retro — that skill is self-contained
- Do not make assumptions about test frameworks — check the project first