Sequential Thinking

Structured problem-solving through iterative reasoning with revision and branching capabilities.

When to Use

This skill is ideal for:

•Complex problem decomposition - Breaking down multi-faceted challenges
•Design planning - Systematic approach to architecture decisions
•Uncertain scope - Tasks where the full scope emerges during analysis
•Root-cause analysis - Tracing issues through multiple layers
•Epic breakdown - Decomposing large features into manageable tasks
•Spec writing - Structuring complex technical specifications
•Complexity assessment - Evaluating task difficulty and risks

How It Works

Core Approach

•Start with initial thought - Express your first understanding of the problem
•Iterate through reasoning - Work through the problem step by step
•Adjust scope dynamically - Update your estimate of total steps as understanding deepens
•Revise when needed - Reconsider previous conclusions if assumptions change
•Branch for alternatives - Explore different approaches when multiple paths exist
•Conclude - Synthesize findings when sufficient analysis is complete

Key Principles

Progressive Refinement: Start with rough estimates, refine as you go

Explicit Uncertainty: Acknowledge what you don't know within reasoning steps

Revision Over Perfection: Better to revise than get stuck on initial assumptions

Branch When Valuable: Explore alternatives when decision has significant impact

Instructions

Step-by-Step Process

1. Initial Assessment

Begin with your first understanding:

code

