Give your AI a process, not another prompt.

---
name: prompt-refiner
description: Refine vague or underspecified requests into executable prompts. Use when a user asks to improve a prompt, the desired outcome is unclear, or an AI keeps returning generic output.
---

# Prompt Refiner

Turn the request into a brief an agent can execute and verify.

## Method

1. State the intended outcome in one sentence.
2. Extract known context, audience, constraints, inputs and required output.
3. Identify only the unknowns that would materially change the result.
4. Resolve low-risk gaps with explicit assumptions. Ask at most three focused questions for material gaps.
5. Write the refined prompt with:
   - role and objective
   - relevant context and source material
   - constraints and exclusions
   - required output structure
   - success checks
6. Remove filler, duplicated instructions and invented facts.

## Output

Return:

- **Refined prompt**
- **Assumptions made**
- **Open question**, only when execution is genuinely blocked

Do not execute the refined prompt unless the user asks you to.

---
name: decision-framer
description: Frame consequential decisions with explicit options, criteria, uncertainty and reversibility. Use when comparing alternatives, deciding whether to proceed, or untangling a choice that feels stuck.
---

# Decision Framer

Make the decision legible before recommending an answer.

## Method

1. Write the decision as: "Should we choose X, Y, or maintain the status quo by DATE?"
2. Name the decision owner and deadline.
3. Separate hard constraints from preferences.
4. List realistic options, including doing nothing when it is genuinely available.
5. Define three to five criteria and explain why each matters.
6. Compare options using evidence, not invented precision.
7. Surface:
   - assumptions carrying the recommendation
   - missing evidence
   - reversible versus irreversible consequences
   - the cost of delay
8. Recommend an option, confidence level and next irreversible step.

## Output

- **Decision**
- **Options**
- **Criteria**
- **Evidence and assumptions**
- **Recommendation**
- **Confidence**
- **Next step**

Do not hide uncertainty behind a score. Explain what would change the recommendation.

---
name: meeting-to-actions
description: Convert meeting notes or transcripts into decisions, owned actions, deadlines and open questions. Use after calls, workshops, reviews or planning sessions.
---

# Meeting to Actions

Extract commitments without upgrading discussion into decisions.

## Method

1. Read the complete source before summarising.
2. Distinguish:
   - confirmed decisions
   - proposed ideas
   - actions explicitly accepted
   - risks and blockers
   - unresolved questions
3. Preserve named owners and dates exactly.
4. Mark missing owners or dates as "Unassigned" or "No date", never infer them.
5. Merge duplicates while retaining the strongest source wording.
6. Flag contradictions and commitments that depend on an unresolved question.

## Output

### Decisions
- Decision, rationale, decision owner

### Actions
- Action | Owner | Due date | Dependency

### Risks and blockers
- Risk | Impact | Owner if stated

### Open questions
- Question | Person needed

### Short recap
A maximum five-sentence factual summary.

Do not attribute a statement to someone unless the source does.

---
name: calibrated-forecasting
description: Turn a vague prediction or unstated confidence level into an explicit, calibrated probability estimate, following the practices Philip Tetlock found separated "superforecasters" from everyone else — breaking questions into sub-questions, checking base rates, updating in small increments as new information arrives, and tracking predictions against outcomes. Use whenever the user makes a confident-sounding claim about the future ("this will definitely work," "there's no way that happens") without a number attached, is trying to decide how much weight to put on a forecast, or wants help thinking through a genuinely uncertain future event.
---

# Calibrated Forecasting

Vague confidence ("probably," "definitely," "no chance") hides how sure
someone actually is and makes it impossible to check later whether they
were right. Attaching a number — even a rough one — fixes both problems.

## The technique

**1. Force a number.** When someone says "probably" or "likely," ask or
propose: does that mean 55% or 90%? These are very different claims that
"probably" hides. Round numbers (50%, 70%, 90%) are fine — precision
theater (73.2%) is not the point.

**2. Break the question into sub-questions.** "Will this product launch
succeed" is too broad to forecast well. Break it into things that are each
individually more checkable: will it ship on time? Will early users
retain? Will the channel convert at the assumed rate? Forecast the parts,
then combine.

**3. Check the base rate first.** Before reasoning about what's special
about this case, ask: what fraction of similar attempts (launches,
negotiations, forecasts of this type) succeed historically? Start there,
then adjust up or down for what's genuinely different about this case —
in that order, not the reverse. Starting from the vivid specifics of this
case and only checking the base rate afterward is a well-documented way to
end up overconfident.

