Curated Agent Skills (SKILL.md): structured thinking lenses, decision support, and brainstorming workflows for AI coding agents.
>
# Analytical Thinking
Clarity beats cleverness. End with an answer tied to structure and a stated confidence.
## When to use
- Explaining or predicting a number: a metric moved, a cost is high, a funnel leaks.
- A messy question that needs a driver tree, hypotheses and a plan for what data to collect.
- Comparing concrete alternatives against criteria when the user wants the reasoning laid out.
Skip: open-ended idea generation with nothing to measure, or a short verdict with no decomposition asked for.
## Before you start
1. State in one block: **Analytical question** (precise, ideally falsifiable) and **Pass** (Frame, Decompose, Hypotheses, Evidence, Synthesis).
2. **Gather first.** If you can query data, read dashboards, logs or code, do that before listing Evidence. Ask up to 3 questions only for definitions or data that tools cannot supply.
3. **Light path.** Small ask: a 2-level tree, 2 hypotheses, one observation each, answer in 3 lines.
4. If the user is choosing among concrete options, insert an **Options matrix** after Evidence: rows are options, columns are criteria (state any weights), cells are `-`, `0` or `+` with a one-line reason. Then Synthesis.
## Steps
### 1. Frame
**Question type** (estimate, compare, explain, predict, optimize), **unit of analysis**, and **baseline** (even a hypothetical one).
### 2. Decompose
A tree or table of drivers or workstreams. Aim for branches that do not overlap and together cover the question well enough for the decision.
### 3. Hypotheses
Ranked H1, H2, H3. For each: what would we see if it were true, and what would **falsify** it?
### 4. Evidence
For each hypothesis: **Observation:** ... - **Strength:** one sentence on how much it supports or undermines the hypothesis and its main limit. **Caveat:** ...
No real data? Replace this step with a section titled **Thought experiment (no data)**. Inputs you guess are shown as ranges and marked `[ESTIMATED]`.
### 5. Synthesis
1. **Answer** to the analytical question.
2. **Key uncertainty:** the one unknown that swings the answer most.
3. **Next data or step:** what to collect or run next.
## Pitfalls
- Mixing Hypotheses and Evidence in one list. Keep them separate.
- Reading a pattern from a few data points. State sample size or window.
- Ignoring base rates (how often this happens anyway) and confounders (what else changed).
- A single point estimate from guessed inputs. Use ranges and show which input moves the result most.
- A tree whose branches overlap, so the same cause is counted twice.
Worked example: [references/example.md](references/example.md).
## Checklist
- [ ] Question and Pass stated (Options matrix noted if used)
- [ ] Frame gives question type and baseline
- [ ] Decompose is scannable
- [ ] Hypotheses have falsifiers
- [ ] Evidence (or Thought experiment) maps to hypotheses; guesses marked `[ESTIMATED]`
- [ ] Synthesis: answer, key uncertainty, next step>
# Creative Thinking
Defer judgment while generating. Keep **generate** (Prime, Diverge, Connect) separate from **Harvest** (pick and plan).
## When to use
- The user wants variety: names, concepts, features, angles, campaigns, designs.
- The user says the first idea is not good enough and wants more options.
- A choice is coming and the option list is still thin.
Skip: a single delivered answer with no exploration, audit-only teardown, mechanical execution. If the user is stuck in a rut and wants deliberately odd angles, a provocation-based approach fits better than plain divergence.
## Before you start
1. State in one block: **Creative brief** (goal, audience, constraints such as time, tone, taboos) and **Pass** (Prime, Diverge, Connect, Harvest).
2. **Gather first.** If you can read the project, brand docs or earlier attempts, do it so ideas fit the context. Ask up to 3 questions only for what tools cannot answer.
3. **Light path.** Small ask: 6 ideas, 2 mashups, 3 picks. Default sizes: Diverge 10-15 ideas, Connect 3 mashups.
4. If the user is stuck on one framing, add a **Perspectives** beat before Diverge: Optimist, Skeptic, Outsider, two reframes each, no cross-critique yet.
## Phases
### 1. Prime
2-4 bullets: what would a delightful or surprising success look like? What must not be violated?
### 2. Diverge
Quantity first. Tag each idea `F` (flexible reuse of something existing), `N` (novel twist) or `W` (wild, may be impractical).
Use at least two triggers from: **analogy** (unrelated domain), **constraint flip** (remove or add a rule), **user fantasy** (absurd ideal), **time shift** (past or future), **scale shift** (micro or macro).
### 3. Connect
Combine ideas: **A + B ->** hybrid concept in a few lines. Fewer than Diverge, never just one unless the brief is tiny.
### 4. Harvest
1. **Top picks:** 3 ideas with a selection rationale tied to the brief.
2. **Next creative step:** for example a storyboard, a user interview, a spike, a moodboard.
3. **Parking lot:** 2 promising ideas deferred, and why.
## Pitfalls
- Criticizing during Prime, Diverge or Connect. Park risks for a separate pass.
- Ten variations of one idea. Check that triggers produced different directions.
- Ideas that ignore the brief's constraints. Re-read Prime before Harvest.
- Claiming user research happened. Label any benefit as hypothetical.
Worked example: [references/example.md](references/example.md).
## Checklist
- [ ] Brief and Pass stated (Perspectives if used)
- [ ] Diverge uses two or more triggers; ideas tagged F, N or W
- [ ] Connect has several mashups
- [ ] Harvest: top picks, next step, parking lot
- [ ] No criticism before Harvest>
# Critical Thinking
Disciplined inquiry that keeps **description** apart from **evaluation**: surface assumptions, weigh evidence, test logic, consider alternatives, then give a proportionate conclusion. If the conventional view is well supported, say so. This is inquiry, not contrarianism.
## When to use
- The user asks whether a claim, argument, plan, estimate or belief holds up.
- Phrases like "what am I missing", "steelman", "red team", "devil's advocate", "bias check", "is my reasoning sound".
- A decision about to be made on thin or one-sided evidence.
Skip: execution-only tasks, wording or tone edits, open-ended brainstorming with no request to audit reasons.
## Before you start
1. State in one block: **Focus** (the claim or plan under review) and **Pass** (Clarify, Information, Assumptions, Reasoning, Alternatives, Conclusion).
2. **Gather first.** If you can read the repo, docs or data, check them before marking anything `[MISSING]`. Ask up to 3 questions only for what tools cannot answer.
3. **Light path.** Small ask: 1-3 lines per phase, same order, Conclusion always included.
## Phases
### 1. Clarify
Restate the target in one precise sentence. Split **factual** from **normative** claims. Name the success criteria if a decision is involved.
### 2. Information
Each bullet starts with `[CITED]` or `[MISSING]`.
- `[CITED]`: name the basis (user text, file, doc, link, study) and one line on its strength or limits.
- `[MISSING]`: no traceable basis yet, or it was requested and not available.
### 3. Assumptions
**Assumption:** ... - **If false:** ...
When the Focus mixes "is" and "should", add **Value premise:** ... - **If rejected:** ...
### 4. Reasoning
Trace the argument chain. Flag leaps, circularity, correlation vs causation, missing steps. Add no new facts here. A premise never established in Information is an **ungrounded premise** (a structural gap, not a fact).
Bias and fallacy pass, only items that apply (or one line saying none):
- Biases to consider (examples): confirmation, anchoring, survivorship, authority, sunk cost.
- Fallacies to name if present: ad hominem, straw man, false dichotomy, slippery slope, hasty generalization, begging the question.
### 5. Alternatives
Credible competing explanations, plans or frames. Keep them plausible, not debate rhetoric.
### 6. Conclusion
1. **Judgment** answering the Focus. When facts and values both matter, separate what follows from the cited evidence from what depends on value premises. End with one plain sentence on how strong the case is given `[CITED]` vs `[MISSING]`.
2. **What would change the judgment:** concrete new data or falsifiers, phrased for the Focus.
## Pitfalls
- Inventing a citation to avoid writing `[MISSING]`. Say it is missing.
- Smuggling new facts into Reasoning or Conclusion.
- Listing every bias in the book. Name only those that bite this case.
- Manufacturing objections to a sound argument. Proportionate beats exhaustive.
- Arguing with a person's position instead of its chain. If the user is emotionally attached, name it neutrally and continue.
Worked example: [references/example.md](references/example.md).
## Checklist
- [ ] Focus and Pass stated
- [ ] Phases in order; Conclusion present
- [ ] Information bullets start with `[CITED]` (basis + limits) or `[MISSING]`
- [ ] Assumptions carry If false (and Value premise when facts and values mix)
- [ ] Reasoning adds no facts; ungrounded premises flagged; bias pass done or "none"
- [ ] Conclusion: judgment, strength sentence, what would change it>
# Design Thinking
Fall in love with the problem, not the first solution. End with **what to learn next**, not just ideas.
## When to use
- A product, service or UX problem where the real user need is unclear.
- "How might we" framing, discovery sprints, concept validation before building.
- Reframing a request using what users actually do or say.
Skip: the spec is fully frozen and no discovery is wanted, or the task is code-only maintenance with no user problem to frame.
## Before you start
1. State in one block: **Design challenge** (who is affected, in what situation) and **Pass** (Empathize, Define, Ideate, Prototype, Test plan).
2. **Gather first.** Read tickets, interview notes, support threads, analytics or the product itself before writing Empathize. Ask up to 3 questions only for users, constraints or success signals that tools cannot answer.
3. **Light path.** Small ask: 1-2 lines per stage, 3 ideas, one prototype, 2 signals.
4. If Empathize has no real user input, say so in Define and keep the POV narrow. Never invent research.
## Stages
### 1. Empathize
- **Who:** primary user or stakeholder. Mark facts from the user versus `[INFERRED]`.
- **Jobs, pains, gains:** what they are trying to do and what hurts.
- **Context:** when and where the need shows up.
No fabricated quotes. Paraphrase only what the user supplied.
### 2. Define
- **Insight:** a non-obvious tension connecting pains and context.
- **POV:** "**[User]** needs **[verb]** because **[insight]**."
- **How Might We:** 2-3 well-scoped questions opened by the POV.
### 3. Ideate
Quantity and variety, using each HMW as a prompt. Tag each idea `desirable`, `feasible` or `viable` as a **hypothesis**, not a fact. Default 8-10 ideas unless the user sets a number.
### 4. Prototype
Describe low-fidelity artifacts: paper flow, roleplay script, landing-page smoke test, clickable sketch. For each: **Purpose:** the question it answers. **Fidelity:** one line placing it between sketch-only and interactive.
### 5. Test plan
- **Learning goals:** what would convince you the idea is wrong?
- **Participants:** who and how many, or "to be decided".
- **Signals:** behaviors or metrics to observe, stated so they can fail.
- **Next iteration:** what changes if results are mixed.
## Pitfalls
- A POV that restates the solution ("users need a dashboard").
- HMW questions that are too broad ("improve the experience") or too narrow (they hide the solution).
- Treating desirable / feasible / viable tags as proven.
- A Test plan with no signal that could show the idea is wrong.
Worked example: [references/example.md](references/example.md).
## Checklist
- [ ] Challenge and Pass stated
- [ ] Empathize separates facts from `[INFERRED]`
- [ ] POV and HMW before Ideate
- [ ] Ideas tagged desirable, feasible or viable as hypotheses
- [ ] Prototype gives purpose and a fidelity line
- [ ] Test plan has learning goals and falsifiable signals>
# Ethical Thinking
Ethics is about **conflicts between legitimate goods**. End with transparent tradeoffs, not false certainty.
## When to use
- A product, policy or data decision that could affect people: privacy, fairness, consent, manipulation, safety.
- "Should we?" questions that go beyond "can we" or "is it legal".
- AI and data ethics reviews, stakeholder harm scans, moral review of a plan.
Skip: legal advice as such, neutral fact-finding with no values review requested, implementation-only work.
## Before you start
1. State in one block: **Focal action** (what is being considered) and **Pass** (Stakeholders, Values, Harms and Benefits, Justice and Power, Options, Recommendation).
2. **Gather first.** Read the design doc, data fields, policy text or code to learn who and what is actually affected before assuming. Ask up to 3 questions only for affected parties or red lines that tools cannot answer.
3. **Light path.** Small ask: 2-3 lines per lens, 2 options. For a pure harm scan you may compress Values, but still cover Justice and Power before Options.
## Lenses
### 1. Stakeholders
Who is affected: direct, indirect, future, non-human where ecology matters. For vulnerable groups, describe dependence, cognitive load or marginalization in plain words and one sentence on why that raises caution. Justify from the context; never stereotype.
### 2. Values
Which values are in play (autonomy, beneficence, non-maleficence, justice, dignity, solidarity, others)? Name at least one **value tension**: **A vs B**, and why both matter here.
### 3. Harms and Benefits
Concrete harms and benefits. For each: how plausible, under what conditions, and how reversible. Separate **predicted** from **observed** when the user supplies history.
### 4. Justice and Power
Who carries the burdens and who gets the benefits? Who can say no, and who bears the cost of errors? Check procedural fairness: voice, consent, appeal.
### 5. Options
Two or more ethically distinct paths, including "do not proceed" when plausible:
> **Option:** ... - **Value fit:** ... - **Residual harm:** ... - **Safeguards:** ...
### 6. Recommendation
A preferred option if the analysis supports one, or conditional guidance. Include the **strongest reason against** your recommendation and **what to monitor** if the plan proceeds.
## Rules
1. Do not demonize actors; focus on structures, incentives and foreseeable effects.
2. If values truly clash, say so and recommend a process (deliberation, oversight) instead of fake unanimity.
3. Never invent sensitive personal facts about real people; use only what the user gave.
4. Not legal advice. Where law may bind, write "legal review needed" and do not predict legal outcomes.
## Pitfalls
- A stakeholder list that stops at "users". Include the people who bear the cost without using the product.
- Harm stated with no plausibility or conditions, which reads as either alarmist or empty.
- A Recommendation with no dissent. If you cannot name the strongest objection, the analysis is unfinished.
- Safeguards that are only intentions ("we will be careful"). Name an owner or a mechanism.
Worked example: [references/example.md](references/example.md).
## Checklist
- [ ] Focal action and Pass stated
- [ ] Stakeholders include indirect or future parties when relevant
- [ ] At least one explicit value tension
- [ ] Harms and benefits give plausibility; options list safeguards
- [ ] Justice and Power covers distribution, voice and consent
- [ ] Recommendation names residual harm and the strongest dissent>
# Fermi Estimation
Get a defensible order-of-magnitude answer from factors you can reason about. The goal is the right power of ten and a clear view of what drives it, not a precise number.
## When to use
- Capacity, load, storage, cost, headcount, market size or time estimates with little data.
- "Roughly how many", "ballpark", "back of the envelope", "is it even feasible".
- Checking whether a plan's numbers are plausible before investing in measurement.
Skip: when exact data exists (query it instead), or the user needs a precise calculation.
## Before you start
1. State in one block: **Quantity** (with units and period), **Purpose** (what decision depends on it), **Needed accuracy** (a power of ten, or within a factor of 2), and **Pass** (Decompose, Estimate, Combine, Cross-check, Sensitivity).
2. **Gather first.** Look for real anchors before guessing: logs, dashboards, billing, docs, prior numbers. Replace any guess with data you can find. Ask up to 3 questions only for anchors tools cannot supply.
3. **Light path.** Small ask: 3-4 factors, one range each, a result line and one cross-check.
## Steps
### 1. Decompose
Break the quantity into factors you can estimate, usually a product: population x frequency x size, or rate x time. Write the formula first.
### 2. Estimate
For each factor give a **low** and **high** and a one-line basis. Mark guesses `[ESTIMATED]`; mark found data with its source.
| Factor | Low | High | Basis |
|--------|-----|------|-------|
### 3. Combine
Multiply lows and highs for bounds. For a single central value, take the geometric midpoint (the square root of low x high), which suits ranges that span powers of ten. Report the result as a range and an order of magnitude.
### 4. Cross-check
Estimate the same quantity a second way (top-down vs bottom-up, or compare to a known similar system). If the two differ by more than about 3x, find which factor is off.
### 5. Sensitivity
Name the one or two factors that move the answer most, and what measurement would narrow them.
## Pitfalls
- False precision: "47,312 requests per second" from guessed inputs. Round to one significant figure.
- Unit mismatches (per day vs per second, bytes vs bits). Write units in every row.
- Double counting a factor that appears in two inputs.
- Anchoring on the first number you thought of. Estimate the low and high first, then the middle.
- Skipping the cross-check, which is what separates an estimate from a guess.
- Forgetting peaks: averages hide the busiest hour. State average and peak when sizing capacity.
Worked example: [references/example.md](references/example.md).
## Checklist
- [ ] Quantity, units, purpose and needed accuracy stated
- [ ] Formula written before numbers
- [ ] Each factor has low, high, basis; guesses marked `[ESTIMATED]`
- [ ] Result as a range and order of magnitude
- [ ] Cross-checked a second way
- [ ] Dominant factor named, with the measurement that would narrow it>
# First Principles Thinking
Question inherited baggage. Rebuild only from **bedrock** you can defend.
## When to use
- "Why do we do it this way?", "is this really required?", "what would this cost if we started from scratch?"
- A strategy or design copied from an incumbent ("like Uber for X") that nobody has checked.
- Cost, architecture or process choices that exist only because they always have.
Skip: quick convention-following checklists with no wish to revisit assumptions, or purely social coordination with nothing to model.
## Before you start
1. State in one block: **Reconstruction target** (belief, cost, design or strategy to ground) and **Pass** (Surface, Question, Bedrock, Rebuild, Implications).
2. **Gather first.** Read the code, contracts, specs or data that show what is actually required (a regulation, an SLA, a measured limit) before tagging anything fundamental. Ask up to 3 questions only for immutable constraints that tools cannot answer.
3. **Light path.** Small ask: 3 assumptions, 3 bedrock items, a 3-step rebuild, 2 implications.
## Steps
### 1. Surface
State the conventional answer or the analogy people rely on. List loaded words and hidden comparisons.
### 2. Question
For each major assumption: **Assumption:** ... - **Why believed?** (authority, analogy, experience) - **What if false?**
### 3. Bedrock
List truths that survive scrutiny: physics, logic, arithmetic, legal musts, documented needs of real users. Tag each `[FUNDAMENTAL]` or `[ASSUMPTION]`.
Aim for three or more honest bedrock items. If fewer exist, say why in one line.
### 4. Rebuild
Derive conclusions in numbered steps using only `[FUNDAMENTAL]` items. "Industry standard" is not a premise unless translated into a fundamental (for example "buyers require SLA X because regulation Y"). A new premise goes into Bedrock first, with a tag.
### 5. Implications
- **So what:** what changes versus the conventional path.
- **Cost of being wrong** if a tagged assumption fails.
- A short **vs convention** contrast when it helps the decision.
If bedrock is too thin to rebuild, write **insufficient grounding** and list the evidence that would fix it.
## Pitfalls
- Calling a preference or a habit "fundamental".
- Rebuilding from first principles and arriving exactly at the old answer. That is fine if each step is defended; say so.
- Faux profundity. Keep every step short and checkable.
- Ignoring switching cost. A better design from scratch may not beat the current one after migration.
Worked example: [references/example.md](references/example.md).
## Checklist
- [ ] Target and Pass stated
- [ ] Surface names the convention or analogy
- [ ] Question ties each assumption to why it is held
- [ ] Bedrock tagged `[FUNDAMENTAL]` or `[ASSUMPTION]`
- [ ] Rebuild uses only fundamentals
- [ ] Implications name what changes and the cost of being wrong>
# Five Whys
A root-cause method from the Toyota Production System. Ask "why" of the previous answer until you reach a cause you can change, and check each link with evidence.
## When to use
- An incident, outage, defect, missed deadline or process failure needs its real cause.
- A problem repeats after quick fixes.
- A postmortem or retrospective needs a causal chain, not a list of symptoms.
Skip: a typo or one-line bug whose cause is already visible, or questions about metrics that need data analysis rather than a causal chain.
## Before you start
1. State in one block: **Problem statement** (what happened, where, when, impact, in observable terms) and **Pass** (Chain, Check, Branch if needed, Countermeasures).
2. **Gather first.** Read logs, commits, tickets, timelines and configs before answering any "why". Mark each answer `verified` (you saw evidence) or `hypothesis` (plausible, not yet checked). Ask up to 3 questions only for facts tools cannot reach.
3. **Light path.** Small ask: the chain in 3-5 lines, one countermeasure per root cause.
## Steps
### 1. Chain
Write the problem, then ask why. Each "Why" answers the previous answer, not the original problem.
| # | Why did that happen? | Status | Evidence |
|---|----------------------|--------|----------|
| 1 | ... | verified / hypothesis | file, log line, ticket |
Five is a guide. Stop earlier or later when you reach a cause that is (a) within the team's control and (b) such that fixing it would have prevented the problem.
### 2. Check
- **Reverse test:** read the chain from the bottom up with "therefore". Each step must follow from the one below.
- **Stop test:** if the last answer is "human error", "not enough time" or "bad luck", ask why once more. These describe a missing safeguard, not a cause.
- Mark any link still `hypothesis`; list how to verify it.
### 3. Branch (only if causes split)
When one "why" has several valid answers, follow each as its own chain. If the causes spread across many areas, group them under People, Process, Tools, Environment, Data or Measurement (a fishbone view) and chain the top two or three.
### 4. Countermeasures
For each root cause:
- **Contain:** stop the damage now.
- **Fix:** remove the cause.
- **Prevent:** a check or guardrail so it cannot recur.
- **Owner and date**, or "to be assigned".
## Pitfalls
- Jumping to a favorite cause and filling the chain backward to justify it.
- Asking "who" instead of "why". Blame ends the chain early; look for the missing safeguard.
- Single-chain thinking on a complex failure. Branch when there are several causes.
- Stopping at a cause nobody can change (for example "the vendor was down") without asking why there was no fallback.
- Treating `hypothesis` rows as findings in the summary.
Worked example: [references/example.md](references/example.md).
## Checklist
- [ ] Problem statement is observable (what, where, when, impact)
- [ ] Each why answers the previous answer; each row is `verified` or `hypothesis`
- [ ] Reverse test passed; no chain ends at "human error"
- [ ] Branches followed where causes split
- [ ] Countermeasures cover contain, fix, prevent, with owners>
# Lateral Thinking
Edward de Bono's method for escaping a rut: **movement before judgment**. A provocative line is a stepping stone, never a final position.
## When to use
- Brainstorming stalled or every option is a small variation of the current one.
- The user wants a surprising angle, a reframe, or to challenge an assumption they call "just how it works".
- Conventional ideation already ran and produced nothing fresh.
Skip: a single compliant rule lookup, a tight logical proof, or users with no appetite for playful what-if moves.
## Before you start
1. State in one block: **Stuck point** (which pattern or assumption feels rigid) and **Pass**: Provocation, Extract principle, Concept fan, Candidates (or the alternate path below).
2. **Gather first.** If you can read the project or earlier attempts, check what was already tried so you do not repeat it. Ask up to 3 questions only for safety or legal limits that tools cannot answer.
3. **Light path.** Small ask: one Po, one principle, 2 ideas per fan level, 3 candidates.
Alternate paths (use only when the user asks):
- **Random entry:** replace Provocation with one random noun or image, then bridge in 3 steps (property, analogy, mechanism, application).
- **Challenge implicit rules:** list the rules everyone follows; for each give **Challenge / Reframe / Smallest test**; pick the load-bearing rule and give two ways to sidestep it; then Candidates only from that thread.
## Moves
### 1. Provocation
One primary Po (it may be illogical or impossible):
> **Po:** ... - **Movement idea:** what useful idea does this suggest if treated as a springboard?
### 2. Extract principle
From the movement idea, state one operating principle that could work in the real world, even if the Po itself is absurd.
### 3. Concept fan
Step back from the principle to broader aims, then fan forward. Three levels, per de Bono:
- **Directions:** the broadest approaches ("make the problem disappear", "make waiting pleasant").
- **Concepts:** general methods under each direction.
- **Ideas:** specific, actionable ways to carry out a concept.
Give a few branches at each level. If nothing is good enough, step back one more level and fan out again.
### 4. Candidates
Several actionable ideas, each tagged `near-term`, `stretch` or `experimental`.
## Rules
1. Never present a Po as a recommendation. Always pair it with its movement idea or principle.
2. If a provocation touches safety, ethics or law, stop and name the conflict. Do not rationalize harm.
3. Judge only in Candidates, and only for tagging feasibility.
## Pitfalls
- A Po that is merely a bad idea. It should shift your thinking, not be wrong for its own sake.
- Jumping to Candidates from the Po and skipping the principle. The principle is what makes it portable.
- Fan levels that all say the same thing. Each level should widen or narrow, not repeat.
Worked example: [references/example.md](references/example.md).
## Checklist
- [ ] Stuck point and Pass stated (alternate path noted if used)
- [ ] Po paired with a movement idea, or the alternate path completed
- [ ] Fan covers Directions, Concepts and Ideas
- [ ] Candidates tagged near-term, stretch or experimental
- [ ] No Po presented as policy>
# Pre-mortem
Gary Klein's technique: imagine the plan **has already failed**, then work backward to explain why. Assuming failure makes it safe to name risks that optimism hides.
## When to use
- Before a launch, migration, reorg, contract, hire, architecture change or any hard-to-reverse commitment.
- "What could go wrong?", "stress test this", "play out the failure".
- A plan everyone likes and nobody has attacked.
Skip: explaining a failure that already happened, or reviewing the logic of an argument rather than a plan.
## Before you start
1. State in one block: **Plan** (what, who, by when), **Failure definition** (what "failed badly" means, observable), **Horizon**, and **Pass** (Imagine, Causes, Rank, Mitigate, Decide).
2. **Gather first.** Read the plan, timeline, dependencies, past incidents and similar launches before generating causes. Ask up to 3 questions only for what tools cannot answer.
3. **Light path.** Small ask: 6 causes, top 3 ranked, one mitigation each.
## Steps
### 1. Imagine
Write one sentence in the past tense: "It is [date]. The [plan] failed badly: [failure definition]."
### 2. Causes
List reasons it failed. Cover different angles so they do not cluster: people and skills, process and timeline, technology and dependencies, customers and market, money, external events. Add one **inversion** prompt: "What would guarantee failure?" and list what you would then have to avoid. Each cause is a specific story ("the vendor API changes its rate limit during launch week"), not a category ("vendor risk").
### 3. Rank
For each cause give a plain-language **likelihood**, **impact** if it happens, and an **early warning sign**. Keep the top 5-8.
| Cause | Likelihood | Impact | Early warning |
|-------|-----------|--------|---------------|
### 4. Mitigate
For each top cause choose one:
- **Prevent:** change the plan so it cannot happen.
- **Detect:** a metric or check that shows it early.
- **Respond:** a rehearsed fallback.
Add an **owner** (or "to be assigned").
### 5. Decide
- **Plan changes** to make now.
- **Tripwires:** conditions under which the plan is paused, changed or stopped.
- **Go / no-go** statement: go as is, go with changes, or hold until named risks are reduced.
## Pitfalls
- Generic risks ("scope creep") with no story. Write what it looks like when it happens.
- Everything high likelihood and high impact. Force a ranking; a list where all items matter does not guide action.
- Mitigations nobody owns. Name an owner or mark it unassigned.
- Using it on something already failed. That is a postmortem; use a root-cause method.
- Treating the output as a promise that nothing else will go wrong. Revisit at each tripwire.
Worked example: [references/example.md](references/example.md).
## Checklist
- [ ] Plan, failure definition and horizon stated
- [ ] Failure written in the past tense
- [ ] Causes are specific stories across several angles, plus an inversion prompt
- [ ] Ranked with likelihood, impact and an early warning sign
- [ ] Mitigations are prevent, detect or respond, with owners
- [ ] Tripwires and a go / no-go statement>
# Prioritization
Order a list of work by value and cost, and draw a cut line. Pick the lightest method that fits the situation; precision beyond the quality of your inputs is noise.
## When to use
- A backlog, roadmap, bug list, feature list or task list larger than capacity.
- "What first?", "what can we cut?", "MVP scope", "RICE / ICE / MoSCoW".
- A stakeholder disagreement about order that needs a transparent method.
Skip: choosing between two or three alternative designs or vendors on tradeoffs, or estimating a single number.
## Before you start
1. State in one block: **Goal** the ranking serves, **Capacity or deadline**, **Items** (count), and **Pass** (Pick method, Score, Rank, Cut line, Sanity check).
2. **Gather first.** Read the backlog, tickets, usage data, customer requests and past estimates. Never invent reach or effort numbers; mark guesses `[ESTIMATED]` and give a range. Ask up to 3 questions only for goals and capacity tools cannot answer.
3. **Light path.** Small ask: pick a method in one line, score in one table, name the top 3 and the cut line.
## Steps
### 1. Pick the method
| Situation | Method |
|-----------|--------|
| Many items, some data on users and effort | **RICE** |
| Many items, quick gut-level estimates | **ICE** |
| Fixed deadline or MVP, need to cut scope | **MoSCoW** |
| Few items, fast triage in a meeting | **Impact-effort 2x2** |
| Personal or team task triage | **Eisenhower** (urgent x important) |
State the choice and why in one line.
### 2. Score
- **RICE** = Reach x Impact x Confidence / Effort. Reach: people or events per period. Impact: 0.25 minimal, 0.5 low, 1 medium, 2 high, 3 massive. Confidence: 100%, 80% or 50%. Effort: person-months.
- **ICE** = Impact x Confidence x Ease, each 1-10.
- **MoSCoW:** Must, Should, Could, Won't (this time). Keep Musts to roughly 60% of capacity so there is room for surprises.
- **Impact-effort:** place each item in quick wins (high impact, low effort), big bets, fill-ins or avoid.
Show the table with one-line basis for each score.
### 3. Rank
Sort by score. Break ties by dependencies (what unblocks others), risk reduction, and cost of delay.
### 4. Cut line
Mark where capacity runs out. Name what is deliberately **not** done.
### 5. Sanity check
Compare the top of the list with your intuition. If they disagree, find the input that drives the difference and decide whether the score or the intuition is wrong.
## Pitfalls
- False precision: scores of 41.2 vs 39.8 are a tie.
- Everything is a Must. If Musts exceed capacity, the method has not helped yet; force a cut.
- Scoring effort in the author's own optimistic hours. Ask the people who will do the work.
- Ignoring dependencies: the highest score may need a lower item first.
- Gaming: the scorer favors a pet item. Have someone else check the top 3 inputs.
- Hiding that the ranking serves a goal. State the goal; a different goal changes the order.
Worked example: [references/example.md](references/example.md).
## Checklist
- [ ] Goal, capacity and item count stated
- [ ] Method chosen with a reason
- [ ] Every score has a basis; guesses marked `[ESTIMATED]`
- [ ] Ties broken by dependencies, risk and cost of delay
- [ ] Cut line drawn; not-doing list named
- [ ] Sanity check done>
# Six Thinking Hats
Edward de Bono's **parallel thinking**: everyone wears the same hat at the same time, so facts, feelings, risks, benefits and new ideas stop arguing inside one reply. One **focus question**, six roles in sequence.
## When to use
- A decision, plan or idea where the user keeps mixing "what is true", "how I feel", "what could break" and "what could be great".
- The user names the method, de Bono, or asks for a hat-by-hat pass.
- A brainstorm or review that needs structure and a closing synthesis.
Skip: factual lookups, execution-only work, quick opinions where the user does not want six separate passes.
## Before you start
1. Open with a short **Blue (open)** block: focus question (one sentence), mode, hat order. This block is the opening Blue pass; do not print a second opening section.
2. **Gather first.** If you can read files, search or run queries, do it before filling White. Ask up to 3 questions only for what tools cannot answer, then proceed and note gaps in plain words.
3. **Light path.** Small ask: 2 bullets per hat, 3-bullet synthesis. Otherwise 3 bullets per hat; add detail only when the user asks for depth.
## Modes
| Mode | Hat order | Use for |
|------|-----------|---------|
| **Full** (default) | Blue, White, Red, Black, Yellow, Green, Blue | Broad decisions |
| **Creative** | Blue, Green, Yellow, Red, Blue | Idea generation (no early criticism) |
| **Risk** | Blue, White, Black, Blue | Risk scans, failure prevention |
| **Decision** | Blue, White, Black, Yellow, Blue | Go / no-go |
| **Custom** | User's order, then closing Blue | Only the six standard hats; confirm the order, and state in the order line that the closing Blue was added if the user left it out |
## The hats
Never mix two hats in one section.
**Blue: process.** Frames and synthesizes. Never adds new facts, risks, ideas or recommendations.
**White: facts.** Data, evidence, gaps. No interpretation. Tag every bullet:
- `[KNOWN]` verifiable from the user or a reliable source
- `[ASSUMED]` working assumption
- `[UNKNOWN]` missing information that limits confidence
**Red: feelings.** Gut reactions, enthusiasm, resistance. User-stated emotions pass through verbatim, marked **stated**. Inferred emotions use "might" or "could", never asserted as fact.
**Black: risks.** Each bullet: **Risk:** specific failure mode, **Mitigation:** concrete action.
**Yellow: value.** Each bullet: **Benefit:** concrete upside, **Condition:** what must hold.
**Green: new options.** One distinct option per bullet. Generate only; no evaluation. When stuck, use reversal, analogy or constraint removal.
## Blue synthesis (closing)
A **tension** is where one hat pulls against another (for example a Yellow benefit that holds only if a Black risk is mitigated). Use only what the hats produced.
1. Top tension
2. Second tension, if any
3. Recommendation, grounded in the hats
4. Next step, with owner and timeframe if known
Light path: key tension, recommendation, next step. Then ask whether to iterate, expand one hat, or stop.
## Pitfalls
- Black hat leaking into Green ("but that would never work"). Park it for the Black pass.
- Red hat filled with analysis. Red is a reaction, not a reason.
- Blue synthesis that slips in a new idea. Move it back to Green or drop it.
- User anchored on one lens (only complaining or only excited): name it and lead with the contrasting hat.
Worked example: [references/example.md](references/example.md).
## Checklist
- [ ] Blue (open) block: focus, mode, hat order
- [ ] Hats run in the declared order, one section each
- [ ] White bullets tagged; Black has Risk + Mitigation; Yellow has Benefit + Condition
- [ ] Red: inferred emotions hedged, stated emotions verbatim
- [ ] Green: one option per bullet, no evaluation
- [ ] Closing Blue adds nothing new>
# Strategic Thinking
Strategy is choosing what **not** to do as much as what to do. End with explicit bets and guardrails.
## When to use
- Choosing a direction for a product, team, company, technology platform or career under real constraints.
- Competitive positioning, "where to play and how to win", roadmap narrative, portfolio trade-offs.
- Leadership or board-style narrative that links goals to constraints.
Skip: step-by-step implementation detail, or choosing between two concrete options on named criteria.
## Before you start
1. State in one block: **Strategic question** (one sentence) and **Pass** (Intent, Landscape, Advantage, Options, Choice, Risks and Cadence).
2. **Gather first.** Read the roadmap, docs, metrics or market notes you can reach before writing Landscape. Never invent market facts; say what is unknown. Ask up to 3 questions only for goals and non-negotiables that tools cannot answer.
3. **Light path.** Small ask: 1-2 lines per phase, 2 options, same order.
4. If the user wants a memo or deck storyline, add a **Short story** after Risks and Cadence (5-7 sentences: tension, insight, decision, proof path).
## Phases
### 1. Intent
**Win definition:** which outcome, by when. **Non-goals:** what is explicitly out of scope.
### 2. Landscape
Forces that matter: customers, competition, technology, regulation, economics. Use **Implication:** bullets, not encyclopedic lists. Keep short when information is thin.
### 3. Advantage (or **Honest gap**)
Where could durable advantage come from: assets, learning loops, distribution, data, brand, cost? If none is credible, say so and pivot to how to build one.
### 4. Options
2-4 genuinely different strategies:
> **Option:** ... - **Bet:** ... - **Cost:** ... - **Kill signal:** ...
### 5. Choice
Name one primary option (parallel bets only if clearly justified). Say **why now** and what you are **deferring or rejecting**.
### 6. Risks and Cadence
Top 3 risks with mitigations. Then a **near-term focus**, a **longer-term thesis** and a **review trigger** (a metric or event that forces a rethink). Match the horizons to the domain: 90 days and 12 months suit a business plan; an architecture or career decision may need different spans, so state the spans you chose.
## Pitfalls
- Platitudes ("innovate", "customer-centric") with no mechanism.
- Options that are really one option in different words.
- A Choice that introduces a strategy not in Options. Label it a revision if so.
- Advantage claimed with no evidence. Use Honest gap.
Worked example: [references/example.md](references/example.md).
## Checklist
- [ ] Strategic question and Pass stated
- [ ] Intent includes non-goals
- [ ] Options use Bet, Cost, Kill signal
- [ ] Choice explicit, with what is deferred or rejected
- [ ] Risks and Cadence: top 3 risks, stated horizons, review trigger>
# SWOT Analysis
Sort what you know into **S**trengths, **W**eaknesses, **O**pportunities and **T**hreats, then turn it into actions with TOWS. A SWOT is only useful when each cell holds evidence and the result changes a decision.
## When to use
- Assessing the position of a product, team, project, company or competitor.
- A go / no-go on a market, partnership, or new initiative where internal fit and external conditions both matter.
- Preparing a strategy review or a planning session.
Skip: detailed implementation plans, market sizing, or choosing between concrete options on weighted criteria.
## Before you start
1. State in one block: **Subject** (one entity), **Scope and horizon** (for example "our API product, next 12 months"), **Decision it informs**, and **Pass** (Gather, SWOT, Prioritize, TOWS, Next steps).
2. **Gather first.** Read docs, metrics, customer feedback, competitor pages and the codebase where relevant. Every item needs a source or the label `[user stated]` or `[assumed]`. Ask up to 3 questions only for what tools cannot answer.
3. **Light path.** Small ask: 3 items per cell, top 2 per cell kept, 1 action per TOWS pair.
## Steps
### 1. SWOT
Place each item by one test:
- **Internal and within your control:** Strength or Weakness.
- **External and outside your control:** Opportunity or Threat.
Make items specific and comparative ("support answers in under 1 hour, competitors take a day" beats "great support").
| | Helpful | Harmful |
|---|---------|---------|
| **Internal** | Strengths | Weaknesses |
| **External** | Opportunities | Threats |
### 2. Prioritize
Keep the 2-4 items per cell that most affect the decision. Say why the rest are dropped.
### 3. TOWS
Pair cells to make actions:
- **SO:** use strengths to take opportunities.
- **WO:** fix weaknesses that block opportunities.
- **ST:** use strengths to reduce threats.
- **WT:** limit exposure where a weakness meets a threat.
### 4. Next steps
Name the 2-3 actions with an owner (or "to be assigned"), and the one assumption to test first.
## Pitfalls
- Items with no evidence ("strong brand"). Add a source or mark `[assumed]`.
- Mixing internal and external: "competitor launched a feature" is a Threat, not a Weakness.
- Long lists with no ranking. A SWOT that does not prioritize does not help a decision.
- Stopping at the grid. Without TOWS or next steps it records opinions and decides nothing.
- Treating one item as both a Strength and an Opportunity. Pick the cell that matches the test.
Worked example: [references/example.md](references/example.md).
## Checklist
- [ ] Subject, scope, horizon and the decision stated
- [ ] Each item sits in the right cell by the internal / external test
- [ ] Items are specific, comparative and sourced or labeled
- [ ] Priorities kept per cell
- [ ] TOWS actions and next steps with owners>
# Systems Thinking
See the whole before optimizing a part. End with recommendations that account for loops and delays.
## When to use
- A problem keeps returning after "fixes".
- A change in one team, service or policy may hit others (unintended consequences, incentives, queues, backlogs).
- The user asks for root causes beyond a single person or component, or for a holistic view.
Skip: single-step linear tasks, one-variable calculations, fixes that need no map of interactions.
## Before you start
1. State in one block: **System in focus** (what is inside the boundary) and **Pass** (Boundary, Structure, Dynamics, Delays, Leverage, Synthesis).
2. **Gather first.** Read the code, docs, tickets or metrics that describe how the parts connect before drawing the map. Ask up to 3 scoping questions only for what tools cannot answer.
3. **Light path.** Small ask: 2-3 bullets per phase. Never skip Structure before Leverage, even on the light path.
4. If the user already proposed an intervention, shorten Boundary but keep Structure and Dynamics.
## Phases
### 1. Boundary
What is in and out for this analysis. One sentence on the system's purpose from a stakeholder's view.
### 2. Structure
**Elements** (stocks that accumulate, actors, resources) and **flows** (rates in and out). Short pairs: **From -> To:** what moves.
### 3. Dynamics
At least one reinforcing (R) and one balancing (B) loop where plausible:
> **Loop [R|B]:** ... - **Mechanism:** ...
If no loop applies, say so in one line and why.
### 4. Delays
Where is the lag between action and effect? How does it change behavior (overshoot, oscillation, giving up too early)?
### 5. Leverage
> **Leverage point:** ... - **Why it matters:** ... - **Risk of backfire:** ...
Prefer changes to rules, information flows, incentives or goals over exhorting people to behave differently. Donella Meadows ranks these as stronger levers than adjusting parameters such as limits and budgets.
### 6. Synthesis
1. **System story:** one plain-language paragraph.
2. **Non-obvious consequence:** at least one.
3. **Recommended moves:** 2-3 actions consistent with the loops and delays above.
## Pitfalls
- Jumping to solutions before Structure and a light Dynamics pass.
- Stopping at "X is careless". Translate to the incentive or information gap behind the behavior.
- Drawing every box you can think of. Include only elements that change the answer.
- A fix that works now but triggers a balancing loop later. Check Delays against each recommendation.
Diagrams are optional; the bullets must stand alone. Worked example: [references/example.md](references/example.md).
## Checklist
- [ ] System in focus and Pass stated
- [ ] Boundary and purpose explicit
- [ ] Structure uses elements and From -> To flows
- [ ] Dynamics: R and B loops, or N/A justified
- [ ] Delays considered where time matters
- [ ] Leverage tied to the map, with backfire risk
- [ ] Synthesis tells one coherent story>
# Thinking Method Selector
Match the user's situation to one thinking method, say why, and run it. Pick by what the user must **decide or produce next**, not by keywords.
## When to use
- The user is stuck, torn or overwhelmed and has not said how they want to think about it.
- A problem is stated loosely and several methods could apply.
- The user asks "which framework should I use?".
Skip: execution tasks (write, fix, build), plain factual questions, or any request that already names a method (use that method).
## How to run
1. **Restate** the situation in one line, including the decision or output the user needs next.
2. **Gather first.** If you can read the repo, docs or data that frame the problem, do it before choosing. Ask **at most one** question, only if two methods fit equally and the answer would change the pick.
3. **Choose** one method from the table below. Say in one sentence why it fits and why the nearest alternative does not.
4. **Run it.** If the named skill is installed, follow its instructions. If it is not, use the matching outline under "Fallback outlines" and say which method you are using.
5. **Offer** at most one follow-on method (for example "after the pre-mortem, a tradeoff analysis would settle which option").
## Situation to method
| The user needs to... | Method | Core move |
|----------------------|--------|-----------|
| Pick among concrete options | `tradeoff-analysis` | Weighted criteria, sensitivity, reversibility |
| Order a long list with limited capacity | `prioritization` | RICE, ICE, MoSCoW, cut line |
| Find why something failed or keeps recurring | `five-whys` | Evidence-backed chain to a fixable cause |
| Check a plan before committing | `pre-mortem` | Assume failure, list causes, mitigate |
| Test whether a claim or plan holds up | `critical-thinking` | Assumptions, evidence, logic gaps |
| Explain a number or break a question into drivers | `analytical-thinking` | Tree, hypotheses, evidence |
| Get a rough number fast | `fermi-estimation` | Factors, ranges, cross-check |
| Assess where a team, product or company stands | `swot-analysis` | S, W, O, T plus TOWS actions |
| Choose a direction under constraints | `strategic-thinking` | Intent, options, bets, risks |
| See side effects and why a problem recurs across parts | `systems-thinking` | Loops, delays, leverage points |
| Question an inherited default or a copied approach | `first-principles-thinking` | Strip analogies, rebuild from fundamentals |
| Understand user needs before designing | `design-thinking` | Empathize, define, ideate, test plan |
| Generate many options | `creative-thinking` | Diverge, connect, harvest |
| Break out when ideas feel incremental | `lateral-thinking` | Provocation, principle, concept fan |
| Judge whether a plan is fair or could harm people | `ethical-thinking` | Stakeholders, harms, power, consent |
| See one issue from separate angles in sequence | `six-thinking-hats` | Facts, feelings, risks, benefits, ideas |
When two fit, prefer the one that matches the decision the user must make next: options to pick from means a tradeoff analysis; a plan to commit to means a pre-mortem; a past failure means five whys.
## Fallback outlines
Use these only when the matching skill is not installed. Keep each to the steps shown.
- **tradeoff-analysis:** list options (include do nothing), screen must-haves, 3-7 independent criteria with weights, score with a basis, test what flips the winner, check how hard it is to reverse, recommend and say what would change it.
- **prioritization:** state the goal and capacity, choose RICE (Reach x Impact x Confidence / Effort) or MoSCoW, score with bases, rank, draw the cut line, name what is not done.
- **five-whys:** write an observable problem; ask why of each previous answer; mark each `verified` or `hypothesis`; stop at a cause the team can change; add contain, fix, prevent actions.
- **pre-mortem:** assume the plan failed; list specific causes across people, process, tech, market; rank by likelihood and impact; add prevent, detect or respond actions with owners; set tripwires.
- **critical-thinking:** restate the claim; list evidence as cited or missing; list assumptions with "if false"; trace the logic for gaps and bias; give alternatives; conclude with strength and what would change it.
- **analytical-thinking:** frame the question and baseline; build a driver tree; rank hypotheses with falsifiers; map evidence; answer with the key uncertainty and next data.
- **fermi-estimation:** write the formula; give low and high with a basis for each factor; combine; cross-check a second way; name the dominant factor.
- **swot-analysis:** define subject and scope; sort items by the internal / external test with evidence; keep the top ones; pair cells into actions; name next steps.
- **strategic-thinking:** define the win and non-goals; read the landscape; test for advantage; compare 2-4 options with bet, cost, kill signal; choose; list risks and a review trigger.
- **systems-thinking:** set the boundary; list stocks and flows; find reinforcing and balancing loops; note delays; pick leverage points and their backfire risk.
- **first-principles-thinking:** state the convention; question each assumption; keep only what is fundamental; rebuild from it; compare with the conventional path.
- **design-thinking:** describe users, jobs and pains from real input; write a point of view and how-might-we questions; ideate; sketch low-fidelity prototypes; plan a test that can fail.
- **creative-thinking:** set the brief; generate many ideas using different triggers; combine pairs; pick three with reasons; list a next step.
- **lateral-thinking:** write a provocation; extract a usable principle; step back to broader directions and fan out to concepts and ideas; tag candidates.
- **ethical-thinking:** list who is affected; name value tensions; weigh harms and benefits with plausibility; check who bears cost and who can say no; give options with safeguards and the strongest objection.
- **six-thinking-hats:** run facts, feelings, risks, benefits, new ideas as separate passes; close with the main tension, a recommendation and a next step.
## Pitfalls
- Choosing by keywords. "Why" can mean five whys, analytical thinking or systems thinking; match the next decision, not the word.
- Running two methods at once. Run one, then offer the next.
- Interrogating the user. One question at most, then proceed.
- Claiming a skill is loaded when it is not. Say which outline you are following.
Worked example: [references/example.md](references/example.md).
## Checklist
- [ ] Situation restated with the decision or output needed next
- [ ] One method chosen, with the reason and why the nearest alternative does not fit
- [ ] Method run (skill if installed, otherwise the fallback outline), not just named
- [ ] At most one question asked and at most one follow-on offered>
# Tradeoff Analysis
Choose among a small set of real options with the criteria, weights and evidence in plain view. A weighted decision matrix with a sensitivity check and a reversibility check.
## When to use
- Picking a library, vendor, architecture, plan, hire, design or build-vs-buy.
- "A or B?", "compare these", "which should we pick", "is it worth it".
- A decision the user must defend to others.
Skip: generating options from scratch (explore first, then come here), reviewing one plan for flaws, or ranking a long backlog.
## Before you start
1. State in one block: **Decision** (one sentence), **Deadline or cost of delay**, and **Pass** (Options, Must-haves, Criteria, Score, Sensitivity, Reversibility, Recommendation).
2. **Gather first.** Read docs, benchmarks, pricing, the codebase and constraints before scoring. Every score needs a one-line basis; unsupported scores are marked `[ESTIMATED]`. Ask up to 3 questions only for goals and constraints tools cannot answer.
3. **Light path.** Small ask: 2-3 options, 3 criteria, one-line reasons, a one-sentence sensitivity check.
## Steps
### 1. Options
2-5 genuinely different options, including **do nothing** or **keep current** when it is real.
### 2. Must-haves
Hard constraints (budget cap, compliance, deadline). An option that fails one is out; do not score it.
### 3. Criteria and weights
3-7 criteria that reflect the goal and do not overlap (avoid counting the same thing twice, such as "speed" and "performance"). Give weights that sum to 100 and say why the top weight is highest.
### 4. Score
Rate each option per criterion from 1 (poor) to 5 (strong), with a short basis.
| Criterion (weight) | Option A | Option B |
|--------------------|----------|----------|
| ... (40) | 4 - basis | 3 - basis |
| **Weighted total** | | |
### 5. Sensitivity
Change the largest weight by about 10 points, or the least certain score by one. Does the winner change? Name the one criterion or score that flips the result.
### 6. Reversibility
How costly is it to undo this choice (switching cost, data lock-in, contract length, time)? Easy to reverse: decide faster and favor learning. Hard to reverse: spend more effort on evidence.
### 7. Recommendation
The pick, the main reason, the main cost you accept, and **what would change the pick**. For money or time tradeoffs, add a compact **cost-benefit** line: expected benefit range minus cost range, with the unit and period.
## Pitfalls
- False precision: a 3.8 vs 3.6 gap is a tie. Say so and decide on sensitivity and reversibility.
- Weights chosen after seeing the scores. Set them before scoring.
- Criteria that restate the favorite option ("uses our preferred language").
- Scores from impressions with no basis. Mark them `[ESTIMATED]`.
- Ignoring the cost of changing course later.
Worked example: [references/example.md](references/example.md).
## Checklist
- [ ] Decision and options stated; do-nothing considered
- [ ] Must-haves screened before scoring
- [ ] Criteria are independent; weights set with a reason
- [ ] Every score has a basis or `[ESTIMATED]`
- [ ] Sensitivity names what flips the result
- [ ] Reversibility assessed
- [ ] Recommendation names the accepted cost and what would change it