Help us improve
Share bugs, ideas, or general feedback.
From claude-mods
Decomposes complex problems into atomic verifiable units with confidence tracking and backtracking. For security analysis, architectural decisions, debugging, proofs.
npx claudepluginhub 0xdarkmatter/claude-mods --plugin claude-modsHow this skill is triggered — by the user, by Claude, or both
Slash command
/claude-mods:atomiseThis skill is limited to the following tools:
The summary Claude sees in its skill listing — used to decide when to auto-load this skill
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.
Applies canonical 7D meta-cognitive reasoning to complex problems with dependencies and tradeoffs, delivering clear answers with confidence scores and caveats.
Exposes Claude's reasoning as auditable traces with atomic claims, assumption ratings, weakest links, confidence decomposition, and falsification conditions. Triggers on 'reasoning', 'why', 'trace'.
Provides structured reasoning for stalled debugging or complex problems: frame issues, track hypotheses, gather/evaluate evidence, progress confidence levels to avoid loops.
Share bugs, ideas, or general feedback.
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