Join the BeatLib Project: a skill library for storytelling to help deeply technical founders

An LLM will write you a thousand stories a minute. They will all sound the same.

Hence, you need skills; harness them to level up the models and tell better stories.

As the startup ecosystem was growing around the world, Sequoia wrote a blog post on business plans, which was adapted into a pitch deck template that became the most famous Sequoia Pitch Deck Template.

At BoldCap, Sathya Nellore Sampat and I are inspired to help founders, especially those who are deeply technical, by complementing their skill set with storytelling. This has been very valuable to founders over the last 1 year, and we decided to productise it as a Skill Library to help more founders.

But today, we need new-age solutions to new-age problems. Inspired by how Sequoia created the pitch deck template, I wanted to build an Open-Source Skill Library for Founders to design their pitch decks and pitch memos in ways that bring out the best in them.

Introducing BeatLib: an open-source skill library for storytelling and narratives. A launch note and an invitation.

Writing was never the bottleneck. Taste was. The moment every founder, marketer, and PM can generate a fluent narrative with a single prompt, fluency stops being a signal and becomes noise. What survives is the part a base model cannot fake: a decision that cost something, a value that actually turns, a customer sentence quoted unprompted, a structure chosen because the evidence demanded it.

BeatLib is our attempt to openly encode that part with you.

The three-sentence version.

1. LLMs made stories infinitely producible and infinitely generic, so the scarce input is now craft, not words.
2. BeatLib is an open-source library of storytelling skills: portable instruction files that make any AI agent build narratives that survive retelling.
3. It is contributor-first, with developers and storytellers building the library together, and it opens on an invite-first basis.

Where this comes from

I am a failed founder and a failed filmmaker. Individually, neither worked out for me; blending them became my job. I tell stories for startups at a venture fund, and I run a small storytelling lab on the side.

The two skills that start this library were not built to launch a project. They were built because I needed them for my own work, every week. I kept writing down what I knew about story, from the craft books, the pitch rooms, and the failures, into instruction files a model could load and follow. At some point I noticed the encoding was the point. Craft written down this way is portable, testable, and improvable by anyone who holds more of it than I do. That is a library, and libraries want contributors.

What storytelling engineering means

A beat is the atomic unit of story: the smallest moment where a value shifts. Storytelling engineering treats a story the way engineers treat a system: raw material becomes typed claims, claims are joined by edges that only count when evidence passes along them, anchors hold the weight, and every draft is audited against a rubric before it ships.

A "skill" here is neither a prompt nor a wrapper. It is a SKILL.md file plus reference material that any capable model loads and runs the same way, in Claude Code, Cursor, Codex, or a raw API call. The mission is narrow and testable: close the gap between a generic model and a good storyteller, and do it in the open.

Show, don't tell

While writing this post, I used a plain model, no skills loaded, and gave it this prompt: "Write a short origin story for BeatLib, an open-source storytelling skill library for AI agents, founded by someone who works in venture capital." Here is what it wrote, unedited:

Read it twice. It is fluent, warm, well-paced. It is also false in every particular. I have never scribbled frameworks in the margins of a deck for a decade. There was no weekend of frustration. The model was asked for a story it had no material for, so it did the only thing a base model can do: it invented a plausible life and handed it to me.

Then I loaded the skill and asked again. It did not write. It asked. With the skill, it interviewed first.

I answered. It then built a version from my answers, and only from my answers.

Every sentence in that version traces to something I actually said. Nothing in the first version does. That is the whole difference, and it is the difference that matters now: the base model gives you a story; the skill makes sure it is yours.

One more, then I'll stop. I also asked the plain model to write the opening of this very post. It produced clean launch copy: "Great stories aren't magic. They're built from beats… install it, contribute to it." Perfectly fine, and it would fit any project launched by anyone this year. The opening you actually read at the top came through the skill: it leads with the problem, stakes a claim a sceptic can argue with, and sounds like one specific person. You are reading the with-skill output right now. This post is the demo.

The two skills we start with

1. Story Architect: the general narrative engine

Its stance is create first, write second: it settles who the audience is, the one idea the piece defends, and the emotional turn being designed, before a sentence exists.

It draws on four bodies of craft, story science, dramatic structure, screenwriting, and proven marketing arcs, and audits every draft against a hard quality bar.

It also carries an adversarial mode: one persona tries to break the story the way a skeptical room would, then a second repairs only what broke.

The mechanics stay under the hood; what you feel is a draft that has already survived its toughest reader.

2. Pitch Story: the specialist for the raise, for customers, for hiring

