# Challenge > Adversarially challenge the current plan or finding. Assume the direction is wrong and build the strongest case against it. Surfaces blind spots, false assumptions, and unexplored alternatives before execution starts. - Skill: `aryaminus/challenge` (Agent Skill) - Install (CLI): `npx skillmds@latest add aryaminus/challenge` - Raw SKILL.md: https://api.skillmd.com/api/skills/aryaminus/challenge/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - License: Apache-2.0 - Author: aryaminus (https://skillmd.com/u/aryaminus) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/aryaminus/challenge --- # Challenge Skill Adversarially review the current plan or a specific finding. The goal is not to block work — it is to surface the strongest objections *before* execution so they can be addressed, not discovered mid-implementation. Inspired by Paradigma/Flywheel's adversarial review nodes: every knowledge claim should have an adversarial pass that tries to refute it before it propagates downstream. ## When to Use - Before executing a plan with `architectural_scope: true` or `depth >= 5` - When the user asks "what could go wrong", "push back on this", or "devil's advocate" - After `ck_review_submit` on a plan that affects multiple files or core modules - When a finding has been open for multiple sessions and no one has questioned it - Before delegating long-running autonomous work ## Challenge Flow ### Step 1 — Load context Call `ck_context` to load: - The current session, task, and latest approved plan - Open findings (especially `blocked` and `escalated`) - Risk tier and compliance constraints If a specific `review_id` or `rule_id` was passed as an argument, use that as the target. Otherwise challenge the latest approved plan from `planning_context.latest_approved_plan`. ### Step 2 — Extract the hypothesis Look for `hypothesis` and `expected_signal` in the plan refinement. If absent, infer them: - **Hypothesis**: what core assumption does this plan rest on? (e.g. "adding X will fix Y", "this abstraction won't break Z") - **Expected signal**: what would confirm the hypothesis is correct? State both explicitly before challenging. If you cannot reconstruct a hypothesis, that itself is the first challenge: **"This plan has no falsifiable hypothesis."** ### Step 3 — Run the adversarial pass For each dimension below, generate the strongest objection you can. Do not hedge — argue as if you are trying to kill the plan. #### A. Assumption inversion List the top 3 assumptions the plan makes. For each, ask: "What if this is false?" If any assumption being false would make the plan fail or significantly change the approach, flag it. #### B. Scope creep signal Look at `scope_estimate`. Is `architectural_scope` underreported? Are there more files likely to be touched than `files_touched_estimate` suggests? Flag any evidence that the real diff will be larger than claimed. #### C. Contradicted findings Check existing findings. Does any open finding (status `open` or `blocked`) directly contradict or undermine the plan? List them with their `rule_id`. #### D. Missing alternatives Look at `options_considered` and `rejected_options`. Is there a viable approach that was never considered? Describe it in one sentence and state why it might be better. #### E. Validation gap Look at `validation_plan`. Is there a scenario where all validation steps pass but the plan still fails in production? Describe it. #### F. Hallucination propagation risk If this plan produces outputs that downstream tasks will depend on — identify what those outputs are and whether they are verifiable. Flag any output that downstream work will treat as ground truth but that has not been independently verified. ### Step 4 — Score the challenge Summarize findings as: ``` STRONG objections (would change the plan): N MODERATE objections (should be addressed): N WEAK objections (worth noting, not blocking): N ``` If `STRONG >= 1`: recommend **blocking execution** and re-submitting the plan with the objections addressed. If `STRONG == 0, MODERATE >= 2`: recommend **addressing before execution starts**, not blocking. If `STRONG == 0, MODERATE <= 1`: recommend **proceeding** with the noted caveats. ### Step 5 — Record findings For each STRONG or MODERATE objection, call `ck_finding` with: - `category`: `"challenge"` - `severity`: `"high"` for STRONG, `"medium"` for MODERATE - `rule_id`: `"challenge."` (e.g. `"challenge.assumption_inversion"`, `"challenge.validation_gap"`) - `plain_message`: the objection in one sentence - `decision`: `"warn"` (never block automatically — the human decides) - `extends_finding_id`: the finding this challenge responds to, if applicable - `contradicts_finding_id`: any existing finding this objection overturns, if applicable Do NOT record WEAK objections as findings. Include them only in the report. ### Step 6 — Output the report ```markdown # Challenge Report **Target:** [plan title or finding rule_id] **Hypothesis:** [stated or inferred] **Expected signal:** [stated or inferred, or "not specified"] ## Verdict: [BLOCK | ADDRESS BEFORE EXECUTION | PROCEED WITH CAVEATS] ## Strong objections [list, or "None"] ## Moderate objections [list, or "None"] ## Weak objections / notes [list, or "None"] ## Findings recorded [list of ck_finding IDs created, or "None"] ``` ## Integration with ck_review_submit After a challenge that clears (no STRONG objections), the caller can re-submit the plan with the moderate objections addressed. The new submission should include: - `hypothesis`: the hypothesis now made explicit - `expected_signal`: the observable confirmation criterion - Prior challenge findings referenced in `alignment_context` This creates a traceable chain: plan → challenge → revised plan → execution. ## What this skill does NOT do - It does not rewrite or fix the plan. It challenges it. - It does not block execution directly. It records findings and gives a recommendation. - It does not repeat static policy checks (`ck_validate` covers those). It targets reasoning and assumption errors.