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.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: elmaxid
• Source: elmaxid/sequential-thinking-skill
• License: MIT

Install and usage instructions live in the source repository linked above.