Open Source · CC BY-SA 4.0

The Golden Section Playbook is open.

Every mistake we have watched B2B software founders make, and the play that prevents each one. Free, forkable, and yours to build on.

168Mistakes
70Plays
59Templates
400+Companies Observed
Read the mistakes list Open the repository

Dear founders,

Golden Section runs on institutional memory. We are deliberate about mistakes — we document them, we learn from them, and we go looking for the next one. That habit is the substance of our partnership with our portfolio, not a slogan about it.

The habit produces two things: a numbered list of mistakes, and the plays that prevent them. Today that is 168 mistakes and 70 plays, with 59 working templates attached. Every mistake is paired to the play that prevents it. All of it came from watching more than 400 B2B software companies over more than a decade.

We have run these plays with founders for years, and shared them widely. Sharing is not the same as handing something over. You could read what we gave you. You could not take it, fork it, correct it, or build something of your own on top of it — because we never actually gave you the right to. Today we do, and we are doing it in a way you can work on alongside us. The whole corpus is here on this site and in a public repository, under a Creative Commons license: yours to copy, adapt, and use commercially, including in ways we would not have thought of.

What changed is the pace. AI is compressing the loop between a conversation with a founder and a codified play. We expect this list to grow faster and get more granular in the next year than it has in ten years of doing it by hand. A playbook that used to change quarterly can now change weekly.

That speed is the opportunity and the risk in one sentence. Version velocity plus AI produces either collective genius or collective slop, and the whole difference is who reviews what gets merged. So there is a human gate: every change is read by a person before it lands, and every claim has to come from something that actually happened to somebody. We would rather move slower and stay true.

We want company in this. Founders, funds, and advisors willing to shepherd it — argue with an entry, add the mistake we have not made yet, fix a formula in a template, or tell us a play did not work. Especially that last one.

This is not altruism and we would rather not pretend it is. We expect to use whatever the collective produces, in our own execution, with our own companies. We can say that plainly because knowledge stopped being the differentiator a while ago. What differentiates now is relationships and execution, and both get stronger as the shared base gets better. There is no version of this where we lose by everyone knowing more.

Our commitment: we keep putting real applications and real outcomes back in, including the ones that did not work. We invite you to do the same.

Start here. Read the mistakes list, end to end. It takes twenty minutes and you will find three things happening in your company right now.

Dougal Cameron
CEO & Co-Founder, Golden Section
What an entry looks like

One mistake, and the play that prevents it.

Every one of the 168 is written like this, and every one points at a play with an owner, a cadence, and an effort estimate. That link is the whole architecture.

From the mistakes list
#16

Running out of cash

Executive

Self-explanatory... don’t do it.

Read it in context →
Prevented by →
The play that prevents it

Cash Flow Forecast

Executive

Build a living cash prediction model from conservative unit-economics assumptions, update it monthly with actuals, and minimize the investment needed to scale.

Owners
Founder, CFO
Cadence
Monthly
Initial effort
13 SP
Ongoing
8 SP
Open the play → Download the Cash Flow Forecast Template (Excel) ↓
See all 168 mistakes
Where to start

Three ways in, by what brought you here.

Something already hurts

Go to the mistakes list, find the one happening in your company right now, and run the play attached to it.

The mistakes list →

I'm building, not firefighting

The 70 plays by category, each with the people required, the cadence, and the effort in story points — so they can be scheduled rather than admired.

The plays by category →

I want it in my own tools

The entire corpus as one Markdown file, plus an llms.txt index — for your own copy, your own fork, or your own AI assistant.

Take the whole corpus →
For AI, explicitly

Hand the whole thing to your model.

The entire corpus — every mistake, every play, every cross-reference — ships as one Markdown file with the attribution and the license in its header, so both travel with the text wherever it goes. Download it, paste it into whichever assistant you already use, and start with this:

Here is the Golden Section Playbook — 168 mistakes B2B SaaS founders make and the plays that prevent them. Read it, then tell me which mistakes my company is currently making based on what I describe next.

Copied
dist/playbook-full.md The whole corpus, one file. Prefer this for ingestion.
llms.txt The repository's index for language models.
goldensection.com/llms-full.txt The site's own full text, if you want the frameworks and research alongside it.

That gets you a model that has read everything. What it still will not know is which of it applies to you — the skills below are the part that does.

Skills, not just text

The corpus says what to do. These say what to do first.

Handing the whole corpus to an assistant works, and it is the fastest thing you can do today. What it will not do is tell you which of the plays applies to your company, this quarter, given the people you actually have. That judgment is the part a venture partner does, and it is the part the repository did not contain.

So the repository now ships a skills/ folder: short instruction files your assistant reads, written to do the four things a play cannot do for itself — choose between plays, fit one to a specific company, check the spreadsheet you already have, and send back what happened when you ran it. They are plain Markdown. No code, no keys, nothing to sign up for, and nothing that stops working if we stop maintaining them.

