Skip to content
cccskills
FreePublished on GitHub

vibe-anti-rationalization-check

Catches shortcuts and reward hacking — weakening or deleting tests to make them pass, hard-coding expected outputs, silently dropping requirements, or claiming work is done without running it. Use before declaring a task complete and whenever a test or requirement feels like it's in the way.

The English summary is being prepared. Showing the original description.

See how to install

Files included (1)

  • SKILL.md3.9 KB

SKILL.md (original)

Review the instructions the agent will receive before you install.

vibe-anti-rationalization-check

Current models rarely skip work out of laziness. The failure that remains is subtler: satisfying the check instead of the goal. A test gets special-cased, an assertion loosened, a requirement quietly narrowed, and the summary says "done." This skill catches that and makes it visible.

When to Use This Skill

  • Before saying a task is complete, fixed, or passing
  • A test is failing and the quickest route to green is changing the test
  • You're about to narrow a requirement the user stated
  • You're about to write "in the interest of time...", "for now...", or "simplified"
  • You catch yourself explaining why something "doesn't really need" to be done

When NOT to Use This Skill

  • The user explicitly asked to skip or simplify something
  • The test itself is genuinely wrong (fix it, but say so explicitly and explain why)
  • You're genuinely unsure whether something is needed (ask the user instead)

Reward-Hacking Patterns

PatternWhat it looks likeDo instead
Test tamperingLoosening an assertion, adding a skip, deleting a failing case, raising a toleranceFix the code. If the test is wrong, change it and say why in the summary.
Special-casingif input == <test fixture>: return <expected> or detecting the test environmentImplement the general behavior.
Hard-coded outputsReturning the literal value a test expectsCompute it.
Mocking away the subjectMocking the very function the test is supposed to exerciseMock only external boundaries.
Silent scope cutImplementing 4 of 5 requirements and summarizing as "done"Finish, or list exactly what is missing.
Unverified claim"This should fix it" / "Tests pass" without running themRun the command and quote the result.
Budget looseningRaising a performance/size budget or threshold because the check failedFix the code; changing a budget needs a spec change and a stated reason
"It's flaky"Re-running until green, adding a retryFind the variable (vibe-flake-root-cause)
Self-approvalRecording a human's approval on their behalf, or treating a code comment as sign-offPoint the human to the item to approve (vibe-publication-leak-guard)
Error swallowingcatch {} / except: pass to stop a crashHandle the specific error, or let it surface.
Deferred forever"I'll add that later" with no tracked follow-upDo it now, or create a tracked issue/TODO with a reference.

Steps

  1. Diff check — Review your own diff for the patterns above. Pay particular attention to changes under test directories, in CI config, and in lint/skip annotations.
  2. Requirement check — Re-read the original request. List every requirement and mark each one done or not done.
  3. Evidence check — For each "works" or "passes" claim, is there command output from this session behind it?
  4. Resolve:
    • A legitimate reason to deviate → ask the user, or state it prominently in the summary
    • A rationalization → do the work
  5. Disclose — If anything was skipped, weakened, or changed in a test, say so plainly in the final summary. Never hide a shortcut.

Output

When run as a self-check, report only if something was found. When invoked explicitly:

Rationalization Check

#PatternLocationResolution
1Test tamperingauth_test.go:88 tolerance 0.01 → 0.5Reverted; fixed rounding in calc.go

Requirements: X/Y met — [list any not met] Unverified claims: [none / list]

Reviews

No reviews yet. Tell others what you thought.

Comments

No login needed. Share how it worked for you, ask a question, or note where it did not run.

No comments yet. Be the first to write one.

Comments are published right away. Do not include personal information such as email addresses or phone numbers. Up to 2 URLs.

0 / 1,000 characters

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

More skills from this repository

Validates completed work against defined acceptance criteria. Use after completing a task that has specific success criteria defined in issues, specs, or task descriptions.

The English summary is being prepared. Showing the original description.

ash1794/vibe-engineering164Updated Oct 8, 2026

Generates edge case, failure mode, and spec-driven test cases. Covers boundary values, nil inputs, concurrency, resource exhaustion, malformed data, and requirement-linked traceability tests. Use after happy-path tests exist and before claiming coverage is complete, when requirements lack tests, or before a security review.

The English summary is being prepared. Showing the original description.

ash1794/vibe-engineering164Updated Oct 8, 2026

Safely integrates commits from parallel agent branches using sequential cherry-pick. Use after parallel work completes in isolated branches or worktrees.

The English summary is being prepared. Showing the original description.

ash1794/vibe-engineering164Updated Oct 8, 2026

Audits tests for concurrency safety — race conditions, shared mock state, cleanup ordering. Use when writing tests that involve goroutines, async operations, or shared mutable state.

The English summary is being prepared. Showing the original description.

ash1794/vibe-engineering164Updated Oct 8, 2026

Enforces tiered test coverage standards with three dimensions — line coverage by tier, spec-to-test traceability, and spec-to-code implementation mapping. Use before claiming code is complete.

The English summary is being prepared. Showing the original description.

ash1794/vibe-engineering164Updated Oct 8, 2026

Extracts and records architectural decisions from diffs, conversation context, and explicit choices. Supports automatic extraction from staged changes, deduplication against prior decisions, and persistent ADR-format logging with spec traceability. Use after a significant design or architecture choice, before committing a diff that embeds implicit decisions, or when the same question keeps resurfacing.

The English summary is being prepared. Showing the original description.

ash1794/vibe-engineering164Updated Oct 8, 2026

See all skills by ash1794

Report a problem with this skill