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.<dimension>" (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

# 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.