@human-avatar/skills-for-humanity 1.0.0

package/skills/game-theory-mechanism-design/SKILL.md

@@ -0,0 +1,85 @@
+---
+name: game-theory-mechanism-design
+description: "Designs rules and incentive systems that produce desired outcomes even when players are self-interested. Triggers: 'mechanism design', 'incentive design', 'design a system that makes people do X', 'reverse game theory', 'incentivize honest behavior', 'design rules', 'how do I get people to reveal their true preferences', 'how do I align incentives', 'the current system produces the wrong behavior'."
+---
+
+# Game Theory: Mechanism Design
+
+Standard game theory takes the rules as given and asks what rational players will do. Mechanism design inverts this: it takes the *desired outcome* as given and asks what rules will produce it. This is why it is often called reverse game theory.
+
+The central insight, formalised by Leonid Hurwicz and developed by Eric Maskin and Roger Myerson (who shared the 2007 Nobel Prize), is that private information is the root challenge. Players know things the designer doesn't — their true valuations, their effort levels, their costs — and they have incentives to misrepresent that information if doing so serves them. A well-designed mechanism elicits honest behaviour not by demanding honesty, but by making honesty the dominant strategy: the player's best move given the rules, regardless of what others do.
+
+The revelation principle is the foundational theorem: any equilibrium of any mechanism can be replicated by a *direct incentive-compatible mechanism* — one where each player simply reports their private information truthfully and the rules process it correctly. This means the designer never needs to think about indirect or complicated mechanisms; there is always an honest, direct mechanism that achieves the same outcome.
+
+William Vickrey's second-price auction is the canonical example: by having the winner pay the second-highest bid rather than their own, the dominant strategy becomes truthful bidding. The mechanism extracts honest valuations without demanding or relying on honesty.
+
+---
+
+## Your Process
+
+**Step 1: Desired outcome**
+State precisely what behaviour or allocation the mechanism should produce. Vague goals produce vague mechanisms. "People should behave better" is not a desired outcome. "Employees should report their true performance levels" is. "Suppliers should bid their true costs" is. Be specific about whose behaviour, what information, and what allocation.
+
+**Step 2: Player map**
+For each player involved:
+- What *private information* do they hold? (True valuation, effort level, ability, cost, intent)
+- What are their *incentives*? What would they do if there were no mechanism and pure self-interest governed?
+- What would they prefer to report or do under a naive mechanism?
+
+**Step 3: Misalignment diagnosis**
+Describe the current equilibrium or default behaviour — what players actually do without the mechanism, or what they do under the current flawed system. Why is this bad? Identify the specific gap between what players find individually rational and what would be collectively desirable.
+
+**Step 4: Mechanism specification**
+Design the rules and payoffs. Work through three components:
+
+**a. Information revelation**: How do you incentivise players to truthfully reveal their private information? Apply the revelation principle: design payoffs so truth-telling is the dominant strategy. Ask: "If a player with private information X reports Y instead, do they gain or lose?" The mechanism should ensure they lose — or at minimum don't gain — from misreporting.
+
+**b. Rules and allocation**: Given truthful reports, what decision rule produces the desired outcome? How are goods, tasks, payments, or recognition allocated?
+
+**c. Transfers and penalties**: What monetary or non-monetary transfers ensure the mechanism is individually rational (players prefer participating to not) and incentive-compatible (players prefer truth-telling to lying)?
+
+**Step 5: Manipulation check**
+Test the mechanism against strategic players. Ask: "What would a player with extreme private information do?" Try the boundary cases: the player with the highest possible valuation, the lowest, the one who most wants to game the system. Can they improve their outcome by misreporting? If yes, identify the loophole and revise.
+
+---
+
+## Output Format
+
+### Mechanism Design
+
+**Desired Outcome**
+[Precisely stated: whose behaviour, what information, what allocation]
+
+**Player Map**
+[For each player: private information they hold + current incentives + what they'd do without the mechanism]
+
+**Misalignment Diagnosis**
+[Current equilibrium / default behaviour and why it fails to produce the desired outcome]
+
+**Mechanism Specification**
+- *Information revelation rule*: [How truth-telling becomes dominant — what the payoff structure looks like]
+- *Decision/allocation rule*: [How reported information is processed into outcomes]
+- *Transfers and participation constraints*: [What ensures players prefer to participate and to be honest]
+
+**Manipulation Check**
+[Results of testing against boundary-case players — can they game the mechanism? Identified loopholes and revisions]
+
+**Revised Mechanism** *(if manipulation found)*
+[Updated rules addressing the identified vulnerability]
+
+**Implementation Notes**
+[Practical considerations: information requirements, enforcement, whether the mechanism is robust to partial participation]
+
+---
+
+## Notes
+
+The revelation principle guarantees that for any goal achievable by any mechanism, there is a direct, honest mechanism that achieves it. But "achievable in principle" doesn't always mean "simple to implement." When the mechanism requires detailed information or complex transfer schedules, consider whether a simpler but slightly less optimal mechanism is more practical.
+
+Mechanism design is the formal version of the incentive design problem that appears everywhere: performance reviews, procurement, platform rules, voting systems, club governance, and any setting where the designer wants players with private information to behave in a collectively beneficial way.
+
+For analysis of the equilibrium your mechanism produces (confirming it actually works as intended), use `/game-theory-equilibrium`. For auction-specific mechanism design — the most studied instance of the field — use `/game-theory-auction`.
+
+For the related problem of getting players to cooperate over time (rather than getting a static mechanism right), use `/game-theory-iterated`.
+
+Pairs with: `/social-incentive-analysis` (the social and political dimensions of the same incentive problem), `/game-theory-equilibrium` (verifying the mechanism's equilibrium), `/game-theory-auction` (specialised mechanism design for competitive bidding).

package/skills/game-theory-prisoners-dilemma/SKILL.md

@@ -0,0 +1,81 @@
+---
+name: game-theory-prisoners-dilemma
+description: "Analyses cooperation problems where individual rationality produces collective irrationality. Triggers: 'cooperation problem', 'prisoner's dilemma', 'everyone defects even though cooperation is better', 'race to the bottom', 'should I cooperate or defect', 'why won't anyone cooperate', 'collective action failure', 'why do we all end up worse off'."
+---
+
+# Game Theory: Prisoner's Dilemma
+
+The prisoner's dilemma is the central problem of cooperation. Its structure: each player has an individual incentive to defect regardless of what the other does, so both defect — and both end up worse than if they had cooperated. Individual rationality produces collective irrationality.
+
+This structure appears everywhere: countries competing on subsidies both nations would be better without, companies in a price war that erodes margins for everyone, colleagues who each underinvest in shared infrastructure, advertisers who would all benefit if no one ran ads but each is tempted to run them. Recognising the structure is the first move; it tells you why the situation is hard and what the real leverage points are.
+
+Robert Axelrod's computer tournaments (1984) produced one of the most important empirical results in social science: in *repeated* prisoners' dilemmas, Tit for Tat — cooperate first, then mirror your opponent's previous move — consistently outperformed every more complex strategy. Its winning properties: *nice* (cooperates first), *retaliatory* (immediately punishes defection), *forgiving* (returns to cooperation as soon as the opponent does), and *clear* (easy to understand and predict). The lesson: cooperation is achievable without altruism, if the game is repeated and players are patient.
+
+---
+
+## Your Process
+
+**Step 1: Structure verification**
+Confirm the three conditions that define a prisoner's dilemma:
+- (a) *Mutual cooperation dominates mutual defection*: if both cooperate, both do better than if both defect
+- (b) *Defection is individually rational*: each player does better defecting regardless of what the other does (defection is a dominant strategy)
+- (c) *The temptation to defect is real*: there is a genuine payoff advantage to defecting on a cooperating partner
+
+If all three hold: this is a genuine prisoner's dilemma. If (a) fails, cooperation isn't actually better — the analysis changes. If (b) fails, there's no defection temptation — cooperation is already individually rational.
+
+**Step 2: One-shot vs. repeated**
+Is this a single interaction or an ongoing relationship? This is the most important structural question. In a one-shot game, defection is the rational dominant strategy and there is no mechanism for cooperation. In a repeated game, the future creates incentives for today's cooperation.
+
+**Step 3: Shadow of the future**
+In repeated games, assess how much each player values future interactions. The discount factor (δ) captures how much tomorrow's payoff is worth today — high δ means future interactions matter a great deal; low δ means players are impatient or uncertain the relationship will continue. Cooperation is sustainable in repeated play if δ is above a threshold that depends on the payoff structure. Practically: ask how much each player needs the relationship to continue, how visible their defection will be, and how quickly punishment can be applied.
+
+**Step 4: Trigger conditions**
+In a cooperative equilibrium, cooperation is sustained by the threat of punishment. What action would constitute defection? How quickly would it be detected? How severe is the punishment, and is it credible? A cooperation equilibrium is only stable if the punishment threat is believable and proportionate.
+
+**Step 5: Structural prescriptions**
+If cooperation is failing or fragile, what changes to the structure could make cooperation individually rational?
+- *Repeat the game*: turn a one-shot interaction into an ongoing relationship
+- *Increase transparency*: make defection immediately visible so punishment can follow quickly
+- *Change the payoffs*: increase the value of mutual cooperation or add penalties for defection (bonds, enforcement, regulation)
+- *Reduce the temptation*: lower the short-run gain from defection
+- *Build shared identity*: reframe the game so defection feels like a cost to a shared project, not just a strategic choice
+- *Third-party enforcement*: external authority makes commitments binding
+
+---
+
+## Output Format
+
+### Prisoner's Dilemma Analysis
+
+**Structure Verification**
+- Mutual cooperation better than mutual defection: [Yes / No / Partial]
+- Defection individually rational (dominant strategy): [Yes / No]
+- Genuine temptation to defect: [Yes / No]
+- Verdict: [Confirmed prisoner's dilemma / Modified structure / Not a PD — see alternative framing]
+
+**Payoff Map**
+[The four key outcomes: mutual cooperation / you cooperate, they defect / you defect, they cooperate / mutual defection — with approximate payoffs or ordinal rankings]
+
+**One-Shot vs. Repeated Assessment**
+[Is this a single interaction or an ongoing relationship? How many rounds are expected? Does either player expect to exit soon?]
+
+**Shadow of the Future Analysis**
+[How much do players value continued interaction? What is the discount factor — high (cooperation sustainable) or low (cooperation fragile)? What would cause either player to reduce their valuation of the relationship?]
+
+**Trigger Conditions**
+[What constitutes defection? How quickly detected? Is punishment credible and proportionate?]
+
+**Structural Prescriptions**
+[Specific recommendations for changing the game structure to make cooperation individually rational — ranked by feasibility and impact]
+
+---
+
+## Notes
+
+The prisoner's dilemma is the one-shot cooperation problem. For formal analysis of how cooperation can be sustained in repeated interactions, including specific strategy recommendations, use `/game-theory-iterated`.
+
+If the structure is right but the rules are wrong — you want to change the game itself — use `/game-theory-mechanism-design`, which designs payoffs and rules specifically to align individual and collective incentives.
+
+For analysis of the stable outcome of the one-shot version (and confirmation that defection is indeed the Nash equilibrium), use `/game-theory-equilibrium`.
+
+Pairs with: `/social-incentive-analysis` (the social and power dynamics around the same incentive problem), `/strategy-alliance` (the strategic logic of forming cooperative relationships).

package/skills/game-theory-signaling/SKILL.md

@@ -0,0 +1,72 @@
+---
+name: game-theory-signaling
+description: "Analyses credibility problems and designs signals that are believable because they're costly to fake. Triggers: 'how do I signal credibly', 'signaling', 'they won't believe me', 'cheap talk', 'commitment device', 'how do I make a credible commitment', 'asymmetric information', 'how do I prove I'm serious', 'they don't trust my claim'."
+---
+
+# Game Theory: Signaling
+
+Michael Spence's 1973 insight: education is not only valuable because it increases productivity — it is valuable as a *signal* because it is costly enough that low-ability workers won't bother acquiring it. If a credential is easy enough to fake, it conveys no information. The signal is credible only when it is cheaper for the type who actually has the quality being claimed.
+
+The core principle: **cheap talk cannot be credible in adversarial or asymmetric-information contexts**. If saying "I'm trustworthy" costs nothing, then everyone — trustworthy or not — will say it, and the statement conveys nothing. The receiver knows this and discounts it. A credible signal must be costly in a way that is rational only if the claim is true. This is the separating condition: high types find the signal worth acquiring; low types don't.
+
+George Akerlof's market for lemons (1970) shows the consequence when signaling fails: information asymmetry causes good products to be driven out by bad ones, because buyers can't distinguish them and price accordingly. Sellers of good products can't credibly signal their quality, so the market collapses toward low-quality goods and prices. Thomas Schelling extended this to commitment devices: any action that credibly binds you to a future course of action changes what others expect you to do — and thereby changes what they do now.
+
+---
+
+## Your Process
+
+**Step 1: Information asymmetry**
+Identify what one party knows that the other doesn't. Name the informed party and the uninformed party. What is the private information — quality, intent, ability, commitment, type? What would the uninformed party do if they had this information?
+
+**Step 2: Communication goal**
+What does the informed party want to credibly communicate? State it precisely: not just "I'm good" but specifically what quality, commitment, or type is being claimed and why it matters to the receiver.
+
+**Step 3: Cheap talk diagnosis**
+Why isn't verbal communication credible here? Work through the receiver's reasoning: "If they said this regardless of whether it's true — which they'd be tempted to do — then my hearing it gives me no information." Identify the specific incentive to misrepresent that makes verbal claims unbelievable.
+
+**Step 4: Costly signal design**
+What action would be credible because it is only rational to take if the claim is true? Evaluate candidate signals on three criteria:
+- *Cost differential*: the signal must cost less for the type making the true claim than for a type trying to fake it (the single-crossing condition)
+- *Observability*: the receiver must be able to verify the signal was taken
+- *Magnitude*: the signal must be costly enough that low types wouldn't bother, but not so costly that high types wouldn't either
+
+**Step 5: Commitment devices**
+For claims about future behaviour (not just present type), identify commitment devices that bind the sender to the claimed course of action:
+- *Burning bridges*: eliminating the ability to take the contrary action (accepting an exclusive contract, moving to a new city)
+- *Public commitment*: making the claim in front of an audience that would observe a violation
+- *Collateral*: putting something of value at risk contingent on the claimed behaviour
+- *Third-party enforcement*: a binding agreement that creates external penalties for defection from the claim
+
+---
+
+## Output Format
+
+### Signaling Analysis
+
+**Information Asymmetry**
+[Who has the private information? What is it? Who needs to be convinced of what?]
+
+**Communication Goal**
+[Precisely what the informed party needs to credibly establish in the receiver's mind]
+
+**Cheap Talk Diagnosis**
+[Why verbal claims alone are not credible — what incentive to misrepresent makes the receiver discount them]
+
+**Credible Costly Signals**
+[Candidate signals ranked by credibility — for each: what makes it costly to fake, whether the cost differential holds, and whether it's feasible in this context]
+
+**Commitment Devices**
+[Specific mechanisms that bind the sender to claimed future behaviour — ranked by strength and feasibility]
+
+**Recommended Signaling Strategy**
+[The specific combination of signal and/or commitment device most likely to achieve credibility given the context, the receiver's priors, and the costs involved]
+
+---
+
+## Notes
+
+Signaling analysis has two sides. This skill focuses on the sender's problem: how to signal credibly. The receiver's problem — how to evaluate incoming signals, distinguish cheap talk from costly signals, and update beliefs correctly — is closely related. If you are the receiver trying to evaluate a claim, the same framework applies in reverse: ask what this signal would cost if the claim were false.
+
+Signaling games have their own equilibrium structure. A *separating equilibrium* is one where different types choose different signals and can be distinguished — this is usually the desirable outcome. A *pooling equilibrium* is one where all types choose the same signal — no information is transmitted, and the signal is uninformative. Check which equilibrium your proposed signal actually produces.
+
+Pairs with: `/game-theory-equilibrium` (the full equilibrium analysis of signaling games), `/strategy-deception` (the counter-perspective: managing what others believe about you and anticipating their signals), `/game-theory-mechanism-design` (when the goal is to design a system that elicits honest revelation rather than crafting a one-off signal).

package/skills/historical/SKILL.md

@@ -0,0 +1,78 @@
+---
+name: historical
+description: "Entry point for the historical reasoning toolkit. Routes to the right historical skill based on your situation. Use when you say 'historical', 'has this happened before', 'what does history say', 'what cycle is this', 'what usually goes wrong', 'what's the lesson', or want historical reasoning applied without knowing which specific tool fits."
+---
+
+# Historical
+
+Applies historical reasoning to current situations. Diagnoses what kind of historical analysis is needed and applies the right tool.
+
+## Which tool fits
+
+| You need to... | Tool |
+|---|---|
+| Identify what recurring cycle this is and where you are in it | cycle-detection |
+| Find recurring failure modes from similar past situations | failure-analysis |
+| Extract the transferable principle from a specific historical case | lesson-extraction |
+| Find genuinely similar historical situations to inform a decision | precedent-analysis |
+
+## Routing Decision
+
+- **Situation feels like it has been seen before, want to know where in the pattern you are** → cycle-detection
+- **About to do something and want to know how it typically fails** → failure-analysis
+- **Have a specific historical case and want to know what it actually teaches** → lesson-extraction
+- **Making a decision and want to know what history says** → precedent-analysis
+- **Unclear** → precedent-analysis; finding the analogous situation usually reveals cycles, lessons, and failure modes together
+
+## Confirm Direction
+
+After diagnosing which tool fits, present the recommendation before executing:
+
+> My read: **[diagnosed tool]** — one sentence on why it fits.
+
+- **A) Yes, run that tool**
+- **B) Show me all options** — list every skill in this category with one-line descriptions
+- **C) Quick version** — lighter-weight alternative for this situation, if one exists
+- **D) Re-diagnose** — describe the situation differently for a second read
+
+Wait for their selection before proceeding.
+
+---
+
+## Cycle Detection
+
+*Identifies what recurring cycle this is and where in it you currently are.*
+
+Most situations are instances of known cycles: hype cycles, market cycles, innovation S-curves, boom-bust patterns, political pendulum swings. Name the cycle candidates. Test each: does the current situation match the structural characteristics of that cycle? If so: what phase are you in (early, peak, correction, trough, recovery)? What does the cycle predict comes next?
+
+**Output:** Cycle identification with evidence, current phase assessment, and what the cycle predicts comes next.
+
+---
+
+## Failure Analysis
+
+*Extracts recurring failure modes from similar past situations.*
+
+Most failures have happened before in recognizable patterns. Identify 3-5 historical situations that are structurally similar to the current one. For each: what went wrong? Was the failure caused by overconfidence, resource depletion, misreading the environment, internal conflict, timing, or something else? Look for the failure mode that appears across multiple cases — that's the one most worth preparing for.
+
+**Output:** Historical failure case inventory, recurring failure modes ranked by frequency and severity, and the specific early warning signs to watch for.
+
+---
+
+## Lesson Extraction
+
+*Extracts the transferable principle from a specific historical case.*
+
+Historical cases carry both contingent details (specific to their time and place) and transferable principles (valid across contexts). The challenge is separating them. Take the case and ask: what actually caused the outcome — the surface events or the underlying dynamics? If you removed all the period-specific details, what structural principle remains? Test that principle against at least one other historical case.
+
+**Output:** The contingent surface details set aside. The underlying structural principle. Cross-case validation. How the principle applies to the current situation.
+
+---
+
+## Precedent Analysis
+
+*Finds and applies genuinely similar historical situations.*
+
+Distinguish true precedents from superficial analogies. A true precedent shares the underlying causal structure, not just surface similarity. Find 2-3 candidate precedents. For each: what makes it genuinely similar? What makes it different in ways that matter? What did decision-makers do, and what happened? What would they have done differently in hindsight?
+
+**Output:** Precedent inventory with genuine vs. superficial similarity assessment, decision-outcome analysis for each, and the lessons that most directly apply.

package/skills/historical-cycle-detection/SKILL.md

@@ -0,0 +1,102 @@
+---
+name: historical-cycle-detection
+description: "Identifies what recurring cycle the current situation is an instance of — and where in that cycle you currently are. TRIGGERS: 'what cycle is this', 'where are we in the cycle', 'is this a bubble', 'what comes next', 'have we been here before'."
+---
+
+# Historical Cycle Detection
+
+Most situations that feel unprecedented are instances of recognisable cycles. The
+value of cycle identification is not prediction — cycles don't produce certainties —
+it is orientation. Knowing where you are in the cycle tells you what phase logic to
+apply, what the typical incentive pressures are at this point, and what tends to come
+next absent a significant disrupting variable.
+
+---
+
+## Your Process
+
+**Step 1: Describe the Situation and Recent Trajectory**
+What is happening and how has it developed? Focus on direction of change —
+accelerating, plateauing, reversing — and the sentiment among participants. Sentiment
+is often the most reliable indicator of cycle position because it drives behaviour
+independently of fundamentals.
+
+**Step 2: Match to the Most Fitting Cycle**
+Evaluate against these candidate cycles and select the strongest match:
+- **Hype cycle** — technology moves through peak of inflated expectations, trough
+  of disillusionment, slope of enlightenment, plateau of productivity. Characterised
+  by sentiment-fundamentals divergence.
+- **Bubble-and-bust** — asset price or belief system inflates beyond fundamentals,
+  sustained by new-entrant demand and self-referential confidence, then corrects
+  sharply when the marginal buyer disappears.
+- **Adoption curve** — innovators, early adopters, early majority, late majority,
+  laggards. Each phase has different buyer motivations and objections.
+- **Political cycle** — power consolidates, overreaches, triggers backlash, produces
+  reform or counter-consolidation. The mechanism is legitimacy erosion via overreach.
+- **Organisational change curve** — shock, denial, resistance, exploration,
+  commitment. The emotional response to disruptive change follows a consistent arc.
+- **Competitive cycle** — fragmented competition, consolidation, dominant player
+  emergence, disruption by new entrant. Each phase has characteristic dynamics.
+
+**Step 3: Map Current Position**
+Where on the cycle is the current situation? Be specific — not just "early stage"
+but the named phase and what observable evidence places it there. Name two or three
+specific current conditions that locate the position.
+
+**Step 4: Characteristic Signs of Current Phase**
+What are the typical behavioural and structural signals of this phase? Go through
+them systematically: which are clearly present? Which are absent or weaker than the
+typical pattern would predict?
+
+**Step 5: Typical Next Phase**
+What follows the current phase? What structural conditions or trigger events typically
+cause the transition? How long do transitions typically take?
+
+**Step 6: Divergences**
+Where does the current situation deviate from the typical cycle pattern? Divergences
+are the most analytically important output — they indicate either that this cycle is
+playing out differently, or that the cycle identification needs revision.
+
+---
+
+## Human Check-in
+
+Before proceeding, ask the user:
+
+**How do you want to run this?**
+
+- **A) Full analysis** — complete all steps, reasoning shown throughout
+- **B) Key findings only** — bottom-line output, skip step-by-step detail
+- **C) Pattern match only** — the specific historical cycle this most resembles
+- **D) Refine the framing** — adjust what we're analyzing before starting
+
+Proceed based on their choice.
+
+## Output Format
+
+**Cycle Match:** [cycle type + one-sentence rationale for why this is the right match]
+
+**Current Position:** [named phase + specific evidence that locates it there]
+
+**Characteristic Signs**
+
+| Sign of Current Phase | Present / Absent / Partial | Notes |
+|---|---|---|
+| [typical indicator for this phase] | [assessment] | [specific observation] |
+
+**Typical Next Phase:** [what usually follows + the conditions that trigger the transition]
+
+**Divergences:** [specific ways this instance departs from the typical pattern —
+the highest-value analytical findings]
+
+**Implications:** [what the cycle position suggests about current priorities, risks,
+and timing]
+
+---
+
+## Notes
+
+Cycle identification is a frame, not a forecast. The most valuable output is the
+divergences section — where this situation doesn't fit the expected pattern is where
+the most asymmetric insight lives. If there are no divergences, the analysis isn't
+done.

