---

name: strict-enforcement description: Use when running claudikins-kernel:verify, checking implementation quality, deciding pass/fail verdicts, or enforcing cross-command gates — requires actual evidence of code working, not just passing tests allowed-tools:

• Read
• Grep
• Glob
• Bash
• WebFetch
• Skill
• mcp__plugin_claudikins-tool-executor_tool-executor__search_tools
• mcp__plugin_claudikins-tool-executor_tool-executor__get_tool_schema
• mcp__plugin_claudikins-tool-executor_tool-executor__execute_code

---

Strict Enforcement Verification Methodology

When to use this skill

Use this skill when you need to:

• Run the claudikins-kernel:verify command
• Validate implementation before shipping
• Decide pass/fail verdicts
• Check code integrity after changes
• Enforce cross-command gates

Core Philosophy

"Evidence before assertions. Always." - Verification philosophy

Never claim code works without seeing it work. Tests passing is not enough. Claude must SEE the output.

The Three Laws

1. See it working - Screenshots, curl responses, CLI output. Actual evidence.
2. Human checkpoint - No auto-shipping. Human reviews evidence and decides.
3. Exit code 2 gates - Verification failures block claudikins-kernel:ship. No exceptions.

Verification Phases

Phase 1: Automated Quality Checks

Run the automated checks first. Fast feedback.

Flaky Test Detection (C-12):

CopyTest fails?
├── Re-run failed tests
├── Pass 2nd time?
│   └── Yes → STOP: [Accept flakiness] [Fix tests] [Abort]
└── Fail 2nd time?
    ├── Run isolated
    └── Still fail? → STOP: [Fix] [Skip] [Abort]

Phase 2: Output Verification (catastrophiser)

This is the feedback loop that makes Claude's code actually work.

Fallback Hierarchy (A-3):

If primary method unavailable, fall back:

1. Start server + screenshot (preferred for web)
2. Curl endpoints (preferred for API)
3. Run CLI commands (preferred for CLI)
4. Run tests only (fallback)
5. Code review only (last resort)

Timeout: 30 seconds per verification method (CMD-30).

Phase 3: Code Simplification (Optional)

After verification passes, optionally run cynic for polish.

Prerequisites:

• Phase 2 (catastrophiser) must PASS
• Human approves: "Run cynic for polish pass?"

cynic Rules:

• Preserve exact behaviour (tests MUST still pass)
• Remove unnecessary abstraction
• Improve naming clarity
• Delete dead code
• Flatten nested conditionals

If tests fail after simplification:

• Log failure reasons
• Show human
• Proceed anyway (A-5) with caveat

See cynic-rollback.md for recovery patterns.

Phase 4: Klaus Escalation

If stuck during verification:

CopyIs mcp__claudikins-klaus available? (E-16)
├── No →
│   Offer: [Manual review] [Ask Claude differently] (E-17)
│   Fallback: [Accept with uncertainty] [Max retries, abort] (E-18)
└── Yes →
    Spawn klaus via SubagentStop hook

Phase 5: Human Checkpoint

The final gate. Present comprehensive evidence.

CopyVerification Report
-------------------
Tests:  ✓ 47/47 passed
Lint:   ✓ 0 issues
Types:  ✓ 0 errors
Build:  ✓ success

Evidence:
- Screenshot: .claude/evidence/login-flow.png
- API test: POST /api/auth → 200 OK
- CLI test: mycli --help → exit 0

[Ready to Ship] [Needs Work] [Accept with Caveats]

Human decides. If approved, set unlock_ship = true.

Rationalizations to Resist

Agents under pressure find excuses. These are all violations:

All of these mean: Get evidence. Human decides. No shortcuts.

Red Flags — STOP and Reassess

If you're thinking any of these, you're about to violate the methodology:

• "It should work because..."
• "The tests pass so..."
• "I'm confident that..."
• "It worked before..."
• "The types check so..."
• "I'll just skip verification this once"
• "Human will approve anyway"
• "Evidence isn't necessary for this change"

All of these mean: STOP. Get evidence. Present to human. Let them decide.

Exit Code 2 Pattern (CRITICAL)

The verify-gate.sh hook enforces the gate:

Copy# Both conditions MUST be true
ALL_PASSED=$(jq -r '.all_checks_passed' "$STATE")
HUMAN_APPROVED=$(jq -r '.human_checkpoint.decision' "$STATE")

if [ "$ALL_PASSED" != "true" ]; then
  exit 2  # Blocks claudikins-kernel:ship
fi

if [ "$HUMAN_APPROVED" != "ready_to_ship" ]; then
  exit 2  # Blocks claudikins-kernel:ship
fi

File Manifest (C-6):

At verification completion, generate SHA256 hashes of all source files:

Copyfind . \( -name '*.ts' -o -name '*.py' -o -name '*.rs' \) \
  | xargs sha256sum > .claude/verify-manifest.txt

This lets claudikins-kernel:ship detect if code was modified after verification.

Cross-Command Gate (C-14)

claudikins-kernel:verify requires claudikins-kernel:execute to have completed:

Copyif [ ! -f "$EXECUTE_STATE" ]; then
  echo "ERROR: claudikins-kernel:execute has not been run"
  exit 2
fi

This enforces the claudikins-kernel:outline → claudikins-kernel:execute → claudikins-kernel:verify → claudikins-kernel:ship flow.

Agent Integration

Both agents run with context: fork and background: true.

See agent-integration.md for coordination patterns.

State Tracking

verify-state.json

Copy{
  "session_id": "verify-2026-01-16-1100",
  "execute_session_id": "execute-2026-01-16-1030",
  "branch": "execute/task-1-auth-middleware",
  "phases": {
    "test_suite": { "status": "PASS", "count": 47 },
    "lint": { "status": "PASS", "issues": 0 },
    "type_check": { "status": "PASS", "errors": 0 },
    "output_verification": { "status": "PASS", "agent": "catastrophiser" },
    "code_simplification": { "status": "PASS", "agent": "cynic" }
  },
  "all_checks_passed": true,
  "human_checkpoint": {
    "decision": "ready_to_ship",
    "caveats": []
  },
  "unlock_ship": true,
  "verified_manifest": "sha256:...",
  "verified_commit_sha": "abc123..."
}

Anti-Patterns

Don't do these:

• Trusting test results without seeing code run
• Skipping output verification because "tests pass"
• Auto-approving verification without human checkpoint
• Modifying code after verification passes
• Ignoring flaky test warnings
• Proceeding when lint/type checks fail

Edge Case Handling

References

Full documentation in this skill's references/ folder:

• verification-checklist.md - Complete verification checklist
• red-flags.md - Common rationalisation patterns
• agent-integration.md - How catastrophiser and cynic coordinate
• advanced-verification.md - Complex verification scenarios
• test-timeout-handling.md - When tests hang (S-13)
• lint-fix-validation.md - Validating auto-fix safety (S-14)
• verification-method-fallback.md - Fallback strategies (S-15)
• type-check-confidence.md - Interpreting type results (S-16)
• cynic-rollback.md - Rolling back failed simplifications (S-17)
• verify-state-compression.md - State management for large projects (S-18)