Thought 1/5 (rough estimate):
Understanding the problem - [describe what you see]
Key unknowns: [list what's unclear]
Initial approach: [high-level strategy]

2. Iterative Reasoning

Work through each step systematically:

code

Thought 2/7 (adjusted from 5):
[Current reasoning step]
- Key insight: [what you learned]
- Implication: [what this means]
- Next: [what to analyze next]

3. Dynamic Scope Adjustment

Update total thought count as understanding deepens:

•Initial: "Thought 1/5" (rough guess)
•Later: "Thought 3/8" (scope expanded)
•Further: "Thought 6/7" (nearly complete)

4. Revision Mechanism

When reconsidering previous conclusions:

code

Thought 5/8 (REVISION of Thought 3):
Original assumption: [what you thought before]
New evidence: [what changed]
Revised conclusion: [updated understanding]
Impact: [what else this affects]

5. Branching for Alternatives

When exploring different approaches:

code

Thought 6/10 (BRANCH A from Thought 4):
Approach A: [first option]
Pros: [advantages]
Cons: [disadvantages]

Thought 7/10 (BRANCH B from Thought 4):
Approach B: [alternative option]
Pros: [advantages]
Cons: [disadvantages]

Comparison: [which is better and why]

6. Conclusion

When sufficient analysis is complete:

code

Thought 8/8 (FINAL):
Summary: [key findings]
Decision: [recommended approach]
Next actions: [what to do]
Confidence: [how certain are you]

Integration with CCPM

Planning Phase

Use with /ccpm:plan:

When creating a new task plan, use sequential thinking to:

•Decompose the feature into logical components
•Identify dependencies and order
•Assess complexity for each component
•Estimate total effort
•Structure implementation phases

Example:

code

User: "/ccpm:plan 'Authentication System' my-project JIRA-123"

Claude: [sequential-thinking activates]

Thought 1/6:
Breaking down authentication system into components:
- User registration
- Login/logout
- Password reset
- Session management
- JWT token handling
- OAuth integration (if needed)

Thought 2/6:
Analyzing dependencies:
- Database schema must come first (user table)
- JWT infrastructure needed before login
- Session management depends on JWT
- OAuth can be added later

Thought 3/6:
Assessing complexity:
- User registration: Medium (validation, email)
- Login: Medium (JWT generation)
- Password reset: High (email flow, tokens)
- Session management: Medium
- OAuth: High (third-party integration)

Thought 4/6:
Estimating effort:
- Total: ~40 hours
- Phase 1 (core): Registration + Login (16h)
- Phase 2 (security): Password reset (12h)
- Phase 3 (sessions): Session management (8h)
- Phase 4 (optional): OAuth (12h)

Thought 5/6 (REVISION of Thought 4):
Realized password reset should be in Phase 1 for MVP.
Revised phases:
- Phase 1: Registration + Login + Password reset (24h)
- Phase 2: Session management (8h)
- Phase 3: OAuth (12h, optional)

Thought 6/6 (FINAL):
Recommended task breakdown:
1. Database schema (2h)
2. User registration endpoint (6h)
3. Login endpoint + JWT (6h)
4. Password reset flow (8h)
5. Session management (8h)
6. OAuth integration (12h, optional)

Next: Create Linear tasks with this structure

Spec Writing Phase

Use with /ccpm:plan architecture:

When writing complex spec sections, use sequential thinking to:

•Outline section structure
•Analyze technical requirements
•Explore alternative architectures
•Document trade-offs
•Recommend final approach

Example:

code

User: "/ccpm:plan DOC-456 architecture"

Claude: [sequential-thinking activates]

Thought 1/8:
Architecture requirements for payment gateway:
- Must handle multiple payment providers (Stripe, PayPal)
- Need robust error handling and retries
- Must be secure (PCI compliance)
- Should support webhooks
- Need to track transaction status

Thought 2/8:
Potential architectures:
A. Monolithic - All payment logic in main service
B. Microservice - Dedicated payment service
C. Adapter pattern - Pluggable payment providers

Thought 3/8 (BRANCH A):
Monolithic approach:
Pros: Simple, fewer moving parts, easier to debug
Cons: Hard to scale, tight coupling, harder to add providers
Verdict: Good for MVP, not long-term

Thought 4/8 (BRANCH B):
Microservice approach:
Pros: Independent scaling, isolation, tech flexibility
Cons: Distributed complexity, network overhead, harder local dev
Verdict: Good for scale, overkill for current size

Thought 5/8 (BRANCH C):
Adapter pattern approach:
Pros: Pluggable providers, testable, maintainable
Cons: More upfront design, abstraction overhead
Verdict: Best balance for current + future needs

Thought 6/8:
Adapter pattern details:
- PaymentProvider interface
- StripeAdapter, PayPalAdapter implementations
- PaymentService orchestrates
- Database tracks transactions
- Webhook handler per provider

Thought 7/8:
Security considerations:
- Never log full card numbers
- Use provider SDKs (not raw API)
- Encrypt sensitive data at rest
- TLS for all communication
- Webhook signature verification

Thought 8/8 (FINAL):
Recommended architecture: Adapter pattern
- Interfaces: PaymentProvider, WebhookHandler
- Implementations: Per provider
- Orchestration: PaymentService
- Storage: TransactionRepository
- Security: Encryption + TLS + SDK usage

Next: Document this in architecture section with diagrams

Complexity Analysis

Use with /ccpm:work:

When assessing task complexity, use sequential thinking to:

•Identify all dimensions of complexity
•Analyze each dimension
•Assess risks
•Provide concrete complexity rating

Example:

code

User: "/ccpm:work AUTH-789"

Claude: [sequential-thinking activates]

Thought 1/5:
Analyzing complexity dimensions:
- Technical complexity
- Integration complexity
- Testing complexity
- Deployment complexity
- Domain complexity

Thought 2/5:
Technical complexity: HIGH
- New OAuth2 flow (unfamiliar)
- Token rotation logic (security critical)
- Multi-tenancy support (complex state)

Thought 3/5:
Integration complexity: MEDIUM
- Integrates with existing user service (stable API)
- Needs new Redis for tokens (new infra)
- Affects login UI (coordinated deployment)

Thought 4/5:
Risks identified:
- Security vulnerabilities (HIGH impact, MEDIUM likelihood)
- Token collision in multi-tenant (MEDIUM impact, LOW likelihood)
- Performance degradation (LOW impact, MEDIUM likelihood)

Thought 5/5 (FINAL):
Overall complexity: HIGH
Factors:
- Unfamiliar OAuth2 flow
- Security-critical functionality
- Multi-tenancy state management
- New infrastructure (Redis)

Recommendation:
- Allocate senior developer
- Add security review checkpoint
- Plan thorough testing (unit + integration + security)
- Consider spike/POC first (4h) before full implementation
- Estimate: 32h (vs initial 16h guess)

Debugging/Root-Cause Analysis

Use with /ccpm:verify:

When debugging complex issues, use sequential thinking to:

•Gather symptoms
•Form hypotheses
•Test each hypothesis
•Trace root cause
•Identify fix

Example:

code

User: "Tests are failing intermittently in CI"

Claude: [sequential-thinking activates]

Thought 1/7:
Symptoms:
- Tests pass locally (always)
- Tests fail in CI (30% of the time)
- No recent code changes
- Error: "Connection timeout to database"

Thought 2/7:
Hypotheses:
A. Database not ready when tests start
B. Race condition in test setup
C. Resource limits in CI environment
D. Network issues in CI infrastructure

Thought 3/7 (Testing Hypothesis A):
Check: Database startup time
Finding: Docker Compose has no health check
Likelihood: HIGH - explains intermittent failures

Thought 4/7 (Testing Hypothesis B):
Check: Test execution order
Finding: Tests run in parallel, no shared state
Likelihood: LOW - tests are independent

Thought 5/7 (Testing Hypothesis C):
Check: CI resource allocation
Finding: Memory/CPU usage normal
Likelihood: LOW - resources sufficient

Thought 6/7 (REVISION of Thought 3):
Root cause confirmed: Database not ready
- CI starts tests immediately after docker-compose up
- Database takes 2-5 seconds to accept connections
- Tests timeout if database not ready
- Explains 30% failure rate (timing dependent)

Thought 7/7 (FINAL):
Root cause: Missing database readiness check
Fix: Add health check to docker-compose.yml
```yaml
services:
  database:
    healthcheck:
      test: ["CMD", "pg_isready", "-U", "postgres"]
      interval: 1s
      timeout: 5s
      retries: 10

Wait for healthy before running tests:

bash

docker-compose up -d database
docker-compose wait database
npm test

Update Linear: Document fix and close blocker

code


## Examples

### Example 1: Epic Breakdown

**Problem**: Break down "User Dashboard" epic

Thought 1/6: Components needed:

•Dashboard layout
•Widget system
•User preferences
•Data visualization
•Real-time updates

Thought 2/6: Dependencies:

•Layout first (foundation)
•Widget system needs layout
•Preferences can be parallel
•Visualization uses widget system
•Real-time updates overlay on all

Thought 3/6: Sizing each component:

•Layout: 8h (responsive, nav, sidebar)
•Widget system: 16h (drag-drop, resize, save layout)
•Preferences: 6h (settings page, API, storage)
•Visualization: 12h (charts, graphs, data fetching)
•Real-time: 10h (WebSocket, updates, reconnection)

Thought 4/6 (REVISION of Thought 3): Widget system too complex for first iteration. MVP: Static widget positions, customization later. Revised: Widget system → 6h (static layout) Future: Drag-drop enhancement → 10h (Phase 2)

Thought 5/6: Task breakdown:

•Dashboard layout (8h)
•Static widget system (6h)
•User preferences (6h)
•Data visualization (12h)
•Real-time updates (10h) Total: 42h (Phase 1), +10h (Phase 2 for drag-drop)

Thought 6/6 (FINAL): Create 5 Linear tasks with dependencies:

•Task 1 blocks Task 2
•Task 2 blocks Tasks 4,5
•Task 3 parallel to all

code


### Example 2: Architecture Decision

**Problem**: Choose database for analytics feature

Thought 1/7: Requirements:

•Store user event data (high write volume)
•Support aggregation queries (hourly/daily rollups)
•Fast reads for dashboards
•Retain 90 days of data

Thought 2/7 (BRANCH A): Option A: PostgreSQL (current database) Pros: Already in stack, familiar, ACID guarantees Cons: May struggle with high write volume, expensive aggregations Analysis: Feasible but may need optimizations

Thought 3/7 (BRANCH B): Option B: ClickHouse (OLAP database) Pros: Built for analytics, fast aggregations, compression Cons: New tech to learn, operational overhead, eventual consistency Analysis: Best for analytics, but higher complexity

Thought 4/7 (BRANCH C): Option C: TimescaleDB (PostgreSQL extension) Pros: Combines PostgreSQL familiarity + time-series optimization Cons: Still PostgreSQL under the hood, some limitations Analysis: Good middle ground

Thought 5/7: Scale analysis:

•Expected: 1M events/day
•PostgreSQL: Can handle with partitioning + indexes
•ClickHouse: Overkill for current scale
•TimescaleDB: Perfect fit

Thought 6/7: Decision factors:

•Current scale: Small (PostgreSQL handles)
•Team expertise: Strong PostgreSQL
•Operational complexity: Minimize
•Future scale: Can re-evaluate at 10M events/day

Thought 7/7 (FINAL): Recommendation: Start with PostgreSQL + optimizations

•Partitioning by date
•Materialized views for aggregations
•Indexes on query patterns
•Re-evaluate if hits performance limits Reasoning: Simplest solution that works, avoid premature optimization

code


## Tips

### Estimating Total Thoughts

**Start rough, refine progressively:**

- Simple problem: 3-5 thoughts
- Medium problem: 5-8 thoughts
- Complex problem: 8-15 thoughts
- Very complex: 15+ thoughts (consider breaking down)

**Adjust as you go:**
- Thought 1/5 → Thought 3/7 (discovered more complexity)
- Thought 5/8 → Thought 5/6 (found shortcut)

### When to Revise

**Trigger revision when:**
- New evidence contradicts assumption
- Discovered missing requirement
- Found simpler approach
- Identified blocker

**Revision format:**

Thought X (REVISION of Thought Y): Original: [what you thought] New: [what changed] Impact: [ripple effects]

code


### When to Branch

**Branch when:**
- Multiple viable approaches exist
- Decision has significant impact
- Trade-offs need explicit comparison
- Team needs to choose between options

**Branch format:**

Thought X (BRANCH A from Thought Y): Approach: [option A] Analysis: [pros/cons]

Thought X+1 (BRANCH B from Thought Y): Approach: [option B] Analysis: [pros/cons]

Conclusion: [comparison and recommendation]

code


### When to Stop

**Conclude when:**
- Sufficient analysis completed
- Clear recommendation formed
- Diminishing returns on further thought
- Ready for action

**Conclusion format:**

Thought X/X (FINAL): Summary: [key findings] Decision: [what to do] Rationale: [why] Next: [action items]

code


## Common Patterns

### Pattern 1: Decomposition

•List all components
•Identify dependencies
•Size each component
•Revise based on constraints
•Create task breakdown
•Document in Linear

code


### Pattern 2: Decision-Making

•Define criteria
•List options
•Branch per option
•Analyze trade-offs
•Compare
•Recommend with rationale

code


### Pattern 3: Root-Cause Analysis

•Gather symptoms
•Form hypotheses
•Test each hypothesis
•Trace to root cause
•Verify fix
•Document for future

code


## Conclusion

Sequential thinking is ideal for:
- ✅ Complex multi-step problems
- ✅ Uncertain scope that emerges during analysis
- ✅ Design decisions requiring trade-off analysis
- ✅ Root-cause analysis through multiple layers
- ✅ Epic breakdown into manageable tasks

It integrates seamlessly with CCPM workflows:
- Planning: `/ccpm:plan`, `/ccpm:plan`
- Analysis: `/ccpm:work`
- Debugging: `/ccpm:verify`

**Philosophy**: Progressive refinement over premature perfection. Start with rough estimates, iterate, revise when needed, and branch when valuable.

---

**Source**: Adapted from [claudekit-skills/sequential-thinking](https://github.com/mrgoonie/claudekit-skills)
**License**: MIT
**CCPM Integration**: Planning, spec writing, complexity analysis, debugging