agentleFS
OpenLaborOpenLabor/openlabor/skills/taleb-antifragility/SKILL.md

Nassim Taleb - Antifragility

Skill5 starsChanged 3 months agoMITView on GitHub

Nassim Taleb's antifragility framework: classifying fragile/robust/antifragile systems, barbell strategy, via negativa, skin in the game test, Lindy effect for technology choices, and optionality design — from Antifragile (2012) and Skin in the Game (2018)

The file

We split this skill into the rules it gives an agent

8 rules. About 0 are common, 8 are distinctive, and 0 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈8

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Before applying any framework, understand the situation:

    line 21
  2. Distinctive:

    Ask the user: "Describe your business or system — what are the key components, and what would happen to them if the world got significantly …

    line 23
  3. Distinctive:

    Read any relevant context — business model, revenue streams, technology stack, team structure, dependencies.

    line 24
  4. Distinctive:

    Ask these questions ONE AT A TIME.

    line 30
  5. Distinctive:

    If volatility/uncertainty doubles, what happens?

    line 57
  6. Distinctive:

    If you receive surprise bad news, does this element suffer?

    line 58
  7. Distinctive:

    If you receive surprise good news, does this element benefit more than expected?

    line 59
  8. Distinctive:

    No obligation to exercise — must be able to walk away

    line 173

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Nassim Taleb - Antifragility

Taleb's antifragility framework argues that the goal is not to build robust systems (which merely resist shocks) but antifragile systems (which improve from shocks). The most successful organizations and strategies gain from disorder.

Routes when user asks about: antifragility, fragile systems, barbell strategy, optionality, via negativa, skin in the game, Lindy effect, volatility, building resilient companies, Black Swan preparation, how to thrive in uncertainty, convexity, asymmetric bets


Phase 1: Context Gathering

Before applying any framework, understand the situation:

  1. Ask the user: "Describe your business or system — what are the key components, and what would happen to them if the world got significantly more volatile or unpredictable tomorrow?"
  2. Read any relevant context — business model, revenue streams, technology stack, team structure, dependencies.

Phase 2: Diagnostic Questions

Ask these questions ONE AT A TIME. Wait for each answer before asking the next. Adapt based on answers — skip questions that have already been answered.

  1. "If your biggest customer disappeared overnight, or your main distribution channel shut down, what happens to your business? How long could you survive?"
  2. "What percentage of your resources are you spending on 'safe' proven activities vs. small experimental bets with potentially big upside?"
  3. "What have you added to your business recently — and more importantly, what have you removed? Is complexity growing or shrinking?"
  4. "How old and battle-tested are the core technologies and business models you rely on? Are you building on proven foundations or cutting-edge unproven ones?"
  5. "When you take advice from someone — a consultant, an advisor, an investor — do they personally bear any consequences if they're wrong?"

Maximum 5 questions. Stop early if you have enough to work with.


Phase 3: Analysis

Apply Taleb's frameworks to the user's specific situation:

The Triad: Fragile / Robust / Antifragile Classification

Classify every key business component:

PropertyResponse to DisorderExample
FragileBreaks, loses valueSingle-customer dependency, high leverage
RobustUnchanged, survivesCash position, redundant systems
AntifragileImproves, gains valueStartup ecosystem from failures, fitness from stress

Classification test for each business element:

  1. If volatility/uncertainty doubles, what happens? Gets worse = Fragile. Unchanged = Robust. Gets better = Antifragile.
  2. If you receive surprise bad news, does this element suffer? Yes = Fragile. No = Robust.
  3. If you receive surprise good news, does this element benefit more than expected? Yes = Antifragile.

Business Fragility Audit:

ComponentFragile SignalAntifragile Signal
RevenueOne customer >30% revenueDiversified, counter-cyclical mix
TeamOne person holds all key knowledgeDistributed knowledge, strong culture
TechnologySingle-vendor lock-inMulti-vendor, open standards
FundingDependent on next funding roundProfitable or near-profitable
DistributionOne channel (e.g., only Google SEO)Multiple independent channels
SuppliersOne critical supplierMultiple qualified suppliers

The Barbell Strategy

Rather than seeking the "optimal" middle position, go to the extremes simultaneously — very safe on one end, high-optionality risk-taking on the other. Avoid the deceptive middle.

Why the middle is dangerous: "Moderate risk" looks safe but has hidden fragility — not safe enough to survive a crash, not risky enough for transformative upside.

Business barbell applications:

Capital barbell:

  • 80-90% in highly conservative, low-return assets (T-bills, cash, proven revenue streams)
  • 10-20% in high-upside, limited-downside bets (experiments, new product lines)
  • Nothing in the "medium-risk, medium-return" middle

Product development barbell:

  • Core product: extremely reliable, well-tested, low-variation (safe end)
  • Experimental features: fast, cheap, high-variance experiments (risk end)
  • No "medium-stakes" development too expensive to be experimental but not reliable enough to be core

