/challenge

name: challenge
description: >-
  Adversarial review skill. Use when the user wants to stress-test an idea,
  argument, proposal, or opinion from multiple independent angles. Spawns
  parallel Hydra workers with orthogonal analytical methodologies.

Challenge

Multi-angle adversarial review via isolated Hydra workers. Each worker attacks the same input using a different analytical method, with no visibility into the others' reasoning.

When to use

• User says "challenge this", "stress-test this", "poke holes in this",

"what am I missing", "argue against this", or similar

• User has been discussing a topic and wants independent critical review
• Any argument, proposal, opinion, decision, or design that needs pressure-testing

Step 1: Extract

Summarize the argument/proposal/opinion from the current conversation into a neutral, complete brief. Include:

• The core claim or proposal
• Key supporting reasons the user or you have discussed
• Any constraints or context that are relevant

Do NOT editorialize or signal which parts you think are weak. The summary must be fair — biased summaries defeat the purpose.

Step 2: Spawn 4 workers

Use `hydra spawn` to launch 4 parallel workers. Each worker receives the same summary but a different methodology prompt. Inherit the current terminal's provider via `--worker-type`.

Worker prompts

Each worker prompt must include, in this order: 1. The mandatory preamble below (verbatim) 2. The full summary from Step 1 3. The methodology instructions below (one per worker) 4. Instruction to write findings to `result.json` atomically

Mandatory preamble (prepend to every worker prompt verbatim)

> **SCOPE RULE — strictly enforced.** > Your analysis MUST extend beyond the immediate input. The input is your > starting point, not your boundary. You are required to: > > 1. **Follow every chain.** When you find something, do not note it and > move on. Ask "what does this lead to?" and trace it at least 2-3 > links further. Each link must be a concrete step, not a vague worry. > 2. **Search outward.** For every finding, actively look for evidence > from outside the input's immediate context — other fields, other > systems, historical precedents, known failure cases, research, prior > art. If you cannot name a specific external reference, you have not > searched wide enough. > 3. **Refuse shallow answers.** If a finding can be stated in one > sentence with no chain and no external reference, it is not finished. > Deepen it or discard it. > > A review that stays inside the input's own frame is a failure. You will > be evaluated on depth of chains and breadth of external evidence.

**Worker 1 — Counterexample**

> Find concrete cases where this fails, backfires, or produces the > opposite of what is intended. Each case must be specific enough to > verify or reproduce — no abstract objections. Prioritize the most > damaging cases first.

**Worker 2 — Hidden Assumptions**

> Surface everything this takes for granted — every unstated dependency, > every "this just works" that is not actually guaranteed. Assumptions > form chains; each one rests on deeper ones. Trace each chain until > you hit bedrock. An assumption is fragile if reasonable people could > disagree with it, if it depends on conditions that may change, or if > the whole thing collapses without it. Rank from most fragile to most > solid.

**Worker 3 — Mechanism & Second-Order Effects**

> Challenge the mechanism — the chain of steps by which this is supposed > to achieve its goal. Map the full chain from action to intended outcome. > For each link: is it proven or assumed? Could the same input produce a > different output? Are there missing steps? Then keep going past the > intended outcome — what second and third-order effects emerge? What > feedback loops are created? What does this look like after the system > evolves?

**Worker 4 — Boundary & Context Shift**

> Find where this stops being valid. Push along every dimension that > matters until something breaks. Do not just find the breaking point — > follow the chain past it: graceful degradation or catastrophic failure? > When one boundary breaks, what else breaks with it? Then shift context > entirely: would this still hold if the surrounding conditions, the > actors, or the constraints were fundamentally different?

Result contract

Each worker writes `result.json`:

{
  "success": true,
  "summary": "<one-paragraph synthesis of the most critical findings>",
  "findings": [
    {
      "point": "<the specific challenge>",
      "severity": "critical | significant | minor",
      "reasoning": "<why this matters>"
    }
  ],
  "outputs": [],
  "evidence": [],
  "next_action": { "type": "complete", "reason": "Challenge review complete" }
}

Write to `result.json.tmp` first, then atomically rename it to `result.json` only after the JSON is complete.

Step 3: Watch

For each spawned worker, run `hydra watch --agent <agentId>`. This polls the worker's assignment run result until it reaches a terminal state (completed, failed, or terminal dead).

Run all 4 watches in parallel (background bash commands or concurrent tool calls). Do not proceed until all 4 complete.

Step 4: Synthesize

Collect all 4 result files. Present to the user:

1. **Critical challenges first** — anything rated "critical" from any worker, grouped by theme rather than by methodology 2. **Significant challenges** — grouped the same way 3. **Minor observations** — briefly listed

Do NOT defend the original argument while presenting challenges. Present them neutrally. Let the user decide what to address.

Step 5: Converge

After presenting, help the user:

• Decide which challenges are real threats vs acceptable risks
• Strengthen the original argument/proposal where needed
• Identify any challenges that change the conclusion entirely

This step is collaborative — you are no longer adversarial.