ultrathink

"The people who are crazy enough to think they can change the world are the ones who do."

Core philosophy:

• Think Different - Question every assumption before designing
• Obsess Over Details - Understand the codebase's soul, not just its code
• Plan Like Da Vinci - Architecture so elegant it feels inevitable
• Simplify Ruthlessly - Remove complexity until nothing is left to take away
• Iterate Relentlessly - First solution is never good enough

When activated:

• --deep flag on any workflow command
• All epic workflows (via deep_planning_triggers.epic_features)
• Features with 30+ estimated tasks (via deep_planning_triggers.complexity_threshold)
• New architectural patterns (via deep_planning_triggers.architecture_change)
• planning.auto_deep_mode: true in user preferences

Outputs:

• Enhanced plan.md with assumption inventory
• craftsman-decision.md artifact documenting deep thinking
• Simpler architecture than standard planning would produce

<quick_start> Execute craftsman planning workflow:

1. Think Different - Create assumption inventory, challenge each one
2. Obsess Over Details - Analyze codebase soul (patterns, philosophy)
3. Plan Like Da Vinci - Sketch architecture before implementing
4. Simplify Ruthlessly - Find minimum viable architecture
5. Iterate - Compare alternatives, refine until inevitable

Key principle: One hour of deeper thinking saves ten hours of rework.

Trigger phrases: "ultrathink", "deep planning", "craftsman mode", "--deep" </quick_start>

Before designing anything, catalog and challenge every assumption.

Create assumption inventory:

## Assumption Inventory

| # | Assumption | Source | Challenge Question | Resolution |
|---|------------|--------|-------------------|------------|
| 1 | Users need X feature | Spec | Is this the real problem or a symptom? | [Validated/Changed/Removed] |
| 2 | We need a database table | Common pattern | Could we use existing data structures? | [Validated/Changed/Removed] |
| 3 | API endpoint required | Architecture | Could this be client-side only? | [Validated/Changed/Removed] |

Challenge questions for each assumption:

1. Why does it have to work this way?
2. What if we started from zero?
3. What would break if this assumption is false?
4. Is this solving the real problem or a symptom?
5. What's the simplest thing that could possibly work?

Categories to examine:

• Technical assumptions - Database, API, frontend framework
• User assumptions - What users actually need vs what we think they need
• Architectural assumptions - Why this pattern? Why these components?
• Integration assumptions - Do we need this external service?

Output: Document in craftsman-decision.md under "Assumptions Questioned"

Read the codebase like you're studying a masterpiece. Understand patterns, philosophy, and the why behind decisions.

Analysis process:

# Find dominant patterns
grep -r "class.*Service" src/ | wc -l
grep -r "Repository" src/ | wc -l
grep -r "Controller" src/ | wc -l

# Analyze architecture style
ls -la src/
tree src/ -L 2

# Find design decisions in comments
grep -r "// NOTE:" src/
grep -r "// DECISION:" src/
grep -r "// WHY:" src/

Questions to answer:

1. What patterns dominate this codebase? (Repository, Service, MVC, etc.)
2. What's the philosophy? (Thin controllers? Fat services? Domain-driven?)
3. Where does complexity live? (Services? Components? Database?)
4. What conventions are sacred? (Naming, file structure, error handling)
5. What anti-patterns should we avoid? (Found mistakes to not repeat)

Soul documentation:

## Codebase Soul

### Dominant Patterns
- Repository pattern for data access (12 instances)
- Service layer for business logic (18 instances)
- React hooks for state management

### Philosophy
- "Thin controllers, fat services" - Controllers are routing only
- "Composition over inheritance" - No deep class hierarchies
- "Explicit over implicit" - No magic, clear data flow

### Conventions
- PascalCase for components, camelCase for hooks
- Services return Result objects, never throw
- Validation at API boundary, trust internal calls

### Anti-Patterns Observed
- src/legacy/UserManager.ts - God object, 2000+ lines (don't repeat)
- Inconsistent error handling in older services