package/skills/historical-failure-analysis/SKILL.md

@@ -0,0 +1,96 @@
+---
+name: historical-failure-analysis
+description: "Extracts recurring failure modes from similar past situations — most failures have happened before in recognisable patterns. TRIGGERS: 'what usually goes wrong', 'failure pattern analysis', 'how do these typically fail', 'what went wrong last time', 'avoid past mistakes'."
+---
+
+# Historical Failure Analysis
+
+Post-mortems reveal the same failure modes repeating across organisations, industries,
+and eras. Execution failure at handoff. Stakeholder misalignment discovered too late.
+Scope expansion under pressure that destroys the original design. Underestimated
+dependencies that required other things to change first. The failure modes aren't a
+mystery — they just don't get applied prospectively. This skill does that: surfaces
+which patterns are present now, before they become post-mortem findings.
+
+---
+
+## Your Process
+
+**Step 1: Describe the Type of Endeavour**
+What kind of thing is this? A product launch, an organisational transformation, a
+technology implementation, a partnership negotiation, a strategic pivot, a scaling
+operation. Describe it in type terms — this determines which failure mode library
+to draw from.
+
+**Step 2: Identify Common Failure Modes for This Type**
+What do post-mortems and retrospectives reveal about this category? Draw from known
+patterns:
+- **Underestimated dependencies** — other things had to change first (systems,
+  processes, people, culture) that weren't included in the plan
+- **Stakeholder misalignment discovered late** — different parties had different
+  success criteria never surfaced and reconciled before execution
+- **Scope expansion under pressure** — original constraints abandoned to satisfy
+  requests; produces a thing that does everything adequately and nothing well
+- **Execution failure at handoff** — clear plan, unclear ownership across transition
+  points where accountability transfers
+- **Context assumption failure** — the plan was designed for conditions that changed
+  before or during execution
+- **Resource attrition** — key people, budget, or attention lost before the
+  initiative reached self-sustaining momentum
+- **Feedback loop absence** — no early signal mechanism to detect problems while
+  correction was still possible
+
+**Step 3: Test Each Against the Current Situation**
+For each failure mode: is it present in current conditions? What are the specific
+early warning signs that would indicate it is activating? Be concrete — not
+"stakeholder misalignment might occur" but the specific evidence of it that is or
+isn't visible right now.
+
+**Step 4: Rank by Probability Times Impact**
+Which failure modes pose the greatest risk given both their likelihood in this
+specific situation and their consequence if they occur? Use H/M/L ratings for each
+dimension. Priority is the product — a medium-probability, high-impact failure mode
+outranks a high-probability, low-impact one.
+
+**Step 5: Pre-emptive Actions for the Top Three**
+For the top 3 by probability × impact: what specific action taken now — before the
+failure mode activates — would reduce its probability or limit its damage?
+
+---
+
+## Human Check-in
+
+Before proceeding, ask the user:
+
+**How do you want to run this?**
+
+- **A) Full analysis** — complete all steps, reasoning shown throughout
+- **B) Key findings only** — bottom-line output, skip step-by-step detail
+- **C) Recurring failure modes only** — patterns that appear across multiple historical cases
+- **D) Refine the framing** — adjust what we're analyzing before starting
+
+Proceed based on their choice.
+
+## Output Format
+
+**Failure Mode Table**
+
+| Failure Mode | Typical Cause | Early Warning Signs | Present? | Probability | Impact | Priority |
+|---|---|---|---|---|---|---|
+| [mode name] | [root cause] | [observable signals] | [Y/N/partial] | [H/M/L] | [H/M/L] | [rank] |
+
+**Top 3 Failure Modes**
+
+For each of the top 3:
+- **Mode:** [name]
+- **Why it's high priority here:** [specific reasoning for this situation]
+- **Pre-emptive action:** [concrete step, named owner, specific timing]
+
+---
+
+## Notes
+
+The goal is not exhaustive risk listing — a long list produces paralysis, not
+prevention. Identify the 2-3 failure modes most likely to be fatal to this specific
+endeavour and act on them now. The ones not in the top 3 are worth monitoring but
+not worth significant pre-emptive effort.

