Decompose complex problems into minimal, verifiable "atoms" of thought. Unlike chain-of-thought (linear, error-accumulating), AoT treats each step as independently verifiable and backtracks when confidence drops.
Use for: Security analysis, architectural decisions, complex debugging, multi-step proofs. Don't use for: Simple questions, trivial calculations, information lookup.
/atomise "<problem>" [--light | --deep] [--math | --code | --security | --design]
1. DECOMPOSE → Break into atomic subquestions (1-2 sentences each)
2. SOLVE → Answer leaf nodes first, propagate up
3. VERIFY → Test each hypothesis (counterexample, consistency, domain check)
4. CONTRACT → Summarize verified state in 2 sentences (drop history)
5. EVALUATE → Confident enough? Done. Too uncertain? Backtrack and try another path.
Repeat until confident or all paths exhausted.
Each atom is a minimal unit:
{id, type, content, depends_on[], confidence, verified}
| Type | Purpose | Starting Confidence |
|---|---|---|
| premise | Given facts | 1.0 |
| reasoning | Logical inference | Inherited from parents |
| hypothesis | Claim to test | Max 0.7 until verified |
| verification | Test result | Based on test outcome |
| conclusion | Final answer | Propagated from chain |
Confidence propagates: A child can't be more confident than its least-confident parent.
These numbers are heuristic, not calibrated probabilities. They're useful for tracking relative certainty, not for actual risk assessment.
| Threshold | Meaning |
|---|---|
| > 0.85 | Confident enough to conclude |
| 0.6 - 0.85 | Needs more verification |
| < 0.6 | Decompose further or backtrack |
| < 0.5 | Backtrack - this path isn't working |
Verification adjusts confidence:
Depth:
--light — Fast: max 3 levels, 0.70 confidence threshold--deep — Exhaustive: max 7 levels, 0.90 thresholdDomain (adjusts verification style):
--math — Arithmetic checks, proof validation, boundary tests--code — Type checking, invariant verification, test generation--security — Threat modeling, attack surface, adversarial thinking--design — Tradeoff analysis, constraint satisfaction, feasibilityANSWER: {result}
CONFIDENCE: {0.0-1.0} - {why}
KEY CHAIN: P1 → R1 → H1 → V1 → C1
ATOMS:
| id | type | content | conf | verified |
|----|------|---------|------|----------|
| P1 | premise | Given: ... | 1.0 | Y |
| R1 | reasoning | Therefore: ... | 0.95 | Y |
| ... | ... | ... | ... | ... |
RISKS: {what could change this}
Add --verbose for full trace, --quiet for just the answer.
When a path yields confidence < 0.5 after verification:
# Complex debugging
/atomise "Why does this function return null on the second call?" --code
# Security review
/atomise "Is this authentication flow vulnerable to session fixation?" --security
# Architecture decision
/atomise "Should we use event sourcing for this domain?" --deep --design
# Quick decision (light mode)
/atomise "Redis vs Memcached for this cache layer?" --light
BAD: /atomise "What's 2+2?" → Just answer it
BAD: /atomise "Rewrite this function" → That's implementation, not reasoning
BAD: Forcing conclusion despite low confidence → Let it backtrack
GOOD: /atomise for genuine uncertainty requiring structured decomposition