**4. Update in increments, not swings.** New information should usually
move a forecast a little, not flip it from 20% to 90%. A single piece of
evidence rarely changes everything — if it feels like it does, check
whether it's actually decisive or just vivid.

**5. Distinguish "I don't know" from "50%".** Genuine 50/50 uncertainty
and genuine ignorance about which way to lean are different things — say
which one it is.

**6. Write the forecast down with a resolution date and criteria.** A
forecast that isn't checkable later can't build a track record. If this is a forecast worth remembering, suggest writing it to a dated
forecast log with clear resolution criteria.

## Output

State the number, the reasoning that produced it (base rate → adjustment
→ final number), and what would move it. Resist the pull to round to a
comfortable, confident-sounding answer if the honest number is messier.

---
name: decision-memo
description: Structure a real, consequential decision as a written narrative memo in the style Jeff Bezos used at Amazon — full sentences and paragraphs rather than bullet points, forcing the logic to be checked rather than gestured at, plus explicit classification of whether the decision is reversible (a "two-way door") or not (a "one-way door"). Use this whenever the user is facing a real decision — a job offer, a hire/fire call, a big purchase, a strategic bet, a yes/no with real stakes — especially if they're leaning on gut feel without having written the reasoning down. Do not use for trivial or low-stakes choices.
---

# Decision Memo

Bullet points let sloppy logic hide. Full-sentence narrative forces every
claim to be either true, sourced, or admitted as an assumption. This skill
turns a decision into a short written memo before it gets made — not
after, as a justification.

## Step 1 — classify the door

Ask (or infer, then confirm): **is this reversible?**

- **Two-way door** — you can back out with acceptable cost. Move fast.
  Don't over-invest process into a decision you can unwind. Optimize for
  speed of learning, not certainty.
- **One-way door** — hard or costly to reverse (a senior hire, a
  multi-year commitment, a public statement, a structural bet). Slow
  down. This is where the memo earns its cost.

If genuinely unsure which it is, that uncertainty is itself worth a
sentence in the memo — treating a one-way door like a two-way door is a
common, expensive mistake.

## Step 2 — write the memo

Use full sentences, not bullets. Structure:

1. **The decision, stated plainly.** One or two sentences. No hedging.
2. **What happens if we do nothing.** The default/status-quo path,
   stated honestly — this is the real alternative being compared against.
3. **The case for.** The strongest honest version, not a strawman.
4. **The case against.** Equally strong — steelman the other side. If you
   can't write a good "against" case, you probably haven't thought about
   it enough yet.
5. **What would change your mind.** Name the specific evidence that would
   flip the decision. If nothing would, say so — that's worth noticing.
6. **The call, and why.** State the decision and the one or two reasons
   that actually drove it — not all the reasons, the ones that mattered.

## Step 3 — pressure-test before finalizing

Before treating the memo as done, check:

- Does the "case against" section actually sound like something a smart
  person who disagrees would say? If it's weak, rewrite it.
- Is there a claim in here that's actually an assumption wearing a fact's
  clothes? Flag it.
- For one-way doors specifically: consider suggesting the `premortem` skill next, then ask a fresh
reviewer to make the strongest honest case against the recommendation.

## Output

Give the memo as continuous prose in the structure above, not a bulleted
outline — the format itself is the point.

---
name: feynman-teachback
description: Test and build genuine understanding of a concept using the Feynman technique — explain it as simply as possible, notice exactly where the simple explanation breaks down, and treat that break point as the thing to actually go learn. Use whenever the user wants to check if they really understand something (not just recognize it), asks for something to be explained simply or "like I'm five," is studying or preparing to teach/present something, or gives an explanation that leans heavily on jargon which may be covering for a gap.
---

# Feynman Teachback

Recognizing a concept and understanding it are different things, and
jargon makes it easy to mistake one for the other. This skill uses
simplification as a diagnostic: the point where a simple explanation
breaks down is exactly the point worth studying next.

## The technique

**1. Explain it as if to a smart person outside the field.** No jargon
without immediately defining it in plain terms. If a term can't be
unpacked simply, that's already informative — flag it rather than
gliding past it.

**2. Notice exactly where it gets hard.** While simplifying, there's
usually a specific point where the explanation wants to reach for jargon,
hand-wave, or say "it's complicated." Don't smooth over that moment — name
it explicitly: "this is the part I'm actually unsure about" or "this is
where I'm restating the term rather than explaining the mechanism."

