home / skills / doanchienthangdev / omgkit / sequential-thinking

sequential-thinking skill

safe

/plugin/skills/methodology/sequential-thinking

This skill helps you structure complex reasoning with numbered thoughts and explicit dependencies to improve multi-step problem solving and debugging.

npx playbooks add skill doanchienthangdev/omgkit --skill sequential-thinking

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

Files (1)

SKILL.md

3.7 KB

---
name: thinking-sequentially
description: AI agent structures complex reasoning through numbered thought sequences with explicit dependencies. Use when facing multi-step problems, complex debugging, or architectural decisions.
category: methodology
triggers:
  - sequential thinking
  - step by step
  - reasoning chain
  - thought process
  - complex problem
---

# Thinking Sequentially

## Purpose

Structure complex reasoning through numbered thought sequences:

- Decompose multi-step problems into traceable chains
- Track dependencies between insights explicitly
- Create checkpoints for periodic review
- Enable revision when assumptions change
- Support parallel hypothesis exploration

## Quick Start

1. **Define** - State the problem clearly as THOUGHT 1
2. **Decompose** - Break into numbered thoughts with dependencies
3. **Track** - Mark dependencies explicitly: "depends on THOUGHT 2"
4. **Checkpoint** - Summarize every 5-10 thoughts
5. **Revise** - Update thoughts when assumptions change, invalidate dependents
6. **Branch** - Explore parallel hypotheses when needed

## Features

| Feature | Description | Guide |
|---------|-------------|-------|
| Numbered Chains | Explicit THOUGHT 1, 2, 3... with IDs | Number every insight, never skip |
| Dependencies | Mark what each thought relies on | `[THOUGHT 4] <- depends on [2, 3]` |
| Checkpoints | Periodic summaries of findings | Every 5-10 thoughts, list key findings |
| Revisions | Update previous thoughts with new data | Mark original as revised, create new |
| Branching | Explore multiple hypotheses in parallel | Create named branches, select winner |
| Visual Maps | Diagram thought relationships | ASCII diagrams for complex chains |

## Common Patterns

```
# Problem Analysis Pattern
THOUGHT 1: Problem statement
THOUGHT 2: Success criteria
THOUGHT 3: Constraints
THOUGHT 4: Assumptions (validate!)
THOUGHT 5-N: Solution exploration
=== CHECKPOINT ===

# Decision Making Pattern
THOUGHT 1: Decision to make
THOUGHT 2: Options identified
THOUGHT 3-N: Evaluate each option
THOUGHT N+1: Comparison matrix
THOUGHT N+2: Recommendation

# Investigation Pattern
THOUGHT 1: What we observed
THOUGHT 2: What we expected
THOUGHT 3: Gap analysis
THOUGHT 4-N: Hypothesis testing
=== CHECKPOINT: Root cause ===
```

```
# Visual thought mapping
        [THOUGHT 1: Problem]
               |
    +----------+----------+
    |                     |
[THOUGHT 2]         [THOUGHT 3]
    |                     |
    +----------+----------+
               |
        [THOUGHT 4: Synthesis]
```

## Use Cases

- Multi-step debugging requiring traceable reasoning chains
- Architectural decisions with complex trade-off analysis
- Code review requiring systematic examination of multiple concerns
- Root cause analysis with hypothesis tracking
- Complex refactoring requiring dependency-aware planning

## Best Practices

| Do | Avoid |
|----|-------|
| Number every thought explicitly | Skipping numbers for "obvious" thoughts |
| Mark dependencies clearly | Hiding dependencies in prose |
| Summarize at checkpoints | Exceeding 20 thoughts without checkpoint |
| Allow revision with reason | Deleting invalid thoughts (strike through) |
| Time-box each thought | Infinite exploration without bounds |
| Branch for parallel exploration | Branching more than 3 levels deep |
| Validate assumptions early | Proceeding with invalidated dependencies |

## Related Skills

See also these related skill documents for complementary techniques:

- **writing-plans** - Structure plans as numbered thought sequences
- **debugging-systematically** - Apply sequential debugging steps
- **tracing-root-causes** - Use numbered investigation chains
- **brainstorming-ideas** - Generate options in thought steps

Overview

This skill structures complex reasoning into numbered thought sequences with explicit dependencies, checkpoints, and branching. It helps keep multi-step analysis traceable, revisable, and auditable. Use it to make decisions, debug systems, or manage architectural trade-offs while preserving the full chain of reasoning.

How this skill works

You state the problem as THOUGHT 1, then create numbered thoughts (THOUGHT 2, 3, ...) that decompose the task and record what each thought depends on. Periodic checkpoints summarize key findings every 5–10 thoughts and revisions are recorded by marking originals as revised and creating new numbered entries. Branches let you explore parallel hypotheses and select a winning line of reasoning while maintaining clear dependency links.

When to use it

Multi-step debugging where root cause must be traceable
Architectural decision-making with many trade-offs
Complex refactoring that requires dependency-aware planning
Code review that needs systematic coverage of concerns
Incident investigation or root cause analysis with hypothesis testing

Best practices

Number every thought explicitly and never skip numbers
Mark dependencies clearly, e.g. "depends on [THOUGHT 2]"
Insert checkpoints every 5–10 thoughts to summarize progress
Time-box thoughts and avoid unlimited exploration
Record revisions instead of deleting original thoughts; invalidate dependents when assumptions change
Use branches for parallel hypotheses but limit depth to avoid combinatorial growth

Example use cases

Debugging a production issue: list observations, expected behavior, gap analysis, hypotheses, tests, and root cause as sequential thoughts
Choosing an architecture: enumerate requirements, constraints, options, trade-offs, and a final recommendation with dependency mapping
Refactoring a large codebase: decompose tasks into dependent steps, schedule checkpoints, and mark impacted modules explicitly
Incident postmortem: trace sequence of events, identify failed assumptions, and validate fixes with numbered tests
Design review: document each concern as a thought, link to related code sections, and summarize conclusions at checkpoints

FAQ

How granular should each THOUGHT be?

Keep each thought focused on a single idea, assumption, or action so dependencies remain clear; combine only when concepts are inseparable.

What if an assumption is invalidated mid-chain?

Mark the original thought as revised, create a new numbered thought with the correction, and invalidate or update all dependents that reference the original assumption.