The highest-stakes narrative a company tells. Pitch Story is architected as a pipeline, not a prompt. Here is what it brings that a base model does not:

• It interviews before it writes. It asks for your real material and refuses to invent what you haven't lived; thin input gets specific questions, not a plausible draft.
• The Three Unlocks. It surfaces what just became knowable, buildable, and wanted, and leads with the strongest case for why now, grounded in evidence rather than assertion.
• The Story Graph. It turns your material into anchored claims a skeptic can't argue with. Graph engineering, not loop engineering. And the graph, not the deck, becomes the reusable asset.
• The Taste Ledger. It excavates the fingerprints a generic pitch smooths over: the feature you killed, the workaround you refused, the hire you passed on.
• A chaptered template, filled. It fills a Story Deck and assembles it into a single self-contained Story Document, along with a verbal pitch, a one-pager, a cold email, a memo, and a gap list of what you haven't lived yet. The same graph re-cuts for the hire pitch and the launch post.

How it works: the system underneath the skill

Underneath the two skills is a system, not a one-shot prompt. At its centre sits persistent state: a story graph of typed, evidence-backed claims, and every draft is a cut of it.

Material moves through staged steps: ingest, excavate, lock the belief-stack, build the arc, draft, cut. Three gates sit between them, and nothing crosses on credit.

Are there enough anchors to build? Has the founder approved the story before any prose exists? Does every claim trace to something they actually said?

Why a process at all?

Because storytelling is inherently a craft that is reinforced. You improvise, you take feedback, you add context, you fix the gaps, and the story sharpens with every pass.

The skill files are shaped around that truth: each of the six steps takes you through one pass of the work, each gate tells you what is missing before you move on, and the output lifts because the passes compound.

A one-shot prompt gives you the model's first guess. A process gives you a story that has already been through its rehearsals.

Both skills share the rule that defines the library, the one you watched in action above: they present what exists, and they never invent. Thin input gets an itemised request for more, not a plausible-sounding draft.

Benchmarking this skill and judging its efficiency

A skill is only as good as its evidence, so I test one the way you would test a model: the same brief, the base model scored against base-model-plus-skill, not on "is it fluent" (both are), but on whether the output does what a story has to do. And I'll be straight: a full benchmark suite is not designed yet, on purpose. Storytelling evaluation is genuinely unsolved: automatic metrics correlate poorly with human judgment, and a hand-wavy rubric is just slop wearing a lab coat. So I am building it in the open.

Where it stands: constraint satisfaction. Right now each skill is tested against constraint-satisfaction scores: every story type declares the elements a good version must contain, and an output is graded on how many it actually satisfies. Objective, checkable, and different per requirement. For an origin story, for example: a named protagonist, a concrete scene or detail, a refusal or a value, a causal turn ("because…"), one line in a real voice.

The principle. A skill has no benchmark of its own: it is inert until a model runs it. So we measure the lift it gives a fixed base model on a fixed rubric, reported per model, on briefs it has never seen. The lift is the product.

Where it is going. A deterministic slop floor (the known tells any output must clear); a faithfulness check for Pitch Story (every claim traced to the founder's own material); and a calibrated judge for the human dimensions, used only once its scores are shown to track real human ratings. Numbers ship when the rubric is calibrated, and the briefs are held out, not before. That restraint is the point, and it is the bar for contributing: a new skill gets merged when its scorecard beats the base model on briefs it has never seen.

Who I am looking for

BeatLib is contributor-first by design. The library will only be as good as the craft the community encodes into it, and I would rather build it with practitioners than ship it finished and closed.

• Developers who build with agents and skills: people who can sharpen a SKILL.md, tighten a reference file, add an eval, or architect a new skill's structure.
• Storytellers: screenwriters, brand strategists, narrative designers, founders who have actually raised. People who hold craft worth encoding.

A contribution is a directory: a SKILL.md with its contract, a spine of principles, and reference files loaded on demand. It clears the library's ethos before it merges: excavate, never invent; one controlling idea per skill; model-agnostic; audited against its own quality bar; and a scorecard that beats the base model on unseen briefs.

Phase 1 is invite-only: a small group of developers and storytellers setting the library's DNA and the standard for contributions.

Phase 2 opens it to everyone: public PRs and a growing catalogue of storytelling skills anyone can install and extend.

This post was written with the skills it describes. Story Architect set the structure and audited it; Pitch Story kept every claim anchored in reality. The base-model quotes above are real outputs, generated while writing and reproduced unedited. No fabricated metrics, because the skills do not allow them.

Supported by BoldCap and Sathya Nellore Sampat. Thanks to Sai Krishna V K for his suggestions on improving it.