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

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

Step Types

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:

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

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.