Business Plan Builder

Business plan builder

Somebody hands you an idea. Your job is to find out whether it holds up, and to leave behind a set of documents that show your work — so the reader can disagree with a specific line rather than with a vibe.

Two things make this skill different from writing a business plan:

1. The pipeline is fixed and it has a gate. Eight passes, in order. Nothing gets specced, architected, or estimated until the decision memo says it's worth building. A no-go is a complete, successful run.
2. The output is a repo, not a reply. A folder of linked markdown in the repo-docs-builder house style, with an index at every level and every claim traceable back to a captured source.

WHEN TO USE THIS SKILL

• Someone gives you an idea — one sentence or twenty pages — and wants to know if it's real.
• "Write up a business plan for X" / "turn this into documentation."
• "Should I build this?" where the honest answer needs sizing, competitors, and a model behind it.
• Pressure-testing an idea the user is already attached to. This is the case the skill is built for.
• An existing plan needs the missing half — it has a market story but no unit economics, or a build estimate with no decision behind it.

Not for: a quick opinion (just answer), a single competitor lookup (do the teardown pass alone), or writing marketing copy for an idea already decided on.

0. THE ONE RULE

Every number is traceable to a source, or it is labeled an assumption.

An analysis that quietly invents a market size is worse than no analysis — it launders a guess into a decision, and downstream nobody can tell. So:

• Never state a figure you did not get from a source or compute from one. No "roughly $4B" from memory.
• Tag every claim — [fact] (sourced, with a URL and retrieval date), [est] (derived — show the math), [assum] (a judgment call — say whose and why). Tags live in the document, inline, forever.
• Date-stamp everything. Get the real date from the environment (Get-Date -Format yyyy-MM-dd on Windows), never from memory — a model's sense of "today" drifts to its training cutoff and quietly falsifies every retrieval date in the repo.
• A conclusion inherits the weakest tag it depends on. Three [assum]s do not sum to a [fact].
• A range beats false precision. "$40–70M SAM, driven by [the penetration assumption]" is honest. "$52.3M" out of a three-step guess chain is not.
• Compute in Python, never in your head. Multi-step arithmetic presented as a figure is how a rounding error becomes a strategy.

Read references/evidence-rules.md before the first pass. It holds the tag definitions, the A–D source grading scale, the list of things that are genuinely unknowable about a private company, and the ethics line on research.

[!IMPORTANT] Be the skeptic, not the cheerleader. Argue the strongest case against the thing the user appears to want. If the business case only works under one heroic assumption, that assumption is the finding — put it in the recommendation, not in a footnote.

1. INTAKE

Before any research, pin down four things and write them into the root README as you go.

Then set the depth. Full run is the default — all eight passes. Drop to a screen (passes 1–4 only, gate closes, no build layer) when the user asks for a quick read or when the idea is early enough that a build estimate would be theater. Say which mode you're in, out loud, in the root README.

2. THE EIGHT PASSES

Run them in this order. Each one writes files and cites the pass before it. The full method for each — what it does, how it's commonly faked, and what it must output — is in references/analysis-passes.md. Read that file before you start; the summaries below are the map, not the territory.

Strategy half — is this worth building?

The gate. Pass 4 ends in a recommendation. If it is anything other than build, stop. Write the memo, write the root README, and hand it over. Specifying a build the memo didn't greenlight is the same failure as inventing a market size, except it gets built.

Build half — only past a greenlight.

Passes 5–8 inherit every rule from 0–4. A schedule is a P&L measured in weeks and it fabricates the same way.

Research reality check

Pass 1 and pass 2 need real sources. Use web search and fetch, capture one file per source into research/ with the URL and retrieval date at the top, and only then reason over them. research/ is append-only — capture before you conclude, not after.

If you have no web access on this run, say so in the root README, in the first paragraph, mark every unsourced figure [assum], and treat the whole strategy half as a structured hypothesis rather than an analysis. That is a usable deliverable. Pretending the numbers are sourced is not.

3. THE OUTPUT REPO

The deliverable is a folder built to the repo-docs-builder house style: a clean top level, a README index in every content folder, links that go down to children and back up to parents, and prose that reads like a person wrote it.

[!NOTE] If the repo-docs-builder skill is installed, load it and follow it for the header blocks, catalog tables, footers, and the humanizer pass — it is the source of that style. If it isn't available, references/output-templates.md carries the condensed version of everything you need, so this skill still works standalone.

Layout

This is a doc library, so the top-level folders are the content categories. No src/, no docs/ hub — the pipeline directories index themselves.

<idea-slug>/
├── README.md            ← Tier 1. Front door: the verdict, the pipeline table, links down to every folder.
├── research/
│   ├── README.md        ← Tier 2 index — the source ledger table (source · grade · retrieved).
│   └── <source>.md      ← one file per source. URL + retrieval date + grade at the top.
├── analysis/
│   ├── README.md        ← Tier 2 index
│   ├── market-scan.md · landscape.md · teardown-<competitor>.md · business-case.md
├── models/
│   ├── README.md        ← Tier 2 index — includes the executed output, pasted
│   └── roi.py · estimate.py
├── decisions/
│   ├── README.md        ← Tier 2 index — one row per memo, with its status
│   └── <YYYY-MM-DD>-<slug>.md
└── build/               ← only exists if the memo said build
    ├── README.md        ← Tier 2 index
    └── spec.md · adr-001-<x>.md · build-plan.md · estimate.md

Three tiers is the ceiling here. Don't create a folder README whose only content is a link to one file — link that file straight from the root.

The rules that make it navigable

