Sequential thinking

Sequential Thinking

Overview

Perform structured sequential analysis for complex problems. Break thinking into numbered steps with explicit tracking of hypotheses, revisions, and alternative branches. Each step builds on, questions, or revises previous steps to reach a well-founded conclusion.

Core principle: Complex problems benefit from explicit, numbered thinking steps where reasoning is visible, revisable, and traceable.

When to Use

• Breaking down complex architecture into analyzable steps
• Tracking multiple hypotheses and eliminating them systematically
• Comparing 3+ approaches with interconnected trade-offs
• Root cause analysis across multiple system components
• Planning with conditional branches ("if X then Y, else Z")
• Any analysis where backtracking or revision is likely needed

Do NOT use for:

• Simple questions with straightforward answers
• Tasks already covered by systematic-debugging (use that for bugs first)
• Creative exploration (use brainstorming skill instead)
• Single-factor decisions with obvious answers

The Thinking Format

Structure each analysis using this explicit format. Present all thinking visibly to maintain rigor and allow the user to follow the reasoning chain.

Step Format

## Sequential Analysis: [Problem Title]

### Step 1 of ~N: [Step Purpose]
[Analysis content]
Status: CONTINUE | REVISE [step] | BRANCH | CONCLUDE

### Step 2 of ~N: [Step Purpose]
[Analysis content]
Status: CONTINUE

### Step 3 of ~N (REVISES Step 1): [Why revising]
[Revised analysis incorporating new information from Step 2]
Status: CONTINUE

### Step 4 of ~N (BRANCH A from Step 2): [Branch purpose]
[Exploration of alternative path A]
Status: CONTINUE

### Step 5 of ~N (BRANCH B from Step 2): [Branch purpose]
[Exploration of alternative path B]
Status: CONTINUE

### Step N of N: Conclusion
[Final synthesis incorporating all steps, revisions, and branch comparisons]

Step Estimation Guide

Problem Complexity	Estimated Steps	Examples
Simple comparison	3-5	Library A vs B, config choice
Architecture decision	5-8	Database selection, API design, service split
Complex debugging	8-12	Multi-service failure, race conditions
System design	8-12	New subsystem, migration strategy

Adjust ~N as understanding deepens. Starting with fewer steps and adding more is better than overestimating.

Step Types

Type	When to Use	Format
Analysis	Breaking down a component or requirement	Step N: Analyze [component]
Hypothesis	Forming a testable theory about behavior	Step N: Hypothesis — [theory]
Revision	Correcting or updating earlier thinking	Step N (REVISES Step X): [reason]
Branch	Exploring an alternative path	Step N (BRANCH A from Step X): [path]
Comparison	Weighing two or more options side by side	Step N: Compare [A] vs [B]
Verification	Checking a hypothesis against evidence	Step N: Verify [hypothesis]
Conclusion	Final synthesis of all reasoning	Step N: Conclusion

Key Rules

Revise Explicitly

When new information contradicts an earlier step, mark the new step as REVISES Step X and explain what changed and why. Never silently change conclusions — the revision trail is the value.

Branch When Needed

When two or more viable paths exist, explore each as a named branch (A, B, C). Branches enable fair comparison without losing context of either option.

Maximum 3 branches. More than 3 indicates the problem should be decomposed into sub-problems first.

Conclude with Synthesis

The final step must synthesize all prior steps, revisions, and branches into a clear recommendation or answer. Reference specific step numbers. A conclusion that introduces new reasoning not grounded in prior steps is an anti-pattern.

Estimate Then Adjust

Start with an estimate of total steps. Increase if the problem proves deeper than expected. Decrease if reaching conclusion early. Signal adjustments: "Adjusting from ~5 to ~7 steps — the trade-offs are more nuanced than initially expected."

Integration with Other Skills

Sequential thinking complements but does not replace other skills:

Skill	Relationship
systematic-debugging	Use debugging for bugs. Escalate to sequential-thinking when Phase 2 (Pattern Analysis) reveals a complex architectural question.
brainstorming	Use brainstorming for creative exploration. Use sequential-thinking to narrow brainstorming results into a rigorous final decision.
writing-plans	Sequential thinking can precede plan writing when the approach itself is uncertain. Once decided, hand off to writing-plans.
dispatching-parallel-agents	When sequential thinking identifies independent sub-problems, dispatch parallel agents for each.

Example: Database Choice for Audit Logs

## Sequential Analysis: Database for Audit Logs

### Step 1 of ~5: Requirements
Audit logs need: immutability, fast writes, infrequent reads,
hash chain integrity, ISO 27001 compliance.
Write volume: ~1000/day. Read: monthly audits only.
Status: CONTINUE

### Step 2 of ~5: Evaluate PostgreSQL
INSERT-only + triggers provides immutability. Hash chain via
SHA-256 on previous row. Advisory locks prevent concurrent
writes corrupting chain. Already in stack — zero new infra.
Status: CONTINUE

### Step 3 of ~5: Evaluate Append-Only Alternatives
Kafka: overkill for 1000/day, adds operational complexity.
File-based: no query capability for audit reports.
Both require additional infrastructure.
Status: CONTINUE

### Step 4 of ~5: Evaluate SQLite (WAL)
Lightweight, single-writer is fine for audit volume.
But: no network access for dual-write architecture needed
by the external audit server requirement.
Status: CONTINUE

### Step 5 of 5: Conclusion
PostgreSQL is the clear choice (Steps 2-4):
- Already in stack (Step 2) — zero new infrastructure
- Supports immutability via triggers (Step 2)
- Hash chain via advisory locks (Step 2)
- Full SQL for audit queries (vs file-based, Step 3)
- Network-accessible for dual-write (vs SQLite, Step 4)
Decision: PostgreSQL with INSERT+SELECT only permissions.

Anti-Patterns

Anti-Pattern	Why It Fails	Fix
Invisible reasoning	Skipping steps or reasoning silently defeats the purpose	Make every step visible and explicit
Never revising	No revisions means the problem is too simple or unconsidered factors exist	If no revisions after 5+ steps, question assumptions
Excessive branching	>3 branches means the problem needs decomposition	Break into sub-problems first
Conclusion without synthesis	Conclusion must reference and integrate prior steps	Cite specific step numbers in conclusion
Fixed step count	Refusing to adjust ~N ignores emerging complexity	Announce adjustments when understanding changes
Premature conclusion	Concluding before exploring alternatives	Ensure at least one comparison or branch before concluding

Additional Resources

Reference Files

• references/thinking-patterns.md — Detailed step templates for 5 specific problem types: architecture decisions, root cause chains, trade-off matrices, decision trees, and incremental refinement.