菜单
Sub-orchestrator for claims and assertions. Routes to ARAW-based testing with appropriate depth, balance, and supplementary analysis skills.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Route any input through a branching question tree to narrow down the optimal response strategy before writing. Two stages — PERCEIVE (classify input) then ACT (select response). Covers all prompt types.
Generate exhaustive guesses about user input using ALL search methods with coverage tracking. Guessing is SEARCH through possibility space. Tracks space created vs space covered to ensure comprehensive exploration.
Systematically evaluate and select from a set of guesses, options, or possibilities. Combines ARAW analysis with prioritization to determine which guesses are strong, weak, actionable, or eliminable.
Extract hidden assumptions from any content. Surfaces what must be true for claims to hold, enabling deeper analysis.
Sub-orchestrator for analytical requests. Routes to decomposition, systems analysis, comparison, risk assessment, or synthesis based on what kind of analysis is needed.
Assume Right - Deep recursive rightness search. For every claim, assume it's right — find what must follow, then assume THOSE implications are right too. Recurse until bedrock. Track every claim found.
| name | claim - Test a Claim |
| description | Sub-orchestrator for claims and assertions. Routes to ARAW-based testing with appropriate depth, balance, and supplementary analysis skills. |
| output | {"format":"prose"} |
Input: $ARGUMENTS
Before executing, identify which interpretation matches the user's input:
Interpretation 1 — Direct assertion: The user states something as fact ("X is true", "Y causes Z") and it needs testing. Interpretation 2 — Uncertain belief: The user holds a belief with some doubt ("I think X", "Is X true?") and wants it examined. Interpretation 3 — Received wisdom: The user presents something they've heard or read ("People say X", "The conventional view is X") and wants to know if it holds up.
If ambiguous, ask: "Are you asserting this, questioning it, or reporting what others believe?" If clear from context, proceed with the matching interpretation.
Claims are tested, not confirmed. The default posture is skeptical curiosity, not validation. Testing means genuinely trying to break the claim, not finding reasons to agree with it.
Bundled claims must be unbundled. "Remote work is better" contains at least three claims: better for whom, better by what measure, and better under what conditions. Each gets tested separately. The most load-bearing claim goes first.
Untestable claims are restated, not dismissed. "Freedom is the highest value" can't be tested as-is, but its observable consequences can. Convert to testable predictions, then test those.
The user's confidence determines the balance. Confident assertions need harder adversarial testing (push AW). Uncertain doubts need harder supportive testing (push AR). Never match the user's emotional investment — counterbalance it.
Verdicts are earned, not declared. A claim is VALIDATED only when AR evidence reaches bedrock and AW doesn't find fatal flaws at bedrock. "Probably true" is not a verdict — it's a failure to test deeply enough.
The most interesting finding is usually the condition. Most claims are neither universally true nor universally false. The valuable output is: "True when A, false when B, and the crux is whether you're in A or B."
What is being claimed? State it as a single testable sentence.
If the input is vague, restate it precisely before proceeding. A claim must be falsifiable — it must be possible for it to be wrong.
Exception: If the user's confidence is about their own future capability or aspiration ('I can do X', 'I will achieve Y'), the confidence is not evidence of bias — it's a claim about commitment. Test the claim's feasibility, not the user's right to be confident.
Before testing, some claims need additional framing:
→ INVOKE: /araw $ARGUMENTS
Use the depth and balance determined above.
For bundled claims: → Unbundle first, then INVOKE: /araw on the most load-bearing claim → Then INVOKE: /araw on remaining claims if needed
For untestable claims: → Restate as testable prediction first → Then INVOKE: /araw on the restated claim
| Situation | Also invoke |
|---|---|
| Claim is an argument with premises | → /agsk (argument analysis) |
| Claim involves predictions | → /fut (future analysis) |
| Claim involves best/worst outcomes | → /gop, /obo, /ogo |
| Claim seems too easy or obvious | → /obv (obvious check) |
| You suspect self-deception | → /sdc (self-deception check) |
| Claim involves safety | → /saf (safety analysis) |
| Claim involves ethics | → /eth (ethics analysis) |
| Claim could be tested empirically | → /abts (A/B test design) |
| Failure | Signal | Fix |
|---|---|---|
| Confirmation testing | AR much deeper than AW; all claims VALIDATED | Push AW harder — find the genuine weaknesses |
| Unbundling failure | Compound claim tested as single unit | Decompose into atomic claims, test each |
| Vague verdict | "It's complicated" or "it depends" without specifics | State exactly what it depends ON — name the conditions |
| Testing the wrong claim | Lots of analysis but the user's actual question isn't answered | Re-read the input; are you testing what they asked? |
| Definitional dodge | Claim restated until trivially true | Test the version that has real-world implications, not the safe version |
| Balance mismatch | Testing aligns with user's confidence instead of counterbalancing | If user is confident, push AW. If doubtful, push AR. |
| Depth | Scope | Floor |
|---|---|---|
| 1x | Quick test — one AR/AW pass on the main claim | 5 claims, 12 findings |
| 2x | Standard — unbundle, test main claim, note conditions | 7 claims, 20 findings |
| 4x | Thorough — all claims tested, assumptions surfaced | 12 claims, 35 findings |
| 8x | Deep — full unbundling, all claims to bedrock, alternatives derived | 18 claims, 55 findings |
Report:
After the claim is tested, the user may need:
