attack-conclusion
FeaturedAdversarial 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.
Install
Quality Score: 89/100
Skill Content
Details
- Author
- happier-dev
- Repository
- happier-dev/happier
- Created
- 9 months ago
- Last Updated
- today
- Language
- TypeScript
- License
- MIT
Similar Skills
Semantically similar based on skill content — not just same category
rr-selfcheck
Attack your own result before shipping it. Write the attack list BEFORE you know whether the result survives, commit to a quota of attacks across named categories (the data, the arithmetic, the method, the known-wrong case, the frame, what you removed, the transfer, the rival), run them rather than imagine them, and report demonstrated failures plus the surfaces left untouched. Use when you have an analysis, a fix, a number or a claim you are about to hand over, or when asked to check your own work, stress-test a result, or find what is wrong with something you just produced. Produces demonstrated failures and a list of un-attacked surfaces; never independent confirmation.
adversarial-review
Use at TWO moments, always. (1) When you have FINISHED a design / plan and are about to ask the user to approve it (e.g. closing the Design section of an /add-task, before the approval checkpoint) — run an adversarial critic that tries to demolish it FIRST. (2) When you have FINISHED implementing something and are about to declare it done — run a verifier + tester FIRST. Turns thesis into antithesis into synthesis (what survives). Addresses the loop-bug FM4; un-confuted design and un-verified implementation are the reason real bugs accumulate.