
questionably-ultrathink-skill
by snowmead
Questionably UltraThink your most complex tasks combining AoT (Atom of Thoughts) and CoV (Chain of Verification)
SKILL.md
name: questionably-ultrathink-skill description: | Use this skill when facing complex problems requiring rigorous reasoning, systematic decomposition, or factual verification.
Activation triggers:
- "be thorough", "analyze carefully", "make sure this is right"
- Complex multi-part questions
- Architecture or security decisions
- "verify", "double-check", "are you sure"
- High-stakes technical decisions
- Debugging complex issues allowed-tools: [Task, Read, Grep, Glob, WebSearch, WebFetch, AskUserQuestion, Bash, Write]
UltraThink Reasoning Framework
You orchestrate advanced reasoning through isolated, verified atomic solving.
<architecture_overview>
Architecture: Isolated Solving with Factored Verification
The Problem with Traditional Decomposition
Traditional approaches have a critical flaw: the same agent that generates questions also sees all answers. This creates bias contamination - knowledge of other questions/answers influences each response.
The Solution: True Factored Execution
- Graph Generator creates ONLY the DAG of questions (no solving)
- Claim Generator (cove-claim-qs) generates claims and verification questions (NO fact-checking)
- Verifiers research and answer verification questions in COMPLETE ISOLATION (no context about claims)
- Verification Maintainer cross-checks claims vs verifier answers, synthesizes final answer
- Graph Maintainer rewrites dependent questions with solved answers (contraction)
Key insight: Only cove-verifier does actual research/fact-checking. All other agents either generate structure or process verified facts.
Factored Verification Flow (Per Atom)
ORCHESTRATOR (you)
│
├─(1)─► cove-claim-qs
│ │ Input: ATOM_DIR
│ └──► reads question.md
│ writes claims.md
│ writes verifiers/{N}.md (ONLY question, no claim text)
│ returns "CLAIMS_GENERATED"
│
├─(2)─► reads claims.md frontmatter to get claim_count
│
├─(3)─► cove-verifier #1 ──► reads/overwrites verifiers/1.md, returns "VERIFIER_DONE"
├─(3)─► cove-verifier #2 ──► reads/overwrites verifiers/2.md, returns "VERIFIER_DONE" (PARALLEL)
├─(3)─► cove-verifier #N ──► reads/overwrites verifiers/N.md, returns "VERIFIER_DONE"
│ │ Input: VERIFIER_FILE (pre-created with ONLY the question)
│ └──► Verifier has ZERO context about the claim
│
└─(4)─► cove-verification-maintainer
│ Input: ATOM_DIR only
│ (reads claims.md + verifiers/*.md itself)
│
└──► creates answer.md (final answer + verification trace), returns "VERIFICATION_COMPLETE"
Key Principles:
- State is determined by FILE EXISTENCE and CONTENT
question.mdexists → atom createdclaims.mdexists → claims generatedverifiers/{N}.mdexists with question only → pre-created by cove-claim-qs, ready for verifierverifiers/{N}.mdhas "# Answer" section → verification question answeredanswer.mdexists → verification complete, final answer synthesized- You only read: metadata.md (DAG structure), claims.md frontmatter (claim_count), FINAL/answer.md (at end)
- Agents return minimal confirmations - they read/write files themselves
</architecture_overview>
<background_execution>
Background Execution for Pipeline Parallelism
You can run subagents in the background to advance multiple independent paths simultaneously instead of waiting sequentially. This dramatically improves throughput when processing multiple atoms.
When to Use Background Execution
Use run_in_background: true in Task tool calls when:
- Multiple atoms at the same level need verification independently
- Verification for one atom doesn't depend on another atom's verification
- You want to start the next atom's pipeline while waiting on verifier responses
Pattern: Parallel Pipeline Advancement
Instead of waiting for ALL verifiers to complete before moving to the next atom:
SEQUENTIAL (slow):
A1: claims → verifiers → wait → maintainer → done
A2: claims → verifiers → wait → maintainer → done
Use background execution for pipeline parallelism:
PARALLEL PIPELINE (fast):
A1: claims → verifiers (background)
A2: claims → verifiers (background)
A1: check verifier files → maintainer (when ready)
A2: check verifier files → maintainer (when ready)
How to Use Background Execution
Step 1: Spawn verifiers in background
Task tool:
- subagent_type: "questionably-ultrathink:cove-verifier"
- prompt: |
VERIFIER_FILE: .questionably-ultrathink/{session-id}/atoms/{atom-id}/verifiers/{N}.md
- run_in_background: true
This returns immediately with an output_file path and task ID.
Step 2: Continue to next atom
While verifiers run in background, spawn the next atom's claim generator and verifiers.
Step 3: Check on background tasks
Use TaskOutput tool or Read the output file to check if background tasks completed:
TaskOutput tool:
- task_id: "{task_id}"
- block: false # Non-blocking check
Or use Grep to check if verifier files have been completed (have "# Answer" section):
Grep: "# Answer" in .questionably-ultrathink/{session-id}/atoms/{atom-id}/verifiers/{N}.md
Step 4: Process completed verification
Once an atom's verifiers are all complete (all verifier files have "# Answer" sections), spawn its verification maintainer. You can do this while other atoms' verifiers are still running.
Example: Level 0 with A1 and A2
1. Spawn cove-claim-qs for A1 and A2 (parallel, blocking)
- This creates claims.md AND verifiers/{N}.md files (with just questions)
2. Read claims.md frontmatter from A1 → spawn N verifiers with VERIFIER_FILE paths (run_in_background: true)
3. Read claims.md frontmatter from A2 → spawn N verifiers with VERIFIER_FILE paths (run_in_background: true)
4. Check A1 verifiers (Grep for "# Answer" in verifier files)
- If all complete → spawn A1's cove-verification-maintainer
- If not → continue
5. Check A2 verifiers (Grep for "# Answer" in verifier files)
- If all complete → spawn A2's cove-verification-maintainer
- If not → continue
6. Repeat checks until all maintainers have run (all atoms have answer.md)
7. Proceed to contract and next level
Guidelines
- Claim generators can run in parallel but should block - You need
claims.mdto know the claim count - Verifiers should run in background - They're independent and you can advance other atoms while waiting
- Maintainers should block - You need
answer.mdcreated before contracting - Track task IDs - Keep a list of background task IDs so you can check on them
- Balance parallelism - Don't spawn too many background tasks; group by atom for manageable tracking
</background_execution>
<clarification_first>
Phase 0: Clarify Intent First (MANDATORY)
ALWAYS start by assessing if clarification is needed. Before invoking any agents, consider:
- Does the problem have multiple valid interpretations?
- Are scope, constraints, or success criteria unclear?
- Could different priorities lead to different analyses?
If ANY of these apply, use AskUserQuestion BEFORE proceeding.
Skip clarification ONLY when the user's intent is unambiguous. </clarification_first>
<rigor_selection>
Phase 0.5: Select Analysis Rigor
After clarifying intent, determine the analysis depth:
question: "What level of analysis rigor do you need?"
header: "Rigor"
options:
- label: "Standard (Recommended)"
description: "Single pass through the DAG. Good for most questions."
- label: "Thorough"
description: "Re-solves atoms with LOW confidence. Takes longer but more reliable."
- label: "High-Stakes"
description: "Maximum rigor. Re-solves any atom below HIGH confidence. Use for security, architecture, or production decisions."
Skip this question if:
- User already specified rigor in their request (e.g., "be thorough", "this is high-stakes")
- Query is simple enough that standard analysis is obviously sufficient </rigor_selection>
<available_agents>
Available Agents
CRITICAL WARNING: You are the orchestrator. NEVER invoke yourself. Only YOU can spawn agents via the Task tool.
aot-graph-generator
Purpose: Build the DAG structure of atomic questions (NO solving)
Invoke: Task tool with subagent_type: "questionably-ultrathink:aot-graph-generator"
Input: Session ID, rigor level, clarified query
Output: Creates metadata.md + atoms/{id}/question.md for each atom
cove-claim-qs
Purpose: Generate claims, verification questions, AND pre-create verifier files for ONE atomic question (NO fact-checking)
Invoke: Task tool with subagent_type: "questionably-ultrathink:cove-claim-qs"
Input: ATOM_DIR path (reads question.md itself)
Output: Creates claims.md AND verifiers/{N}.md files in atom directory, returns CLAIMS_GENERATED: {atom-id}
CRITICAL: This agent does NOT research or fact-check. It:
- Generates claims and verification questions → writes to
claims.md - Pre-creates verifier files with ONLY the question → writes to
verifiers/{N}.md
The verifier files contain ONLY the verification question (no claim text). This ensures factored verification - verifiers can't be biased toward confirming claims they never see.
cove-verifier
Purpose: Research and answer ONE verification question in complete isolation (no context about the claim being verified)
Invoke: Task tool with subagent_type: "questionably-ultrathink:cove-verifier"
Input: VERIFIER_FILE path (the pre-created file containing ONLY the verification question)
Output: Overwrites VERIFIER_FILE with question + answer + confidence + sources, returns VERIFIER_DONE
CRITICAL: The verifier reads ONLY its pre-created file which contains ONLY the verification question. It has ZERO knowledge of the claim text. This is the key to factored verification - the verifier cannot be biased toward confirming a claim it never sees.
cove-verification-maintainer
Purpose: Cross-check claims against independent verifier answers; synthesize final answer
Invoke: Task tool with subagent_type: "questionably-ultrathink:cove-verification-maintainer"
Input: ATOM_DIR only (reads claims.md and verifiers/*.md itself)
Output: Creates answer.md in atom directory, returns VERIFICATION_COMPLETE: {atom-id}
aot-graph-maintainer
Purpose: Contract unsolved atom questions with solved answers from dependencies
Invoke: Task tool with subagent_type: "questionably-ultrathink:aot-graph-maintainer"
Input: SESSION_DIR only (reads metadata.md and answer.md files to discover solved atoms)
Output: Updates question.md files for dependent atoms, returns CONTRACTION_COMPLETE: {count}
aot-judge (Optional - High-Stakes Only)
Purpose: Evaluate answer quality across atoms at a level (coherence, contradictions, completeness)
Invoke: Task tool with subagent_type: "questionably-ultrathink:aot-judge"
Input: Session ID and level number
Output: Returns JUDGE_RESULT: {PASS|ISSUES} and RE_SOLVE: [{atom-ids or "none"}]
Use when:
- Rigor level is High-Stakes
- After solving all atoms at a level
- When you want additional quality assurance beyond factored verification </available_agents>
<full_pipeline>
Full Pipeline Orchestration
You orchestrate the full pipeline by chaining agent calls. Follow these phases exactly.
<phase_1>
Phase 1: Generate Session & Build Graph
Step 1.1: Generate Session ID
Generate a short session ID (8 characters, alphanumeric):
Example: a1b2c3d4
Step 1.2: Create Session Directory
mkdir -p .questionably-ultrathink/{session-id}/atoms
Note: Verifier directories are created inside each atom folder by the verifier agents.
Step 1.3: Get Timestamp and Invoke Graph Generator
Task tool:
- subagent_type: "questionably-ultrathink:aot-graph-generator"
- prompt: |
SESSION_ID: {session-id}
TIMESTAMP: {ISO timestamp from `date -u`}
RIGOR: {rigor-level}
QUERY: {clarified query}
Expected response: GRAPH_CREATED: {atom-count}
What this produces:
.questionably-ultrathink/{session-id}/metadata.mdwith DAG structure (immutable).questionably-ultrathink/{session-id}/atoms/{id}/question.mdfor each atom
Step 1.4: Read Metadata
Read the metadata file to get the solve order:
Read: .questionably-ultrathink/{session-id}/metadata.md
Extract solve_order - the list of atoms grouped by level.
</phase_1>
<phase_2>
Phase 2: Iterative Solve Loop with Factored Verification
Process each level in order. State is determined by file existence:
question.mdexists → atom createdclaims.mdexists → claims generated, ready for verificationanswer.mdexists → verification complete
For each level in solve_order:
Step 2a: Check atom states using Glob
For each atom at the current level, check which files exist:
Glob: .questionably-ultrathink/{session-id}/atoms/{atom-id}/claims.md
Glob: .questionably-ultrathink/{session-id}/atoms/{atom-id}/answer.md
This determines where each atom is in the pipeline.
Step 2b: Spawn cove-claim-qs for atoms missing claims.md (PARALLEL)
For atoms where claims.md does NOT exist, spawn the claim generator:
Task tool:
- subagent_type: "questionably-ultrathink:cove-claim-qs"
- prompt: |
ATOM_DIR: .questionably-ultrathink/{session-id}/atoms/{atom-id}
Expected response: CLAIMS_GENERATED: {atom-id}
CRITICAL:
- The agent reads
question.mdand writesclaims.mditself - It generates claims and verification questions only
- It does NOT research or fact-check (cove-verifier does that)
Invoke ALL atoms at the same level in parallel (single message with multiple Task calls).
Step 2c: Read claims.md frontmatter to get claim count
For atoms with claims.md but missing answer.md, read ONLY the frontmatter to get claim_count:
Read: .questionably-ultrathink/{session-id}/atoms/{atom-id}/claims.md
Extract claim_count from frontmatter - this tells you how many verifiers to spawn.
Step 2d: Check which verifiers are complete and spawn for incomplete ones (PARALLEL or BACKGROUND)
The verifier files were pre-created by cove-claim-qs with ONLY the verification question. Check which have been completed (have an Answer section):
Grep: "# Answer" in .questionably-ultrathink/{session-id}/atoms/{atom-id}/verifiers/*.md
Or check file size - pre-created files are small (question only), completed files are larger.
For each INCOMPLETE verifier file (1 to claim_count), spawn a fresh verifier:
Task tool:
- subagent_type: "questionably-ultrathink:cove-verifier"
- prompt: |
VERIFIER_FILE: .questionably-ultrathink/{session-id}/atoms/{atom-id}/verifiers/{N}.md
- run_in_background: true # Optional: enables pipeline parallelism
Expected response: VERIFIER_DONE
CRITICAL:
- The verifier file was pre-created by cove-claim-qs with ONLY the verification question
- The verifier reads this file and has ZERO context about the claim being verified
- It overwrites the file with question + answer + confidence + sources
- This is what makes it "factored" verification - complete isolation
Parallelization options:
-
Parallel within atom (blocking): Invoke ALL verifiers for one atom in parallel (single message with multiple Task calls). Wait for completion before moving to next atom.
-
Background for pipeline parallelism (recommended): Spawn verifiers with
run_in_background: true. This lets you immediately start the next atom's verification while the first atom's verifiers run. Check on background tasks withTaskOutput(block: false) and spawn maintainers as each atom's verifiers complete. See<background_execution>section for details.
Step 2e: Wait for verifiers to complete
For blocking calls: Verifiers return VERIFIER_DONE when complete.
For background calls: Use TaskOutput tool to check completion:
TaskOutput tool:
- task_id: "{task_id from background spawn}"
- block: true # Wait for completion
- timeout: 30000 # 30 second timeout
Or use block: false to check without waiting (for pipeline advancement).
Checking verifier completion: Verifier files at .questionably-ultrathink/{session-id}/atoms/{atom-id}/verifiers/{N}.md are pre-created with just the question. A completed verifier file has an "# Answer" section added by the verifier agent.
Step 2f: Spawn verification maintainer when all verifiers are complete
When all verifier files have been completed (all have "# Answer" sections), spawn the maintainer:
Task tool:
- subagent_type: "questionably-ultrathink:cove-verification-maintainer"
- prompt: |
ATOM_DIR: .questionably-ultrathink/{session-id}/atoms/{atom-id}
Expected response: VERIFICATION_COMPLETE: {atom-id}
The maintainer will:
- Read
claims.mdto get claims and verification questions - Read
verifiers/*.mdfiles from the atom directory - Compare each claim to its verification answer
- Mark claims as VERIFIED, REVISED, REFUTED, or UNCERTAIN
- Synthesize the final answer from verified facts
- Create
answer.mdwith the full verification trace
Step 2g: Contract dependent atoms
After ALL atoms at current level have answer.md, invoke the graph maintainer:
Task tool:
- subagent_type: "questionably-ultrathink:aot-graph-maintainer"
- prompt: |
SESSION_DIR: .questionably-ultrathink/{session-id}
Expected response: CONTRACTION_COMPLETE: {count}
The maintainer will:
- Read
metadata.mdfor the DAG structure - Read
answer.mdfrom solved atoms to get their answers - Update
question.mdfor next-level atoms with "Given..." context
Step 2h: Continue to next level
Repeat 2a-2g for each level until FINAL has answer.md.
</phase_2>
<phase_3>
Phase 3: Synthesize Final Response
After FINAL has answer.md:
Read: .questionably-ultrathink/{session-id}/atoms/FINAL/answer.md
The FINAL atom's answer IS your synthesis - it was designed as the synthesis question. Present this answer to the user with appropriate confidence markers.
You only read FINAL/answer.md - all other atom answers have already been incorporated through contraction. </phase_3>
<rigor_based_iteration>
Rigor-Based Re-Solving
After completing all levels, check confidence based on rigor:
| Rigor Level | Re-solve When | Confidence Threshold |
|---|---|---|
| Standard | Never (single pass) | N/A |
| Thorough | Any atom has LOW confidence | score < 0.4 |
| High-Stakes | Any atom below HIGH confidence | score < 0.7 |
Confidence Score Mapping:
- 0.0 - 0.4 = LOW
- 0.4 - 0.7 = MEDIUM
- 0.7 - 1.0 = HIGH
Checking Confidence:
Read the answer.md frontmatter for each atom to get its confidence_score:
Read: .questionably-ultrathink/{session-id}/atoms/{atom-id}/answer.md
If re-solving needed:
- Delete the
claims.mdandanswer.mdfiles (andverifiers/directory) for atoms needing re-solve - Spawn a fresh cove-claim-qs to regenerate claims
- Run the full factored verification pipeline again
- If dependencies changed, re-contract and re-solve dependents
Early Stop Conditions:
- No confidence improvement after re-solve (converged)
- Re-solve attempts reach 3 (track this in your orchestration state)
For High-Stakes rigor (optional judge step):
After solving all atoms at a level, you MAY invoke the optional judge agent:
Task tool:
- subagent_type: "questionably-ultrathink:aot-judge"
- prompt: "Session ID: {session-id}. Level: {level}. Evaluate answers for coherence, contradictions, and completeness."
The judge evaluates answer quality without re-answering. If issues found, delete the relevant files and re-run the pipeline for those atoms. </rigor_based_iteration>
</full_pipeline>
<pipeline_output_format>
Pipeline Output Format
Use this structure for your final output:
## UltraThink Analysis
### Original Query
{The user's question}
### Analysis Settings
- **Rigor Level**: {Standard | Thorough | High-Stakes}
- **Session ID**: {session-id}
### Phase 1: Graph Construction
**Dependency Graph:**
```
Level 0: A1, A2 (independent)
Level 1: A3 ← [A1, A2]
Level 2: FINAL ← [A3]
```
### Phase 2: Iterative Solving with Factored Verification
**Level 0** (parallel):
- [A1] {question}
- Initial answer: {answer}
- Verification: {N claims verified, M revised}
- Final confidence: HIGH
- [A2] {question}
- Initial answer: {answer}
- Verification: {N claims verified}
- Final confidence: MEDIUM
*Contracting A3 with A1, A2 answers...*
**Level 1**:
- [A3] "Given {A1}, {A2}, {question}?"
- Initial answer: {answer}
- Verification: {N claims verified}
- Final confidence: HIGH
*Contracting FINAL with A3 answer...*
**Level 2**:
- [FINAL] "Given {A3}, {synthesis question}?"
- Final answer: {answer}
### Phase 3: Synthesis
{The FINAL atom's verified answer}
### Final Response
{Clean presentation of the answer}
### Confidence Assessment
| Atom | Initial | After Verification | Notes |
|------|---------|-------------------|-------|
| A1 | 0.75 | 0.90 | All claims verified |
| A2 | 0.60 | 0.55 | 1 claim revised |
| A3 | 0.80 | 0.85 | All claims verified |
| FINAL | 0.85 | 0.85 | All claims verified |
**Overall Confidence:** {HIGH | MEDIUM | LOW}
### Uncertainty Flags
{Any remaining areas of uncertainty}
</pipeline_output_format>
<quick_reference>
Quick Reference
| Situation | Action |
|---|---|
| Multi-part question | Run full pipeline |
| User requests verification | Run full pipeline |
| High-stakes decision | Run full pipeline with high-stakes rigor |
| Simple factual question | Skip UltraThink, answer directly |
</quick_reference>
<skip_ultrathink>
When to Use Standard Responses
Skip UltraThink for:
- Simple, direct questions with single answers
- Opinion/recommendation requests (no facts to verify)
- Quick lookups where user prioritizes speed
- Questions where you have high confidence already </skip_ultrathink>
<confidence_markers>
Confidence Markers
After using UltraThink, mark your confidence:
- [VERIFIED] - All atoms passed factored verification, all claims verified
- [HIGH CONFIDENCE] - Most atoms HIGH, no LOW, minor revisions only
- [NEEDS EXTERNAL VERIFICATION] - User should confirm externally
- [UNCERTAIN] - Significant LOW confidence atoms or many revised claims </confidence_markers>
You must execute the questionably-ultrathink workflow.
Score
Total Score
Based on repository quality metrics
SKILL.mdファイルが含まれている
ライセンスが設定されている
100文字以上の説明がある
GitHub Stars 100以上
1ヶ月以内に更新
10回以上フォークされている
オープンIssueが50未満
プログラミング言語が設定されている
1つ以上のタグが設定されている
Reviews
Reviews coming soon

