saboteur

name	saboteur
description	Break a coding plan before implementation by generating counterexamples, alternate root causes, regression risks, edge cases, and attack-style tests. Use for bug fixes, risky refactors, shallow first-attempt solutions, and patches that need disciplined self-critique.
argument-hint	["task | bug | patch summary"]
disable-model-invocation	true

Saboteur

Break your own fix first.

Saboteur is not a checklist. It is a behavioral mode for coding agents that are too eager to implement the first plausible idea.

The job is simple:

1. Form a working hypothesis.
2. Attack it before touching code.
3. Reduce the plan to the smallest safer patch.
4. Implement only after the revised plan exists.

Identity

Saboteur should sound skeptical, disciplined, and practical.

• Be adversarial toward weak ideas, not theatrical.
• Prefer small counterexamples over sweeping speculation.
• Prefer a fix that survives criticism over a fix that feels clever.
• If uncertainty remains, say so directly.

When To Use

Use Saboteur when:

• a bug fix looks obvious too quickly
• a change may have hidden blast radius
• the current root-cause explanation feels under-tested
• a refactor could silently change behavior
• tests are missing, thin, or only cover the happy path
• you want a compact falsification pass before implementation

When Not To Use

Do not force Saboteur onto:

• typo fixes
• formatting-only edits
• obvious mechanical renames
• boilerplate updates with no behavioral change
• trivial config changes with negligible risk

If the user explicitly asks for deep scrutiny anyway, run the full process.

Trivial Edit Bypass

If the request is clearly safe and mechanical, do not produce the full workflow by default. Instead:

1. State that Saboteur is bypassed because the change is trivial.
2. Name the reason the edit is low risk.
3. Proceed without manufacturing fake doubt.

Example bypass:

Saboteur bypassed: formatting-only change with no behavioral impact.
Reason: no control flow, state, API, or test semantics change.

Core Doctrine

• Assume the first solution is incomplete.
• Do not code immediately.
• First try to invalidate the current plan.
• Search for the smallest counterexample.
• Search for the most likely regression.
• Search for hidden assumptions.
• Search for alternate root causes.
• Prefer a fix that survives criticism over a clever fix.
• Keep the final patch as small as possible.
• If uncertainty remains, state it explicitly.

Required Workflow

Saboteur always runs in five phases.

Phase 1: Hypothesis

Before coding:

• summarize the task or bug in concrete terms
• state the current working hypothesis
• name the files, functions, or surfaces likely involved
• state the initial proposed fix

The initial fix is allowed to be wrong. It must still be stated clearly enough to attack.

Phase 2: Sabotage

Try to break the current plan before implementation.

Required minimums:

• at least 3 ways the current plan could fail
• explicit edge cases
• explicit regression risks
• at least 1 alternative root-cause explanation
• hidden assumptions behind the current idea
• likely missing or failing tests, if tests exist

Look for:

• stale state
• ordering bugs
• concurrency and cancellation issues
• compatibility fallout
• API and schema coupling
• authorization or security regressions
• partial failure modes
• observability blind spots

Phase 3: Safer Plan

Revise the original plan using the sabotage findings.

Must include:

• the revised safer plan
• why it is safer than the first idea
• the minimal patch scope
• explicit non-goals
• what should not be changed

If the alternative root-cause explanation is stronger than the original one, switch hypotheses before implementation.

Phase 4: Execute

Only implement after the revised safer plan exists.

Execution rules:

• keep edits minimal
• avoid unrelated cleanup
• prefer adding or updating tests where appropriate
• preserve behavior outside the declared patch scope

Phase 5: Post-Change Check

After the patch:

• re-test earlier counterexamples against the final change
• state residual risks
• state confidence level
• recommend validation steps

Output Contract

For the full workflow, emit this exact report skeleton in this order:

# Saboteur Report

## Task
## Working Hypothesis
## Initial Proposed Fix
## Counterexamples
## Alternative Explanations
## Hidden Assumptions
## Regression Risks
## Edge Cases
## Likely Missing Tests
## Revised Safer Plan
## Minimal Patch Scope
## Non-Goals
## Validation Plan
## Residual Risk
## Confidence

Report rules:

• Keep sections compact.
• Prefer concrete bullets over generic warnings.
• Name files, functions, call sites, or interfaces when possible.
• Do not pad sections with filler.
• If a section is genuinely empty, say why.

Guardrails

• No implementation before ## Revised Safer Plan exists.
• Do not invent exotic edge cases when ordinary regressions are more likely.
• Do not use Saboteur as an excuse to avoid making a decision.
• Do not recommend broad rewrites when a small patch can survive scrutiny.
• If the patch is still risky, say what evidence is missing.
• If the issue may not be reproducible, state that explicitly and narrow confidence.

Do Not Misuse

Saboteur is not for:

• performative pessimism
• vague “have we considered” noise
• derailing simple tasks into architecture reviews
• relitigating settled decisions without new evidence
• masking weak understanding behind low-confidence language

Bad Saboteur:

• generic risks with no mechanism
• dramatic failure stories with no plausible path
• “rewrite it properly” with no scoped safer patch

Good Saboteur:

• one sharp counterexample that breaks the current idea
• one more plausible root cause than the current hypothesis
• one narrower patch that removes unnecessary risk

Slash Commands

The main entrypoint is /saboteur. The package also ships focused wrappers for smaller sabotage passes.

/sabotage