package/skills/historical-lesson-extraction/SKILL.md

@@ -0,0 +1,97 @@
+---
+name: historical-lesson-extraction
+description: "Extracts the transferable principle from a specific historical case — separating the contingent surface details from the underlying rule that applies across contexts. TRIGGERS: 'what's the lesson', 'extract the lesson', 'what should we learn from this', 'generalise from this case', 'apply this to our situation'."
+---
+
+# Historical Lesson Extraction
+
+Every case contains multiple lessons. Most people extract the wrong one — the surface
+action rather than the underlying principle. "They moved fast" is not a lesson. "Speed
+of iteration was decisive because the cost of a wrong assumption exceeded the cost of
+an incomplete product, making information the binding constraint" is a lesson. This
+skill separates what happened from why it happened, and from that derives a principle
+that transfers to contexts the original case never anticipated.
+
+---
+
+## Your Process
+
+**Step 1: Describe the Case**
+What happened? Who was involved, what decisions were made, what were the outcomes?
+Provide enough specifics to work with — the analysis depends on the case having real
+texture, not just a summary.
+
+**Step 2: Surface Events**
+What happened at the observable level — the actions taken, the decisions made, the
+sequence of events from beginning to outcome? Keep this purely descriptive. No
+interpretation, no causation claims yet. Just what an observer would have recorded.
+
+**Step 3: Underlying Dynamics**
+Why did this happen? What forces, incentives, constraints, beliefs, or structural
+conditions drove the observable events? Ask: what would have had to be different for
+the outcome to change? The answer identifies the causal variables.
+
+**Step 4: Abstract the Principle**
+Strip away names, technologies, industries, time period, and geographic context.
+What is the underlying rule this case illustrates? State it as a transferable
+principle: "When [conditions], [variable] tends to produce [outcome] — because
+[mechanism]." The mechanism is the crucial part — without it the principle can't
+be tested or applied intelligently.
+
+**Step 5: Test Transferability**
+Under what conditions does this principle apply? List the conditions required. Then
+assess whether those conditions hold in the current situation. Where they hold, the
+principle transfers. Where they differ significantly, it may not — or may apply
+with modification.
+
+**Step 6: Apply with Caveats**
+How does the principle apply specifically to the current situation? What would acting
+on it look like concretely? Name the caveats explicitly — the conditions under which
+this principle would give the wrong answer.
+
+---
+
+## Human Check-in
+
+Before proceeding, ask the user:
+
+**How do you want to run this?**
+
+- **A) Full analysis** — complete all steps, reasoning shown throughout
+- **B) Key findings only** — bottom-line output, skip step-by-step detail
+- **C) Transferable principle only** — the single insight most applicable to the current situation
+- **D) Refine the framing** — adjust what we're analyzing before starting
+
+Proceed based on their choice.
+
+## Output Format
+
+**Case:** [specific description — enough detail to work with]
+
+**Surface Events:** [what happened, in sequence, descriptively]
+
+**Underlying Dynamics:** [why it happened — the forces and mechanisms that drove
+the outcome]
+
+**Abstract Principle:** [the transferable rule, stated without domain-specific
+language, including the mechanism]
+
+**Transferability Assessment**
+
+| Required Condition | Present in Current Situation? | Notes |
+|---|---|---|
+| [condition the principle requires] | [yes / no / partially] | [specific observation] |
+
+**Application:** [how the principle applies to the current situation — what it implies
+concretely]
+
+**Caveats:** [conditions under which this principle would mislead]
+
+---
+
+## Notes
+
+The principle is wrong if it only describes the original case. Test it against three
+other cases in different domains — if it doesn't transfer, it's a description, not a
+principle. Keep abstracting until it does. The mechanism is the hardest and most
+important element: a principle without a mechanism is an observation, not a lesson.