**3. Go back and fill the gap.** Once the sticking point is named, that's
the actual thing to research or think through — not the whole topic
again. This is what makes the technique efficient: it targets the real
gap instead of re-reviewing everything.

**4. Re-explain, simpler than the first pass.** A second pass after
filling the gap should be shorter and use more everyday analogies, not
more precise terminology. If it got more complicated, the gap wasn't
actually filled — it was just described more thoroughly.

## When the user is explaining something to Sage

If the user is the one explaining a concept (to check their own
understanding, or while drafting a presentation), listen for:

- Places where they use a technical term to stand in for a mechanism
  without describing the mechanism.
- Places where the explanation would fall apart under a genuinely naive
  follow-up question ("but why does that happen?").

Ask that naive follow-up question directly rather than accepting the
jargon. This is more useful than praising the explanation — the goal is
finding the gap, not confirming the explanation.

## Output

Either: a simplified explanation with the sticking point explicitly
flagged, or a pointed follow-up question aimed at a specific gap in the
user's own explanation — not generic encouragement.

---
name: first-principles
description: Rebuild a problem from fundamental truths (physics, economics, unit costs, what's actually true regardless of convention) rather than by analogy to how things are normally done — the reasoning style associated with Elon Musk's approach to manufacturing cost problems and Richard Feynman's approach to physics problems. Use this whenever the user is reasoning by analogy or precedent ("that's just how it's done," "industry standard is..."), is stuck because "everyone knows X isn't possible," or is pricing/costing something and the number seems anchored to convention rather than to actual inputs. Not a fit for problems that are genuinely about social convention or law, where precedent is the actual substance of the answer.
---

# First Principles

Reasoning by analogy is usually fine and fast — most of the time, doing
what's normally done is a reasonable shortcut built on real accumulated
knowledge. First-principles reasoning is for the specific moments when
the analogy is the thing holding a wrong answer in place.

## The technique

1. **State the claim being taken for granted.** Usually something like
   "X costs/takes/requires Y" where Y is treated as fixed. Say it plainly:
   "the assumption here is that ___."

2. **Ask why that's true, one layer down.** Not "is it expensive" but
   "what specifically makes it expensive — which inputs, at what
   quantities, at what price?" Keep asking "why is *that* true" until you
   hit something that's actually fundamental (raw material cost, a
   physical constraint, a real regulatory requirement) rather than
   another layer of "because that's how it's usually done."

3. **Rebuild the estimate from the fundamental layer up.** If you costed
   out the raw inputs at their actual prices, what would this cost? This
   number is often wildly different from the conventional number —
   that gap is the interesting part, and it's exactly the gap Musk
   pointed at with rocket manufacturing costs and battery costs.

4. **Explain the gap.** If the first-principles number is much lower than
   the conventional one, the gap is usually markup, inefficiency,
   regulatory capture, or a coordination problem — name which one, because
   that's what tells you whether the gap is closeable.

5. **Check you haven't thrown away something real.** Precedent sometimes
   encodes hard-won knowledge, not just inertia (this is why circle of
   competence matters — see `mental-models`). Before concluding "this
   should be way cheaper/faster/different," ask what the incumbent
   approach might know that the rebuild is missing.

## Output

Show the layer-by-layer "why is that true" chain explicitly, not just the
final rebuilt number — the chain is what makes the conclusion trustworthy
rather than just a different unsupported guess.

---
name: focus-and-tradeoffs
description: Cut a bloated plan, roadmap, or list of priorities down to the one or two things that actually matter, in the tradition associated with Steve Jobs's product focus — "innovation is saying no to a thousand things." Use whenever the user has a long list of priorities/features/goals with no clear ranking, describes something as "trying to do everything," is building a roadmap or plan that keeps growing, or asks for help prioritizing. This is about forcing real tradeoffs, not just reordering a list — the output should include things explicitly cut, not just resequenced.
---

# Focus and Tradeoffs

A list where everything is "important" hasn't actually been prioritized —
it's been left unprioritized with a rank order attached. Real focus means
some things get cut, not just moved to the bottom.

## The technique

**1. List everything, without judgment first.** Get the full list out
before ranking anything — premature cutting during listing loses good
ideas along with bad ones.

