vibe-anti-rationalization-check
npx machina-cli add skill ash1794/vibe-engineering/anti-rationalization-check --openclawvibe-anti-rationalization-check
LLMs systematically rationalize shortcuts. This skill catches it happening.
When to Use This Skill
- You catch yourself thinking "this is simple enough to skip testing"
- You're about to reduce scope without the user asking
- You notice you're explaining why something "doesn't really need" to be done
- A constraint feels "too strict" and you want to relax it
- You're about to say "in the interest of time..."
When NOT to Use This Skill
- The user explicitly asked to skip something
- You're genuinely unsure if something is needed (ask the user instead)
- The simplification is the user's explicit request
Known Rationalization Patterns
Watch for these thoughts — they're red flags:
| Rationalization | Reality |
|---|---|
| "This is too simple to need tests" | Simple code in complex systems causes the hardest bugs |
| "The user probably doesn't care about this edge case" | Production users will find every edge case |
| "We don't need error handling here" | Internal code fails too, especially during refactors |
| "I'll add that later" | "Later" never comes. Do it now or create a tracked task |
| "This is just boilerplate" | Boilerplate often contains critical correctness constraints |
| "The happy path is enough for now" | The sad path is where real users spend most of their time |
| "It works, so it must be correct" | "Works" and "correct" are different things |
| "This test is redundant" | Redundant tests catch redundant bugs |
| "Let me simplify this requirement" | Simplifying without asking = silently dropping scope |
| "This doesn't need documentation" | If you thought about it for >2 minutes, document why |
Steps
When you detect a rationalization:
- Name it — "I notice I'm rationalizing skipping [X]"
- State the constraint — "The requirement says [specific requirement]"
- Evaluate honestly — Is there a legitimate reason to skip this, or is it laziness?
- Choose:
- If legitimate: Ask the user "Should we skip X because Y?"
- If rationalization: Do the work. Don't mention the temptation.
- If you skipped something without asking: Go back and do it
Output
This skill doesn't produce output — it's a mental discipline check. When triggered, it modifies behavior, not output.
If invoked explicitly by the user, report:
- What rationalizations were detected in recent work
- What was skipped and why
- What should be revisited
Source
git clone https://github.com/ash1794/vibe-engineering/blob/master/skills/anti-rationalization-check/SKILL.mdView on GitHub Overview
Vibe anti-rationalization-check detects shortcut rationalizations that lead to skipping steps, reducing scope, or relaxing constraints. It helps maintain rigor and reduce risk by surfacing these patterns early and guiding appropriate action.
How This Skill Works
The skill monitors reasoning for common rationalization signals such as skipping tests, shrinking scope, or relaxing constraints. When a signal is detected, it does not change outputs by itself but triggers a disciplined flow: name the rationalization, restate the constraint, evaluate legitimacy, and either escalate to user input or complete the work with justification. This is a mental discipline check, not a content generator, and when triggered it modifies behavior rather than output.
When to Use It
- You catch yourself thinking this is simple enough to skip testing
- You're about to reduce scope without the user asking
- You notice you're explaining why something doesn't really need to be done
- A constraint feels too strict and you want to relax it
- You're about to say in the interest of time
Quick Start
- Step 1: When you detect a rationalization, name it clearly
- Step 2: State the constraint or requirement you are questioning
- Step 3: Decide to ask the user or do the work; if you skipped, revisit and complete
Best Practices
- Name the rationalization as soon as you detect it
- Restate the constraint or requirement precisely
- Evaluate honestly whether skipping is legitimate or laziness
- If legitimate, ask the user for confirmation before skipping
- If rationalization is present, do the work and document the justification; if something was skipped, revisit
Example Use Cases
- Assuming this is simple enough to skip tests and removing test coverage
- Attempting to reduce scope without user prompt or approval
- Claiming an edge case does not matter and ignoring it
- Saying you will add that later and leaving it undone
- Calling boilerplate unnecessary to save time and skipping it