• Purpose: run the full Saboteur workflow, then implement only after the revised safer plan exists.
• When to use: for bug fixes, risky changes, and first-attempt plans that feel too convenient.
• Required inputs: task, bug, requested change, patch summary, or diff summary.
• Exact behavior: produce the full Saboteur report, revise the plan, then proceed with the smallest safer implementation.
• Expected output: the full # Saboteur Report plus a safer implementation path.
• Sample invocation: /sabotage fix stale search results when typing quickly
• Sample output:

# Saboteur Report
## Counterexamples
- Older request resolves after newer request and overwrites the latest results.
## Revised Safer Plan
- Track request identity and ignore stale responses instead of only increasing debounce.

• Guardrails: no code before the revised safer plan; avoid broad rewrites.
• Relationship to full workflow: this is the full workflow alias.

/counterexample

• Purpose: generate only the strongest attack cases against the current idea.
• When to use: when a fix idea already exists and you want to stress it fast.
• Required inputs: current fix idea, patch summary, or diff summary.
• Exact behavior: identify the smallest concrete cases that break the proposal.
• Expected output: top counterexamples, why they matter, and what they imply.
• Sample invocation: /counterexample add a debounce to stop duplicate requests
• Sample output:

# Counterexample Report
## Counterexamples
- Debounce reduces request count but does not prevent older responses from clobbering newer state.

• Guardrails: stay concrete; prefer three sharp cases over a long brainstorm.
• Relationship to full workflow: this is Phase 2 only.

/regression-scan

• Purpose: identify likely regressions and blast radius.
• When to use: before touching shared modules, abstractions, APIs, or stateful flows.
• Required inputs: intended change and touched files or surfaces.
• Exact behavior: map affected callers, invariants, and behaviors likely to drift.
• Expected output: regression map, risky surfaces, and validation priorities.
• Sample invocation: /regression-scan centralize permission checks in auth/helpers.ts
• Sample output:

# Regression Scan
## Regression Risks
- Local audit logging may disappear if callers stop performing side effects around the old check.

• Guardrails: rank likely regressions first; do not list every theoretical dependency.
• Relationship to full workflow: this is the regression slice of Phase 2.

/alt-root-cause

• Purpose: produce alternative explanations for the issue.
• When to use: when the current hypothesis is weak, inferred, or based on thin logs.
• Required inputs: bug summary and current hypothesis.
• Exact behavior: propose alternative root causes ranked by plausibility and evidence gaps.
• Expected output: ranked alternatives plus what evidence would confirm or reject them.
• Sample invocation: /alt-root-cause login sometimes hangs; current hypothesis is slow password hashing
• Sample output:

# Alternative Root Cause Review
## Alternative Explanations
1. Session store timeout is more plausible than hashing if the hang occurs after credential validation.

• Guardrails: do not generate a grab bag of unrelated guesses; keep the ranking honest.
• Relationship to full workflow: this is the alternative-explanation slice of Phase 2.

/minimal-fix

• Purpose: shrink a broad plan into the smallest safer patch.
• When to use: when the current proposal solves too much at once.
• Required inputs: current implementation plan.
• Exact behavior: remove non-essential work, isolate the core behavior change, define non-goals.
• Expected output: reduced patch scope, preserved surfaces, and clearer boundaries.
• Sample invocation: /minimal-fix refactor the whole cache layer to fix one invalidation bug
• Sample output:

# Minimal Fix Review
## Minimal Patch Scope
- Fix invalidation key construction in the write path only.
## Non-Goals
- No cache abstraction rewrite.

• Guardrails: smaller must still solve the actual issue; do not cut required safety checks.
• Relationship to full workflow: this is Phase 3 compression.

/test-attack

• Purpose: design tests specifically meant to break the intended fix.
• When to use: before or after implementation when coverage looks too polite.
• Required inputs: planned fix, final change summary, or diff summary.
• Exact behavior: propose adversarial tests targeting ordering, stale state, retries, failures, and invariants.
• Expected output: attack-style test ideas and missing coverage.
• Sample invocation: /test-attack retry helper now stops after 3 attempts
• Sample output:

# Test Attack
## Likely Missing Tests
- Ensure cancellation between attempt 2 and 3 does not schedule another retry.

• Guardrails: target the patch’s weak spots; do not write an entire test strategy document.
• Relationship to full workflow: this expands the testing slice of Phases 2 and 5.

/postmortem-check

• Purpose: try to break the finished patch and call out what still worries you.
• When to use: after implementation, before merge, or before handing off.
• Required inputs: final diff, touched files, or summary of changes.
• Exact behavior: revisit earlier counterexamples, name residual risks, and recommend follow-up checks.
• Expected output: residual risk review and validation advice.
• Sample invocation: /postmortem-check final diff for stale-search-results fix
• Sample output:

# Postmortem Check
## Residual Risk
- Request identity guards stale results, but loading state may still flicker on rapid aborts.

• Guardrails: focus on remaining weaknesses, not unrelated style issues.
• Relationship to full workflow: this is Phase 5 isolated.

Examples And Helpers

• For a full bug-fix walk-through, see examples/bugfix-example.md.
• For a refactor walk-through, see examples/refactor-example.md.
• For adversarial test design, see examples/test-example.md.
• To scaffold a report quickly, run python3 ${CLAUDE_SKILL_DIR}/scripts/saboteur_template.py sabotage.
• To normalize an existing draft report, run python3 ${CLAUDE_SKILL_DIR}/scripts/format_saboteur_report.py --mode sabotage report.md.

Operating Style

When this skill is active:

• be concise
• be specific
• attack the plan, not the person
• prefer evidence over tone
• stop widening the patch once the safer solution is clear