**2. Force a hard constraint.** Ask or propose: if only ONE of these
could happen this cycle, which is it, and why? Not "top 3" — one. The
discomfort of choosing one is the point; it's what surfaces the real
priority instead of a comfortable spread.

**3. For everything else, ask what it's actually trading against.**
Every "yes" to one thing is implicitly a "no" to something else
(capacity, attention, coherence). Make that trade explicit: "doing this
means NOT doing ___, because ___." If the tradeoff can't be named, the
priority list probably hasn't been thought through yet, it's just been
listed.

**4. Distinguish "important" from "urgent" from "easy."** Long lists
often mix these up — something gets kept because it's easy to do, not
because it matters. Flag items that seem to be on the list for that
reason specifically.

**5. Say what gets cut, out loud.** The output of this exercise should
include an explicit "not doing" list, not just a reordered "doing" list.
Saying no to something is the actual deliverable — a prioritized list
that quietly keeps everything hasn't done the work.

**6. Check for coherence, not just individual value.** A focused plan is
usually a small number of things that reinforce each other, not just the
individually highest-scoring items picked independently. Ask whether the
top items actually combine into one clear story.

## Output

A short "doing" list (ideally 1-3 items) and an explicit "not doing, and
here's why" list. Resist the pull to soften the cuts by saying "later" for
everything — some things should be a real no, not a deferred yes.

---
name: jobs-to-be-done
description: Diagnose what "job" a customer is actually hiring a product, service, or workaround to do, using the Jobs-to-be-Done framework (Clayton Christensen's "progress in a specific circumstance," Bob Moesta's forces-of-progress and switch interview, Tony Ulwick's job statements and desired-outcome scoring). Use this whenever the user is trying to understand a problem before jumping to a solution, is confused about why customers churn, switch, or don't adopt something that looks objectively better, is segmenting users by demographics/persona and it isn't predicting behavior well, or is scoping a new use case and needs to know what progress the customer is actually trying to make. Not a fit once the problem is already well-understood and the question has shifted to prioritization (use focus-and-tradeoffs) or a go/no-go call (use decision-memo).
---

# Jobs to Be Done

People don't buy products — they hire something (a product, a service, a
workaround, even doing nothing) to make progress toward a specific goal
in a specific circumstance. The job is the progress being sought; the
product is just whatever gets hired to deliver it. Demographics and
personas often fail to predict behavior because two very different people
can be trying to make the exact same progress, and one person can hire
completely different things for different jobs in different moments of
their own life.

## The core move

Stop asking "who is the customer" and start asking "what progress are
they trying to make, and what's currently getting in the way of making
it." The circumstance matters more than the person — the same person
hires something different for the "get through a boring commute" job than
for the "feel like a good parent on a Saturday" job, even though it's the
same person both times.

## The four forces (Moesta)

When someone switches from an old solution (including "doing nothing") to
a new one, four forces are in tension:

- **Push** — dissatisfaction with the current situation strong enough to
  seek an alternative.
- **Pull** — the magnetism of the new solution, specifically how it
  promises to make the progress easier or better.
- **Anxiety** — uncertainty about the new solution (will it actually
  work, is it worth the risk, what if I look foolish adopting it).
- **Habit of the present** — the comfort and momentum of what's already
  being done, even if it's mediocre.

A switch happens when push + pull outweigh anxiety + habit. If adoption
is stalling, name which of the four is actually the blocker — increasing
pull (a better pitch) does nothing if the real blocker is anxiety, and
that's a very common mismatch: teams pour effort into making the pitch
better when the real problem is fear of switching.

## The switch interview (Moesta)

To find the forces at play, reconstruct the actual timeline of the
decision with someone who recently switched (or recently chose not to):
what was happening right before they started looking, what almost stopped
them, what tipped it, what they were worried about. Concrete recent
events beat abstract stated preferences — "walk me through the day you
decided to look for something else" surfaces more than "what do you look
for in a solution."

## Job statements and desired outcomes (Ulwick)

For a sharper, more structured version of the same idea:

- **Job statement**: verb + object + context, stripped of any reference
  to a specific solution. "Reduce time spent reconciling expense reports
  during month-end close," not "get a better expense tool."
- **Desired outcome statements**: "minimize/increase [metric] of [process
  step] when [context]" — specific and measurable, not "make it easier."
- **Opportunity = importance × (satisfaction gap)**: outcomes that are
  highly important but poorly satisfied by current options are where the
  real opportunity sits — not the outcomes people mention most often,
  which are usually just the ones already well served (and therefore top
  of mind).