Work out what is live

Which mistakes are happening in your company right now, the two or three plays to run about it, and — the part most advice skips — what you are choosing not to do, and which mistake that accepts.

playbook-triage →

Turn a play into work

One play becomes assigned, dated tasks — in the task manager you already use, as a CSV you import, or as a PDF with one page per person, which for a ten-person company is often the better answer.

run-play →

Send back what happened

What you adapted, what it actually cost against the play's estimate, and whether the cadence held after the first month — anonymized, and reviewed by you before it goes anywhere.

field-report →

Six are for founders running the playbook in their own company. Two are for people watching a portfolio of them, and for anyone contributing back.

context-interview

Fifteen minutes on a hard clock, once. It asks in the order that changes the advice most — what hurts, the numbers with a date on each, which roles actually exist, what you already run — and it would rather read your board deck than have you recite from memory. It ends by naming the two or three mistakes it already suspects, so the fifteen minutes pays for itself before you do anything else.

playbook-triage

The diagnosis. Which numbered mistakes are live, with the evidence for each; at most three plays, in the order their prerequisites demand; and an explicit list of what is being skipped and the mistake each skip accepts. Three is a hard cap, because a founder in a cash crisis will run none of a list of twelve. It works before you have set anything up, on five questions asked out loud.

artifact-review

You almost certainly have more artifacts than plays — a cash model nobody has put actuals in since spring, an ARR schedule counting unsigned deals. This holds one of them against the play that governs it and grades it: running, nominal, hollow, or absent. Hollow is the dangerous one, because everybody believes that play is covered. Usually the fastest way to find out whether any of this has something to tell you.

run-play

Tasks derived from the play's own steps, assigned by the roles the play names, with the recurring work scheduled at the play's cadence — because a play with no recurrence is a project. When a play names a role you do not have, it puts that to you as a decision rather than quietly assigning fourteen tasks to the founder, which is how a plan dies in week two.

mistake-watch

Your own meeting notes and records read against the mistakes list, monthly. A match needs an observed behavior with a quote and a date, not a vibe. It keeps a log, so a mistake live for three months running looks different from one that appeared last week — which is the distinction that actually changes what you do.

field-report

The loop back. Effort actually spent against the play's story-point estimate is the single most useful thing you can give this corpus, and you can give it without revealing anything. A report saying the play did not work, and why, is worth more than a success story — and it is the one founders swallow.

play-hunt operators

For someone watching many companies rather than one: meeting transcripts read against the corpus, surfacing both the mistakes in progress and the patterns recurring across companies that deserve to become plays the list does not have yet.

play-forge contributors

Writes a play or a mistake to this repository's actual contract — the frontmatter schema, the vocabularies, the body conventions measured across every existing play — and ships a validator that catches the errors before CI does. If you are contributing, start here.

Installing them is copying folders. In Claude Code, this puts them where every project can reach them:

git clone https://github.com/Golden-Section-Tx/playbook.git mkdir -p ~/.claude/skills cp -r playbook/skills/*/ ~/.claude/skills/

Copied

Anywhere else, paste the SKILL.md into your assistant as instructions — they are written to be read by a model, but they are also just readable. Without an assistant at all, the grading scale in artifact-review and the selection rules in playbook-triage work perfectly well in a notebook. Browse them all in skills/.

Your numbers

It has to know your numbers. They stay on your machine.

None of this works on a company the assistant knows nothing about. Advice that does not know your runway, your churn, or whether you have a CFO is the generic advice you can already get anywhere. So the skills need real figures — and real figures are exactly what a founder should be careful about putting inside a folder that came from someone else's repository.

Here is precisely how that is handled, so you can check it rather than trust it.

One folder, and it is yours

Everything the skills learn about your company lives in workspace/ in your copy of the repository: what your assistant knows about the business, the plays you have committed to run, the plans, the reviews, and a log of what has been going wrong. Plain Markdown you can read, edit, or delete without any tool's permission. It doubles as a small operating record — what was true, what you decided to fix, and what happened.

It is excluded from everything you send back

The repository's .gitignore excludes that whole folder, so it is not committed and not pushed. The skills are instructed never to put anything from it into a commit, a branch name, an issue, or a pull request. And when you do contribute something, the skill builds it on a fresh branch taken from this repository rather than the branch you have been working in — which matters, because a pull request carries every commit on its branch, not only the file you meant to change.

Nothing is submitted without you reading it

Anything bound for this repository is anonymized as it is written, not cleaned up afterward, and shown to you in full before it is sent. You say yes, or it does not go.

Two honest caveats

Being ignored by git is a weaker promise than it sounds, and you should know why. Ignoring a file has no effect once git is already tracking it, so a file committed once — by accident, or by forcing it — stays committed. And git history keeps what you delete, so removing a file in a later commit does not remove it from the history you would push.

Which is why there is a check rather than a promise. Run this before you push anything:

