/attack-conclusion

name: attack-conclusion
description: Adversarial self-review of your own conclusion, fix, or root-cause verdict before handoff — alternative causes, neighboring cases, blast radius, environment gap, hypothesis lock, subtraction, and a scan for fake-competence patterns. Use as a compact author check before non-trivial handoff and as a structured attack at substantial review or ship boundaries; pair with autoreview only when the selected boundary calls for it.

Attack Your Conclusion

Before handing over a conclusion, switch roles completely: you are no longer the author defending it, you are the reviewer paid to break it, with the same energy spent building it. Full doctrine: `docs/agent-craft.md` §6 and §8.

The test of whether you actually switched roles: did you go looking for evidence that would change your mind, or only re-inspect the evidence that formed the conclusion?

The standard attacks — in order of cheapness, each as a runnable check

1. **Alternative cause or falsifier.** Ask what else could explain the same evidence. When the evidence supports a materially different candidate, name it and run the cheapest discriminating observation; when the mechanism is directly established, do not manufacture a second hypothesis—identify and run the cheapest observation that could falsify the conclusion instead. 2. **Neighboring cases.** The fix works for the reproduced case. Run the case next door: the empty list, the second invocation, the other platform, the resumed session, the concurrent caller. 3. **Blast radius.** What consumes what you changed? Search callers, readers, subscribers, tests, serialized forms. "Nothing else uses this" is a claim — re-derive it, don't assert it. 4. **Environment gap.** Does the conclusion survive where the code actually runs, or only in the harness? Host tests encode the same assumptions the author had. For user-visible behavior, use the risk-appropriate browser/device gate in `skills/happier-testing`. 5. **Hypothesis lock.** Are you explaining the evidence, or explaining your first hypothesis? Re-read the raw evidence pretending you just arrived and have no favorite.

Run the cheap attacks; an attack that is just worry is not an attack. If you cannot state what would falsify the conclusion, it is not a conclusion yet — it is a preference.

Architecture-impact attack

Run this only when the change establishes or moves an owner, crosses package boundaries, introduces persistence or concurrency, materially changes a public interface, or performs a substantial refactor. Skip it for routine local and mechanical work.

Build a compact complexity ledger from the diff and affected callers:

• **Added:** domain concepts, interfaces or seams, dependencies, configuration, persisted state, modes or branches, failure paths, and facts callers must know.
• **Removed:** duplicate decisions, special cases, invalid states, compatibility paths, direct bypasses, lockstep edits, and operational failure modes.

Then test whether the change improves total system locality, leverage, and code health. Added structure is justified when observed domain variation, lifecycle, ownership, or invariants require it and the result removes greater distributed complexity. A large coherent diff can pass this attack; a small local patch can fail it. Report the evidence, not a line-count verdict.

Run a **subtraction attack** on every material new mechanism, dependency, mode, configuration value, wrapper, fallback, abstraction, or parallel path: try removing it while preserving the complete authorized contract. If the behavior already holds, the canonical owner can enforce it more directly, or a standard/platform/existing package facility satisfies every affected surface with lower lifetime cost, the addition is unsupported complexity. Compare concepts, ownership, caller knowledge, invalid states, and failure paths—not lines, files, or tests; this is an in-place lens, not a new lane, report, or gate.

For a changed domain concept, run a **split-brain attack**: search the touched corridor for another active owner, decision, registry, parser/normalizer, reader/writer, bypass, or similar-but-different implementation. A pre-existing same-concept split-brain is a finding, not grandfathered debt. Verify that any remaining compatibility adapter only translates a historical shape and delegates decisions to the canonical owner.

For compatibility-sensitive changes, run a **provenance attack** using `skills/happier-compatibility`: re-derive each retained path from an exact released artifact/tag or applicable predecessor worktree basis, check every claimed reachable old/new direction, and identify shims or tests that preserve only an undeployed intermediary. Reject speculative matrices and fallbacks that are not tied to a reachable seam.

Fake-competence scan

Check the deliverable against the patterns that read as skill and aren't (`docs/agent-craft.md` §8). The highest-frequency ones:

• **Thoroughness theater** — exhaustive coverage of what was easy to check, presented as coverage of the risk. Where are the "if I'm wrong, it's here" spots in the report?
• **Green tests as proof** — green means "didn't break what we previously thought to check", not "correct".
• **Defensive over-engineering** — fallbacks for impossible states are unexamined uncertainty made permanent, and future split-brains.
• **Silent recovery** — an error worked around and not mentioned discards the most informative event of the session.
• **Uniform hedging** — everything marked uncertain so nothing can be wrong; commit where the evidence commits.

Self-check and independent review boundary

Schedule adversarial review with the work at the boundary defined by root `AGENTS.md` and `skills/happier-review`:

• The author runs this compact self-attack in place before every non-trivial handoff and when a hypothesis changes. It creates no separate reviewer, workspace, report, approval gate, or durable status updat