• Root README opens with the verdict. Recommendation first, always. Nobody should have to click into decisions/ to learn what you concluded.
• Every folder README links one level down in a catalog table with the link bold in the leftmost column: [**market-scan.md**](market-scan.md) | Bottom-up SAM of $41–68M, driven by the seat-price assumption. The description cell carries information — never a restatement of the filename.
• Every folder README links back up in a centered footer nav row. A down-only index is a trap.
• Links are relative so they resolve in GitHub and in Obsidian both.
• Headers follow the house style — the root gets the hero block (an # H1 fallback where there's no logo asset, never an invented image path), every folder README gets the centered emoji-<h1> + tagline + a badge row of one to three.
• Prose gets the humanizer pass. No comprehensive, seamless, robust, leverage, delve, no -ing tails bolted on to fake depth, no serves as where is works. The emoji headers, bold leftmost links, and badges are navigation and stay. Details in references/output-templates.md §2.

Badges worth setting

The root header badge row is where a reader gets the state of the analysis in one glance. Set these three honestly:

4. WORKFLOW

1. Intake (§1). Restate the idea, name the decision, split given-vs-supplied, agree the destination. Get the real date.
2. Scaffold. Create the folder and the empty pipeline directories. Write a stub root README with the intake block in it, so there's a spine to hang findings on.
3. Read the references. evidence-rules.md first, then the passes you're about to run in analysis-passes.md.
4. Pass 1–2 — research and capture. Search, fetch, and write one research/ file per source before reasoning over it. Then write the analysis files that cite them.
5. Pass 3 — model it. Write the Python file, run it, and paste the executed output into models/README.md. Sweep every driver across its plausible range and sort the swings — the widest bar is the finding. A model you didn't run is a text file.
6. Pass 4 — the memo. Recommendation up top. Steelman the option you rejected until its advocate would sign off on your version of it. Name the single assumption the call rests on. Write the falsifiers with an observable, a threshold, and a date.
7. Check the gate. Not build? Finish the root README and stop. Say plainly in the handoff that the build layer was not written and why.
8. Pass 5–8 if greenlit. Spec, then ADRs for the one-way doors only, then the estimate model (run it), then the sliced plan with a "when we'd stop" section.
9. Wire and audit (§5). Every index links down and up; every claim carries a tag; every figure cites a file.
10. Hand over. A short inline summary: the verdict, the key assumption, the number that would flip it, and the path to the repo. Not a re-narration of the documents.

Write each file's prose through the humanizer as you finish that file — not batched at the end, where it always degrades into a rubber stamp.

5. SELF-AUDIT BEFORE HANDOVER

Run this. Every failure here is one somebody else would have found.

1. No untagged figure anywhere. Grep for digits in analysis/ and decisions/ and check each one carries [fact], [est], or [assum].
2. Every [fact] has a URL and a retrieval date, and that date is real.
3. Every figure in the memo traces to a file. If it can't be walked back to models/ or analysis/, it doesn't belong in the memo.
4. research/ actually has files in it. An analysis/ folder citing an empty research/ folder is the signature failure of this whole skill.
5. The model was executed and its real output is pasted into models/README.md.
6. The memo names one key assumption, singular, and the sensitivity sweep supports the choice.
7. "What would change my mind" exists and each entry has an observable, a threshold, and a date. A memo without it is a pitch.
8. The unknowns section exists in the competitive work and says what is not determinable, rather than estimating it anyway.
9. The gate held. No build/ folder unless the memo says build.
10. Navigability — every folder has a README, every README links down to its children and up to its parent, no orphan files, all links relative.
11. Voice — ask yourself "what makes this obviously AI generated?", answer honestly, then fix it. There is almost always something.

6. ANTI-PATTERNS

Analysis

• Top-down sizing presented as the answer. "$40B market, we need 1%" is the absence of an argument. Name the first twenty customers and who they pay today.
• Inventing a private company's revenue, churn, or margins. Headcount × a revenue-per-employee multiple produces a number with error bars so wide it carries no information — and it stops the reader from asking. Write "not determinable from public sources" and route the problem.
• Fabricated customer quotes. The single worst artifact this skill can produce; downstream it is indistinguishable from a real one.
• A framework run for its own sake. Before writing a Five Forces or a SWOT section, state in one sentence what result would flip the recommendation. If nothing would, delete the section.
• A single-number model output. The sensitivity sweep is the deliverable; the base case is the excuse to run it.
• Averaging away a conflict between sources. Show the conflict and say which you'd bet on.

Process

• Writing the build layer without a greenlight, or writing a greenlight because the user clearly wants one.
• Reasoning first, capturing sources after — that's how a remembered figure gets a citation glued on.
• Reporting arithmetic you did in your head.
• Retro-editing a memo to look smarter than it was. The value of decisions/ in two years is entirely in the memos that were wrong and said in advance what would prove it.
• Burying the recommendation. The reader should never have to reach the bottom for the call.

Output

• A flat pile of markdown files with no index. Every folder gets a README that links down and up.
• Table cells that restate the filename — | **spec.md** | The spec. |.
• A logo hero on a folder README, or an invented image path in the root header.
• Promotional prose in a business document. A comprehensive, robust platform leveraging cutting-edge… — cut it and say what the thing does.
• A "Challenges and Future Prospects" closer. If there's real work left, it goes in the memo's next-step section with an owner and a date.

[!NOTE] The eight passes are adapted from a set of standard business-analysis disciplines — market sizing, competitive intelligence, ROI modeling, decision memos, product spec, technical architecture, build estimation, and shipping discipline — condensed and re-scoped here for one-shot use on a single idea rather than run as separate tools.