challenge
SolidAdversarial verification protocol for claims, plans, and root causes -- refute by default, fresh-context intake, sources-backed, bounded rounds. Runs SYSTEMATICALLY, by claim TYPE (not a stakes judgment), before reporting to the owner any of: a root-cause conclusion, a done/verified claim, an irreversible action (commit/deploy/rm/push), or a 2nd-time fix -- WHETHER inside an APEX task OR in plain conversation. Also runs systematically at every APEX eLicit round and every Verify gate, exactly like sniper runs systematically at eXamine, NO EXCEPTIONS. Do NOT use for: code correctness/lint/type validation (use code-quality/sniper).
Install
Quality Score: 82/100
Skill Content
Details
- Author
- fusengine
- Repository
- fusengine/agents
- Created
- 6 months ago
- Last Updated
- 2 days ago
- Language
- TypeScript
- License
- MIT
Similar Skills
Semantically similar based on skill content — not just same category
challenging
Cross-context adversarial review for deliverables before shipping. Use when producing blog posts, technical recommendations, analysis briefs, code, or any artifact where accuracy matters more than speed. Triggers on "challenge this", "review before shipping", "adversarial pass", "stress test this".
ref-sp-agents-verification-discipline
Portable verification discipline that counters jumping to answers, sycophancy, and overconfidence: enumerate candidate approaches or root causes, route verification by confidence and stakes, prune on evidence, abstain explicitly when nothing can settle a claim. Use when: choosing between approaches or root causes, acting on an unverified claim or assumption, responding when the user challenges or contradicts a conclusion, deciding how much verification a risky or irreversible action needs, or calibrating stated confidence in answers, reviews, and reports.
edge-case-challenger
Challenge a working assumption or a settled decision that nobody re-questions, by running a fixed set of probes against the ONE decision, not by free-associating about what could break. Use when something has worked long enough to feel settled and the user wants it pressure-tested: '여태 이렇게 해왔는데', '이 가정 맞나', '전제를 다시 보자', '엣지 케이스', '스케일업하면?', '이거 언젠가 터지지 않나', 'pressure-test this assumption', 'what breaks at scale', 'challenge this decision', 'is this premise still true', 'stress this at 10x', or when a decision passed review on one axis and no one checked the others.