self-reflecting-chain
Skill0 starsChanged 32 days agoMITView on GitHub
Works through a problem one dependent step at a time, reflecting on each step's validity and backtracking when a step fails. Use when order matters and each step builds on the last - tracing a known execution path, a proof or derivation, a causal chain, a plan where phase B needs phase A - or when the user says "walk me through it step by step", "check each step", "trace this through". Not for finding an unknown root cause among many candidates (use hypothesis-elimination), for choosing among options (use tree-of-thoughts or breadth-of-thought), or for steps that can run in any order.
In this repository15 other files it gives its agents.
- .claude/CLAUDE.mdCLAUDE.md
- adversarial-reasoningSkill
- analogical-transferSkill
- breadth-of-thoughtSkill
- dialectical-reasoningSkill
- hypothesis-eliminationSkill
- integrated-reasoningSkill
- negotiated-decision-frameworkSkill
- option-synthesisSkill
- parallel-executionSkill
- premortem-evolvedSkill
- rapid-triage-reasoningSkill
- reasoning-handover-protocolSkill
- skill-gauntletSkill
- tree-of-thoughtsSkill
The file
We split this skill into the rules it gives an agent
9 rules. About 0 are common, 9 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈9
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 81
Empirical Verification: If this step involves code, did you compile/run it?
- Distinctive: line 132
Mark failed path: Document why previous path failed
- Distinctive: line 156
Backward Consistency: Do all previous steps still hold given new information?
- Distinctive: line 158
Alternative Paths: Should we backtrack and try different approach?
- Distinctive: line 176
Alternative paths explored: Document backtracks and why
- Distinctive: line 222
Missing Dependencies: Not checking if later steps depend on earlier ones
- Distinctive: line 223
No Backtracking: Never questioning previous steps when contradictions arise
- Distinctive: line 225
Hidden Assumptions: Not explicitly stating what you're assuming
- Distinctive: line 250
Use it when order matters, dependencies exist, and you need one correct answer with full reasoning trace.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Effort & Thinking Budget
- Recommended effort: medium/high — step-by-step reasoning doesn't always need max depth per step
- Include "ultrathink" only for steps with confidence below 70% that require deeper analysis
- For time-constrained scenarios, use effort: medium with fewer backtracking iterations
Model Recommendation
Best with Opus for maximum reasoning depth. Sonnet handles straightforward sequential chains well; reserve Opus for chains with complex dependencies or high-stakes backtracking decisions.
Self-Reflecting Chain Reasoning Methodology
Purpose: Sequential step-by-step reasoning with deep self-reflection at each step. Unlike parallel exploration (ToT/BoT), this follows a single logical chain, reflects on each step's validity, and backtracks when errors detected.
When to Use Self-Reflecting Chain
✅ Use when:
- Steps have dependencies (Step N depends on Step N-1)
- Logical reasoning required (mathematical, causal, deductive)
- Need to trace exact reasoning path
- Error detection and correction critical
- Sequential planning (Step A must complete before Step B)
- Debugging (trace bug through execution flow)
❌ Don't use when:
- Multiple independent solution paths exist → Use ToT or BoT
- Need to explore many options in parallel → Use BoT
- Steps can execute in any order → Don't need sequential reasoning
Examples:
- "Debug this race condition by tracing execution step-by-step" ✅
- "Prove this mathematical theorem" ✅
- "Plan project where each phase depends on previous" ✅
- "Choose between 5 architectures" (parallel problem - use BoT) ❌
Core Methodology: Chain-Reflect-Backtrack
Step 1: Problem Decomposition
Objective: Break problem into sequential logical steps
Actions:
- Identify starting state
- Define goal state
- List steps to get from start to goal (sequential order)
- Number steps clearly (Step 1, 2, 3...)
- Identify dependencies between steps
Example (Debugging):
Start: System crashes when user clicks "Submit"
Goal: Identify root cause
Steps:
1. Trace user action to event handler
2. Check event handler for errors
3. Trace data flow to backend
4. Check backend validation logic
5. Inspect database query execution
6. Identify exact failure pointStep 2: Execute Step N with Deep Reflection
For each step:
- Execute: Perform the reasoning/action for this step
- State Result: What did you learn/discover?
- Self-Reflect: Is this step correct?
- Check Validity: Does logic hold? Any assumptions?
- Empirical Verification: If this step involves code, did you compile/run it?
- Confidence: How confident in this step (0-100%)?
CRITICAL: Empirical Verification Requirement
For any step involving code, PoCs, or technical claims:
- Code compiles/builds successfully
- Code executes without errors (or crashes as expected)
- Output demonstrates the claimed behavior
- Commands and output documented
Without empirical verification, confidence for this step: MAXIMUM 50%
Step Template:
## Step [N]: [Action]
### Execution
[Perform the reasoning or analysis]
### Result
[What was discovered/concluded]
### Self-Reflection
- **Confidence**: [0-100]%
- **Assumptions**: [What assumptions does this step make?]
- **Logic Check**: [Is the reasoning sound?]
- **Dependencies**: [Does this depend on previous steps being correct?]
- **Potential Errors**: [What could be wrong with this step?]
### Decision
- ✅ **Proceed** to Step [N+1] (confidence ≥70%)
- ⚠️ **Low Confidence** but proceeding (60-69%)
- ❌ **Backtrack** to Step [N-X] (confidence <60%)Step 3: Backtracking Protocol
Trigger backtracking when:
- Step confidence <60%
- Logic error detected
- Assumption proven false
- Result contradicts known facts
- Dead end reached
Backtracking Process:
- Identify error point: Which step was wrong?
- Return to that step: Go back to Step N-X
- Try alternative: Take different reasoning path
- Mark failed path: Document why previous path failed
- Resume forward: Continue from corrected step
Backtracking Example:
## Step 5: [Attempted reasoning]
→ Result: Contradiction detected
→ Confidence: 25% (contradicts Step 3 result)
**Backtrack Decision**: Return to Step 3, try alternative interpretation
## Step 3 (Revised): [Alternative reasoning]
→ Result: New interpretation consistent
→ Confidence: 80%
→ Proceed to Step 4 with revised understanding...Step 4: Chain Validation
At each step, validate the entire chain so far:
- Forward Consistency: Does Step N follow logically from Step N-1?
- Backward Consistency: Do all previous steps still hold given new information?
- Assumption Check: Have any assumptions been violated?
- Alternative Paths: Should we backtrack and try different approach?
Validation Checklist:
- Each step's confidence ≥70%
- No logical contradictions
- All assumptions explicitly stated
- Dependencies satisfied
- No better alternative path obvious
Step 5: Final Synthesis
After completing chain:
- Trace complete path: List all steps from start to goal
- Confidence per step: Show confidence for each step
- Overall confidence: Minimum confidence across all steps
- Alternative paths explored: Document backtracks and why
- Final answer: Clear conclusion with reasoning trace
Synthesis Template:
## Reasoning Chain Complete
### Complete Path
1. [Step 1] → Result: [X] (Confidence: 85%)
2. [Step 2] → Result: [Y] (Confidence: 90%)
3. [Step 3] → Result: [Z] (Confidence: 75%)
4. [Step 4] → Result: [A] (Confidence: 88%)
5. [Step 5] → Result: [B] (Confidence: 82%)
### Overall Confidence
**Minimum**: 75% (Step 3 was lowest)
**Chain Confidence**: 75% (limited by weakest link)
### Backtracks
- Backtracked from Step 4 to Step 2 (logic error)
- Alternative path tried at Step 3 (failed, original was correct)
### Final Conclusion
[Answer based on complete reasoning chain]
**Reasoning Trace**: Step 1 → Step 2 → Step 3 → Step 4 → Step 5 → ConclusionSelf-Critique Checklist
- Step Independence: Is each step clearly defined?
- Logical Flow: Does each step follow from previous?
- Reflection Depth: Did I genuinely reflect on each step (not boilerplate)?
- Backtracking Used: Did I backtrack when confidence low?
- Assumptions Explicit: Are all assumptions stated clearly?
- Weakest Link: Is chain confidence based on weakest step?
- Alternative Paths: Did I consider other approaches when stuck?
Common Mistakes
- Skipping Reflection: Moving to next step without genuine self-reflection
- Ignoring Low Confidence: Proceeding when confidence <60%
- Missing Dependencies: Not checking if later steps depend on earlier ones
- No Backtracking: Never questioning previous steps when contradictions arise
- False Confidence: High confidence without justification
- Hidden Assumptions: Not explicitly stating what you're assuming
Sequential vs Parallel Decision Guide
| Problem Type | Use Self-Reflecting Chain | Use ToT/BoT |
| Dependencies | Sequential steps | Independent paths |
| Goal | Single logical conclusion | Explore options |
| Method | Step-by-step reasoning | Parallel branches |
| Backtracking | Return to previous step | Prune branches |
| Output | Reasoning trace | Multiple solutions |
Summary
Self-Reflecting Chain is systematic methodology for:
- Sequential reasoning (step-by-step)
- Deep self-reflection (confidence at each step)
- Error detection (validate logic continuously)
- Backtracking (correct errors when found)
- Traceability (clear reasoning path)
Use it when order matters, dependencies exist, and you need one correct answer with full reasoning trace.
Remember: Chain confidence = minimum step confidence. A 95% confident chain with one 60% step has 60% overall confidence. Strengthen the weakest link.
Backstage rule — the method never appears in the answer
This methodology is scaffolding, not content. In the user-facing answer: no method names ("Self-Reflecting Chain", "SRC", or any other pattern name), no method narration ("applying the method", "scoring the dimensions", "this branch scores 7/10"), no internal scores or affinity arithmetic, no confidence-aggregation or checkpoint talk. Structure earns its place only as content built from the problem's own facts — a hypothesis table in a diagnosis, an options-vs-criteria matrix in a selection — never as a display of process. Before delivering, run a literal text search over the answer for the names above and for "pattern", "branch", "affinity", "dimension score", "confidence aggregation", "checkpoint"; rewrite every hit as content or delete it. The reader sees findings, not the apparatus that produced them.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

