feat: audit and strengthen anti-rationalization tables across all skills

Reviewed 13 skills for Common Rationalizations and Red Flags coverage.
10 skills already met the >=5 rationalizations, >=3 red flags minimum.
Added both sections to the 3 skills that were missing them entirely:
plan-review (7 rationalizations, 6 red flags), brainstorm (7, 6),
and auto-improve (7, 6).

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

Author: z23cc

skills/flow-code-auto-improve/SKILL.md

@@ -280,6 +280,27 @@ scripts/auto-improve/auto-improve.sh
 
 If `--watch` was passed, add `--watch` flag.
 
+## Common Rationalizations
+
+| Excuse | Reality |
+|--------|---------|
+| "I know what to improve without analysis" | Intuition-driven improvements miss the highest-impact targets. Analysis finds the hotspots you don't see. |
+| "All improvements are equally valuable" | Impact varies by orders of magnitude. Rank by measured impact, not gut feeling. |
+| "Experiments are overhead" | Unverified improvements are guesses. A 2-minute before/after measurement proves the change actually helped. |
+| "Guard passes, so the change is safe" | Guards catch regressions, not quality improvements. Passing guards means you didn't break anything — not that you improved anything. |
+| "Let's improve everything at once" | Batch changes can't be isolated. One improvement per commit lets you revert the one that caused a regression. |
+| "The codebase is too messy to measure" | That's exactly why you need baselines. Measurement reveals which mess matters most. |
+| "This refactor is obviously better" | "Obviously better" without metrics is opinion. Measure readability, performance, or maintainability to confirm. |
+
+## Red Flags
+
+- Improvement commits with no before/after metrics in the message
+- Multiple unrelated improvements in a single commit
+- Auto-improve loop running without guard command configured (no safety net)
+- program.md unchanged across many iterations (stale focus, diminishing returns)
+- Improvements that increase code complexity without measured benefit
+- Reverting to fix regressions introduced by "improvements"
+
 ## Notes
 
 - First run auto-scaffolds `scripts/auto-improve/`. Subsequent runs reuse existing program.md (preserves user edits).

skills/flow-code-brainstorm/SKILL.md

@@ -160,3 +160,24 @@ Requirements written to .flow/specs/<slug>-requirements.md
 
 Next step: Run /flow-code:plan .flow/specs/<slug>-requirements.md
 ```
+
+## Common Rationalizations
+
+| Excuse | Reality |
+|--------|---------|
+| "I already know what to build" | Premature certainty is the most expensive mistake. Brainstorming surfaces assumptions you didn't know you had. |
+| "Brainstorming is just talking, not real work" | Brainstorming produces the requirements doc that drives everything downstream. Skip it and you plan against assumptions. |
+| "We don't have time to explore alternatives" | Exploring 3 approaches for 15 minutes is cheaper than rebuilding after choosing wrong on day one. |
+| "The first idea is usually right" | First ideas are anchored on recent experience. Pressure-testing reveals options that outperform the obvious choice. |
+| "Requirements are already in the ticket" | Tickets describe what someone wants, not what should be built. Brainstorming translates desire into actionable constraints. |
+| "Let's just start and iterate" | Iteration without direction is wandering. Brainstorming sets the constraints that make iteration productive. |
+| "This is too small to brainstorm" | Small scope doesn't mean small risk. A 5-minute pressure test on a "simple" feature often reveals hidden complexity. |
+
+## Red Flags
+
+- Jumping straight to /flow-code:plan without exploring requirements
+- Only one approach considered (no alternatives generated or evaluated)
+- Requirements doc has zero constraints or non-goals listed
+- "Open Questions" section is empty (every problem has unknowns)
+- Brainstorm output restates the original request without adding new insight
+- User's actual problem never identified (solution proposed without understanding need)

skills/flow-code-plan-review/SKILL.md

@@ -200,3 +200,24 @@ $FLOWCTL checkpoint restore --epic <EPIC_ID> --json
 ```
 
 **CRITICAL**: For RP, re-reviews must stay in the SAME chat so reviewer has context. Only use `--new-chat` on the FIRST review.
+
+## Common Rationalizations
+
+| Excuse | Reality |
+|--------|---------|
+| "The plan looks reasonable, ship it" | Reasonable-looking plans fail at implementation. Review forces you to find the gaps before code exists. |
+| "We already discussed this verbally" | Verbal agreement evaporates. Written review catches assumptions that felt obvious in conversation but aren't. |
+| "Reviewer doesn't know our codebase" | External perspective catches blind spots. Codebase familiarity causes pattern blindness — fresh eyes find structural issues. |
+| "Review is blocking progress" | Review prevents rework. A 30-minute review saves days of implementing the wrong design. |
+| "The spec is too detailed to review" | Over-detailed specs hide weak architecture behind volume. If it's too complex to review, it's too complex to implement. |
+| "Minor plan issues, we'll fix during implementation" | Plan issues compound during implementation. A wrong assumption in the spec becomes wrong code in every task. |
+| "Just one more iteration and it's perfect" | Diminishing returns are real. Hit the circuit breaker, ship what's good enough, and capture remaining concerns as gaps. |
+
+## Red Flags
+
+- Plan approved without any reviewer reading the actual task specs
+- SHIP verdict with zero questions asked (rubber-stamp review)
+- Review feedback ignored because "we know better"
+- Same structural issue found in implementation that was present in the plan (review missed it)
+- Plan-review skipped because "we're behind schedule"
+- Reviewer only checked formatting, not technical feasibility