## Functional, emotional, and social dimensions

The job usually isn't purely functional. Ask what emotional progress
("feel more in control," "feel confident/competent") and social progress
("feel or be seen as good at this") are bundled into the functional one —
missing these is a common reason a functionally-superior alternative
still loses to something that resonates more emotionally or socially.

## Common failure mode

Segmenting or designing around who the customer is (age, title, company
size) rather than what job they're hiring for, then being surprised when
the segment doesn't predict behavior. If demographic segmentation isn't
predicting adoption or churn, that's the signal to re-run this framework
instead of collecting more demographic detail.

## Output

Name the job in one job-statement sentence, identify which of the four
forces is actually the blocker (if this is about a stalled decision), and
flag whether the current segmentation approach is actually job-based or
just demographic. If this feeds into scoping a use case, hand off to
`outcome-hypothesis` with the job statement as the starting point rather
than a vague value proposition.

---
name: mental-models
description: Apply Charlie Munger's "latticework" approach — a small set of cross-disciplinary thinking tools (inversion, second-order effects, incentives, circle of competence, opportunity cost, base rates) to frame a vague or general problem. Use this whenever the user brings a fuzzy problem that hasn't been broken down yet, asks "how should I think about this," seems to be reasoning from a single framework when the problem is really cross-disciplinary, or seems stuck circling the same angle repeatedly. This is the default general-purpose skill when no more specific skill (decision-memo, premortem, first-principles) obviously fits better.
---

# Mental Models

Most bad reasoning isn't a lack of intelligence — it's using one lens on a
problem that needs several. This skill applies a short list of
cross-disciplinary tools to reframe a fuzzy problem before diving into
solving it. Don't run through the whole list mechanically — pick the 1-3
tools that actually bite for this problem.

## The tools

**Inversion.** Instead of asking "how do I succeed," ask "what would
guarantee failure, and am I doing any of that?" Working backward from
failure surfaces risks that forward reasoning misses.

**Second-order effects.** The first-order effect of an action is usually
obvious and is why people do it. The second- and third-order effects are
where most surprises live. Ask: "and then what happens? And then what
happens after that?" at least twice.

**Incentives.** Look at what people are actually rewarded for, not what
they say their goals are. Munger's line: "show me the incentive and I'll
show you the outcome." Misaligned incentives predict behavior better than
stated intentions do.

**Circle of competence.** Be honest about where real expertise ends. The
question isn't "could I have an opinion on this" — it's "do I actually
have a track record or mechanism for knowing this, or am I guessing with
confidence." Flag it explicitly when a problem has drifted outside it.

**Opportunity cost.** The real cost of a choice is the best alternative
given up, not the sticker price. Ask "compared to what?" before evaluating
whether something is a good use of time, money, or attention.

**Base rates.** Before reasoning about the specifics of this situation,
ask what typically happens in situations like this. Specific, vivid
details about *this* case often crowd out the boring statistical reality
of similar cases — check the base rate first, then adjust.

## How to use these in a response

1. Restate the problem in one sentence to confirm you're solving the right
   thing.
2. Pick the tools that actually apply — usually 1-3, rarely all 6. Naming
   all of them regardless of fit is exactly the "label instead of think"
   failure mode to avoid.
3. Work the problem with them, showing the reasoning, not just the
   conclusion.
4. If two tools point in different directions (e.g. base rate says one
   thing, this-case-specifics say another), say so — that tension is
   often the most useful part of the answer.

## Failure mode to avoid

Don't just attach a model's name to what the person already said as a
way of sounding smart ("ah, that's just opportunity cost"). If the label
doesn't change the answer, it wasn't worth naming.

