Thinking
Adjacent skills: thinking (explore, analyse, converge) -> recursive-thinking (adversarial stress-test) -> dream-thinking (retrospective learning).
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.
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 divergent-generation mode when the user wants sustained idea 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
- 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
- Inspect the current code, docs, arguments, and constraints.
- 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.
- 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.
- 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.
- 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.
- 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 the forced comparison.
- 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. - For high-uncertainty ideas, prefer the cheapest credible experiment over a full build.
- 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.
Decision Rules
- 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
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
Anti-patterns
- 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.
These are optional output templates; use them when they make the answer clearer, not as mandatory scaffolding.
Small tasks (clear issue, bounded change):
## Goal
One sentence.
## Key Insight
What matters most about the problem or trade-off.
## Approach
What to change or test and why.
## Validation
How to verify it worked.Medium tasks (multiple files, meaningful trade-offs, moderate ambiguity):
## Goal
What we're trying to achieve and what success looks like.
## Constraints
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, file group, or experiment.
## Validation
Tests, manual checks, or acceptance criteria.Large or ambiguous tasks (cross-cutting, ecosystem, or strategic):
## 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 the chosen path fails.