/with-anti-rationalization

name: with-anti-rationalization
promoted_to: testing
description: "Anti-rationalization enforcement for maximum-rigor task execution."
user-invocable: false
argument-hint: "<task>"
allowed-tools:
  - Read
  - Write
  - Bash
  - Grep
  - Glob
  - Edit
  - Task
routing:
  triggers:
    - "maximum rigor"
    - "anti-rationalization"
    - "strict verification"
    - "strict mode"
    - "no shortcuts"
  category: process
  pairs_with:
    - testing

Anti-Rationalization Enforcement Skill

Overview

This skill operates as a composable modifier that wraps any task with explicit anti-rationalization enforcement. It implements the **Gate Enforcement** architectural pattern—every phase transition requires evidence, every completion claim requires proof—with **Pressure Resistance** embedded to prevent quality erosion under time or social pressure.

This skill is not a substitute for domain-specific methodologies (debugging, refactoring, testing have their own skills). Instead, it layers anti-rationalization checks on top of whatever task you're executing. It adds intentional overhead for safety on critical work where shortcuts cause harm.

---

Instructions

Phase 1: LOAD PATTERNS

**Goal**: Load all anti-rationalization patterns relevant to the task before starting work.

**Constraint**: Full pattern loading is mandatory because domain-specific patterns catch rationalizations that the core set misses.

**Step 1: Identify task domain**

Classify the task to determine which domain-specific patterns apply:

| Domain | Pattern to Load | |--------|----------------| | Any task | `anti-rationalization-core.md` | | Code review | `anti-rationalization-review.md` | | Testing | `anti-rationalization-testing.md` | | Security | `anti-rationalization-security.md` | | Multi-phase work | `gate-enforcement.md` | | User pressure detected | `pressure-resistance.md` | | Pre-completion | `verification-checklist.md` |

**Step 2: Load and acknowledge patterns**

Read the identified shared-pattern files. Internalize the rationalization tables and enforcement rules. **Constraint**: State explicitly which patterns were loaded and why—this creates accountability and prevents performative checking.

**Gate**: All relevant patterns are loaded and acknowledged. Proceed only when you can articulate why each pattern applies. Rubber-stamp gate checks fail the purpose of the skill, so explain why each pattern is relevant before moving on.

Phase 2: EXECUTE WITH ENFORCEMENT

**Goal**: Run the underlying task with anti-rationalization checks at every transition.

**Constraint**: This skill wraps other methods. For debugging or refactoring, use this action: Call the Skill tool with `workflow`. Run its `systematic-debugging` or `systematic-refactoring` pipeline. The anti-rationalization layer adds checks on top, not instead of them.

**Step 1: Delegate to appropriate methodology**

Identify the work type. If an indexed skill owns the method, use the exact Skill-tool call contract. If a workflow pipeline owns it, call `workflow` and select the pipeline. Anti-rationalization enforcement amplifies the method; it does not replace it.

**Step 2: At each phase transition, run gate check**

For each transition, verify: 1. All exit criteria met 2. Evidence documented (not just claimed) 3. Anti-rationalization table reviewed against patterns 4. No rationalization detected

**Constraint - Pressure Resistance**: If the user requests skipping a step: 1. Acknowledge the request 2. Explain why the step matters (one sentence) 3. Proceed with the step 4. If user insists on a non-security matter, note the risk and comply 5. **Never skip security-sensitive steps**—security shortcuts are non-negotiable. Document refusal and reasoning.

Then run a rationalization scan:

• Am I assuming without verifying?
• Skipping because it "looks right"?
• Rushing from perceived pressure?
• Calling something "not applicable" when really skipping?
• Treating "basically passes" as "passes"?

If any answer is YES: STOP and address the rationalization before proceeding.

**Constraint - Proportionate Rigor**: Scale check depth to task risk. Critical production changes get full ceremony. A three-file refactor gets lighter gates. Never zero—apply at least proportionate rigor.

**Gate**: Task phases executed with all gate checks passing. Proceed only when gate passes.

Phase 3: VERIFY WITH FULL CHECKLIST

**Goal**: Verify completion with the full verification checklist and anti-rationalization self-check.

**Step 1: Run verification checklist**

| Check | Verified? | Evidence | |-------|-----------|----------| | All stated requirements addressed | [ ] | [specific evidence] | | Tests pass (if applicable) | [ ] | [test output] | | No regressions introduced | [ ] | [existing test output] | | Error handling in place | [ ] | [error paths tested] | | Code compiles/lints | [ ] | [build output] | | Anti-rationalization table reviewed | [ ] | [self-check completed] |

**Constraint**: Every check requires actual evidence, not claims. "Code looks right" is not evidence. "Tests should pass" is not evidence. Test output screenshot is evidence.

**Step 2: Run completion self-check**

## Completion Self-Check

1. [ ] Did I verify or just assume?
2. [ ] Did I run tests or just check code visually?
3. [ ] Did I complete everything or just the "important" parts?
4. [ ] Would I bet 100 dollars this works correctly?
5. [ ] Can I show evidence (output, test results)?

If ANY answer is uncertain, return to Phase 2 and address the gap before continuing. Keep the gate criteria intact until the gap is closed.

**Step 3: Document completion evidence**

Summarize: task description, patterns loaded, gate checks passed, rationalizations detected and addressed, and final evidence proving the task is complete.

**Gate**: All verification steps pass. Self-check is clean. Evidence documented. Task is complete.

---

Examples

Example 1: Critical Production C