---
name: moat-analysis
description: Assess whether a competitive advantage is durable (a real "moat," in Warren Buffett and Charlie Munger's terms) or temporary, by checking it against the standard sources of durable advantage — switching costs, network effects, economies of scale, brand/trust, and regulatory or IP protection — rather than taking "we're ahead right now" at face value. Use whenever the user is evaluating a business, a product's competitive position, a startup idea, an investment, or their own company's defensibility, especially when the current advantage is described in terms of being first, faster, or better rather than structurally harder to copy.
---

# Moat Analysis

"We're ahead" and "we have a moat" are different claims. Being first or
currently better is often temporary — a moat is a structural reason a
competitor with equal resources and full knowledge of your position still
can't easily catch up.

## The five structural sources of durable advantage

Check the advantage in question against these, specifically:

**Switching costs.** Would a customer face real cost, risk, or effort to
leave — not just mild preference for the incumbent? Data lock-in,
retraining cost, and integration depth create this; a slightly better UI
does not.

**Network effects.** Does the product get better *for each user* as more
users join, in a way a new entrant can't shortcut? Beware fake network
effects — lots of users isn't the same as the product getting structurally
better because of them.

**Economies of scale.** Does unit cost meaningfully drop as volume grows,
in a way a smaller competitor structurally can't match without first
reaching the same scale?

**Brand / trust.** Would customers pay a premium or default to this
option specifically because of accumulated trust, in a category where
trust is hard to earn quickly (health, finance, safety)? Brand recognition
alone, without a trust-sensitive category, is weaker than it looks.

**Regulatory or IP protection.** Is there a real legal barrier (patent,
license, regulatory approval) that a well-funded competitor can't simply
route around or wait out?

## How to run the analysis

1. State the advantage as currently described by the user.
2. Check it against each of the five sources above — most real advantages
   are a combination of one or two, not all five.
3. For each one that seems to apply, ask the stress-test question: "if a
   well-funded, competent competitor knew exactly what we're doing and
   copied it starting today, what specifically stops them?" A good answer
   names a structural reason. A weak answer names a temporary lead
   ("we're just further along," "we move faster").
4. Be honest about "moats" that are really just current execution
   advantages — those are real and valuable, but they erode, and should be
   treated differently (as something to keep re-earning) than a structural
   moat (something to defend once built).

## Output

Name which of the five sources actually apply, flag any claimed advantage
that's really just a temporary lead, and state plainly whether the
overall position looks durable or needs continued execution to hold.

---
name: negotiation-prep
description: Prepare for a high-stakes negotiation or hard conversation using tactical-empathy techniques associated with former FBI negotiator Chris Voss — labeling emotions, calibrated open-ended questions, mirroring, and getting to genuine "that's right" rather than a grudging "yes." Use whenever the user is preparing for a negotiation, a hard ask (raise, funding, pricing), a difficult conversation with a stakeholder, or a conflict where the other party's real position or constraints aren't yet clear. Not a fit for drafting the message itself in detail — pair with normal drafting help for that.
---

# Negotiation Prep

Most negotiation prep focuses only on what you want to say. This skill
focuses on the other side — their likely position, real constraints, and
the specific questions that would surface what they actually need instead
of what they say they need.

## The technique

**1. Separate their stated position from their underlying constraint.**
What they're asking for and what they actually need to be okay with are
often different. Ask: what would they need to be true for this to work
for them, that isn't the same as what they've literally asked for?

**2. Draft calibrated, open-ended questions, not closed ones.** Questions
starting with "how" or "what" that can't be answered yes/no put the
work of solving the problem onto the other side, which tends to produce
more honest information than a direct ask does. "How can we make this
work for both of us?" surfaces more than "can you come down on price?"

**3. Prepare labels, not arguments.** A label names an emotion or
position out loud without judgment — "it sounds like timing is the real
issue here" — and tends to get more genuine disclosure than arguing
against a stated position does. Draft 2-3 labels that might apply to their
likely state going into the conversation.

**4. Aim for "that's right," not "you're right."** "You're right" is often
just a way to end the conversation. "That's right" means they feel
genuinely understood, which is what actually produces movement. Prepare a
summary of their position specific and accurate enough that hearing it
back would produce a real "that's right."

**5. Know your walk-away, and don't fake urgency you don't have.** Be
honest with the user about what their actual alternative is (see
opportunity cost in `mental-models`) — a negotiator who doesn't know their
own walk-away tends to concede more than the situation requires.

**6. Prepare for the most likely objection specifically**, not a generic
one — ask what this particular counterpart, given what's known about
them, is most likely to push back on, and draft the response to that
exact objection.

## Output

The other side's likely real constraint, 2-3 draft calibrated questions,
1-2 draft labels, and the user's own honest walk-away point. Not a script
to read verbatim — a set of tools to use adaptively in the actual
conversation.

---
name: postmortem-retro
description: Extract a specific, reusable lesson after something succeeded or failed, following the principle (associated with Ray Dalio's "pain plus reflection equals progress") that outcomes only compound into better judgment if they're deliberately converted into a written, checkable lesson rather than just felt and moved past. Use whenever the user is wrapping up a project, a decision has resolved (especially one logged earlier via decision-memo or calibrated-forecasting), something went notably well or badly, or /retro is invoked directly. This is the feedback loop that makes future decisions sharper — turn real outcomes into a durable lesson, not just another conversation.
---

# Postmortem / Retro

An outcome without a deliberate retro teaches nothing, or teaches the
wrong thing — people are prone to over-crediting skill for good outcomes
and bad luck for bad ones. This skill forces the harder, more useful
version of the accounting.

## The technique

**1. State the outcome plainly, without spin.** What actually happened,
in one or two sentences, stated the same way it would be described to
someone with no stake in it looking good.

**2. Separate decision quality from outcome quality.** A good decision can
have a bad outcome (bad luck) and a bad decision can have a good outcome
(good luck). Ask explicitly: given what was actually known *at the time*
(not what's known now), was this a good decision? This is the single most
commonly skipped step, and skipping it is what makes people learn the
wrong lesson from a good result reached the wrong way, or punish
themselves for a good call that got unlucky.

**3. Check any prior forecast or premortem against reality.** If there
was a `calibrated-forecasting` estimate or a `premortem` list of risks
made beforehand, check it explicitly: what did it get right, what did it
miss, and why? An unchecked prediction can't improve future ones.

**4. Find the one thing that would change next time**, not five vague
ones. Push past the first, easy lesson ("communicate more") to something
specific enough to actually change behavior ("send the draft two days
earlier so there's time for one real revision round," not "be more
proactive").

**5. Name what to keep doing.** Retros that only hunt for what went wrong
miss reinforcing what worked — ask explicitly what should be repeated
deliberately, not just what should stop.

**6. Write the durable lesson down.** A lesson that stays only in this
conversation does not compound. If it is genuinely reusable rather than a
one-off circumstance, add it to the user's own dated decision or learning log.

## Output

The plain outcome, the decision-quality-vs-outcome-quality read, one
specific lesson to change, one thing to keep doing, and a concise durable
lesson to save when appropriate.

---
name: premortem
description: Run a premortem — psychologist Gary Klein's technique of imagining a plan has already failed and working backward to explain why, which surfaces risks that forward planning misses because it counteracts the social and psychological pressure to seem confident. Use this whenever the user is about to commit to a plan, launch, project, or big bet, when a group seems to have converged on optimism too quickly, or whenever premortem is explicitly requested. Best used before commitment, not after — if something has already failed, use postmortem-retro instead.
---

# Premortem

Teams that feel good about a plan tend to suppress doubts — voicing
concern feels like disloyalty or pessimism. A premortem removes that
pressure by making failure the assumed starting point, which makes
raising risks feel like the *helpful* thing to do rather than the
negative thing.

## The technique

Frame it exactly like this, don't soften it: **"It's [some point in the
future]. This has failed completely. What happened?"**

Then generate specific, concrete reasons — not vague ones. "It failed
because of poor execution" is not a premortem finding. "The vendor missed
the integration deadline by six weeks because nobody owned the
dependency" is.

Push for a real list, not one obvious answer:

1. Generate at least 5-8 distinct failure stories before evaluating any
   of them. Breadth first, judgment second — evaluating too early kills
   the quieter, weirder failure modes that turn out to matter most.
2. For each one, ask: is this preventable, detectable early, or just a
   risk we accept? Sort them into those three buckets.
3. For "preventable," name the specific change to the plan now.
4. For "detectable early," name the leading indicator to watch for and
   who's watching it.
5. For "accept," say so explicitly rather than letting it go unspoken —
   an accepted risk that's written down is very different from one nobody
   noticed.

## Common failure categories worth checking explicitly

- **Dependency failure** — something outside your control that the plan
  quietly assumes will go right.
- **Timeline compression** — the plan assumed the best case for how long
  things take, not the typical case.
- **Adoption/behavior** — the plan assumes people will act differently
  than they have before, without a mechanism forcing that change.
- **Second-order reaction** — a competitor, regulator, or stakeholder
  responds in a way the plan didn't model.
- **Silent single point of failure** — one person, system, or assumption
  that everything else quietly depends on.

## Output

A short list of concrete failure stories, sorted into
prevent/detect/accept, with the plan changes that follow from the
"prevent" bucket stated explicitly. Don't just list risks — say what
changes about the plan as a result.