home / skills / samhvw8 / dotfiles / 0-sequential-thinking

0-sequential-thinking skill

/dot_ccp/hub/skills/0-sequential-thinking

This skill helps you solve complex problems by guiding step-by-step reasoning, dynamic adjustment, and hypothesis verification for reliable outcomes.

npx playbooks add skill samhvw8/dotfiles --skill 0-sequential-thinking

Review the files below or copy the command above to add this skill to your agents.

Files (15)
SKILL.md
3.6 KB
---
name: sequential-thinking
description: "Structured reflective problem-solving methodology. Process: decompose, analyze, hypothesize, verify, revise. Capabilities: complex problem decomposition, adaptive planning, course correction, hypothesis verification, multi-step analysis. Actions: decompose, analyze, plan, revise, verify solutions step-by-step. Keywords: sequential thinking, problem decomposition, multi-step analysis, hypothesis verification, adaptive planning, course correction, reflective thinking, step-by-step, thought sequence, dynamic adjustment, unclear scope, complex problem, structured analysis. Use when: decomposing complex problems, planning with revision capability, analyzing unclear scope, verifying hypotheses, needing course correction, solving multi-step problems."
version: 1.0.0
license: MIT
---

# Sequential Thinking

Structured problem-solving via manageable, reflective thought sequences with dynamic adjustment.

## When to Apply

- Complex problem decomposition
- Adaptive planning with revision capability
- Analysis needing course correction
- Problems with unclear/emerging scope
- Multi-step solutions requiring context maintenance
- Hypothesis-driven investigation/debugging

## Core Process

### 1. Start with Loose Estimate
```
Thought 1/5: [Initial analysis]
```
Adjust dynamically as understanding evolves.

### 2. Structure Each Thought
- Build on previous context explicitly
- Address one aspect per thought
- State assumptions, uncertainties, realizations
- Signal what next thought should address

### 3. Apply Dynamic Adjustment
- **Expand**: More complexity discovered → increase total
- **Contract**: Simpler than expected → decrease total
- **Revise**: New insight invalidates previous → mark revision
- **Branch**: Multiple approaches → explore alternatives

### 4. Use Revision When Needed
```
Thought 5/8 [REVISION of Thought 2]: [Corrected understanding]
- Original: [What was stated]
- Why revised: [New insight]
- Impact: [What changes]
```

### 5. Branch for Alternatives
```
Thought 4/7 [BRANCH A from Thought 2]: [Approach A]
Thought 4/7 [BRANCH B from Thought 2]: [Approach B]
```
Compare explicitly, converge with decision rationale.

### 6. Generate & Verify Hypotheses
```
Thought 6/9 [HYPOTHESIS]: [Proposed solution]
Thought 7/9 [VERIFICATION]: [Test results]
```
Iterate until hypothesis verified.

### 7. Complete Only When Ready
Mark final: `Thought N/N [FINAL]`

Complete when:
- Solution verified
- All critical aspects addressed
- Confidence achieved
- No outstanding uncertainties

## Application Modes

**Explicit**: Use visible thought markers when complexity warrants visible reasoning or user requests breakdown.

**Implicit**: Apply methodology internally for routine problem-solving where thinking aids accuracy without cluttering response.

## Scripts (Optional)

Optional scripts for deterministic validation/tracking:
- `scripts/process-thought.js` - Validate & track thoughts with history
- `scripts/format-thought.js` - Format for display (box/markdown/simple)

See README.md for usage examples. Use when validation/persistence needed; otherwise apply methodology directly.

## References

Load when deeper understanding needed:
- `references/core-patterns.md` - Revision & branching patterns
- `references/examples-api.md` - API design example
- `references/examples-debug.md` - Debugging example
- `references/examples-architecture.md` - Architecture decision example
- `references/advanced-techniques.md` - Spiral refinement, hypothesis testing, convergence
- `references/advanced-strategies.md` - Uncertainty, revision cascades, meta-thinking

Overview

This skill implements a structured, reflective problem-solving methodology that guides multi-step reasoning and dynamic course correction. It decomposes complex problems, generates and verifies hypotheses, and iterates until verified solutions emerge. The process supports both visible step-by-step traces and silent internal application for routine tasks.

How this skill works

The skill decomposes a problem into focused thoughts, each addressing one aspect with explicit assumptions and next-step signals. It supports expanding, contracting, revising, and branching the thought sequence as new information appears. Hypotheses are proposed and verified with targeted checks; revisions record original claims, why they changed, and the impact on the plan.

When to use it

  • Decomposing complex or poorly scoped problems
  • Planning projects with need for iterative revision
  • Debugging or investigation requiring hypothesis testing
  • Solving multi-step tasks that need context maintenance
  • Situations where course correction and adaptive planning are likely

Best practices

  • Start with a loose estimate of steps and update as understanding changes
  • Keep each thought focused: state assumptions, uncertainty, and explicit next action
  • Use revision entries to capture what changed and why to avoid repeating mistakes
  • Branch only when alternatives are materially different and compare outcomes explicitly
  • Choose explicit visible thought traces for high-complexity or collaborative work; use implicit mode for routine automation

Example use cases

  • Designing a software architecture by breaking features into prioritized design thoughts
  • Debugging a flaky system: hypothesize root causes, test, and revise the sequence
  • Planning a research or product roadmap with staged verification and checkpoints
  • Conducting root-cause analysis on production incidents with branching exploration
  • Creating stepwise instructional content that must adapt to emergent requirements

FAQ

Do I always show the thought sequence to users?

No. Use explicit thought markers when the user requests transparency or when complexity demands a visible trace. Use implicit application when clarity and brevity are preferred.

How do I know when to revise a previous thought?

Revise when new evidence invalidates an assumption, changes impact downstream steps, or when a better approach emerges. Record original, reason for revision, and consequences.