python3 scripts/check_private.py

Copied

It reports exactly what would leave your machine, and fails if anything about your company is tracked by git, staged, sitting in your history, or riding along on a branch you are contributing from. It also tells you how to fix each case. It changes nothing by itself, and it needs only Python — no install, no account.

There are two nets, and they catch different things. That check runs on your machine and catches your data before it leaves. A second scan runs on every pull request opened here, checking the diff against a blocklist we maintain on our side. Neither replaces reading your own diff before you open it — a public pull request cannot be unpublished. If you would rather keep your workspace in version control, and it is a useful record to keep, make your fork private and remove the workspace lines from .gitignore. That is a perfectly good setup; the risk lives only in a public fork.

Our editorial position

Collective genius, or collective slop.

Version velocity is going up. AI will generate plausible operating advice faster than any group of people can check it, and plausible is the problem — wrong material that reads right is worse than no material at all.

We think there are only two defences, and we are committing to both. A human reads every change before it lands. And every claim has to trace back to something that actually happened to somebody — not a synthesis of things that sound true.

In practice that means three rules, and they are written down in the repository rather than left to good intentions:

A named merge gate

Merge authority sits with Golden Section's general partners. Anyone can fork it and anyone can propose a change; only a named person can land one. See GOVERNANCE.md.

Provenance on every contribution

Tell us what you watched happen. Anonymized — no company names, no founder names, no figures precise enough to identify anyone — but real. An entry that came from somewhere is worth ten that came from a model.

No anonymous bulk edits

A hundred generated entries in one pull request will be closed, however good they look. We would rather move slower and stay true.

If you disagree with this position, that is useful too — open an issue and argue with it. Publishing the stance is how we find the people who share it.

How to help

Three ways to contribute, and only one needs Git.

Tell us something

A mistake you have watched happen, and a paragraph about it, is a complete contribution — we will shape it into an entry. You do not need to know the format, and you do not need to open a pull request.

Describe a mistake →

Open an issue

Something wrong, missing, or out of date in an entry. Or a license question — if ShareAlike is what stops you getting this in front of founders, that has its own form.

Open an issue →

Open a pull request

For the technical. Fork it, change it, and send it back. Contributions require signing the CLA, which the bot prompts for on your first pull request.

Read CONTRIBUTING.md →

Or help shepherd it.

We want founders, funds, and advisors curating this alongside us. A maintainer reviews contributions in their domain — the entries and plays they actually know something about — and gets write access to the repository. If that is you, say so and tell us the domain you would own.

Raise your hand
License

CC BY-SA 4.0, in plain words.

Use it, change it, sell things built on it. Two conditions: credit Golden Section, and license your adaptations the same way so they stay available to the founders after you.

If ShareAlike is what stops you getting this in front of founders, ask us. Open an issue. We grant other terms for founder-serving uses, and the answer is usually yes.

Copy-paste attribution

The Golden Section Playbook — Golden Section — CC BY-SA 4.0 github.com/Golden-Section-Tx/playbook

Copied

The content is CC BY-SA 4.0; the scripts and schemas are MIT. The Golden Section name, logo, and marks are not licensed — see NOTICE. Need other terms? Ask for a license exception.

Recently changed

It is a live repository, not an announcement.

The most recent changes to land. Pulled from the repository's commit history each time this site is built.

Add agent skills: apply the corpus to one company, and contribute back (#2)
Added board meeting preparation as a play
Add six plays, six mistakes, and the letter to founders
Spelling: use US "license" throughout (#1)
Remove the direct-push verification file

Full history in CHANGELOG.md.

Questions

The six real objections.

Is it actually free?

Yes. No signup, no email, no download form. Read it on this site, or clone the repository and keep your own copy.

Do I need to use GitHub?

No. The whole corpus is readable here — the mistakes list and every play. The repository is for people who want their own copy, or who want to propose a change.

Do I have to be a Golden Section company?

No. It is the same material we use with our own portfolio, published for anyone building B2B vertical software.

Will you use my contribution commercially?

Yes, and we say so up front — see the contributor terms in the repository. Golden Section holds a broad license to contributions, including for our own products. Your name stays on your work.

Are you collecting my data?

No. There is nothing to sign up for on this page, and nothing is gated behind a form.

If I use the skills, where does my company's data go?

Nowhere. It stays in a workspace folder inside your own copy of the repository, which is excluded from anything sent back to us. A script in the repository reports exactly what a push would carry and fails if anything about your company is tracked, staged, or sitting in your git history. Nothing is ever submitted upstream without showing you the text first.

Who wrote this

Golden Section.

Golden Section is a Houston-based growth equity firm investing $1M–$5M into capital-efficient B2B vertical SaaS companies, with a complementary non-dilutive lending business. The plays and the mistakes came out of more than a decade of operating alongside those companies — over 400 of them.

If reading this made you want to talk to someone about your company rather than fix it alone, that is what we do.

Work with us