Menu
Pressure-test a claim, recommendation, or assumption. Defaults to skepticism.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Deep single-model analysis of a topic, question, or architectural decision.
Multi-model consensus workflow. Role-assigned models converge toward a shared recommendation through two rounds of evaluation and reconciliation.
Adversarial multi-model evaluation. Models argue for, against, and neutrally about a subject.
Multi-model panel review. Multiple models review independently, then findings are synthesized.
Full Forge QA checklist in Docker container. Use for release validation or comprehensive verification of all Forge features.
Review design documents, specs, and technical writing for completeness and consistency.
| name | forge:challenge |
| description | Pressure-test a claim, recommendation, or assumption. Defaults to skepticism. |
| argument-hint | [claim or objection] |
| effort | high |
| allowed-tools | Read, Grep, Glob, Bash, Agent |
Pressure-test a claim, recommendation, or assumption with adversarial skepticism.
/forge:challenge [claim]
| Argument | Required | Description |
|---|---|---|
claim | Optional | Statement, objection, or question to pressure-test (inferred if empty) |
$ARGUMENTS is the claim to challenge. It should be a statement, objection, question, or instruction -- not a bare file
path. If it starts with @, strip the prefix (Claude Code file reference syntax).
If $ARGUMENTS is empty, infer the claim from the immediately preceding conversation context: the last recommendation,
decision, assertion, or proposed change. Only ask the user what to challenge if no prior claim is identifiable from
context.
Never ask the user to clarify if a claim was provided. If $ARGUMENTS contains anything, proceed immediately.
This skill defaults to skepticism, not balance. The starting posture is adversarial: assume the claim may be wrong and try to prove that. Only soften to a balanced conclusion if the skeptical case genuinely fails.
If the challenge starts from a neutral or symmetrical frame, it provides no value over a standard analysis. The entire point is targeted pressure-testing.
Execute these steps:
Restate the claim precisely. What exactly is being asserted? Remove ambiguity.
Assume it is wrong. Actively search for:
Investigate the repo. Use Read, Grep, and Glob to find evidence. Check whether the claim holds against actual code, tests, configuration, and documented decisions. Do not reason from first principles alone when evidence is available.
Test the skeptical case. Is the counterargument strong, or does it fall apart under scrutiny?
If the skeptical case fails, explain clearly why the original claim survives. This is a valid and useful outcome -- the claim is stronger for having been tested.
Return a verdict:
Present the challenge as:
## Challenge: [restated claim]
### Skeptical Case
[The strongest argument against the claim, with evidence]
### Counter-Evidence
[What supports the claim, why the skeptical case fails (if it does)]
### Verdict: [verdict]
[1-2 sentence summary of the conclusion]