---
description: Deep first-principles thinking with skill activation and agent orchestration
argument-hint: "[problem or feature]"
---

# Strategic Thinking: $ARGUMENTS

**Objective:** Find the inevitable solution through structured reasoning, research, and craftsmanship.

**Skills activated:**

- sequential-thinking (structured reasoning with revision capability)
- problem-solving/when-stuck (technique dispatch for stuck-types)
- docs-seeker (documentation research)

---

## Phase 1: Structure the Problem

**Use sequential-thinking skill for complex analysis.**

Break down: $ARGUMENTS

**Questions to explore:**

1. What's the REAL problem beneath stated requirements?
2. What assumptions am I making?
3. What would this look like if we started from zero?
4. What's the most elegant solution possible?

**Technique:** Use `sequential-thinking` for multi-step analysis with revision capability.

---

## Phase 2: Research Existing Solutions

**Delegate to @researcher for comprehensive research.**

Create research task:

```
@researcher research $ARGUMENTS

Sources to check:
- Codebase patterns (gkg_search_codebase_definitions)
- Real implementations (gh_grep_searchGitHub)
- Official docs (context7_get-library-docs)
- Knowledge base (rg .opencode/memory/research/)
```

**Alternative:** Use docs-seeker skill for documentation-first research.

**Learn from masters:**

- How do elite codebases solve this?
- What patterns appear across 3+ domains?
- What did they try and abandon?

---

## Phase 3: Apply Problem-Solving Techniques

**Use problem-solving/when-stuck skill to identify stuck-type and dispatch to right technique:**

| Stuck Type                                       | Technique          | Skill Path                               |
| ------------------------------------------------ | ------------------ | ---------------------------------------- |
| Complexity spiraling (5+ ways, special cases)    | Simplification     | problem-solving/simplification-cascades  |
| Need innovation (conventional inadequate)        | Collision thinking | problem-solving/collision-zone-thinking  |
| Recurring patterns (same issue different places) | Meta-patterns      | problem-solving/meta-pattern-recognition |
| Forced by assumptions ("must be this way")       | Inversion          | problem-solving/inversion-exercise       |
| Scale uncertainty (production limits unclear)    | Extremes testing   | problem-solving/scale-game               |

**Technique selection:** Read problem-solving/when-stuck/SKILL.md for dispatch logic.

---

## Phase 4: Design Solution Space

**Present 2-3 approaches with honest analysis:**

### Option 1: [Name that sings its purpose]

- **Core Idea:** [One-sentence inevitable abstraction]
- **Pros:** [Why it's beautiful]
- **Cons:** [Honest tradeoffs]
- **Complexity:** Simple/Medium/Complex

### Option 2: [Alternative vision]

- **Core Idea:** [Different fundamental approach]
- **Pros:** [Strengths]
- **Cons:** [Weaknesses]
- **Complexity:** Simple/Medium/Complex

### Option 3: [Contrarian approach]

- **Core Idea:** [What if opposite is true?]
- **Pros:** [Unexpected benefits]
- **Cons:** [Clear limitations]
- **Complexity:** Simple/Medium/Complex

---

## Phase 5: Craftsmanship Test

**For recommended solution:**

✓ **Could this be simpler?** [Yes/No - if yes, simplify]
✓ **Is every component necessary?** [Yes/No - if no, remove]
✓ **Does naming feel inevitable?** [Yes/No - if no, rename]
✓ **Would this survive 5 years?** [Yes/No - if no, rethink]
✓ **Can you explain it in one sentence?** [Yes/No - if no, too complex]

**Elegance check:**

> The solution should feel so right that no other approach makes sense.
> If you're defending complexity, you haven't found it yet.

**Optional:** Delegate to @code-auditor for design review before implementation.

---

## Phase 6: Implementation Blueprint

**Only present after solution feels inevitable:**

### The Plan

1. [Step that anyone could understand]
2. [Next inevitable step]
3. [Natural progression]

### Edge Cases Handled

- [Graceful degradation]
- [Natural error paths]

### Verification

- [ ] Tests that validate intent, not implementation
- [ ] Cross-platform (macOS/Linux)
- [ ] Rollback strategy

---

## Decision Gate

**Present to user:**

```
🎯 Recommended Solution: [Name]

[One-sentence explanation of why this is inevitable]

Complexity: [Simple/Medium/Complex]
Risk: [Low/Medium/High]
Time: [Estimate]

Alternatives considered and why rejected:
- [Option]: [Fatal flaw or unnecessary complexity]

Ready to implement?
```

**User responses:**

- **"build"** → Delegate to @plan for structured implementation planning
- **"revise [aspect]"** → Return to specific phase, question assumptions again
- **"explain [part]"** → Clarify the vision with more detail
- **"research more"** → Delegate to @researcher for deeper investigation

---

## Principles (Core Philosophy)

**DO NOT:**

- Accept first solution that works
- Implement without questioning assumptions
- Skip the craftsmanship test
- Add complexity without compelling reason
- Proceed without user approval

**DO:**

- Think in first principles
- Simplify ruthlessly
- Make every name inevitable
- Plan so clear anyone understands
- Leave codebase better than found

---

**Remember:** Code should be inevitable. If it's not, you haven't thought deep enough.

_"Simplicity is the ultimate sophistication."_ — Jobs channeling da Vinci