Hiring barbell:

  • Core team: deeply trusted, long-tenure, extremely reliable (safe end)
  • Contractors/experimenters: cheap, time-limited, high-variance experiments (risk end)

Barbell design template:

Conservative End (70-90% of resources):
- What is this protecting?
- Downside if this fails? [must be: company-survivable]
- Return: [low but reliable]

Risk End (10-30% of resources):
- Potential upside?
- Maximum loss? [must be: pre-committed, limited]
- Asymmetry ratio: upside / downside = [must be > 5:1]

Via Negativa (Subtraction Principle)

"The good is mostly in the absence of bad." — Taleb

Removing negatives is more powerful than adding positives — and far less risky.

Why subtraction wins:

  • Adding creates complexity; complexity creates fragility
  • Removing bad things is often irreversible improvement
  • We know what to subtract (current problems) better than what to add
  • Adding creates dependencies; subtracting creates independence

Via negativa audit for the user's business:

What can we remove?

  • Meetings that could be emails (or eliminated entirely)
  • Features nobody uses (product complexity tax)
  • Customers who cost more than they generate
  • Processes added "just in case" that no longer serve a purpose
  • Tools that overlap with other tools
  • Organizational layers adding bureaucracy without judgment
  • Commitments consuming attention without commensurate return

Identify top 3 things in each category that, if removed, would make everything else work better.

The Lindy Effect

"If a book has been in print for 40 years, it will stay in print for another 40 years." — Taleb

For non-perishable things (technologies, business models, ideas), future life expectancy is proportional to current age.

Lindy test for technology choices:

Technology AgeLindy AssessmentDecision
<2 yearsUnproven, high failure rateBarbell experiments only
2-5 yearsGaining evidence, still riskyNon-critical systems only
5-15 yearsSubstantial track recordReasonable for core systems
15+ yearsBattle-testedPrefer for mission-critical

Lindy for business models:

  • Subscription model (100+ years): very Lindy
  • Advertising model (100+ years): Lindy
  • Marketplace model (50+ years): Lindy
  • NFT-based revenue (3 years): not Lindy — don't bet the company on it

Optionality Design

Antifragility comes from having options — positions with capped downside and uncapped upside.

What an option looks like in business:

  • Has a capped, pre-known downside (the option premium)
  • Has an uncapped upside
  • Doesn't require you to exercise it if upside doesn't materialize

Business options to identify:

  • Small R&D project ($50K downside; new product line upside)
  • Waitlist for a new feature (time cost; validated demand before building)
  • Design partner relationship (time cost; product direction + first customer)
  • Partnership pilot (3 months; scalable channel)
  • Freelancer before full-time hire (higher hourly; validated need before commitment)

Option design rules:

  1. Know the maximum downside before entering
  2. Asymmetry ratio: upside should be at least 5x the downside
  3. Multiple small options > one large bet
  4. No obligation to exercise — must be able to walk away
  5. Time-bounded: clear review date

Skin in the Game Test

"Never take advice from someone who doesn't bear the consequences of their recommendations." — Taleb

For any recommendation the user is receiving, ask: "What happens to this person if they're wrong?"

Implementing skin in the game:

  • Contractors paid on results > paid by the hour
  • Partners with equity/revenue-sharing > flat fees
  • Seek advice from people personally invested in outcomes (founders, operators) over those who aren't (most consultants, journalists, academics)

Phase 4: Report

Produce a structured report with this format:

Antifragility Assessment — Taleb Framework

Situation Summary: [1-2 sentences describing the business/system]

Antifragility Scorecard:

DimensionScore (1-5)Evidence
Revenue diversification/5
Customer concentration/5
Technology dependencies/5
Team knowledge distribution/5
Funding/cash runway/5
Active options/experiments/5
Lindy score of core technology/5
Advisor skin in the game/5

Overall: [X/40] — 35-40: Antifragile. 25-34: Robust. Below 25: Fragile.

Key Findings:

  • Fragile elements: [specific components classified as fragile with evidence]
  • Barbell assessment: [is the user in the dangerous middle, or properly positioned at extremes?]
  • Via negativa opportunities: [top 3 things to remove]

Recommendations:

  1. [Most critical fragility to address] — Why: [Taleb framework reasoning]
  2. [Barbell strategy adjustment — what to move from middle to extremes]
  3. [Via negativa action — what to subtract for immediate improvement]

Risk/Watch Items:

  • [Non-Lindy dependencies that could fail]
  • [Advisors without skin in the game]

Bottom Line: [One sentence — Taleb's verdict: is this system fragile, robust, or antifragile — and what's the single most important change to move it toward antifragility?]


Sources

  • Antifragile: Things That Gain from Disorder — Nassim Nicholas Taleb (2012)
  • The Black Swan — Nassim Nicholas Taleb (2007)
  • Skin in the Game — Nassim Nicholas Taleb (2018)
  • Fooled by Randomness — Nassim Nicholas Taleb (2001)
  • Incerto series — complete 5-volume collection

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.