138 added, 52 removed. Audit A to A.
---
name: thinking
- description: Planning and design skill. Merges convergent planning, focused inquiry, and kaizen-style incremental improvement. Use for quick-to-medium planning tasks where structured thinking improves the outcome. Lighter than a full plan document — heavier than just asking the LLM to think.
+ description: Structured thinking skill. Merges ideation, systems analysis, critical reasoning, and convergent planning. Use when a user needs to explore and narrow a vague idea, challenge assumptions, compare approaches, or converge on a practical next move in the same pass. Do not use when sustained divergence alone is the goal or when a candidate plan already exists and needs adversarial stress-testing.
---
# Thinking
- Adjacent skills: **brainstorming** (divergent generation) → **thinking** (convergent planning) → **recursive-thinking** (adversarial stress-testing) → **dream-thinking** (retrospective learning).
+ Adjacent skills: **thinking** (explore, analyse, converge) -> **recursive-thinking** (adversarial stress-test) -> **dream-thinking** (retrospective learning).
- Use **thinking** when the main need is to converge on a practical plan.
- Do not escalate to **recursive-thinking** unless the decision is high-risk, ambiguous, contentious, or likely to hide important assumptions.
+ Use **thinking** when the job is to move from ambiguity to a clear recommendation, experiment, or implementation-ready plan.
+ Use it when exploration and convergence both matter in the same session.
+ Do not escalate to **recursive-thinking** unless the decision is high-risk, contentious, or likely to hide important assumptions after a solid first pass here.
- Typical chaining:
- - use **thinking** to converge on a plan
- - use **recursive-thinking** to challenge that plan when risk or ambiguity is high
- - use **dream-thinking** after execution, conflict, or reflection-worthy experience
+ ## Core Cadence
+ Run the skill through one simple loop:
+
+ - understand what is stuck
+ - explore only enough to improve the decision
+ - name what matters
+ - choose what changes next
+
+ Everything else in this skill supports that loop.
+
+ ## Switch Skills When
+
+ - switch to **recursive-thinking** when a candidate recommendation, design, or plan already exists and the main job is to pressure-test it
+ - switch to a dedicated brainstorming skill when the user wants sustained divergence, creative volume, or facilitated ideation without convergence pressure
+ - switch to implementation or plan-writing once the main trade-off is settled and the remaining work is execution detail
+
## Default Stance
- - understand the current repo shape before proposing changes
- - prefer incremental, testable improvements over rewrites — unless the complexity is structural (>3 files or ongoing maintenance burden), in which case compare rewrite cost against compounding workaround cost
- - keep plans implementation-ready and decision-complete
+ - inspect the current repo, docs, and constraints before proposing changes
+ - treat exploration and planning as one continuum: diverge only enough to improve the decision, then converge
+ - prefer one focused question at a time when clarification materially changes the outcome
+ - make assumptions explicit instead of silently filling gaps
+ - prefer incremental, testable moves over rewrites unless the complexity is structural
+ - optimise for learning value, carrying cost, and reversibility, not novelty
- remove unnecessary complexity ruthlessly
+ ## Modes
+
+ Pick the lightest mode that fits. Switch modes as new information arrives.
+
+ - **Problem framing**: clarify the real problem, user, constraint, and success signal before discussing solutions
+ - **Ideation**: generate multiple plausible directions when the path is unclear or the first idea is too narrow
+ - **Assumption testing**: surface what must be true, what evidence exists, and what would disprove the current idea
+ - **Systems analysis**: map players, incentives, feedback loops, stocks/flows, and second-order effects when multiple actors interact, local optimisation can damage the whole, or effects compound over time
+ - **Plan convergence**: compare approaches, choose the narrowest viable move, and define validation
+
+ ## Mode Selection
+
+ Before doing substantive work, choose the current mode from the user's actual bottleneck:
+
+ - unclear problem or weak framing -> **Problem framing**
+ - clear problem, unclear options -> **Ideation**
+ - promising option, unclear evidence or risks -> **Assumption testing**
+ - multi-actor, ecosystem, or incentive-heavy problem; at least two actors with misaligned incentives; or clear risk of second-order effects -> **Systems analysis**
+ - enough context gathered, main question is "what should we do?" -> **Plan convergence**
+
+ If the bottleneck changes, say so briefly and switch modes. Do not stay in ideation once one option is clearly ahead and the remaining work is evaluation or planning.
+
## Workflow
- 1. **Inspect** the current code, docs, and constraints.
- 2. **Clarify** goal, success criteria, and out-of-scope items. If ambiguous, ask one focused question.
- 3. **Compare** 2-3 approaches when the choice materially affects the outcome.
- - Compare on: complexity, risk, reversibility, time-to-implement, dependency count.
+ 1. **Inspect** the current code, docs, arguments, and constraints.
+ 2. **Understand what is stuck.**
+ - State the goal, success criteria, and out-of-scope items.
+ - If the user starts with a solution, check whether the underlying problem is actually settled.
+ - If ambiguity is low and one viable path exists, skip heavy ideation.
+ 3. **Explore only enough to improve the decision.**
+ - Ask one focused question at a time.
+ - Prefer multiple choice when choosing one direction.
+ - If the answer will not change the design, make a labeled assumption and continue.
+ 4. **Diverge** when the solution space is still underexplored.
+ - Generate 3-7 distinct directions depending on task size.
+ - Vary along meaningful dimensions: scope, user segment, timing, process vs product, add vs remove, quick win vs durable investment.
+ - Include at least one subtraction or inversion option when useful.
+ - Do not evaluate too early; weak divergence produces fake convergence.
+ - Stop diverging once the option set is meaningfully different and further ideas would mostly repeat earlier patterns.
+ 5. **Name what matters.**
+ - Steelman the core claim or proposal before critiquing it.
+ - List key assumptions, missing evidence, and the riskiest unknown.
+ - For complex systems, map players, incentives, feedback loops, stocks, and flows.
+ - Activate systems analysis when at least two actors have meaningfully different incentives, when a local improvement could hurt the broader system, or when delayed effects are likely to matter.
+ - Trace second-order effects before recommending changes that shift incentives or constraints.
+ - If reasoning gets tangled, break it into sequential steps and revise earlier conclusions explicitly.
+ - If the user mainly wants critique of an already-formed plan, spend most of the pass here instead of reopening wide ideation.
+ 6. **Compare** 2-3 serious approaches when the choice materially affects the outcome.
+ - Compare on: user value, complexity, risk, reversibility, time-to-validate, and carrying cost.
- For each rejected approach, state why it lost in one line.
- - If only one viable approach exists, say so and skip comparison.
- 4. **Choose** the approach with the least unnecessary complexity.
- - "Narrowest" = fewest behavioral changes, smallest API surface, least cross-cutting risk.
+ - If only one viable approach exists, say so and skip the forced comparison.
+ 7. **Choose what changes next.**
+ - "Narrowest" means the smallest step that meaningfully improves the situation or tests the key assumption.
- When narrowest conflicts with quality, prefer quality unless explicitly time-boxed.
- 5. **Produce** a concrete plan using the output structure below.
+ - For high-uncertainty ideas, prefer the cheapest credible experiment over a full build.
+ 8. **Produce** a concrete output using the structure below.
+ - If the best next move is learning rather than building, the output may be an experiment, decision memo, or research step instead of an implementation plan.
- ## Plan Revision
+ ## Decision Rules
- Watch for: blocked on something unanticipated, new constraint discovered during implementation, execution diverging from assumptions. When any fires: update the plan before continuing.
+ - Understand the argument in terms its owner would accept before critiquing it.
+ - Separate conclusions, supporting points, evidence, and assumptions.
+ - Distinguish symptoms from root causes; keep asking why until the frame stops moving.
+ - Keep the core cadence visible in the response: what is stuck, what matters, and what changes next.
+ - Keep divergence and convergence explicit; do not mix them so loosely that the user cannot tell whether you are still exploring or already recommending.
+ - Flag hidden incentives and local optimisations that could damage the larger system.
+ - Prefer options that create durable leverage, not just local relief.
+ - Use frameworks as tools, not templates. Pull in only the smallest one that improves the decision.
+ - If new constraints appear during implementation, update the plan before continuing.
## Planning Stop Test
- Planning is sufficient when all three are true:
- - the next implementation step is concrete
+ Thinking is sufficient when all three are true:
+
+ - the next step is concrete
- the main trade-off has been decided or explicitly deferred
- validation is clear enough to detect failure
- ## Focused Inquiry Rules
-
- - ask only questions that materially change the design
- - prefer one issue at a time over broad unfocused discovery
- - validate assumptions early when they affect architecture or rollout
-
- ## Kaizen Rules
-
- - make invalid states harder to express
- - use the type system, validation, and clear contracts to prevent mistakes
- - when modifying a file, fix at most one small adjacent issue — do not refactor unrelated code
-
## Anti-patterns
- - inventing weak alternative approaches just to satisfy the comparison step
- - asking broad discovery questions that do not change the plan
- - producing a plan that sounds organized but leaves the next action ambiguous
+ - converging on the first plausible idea without exploring alternatives
+ - inventing weak alternatives just to satisfy the comparison step
+ - asking broad discovery questions that do not change the decision
+ - treating frameworks like checklists instead of thinking tools
+ - critiquing a claim before restating it fairly
+ - analysing only first-order effects in multi-stakeholder systems
+ - staying in ideation after the decision has effectively been made
- using "narrowest" to justify avoiding necessary quality improvements
+ - producing a plan that sounds organised but leaves the next action ambiguous
## Output Structure
Scale to task size.
- **Small tasks** (single file, clear approach):
+ **Small tasks** (clear issue, bounded change):
- ```
+ ```markdown
## Goal
One sentence.
+ ## Key Insight
+ What matters most about the problem or trade-off.
+
## Approach
- What to change and why.
+ What to change or test and why.
## Validation
- How to verify it works.
+ How to verify it worked.
```
- **Medium tasks** (multiple files, trade-offs):
+ **Medium tasks** (multiple files, meaningful trade-offs, moderate ambiguity):
- ```
+ ```markdown
## Goal
What we're trying to achieve and what success looks like.
## Constraints
- What's out of scope, what must not break.
+ What must not break, what is out of scope.
+ ## Assumptions
+ What we're taking as given and what would invalidate the plan.
+
## Approach Comparison
| Approach | Pros | Cons | Risk |
|----------|------|------|------|
| A | ... | ... | ... |
| B | ... | ... | ... |
Chosen: A, because [reason]. Not B, because [reason].
## Key Changes
- By subsystem or file group.
+ By subsystem, file group, or experiment.
## Validation
Tests, manual checks, or acceptance criteria.
-
- ## Assumptions
- What we're taking as given. What would invalidate the plan.
```
- **Large tasks** (cross-cutting, architectural): Medium template plus:
+ **Large or ambiguous tasks** (cross-cutting, ecosystem, or strategic):
- ```
+ ```markdown
+ ## Goal
+ What we're trying to achieve and why it matters now.
+
+ ## System View
+ Players, incentives, constraints, and important second-order effects.
+
+ ## Assumptions and Risks
+ What must be true, what is most likely to fail, and what evidence is missing.
+
+ ## Approach Comparison
+ | Approach | Upside | Cost | Risk | Reversibility |
+ |----------|--------|------|------|---------------|
+ | A | ... | ... | ... | ... |
+ | B | ... | ... | ... | ... |
+
+ Chosen: A, because [reason]. Not B, because [reason].
+
## Phases
Ordered steps with dependencies noted.
+ ## Validation
+ What success and failure look like.
+
## Rollback
- What to do if a phase fails.
+ What to do if the chosen path fails.
```