Help us improve
Share bugs, ideas, or general feedback.
From skills-for-humanity
Extracts transferable principles from historical cases by separating surface details from underlying dynamics. Use for learning from past events and applying insights to current situations.
npx claudepluginhub human-avatar/skills-for-humanityHow this skill is triggered — by the user, by Claude, or both
Slash command
/skills-for-humanity:historical-lesson-extractionThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Every case contains multiple lessons. Most people extract the wrong one — the surface
Routes to the right historical reasoning tool based on your situation — cycle detection, failure analysis, lesson extraction, or precedent analysis.
Deconstructs problems and decisions via first-principles analysis: surfaces hidden assumptions with origins and load-bearing ratings, uncovers foundational truths, rebuilds from scratch, identifies high-leverage moves. Invoke via /deconstruct.
Builds students' capacity to contextualize historical documents in temporal and social settings. Useful when students read sources ignoring contemporaneous events or know context but fail to apply it.
Share bugs, ideas, or general feedback.
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.
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.
Before proceeding, use the AskUserQuestion tool:
Proceed based on their selection.
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]
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.
After delivering this output, use AskUserQuestion to offer the next move:
/decision-criteria-weighting — Weight decision criteria by the historical lessons/strategy-positioning — Position to apply what history teaches/systems-leverage-analysis — Find leverage points the historical lessons reveal