Was macht kill-or-build?
Der letzte Schritt. Ein einziges Dokument, auf das ein Gründer reagieren kann, erstellt nur aus dem, was das Paket gefunden hat, und ehrlich darüber, welche Teile real sind.
Lies zuerst ${CLAUDE_SKILL_DIR}/../receipts/rules.md.
Werkzeug in diesem Ordner:
python3 "${CLAUDE_SKILL_DIR}/compile.py" --dir founder
Schritt 1: Prüfen, was vorhanden ist
python3 "${CLAUDE_SKILL_DIR}/compile.py" --dir founder --check
gibt das Urteil und jede Prüfung aus. Die Prüfungen, alle berechnet:
- Jede Einheit verdient Geld vor Fixkosten (
founder/numbers.json). - Jahr 1 erwirtschaftet einen operativen Gewinn.
- Der Break-even liegt innerhalb der Kapazität, sofern eine Kapazität angegeben wurde.
- Genügend simulierte Käufer kaufen (
founder/panel/results.json; Standard-Schwelle 25 %, ändern mit--min-buy-rateund begründen). Ein niedriges Gremium lässt den Plan durchfallen; ein hohes Gremium beweist nichts. - Echte Nachfrage: mindestens ein
MEASURED-Nachweis infounder/evidence/claims.csv(eine Zahlung, eine Anzahlung, ein unterschriebener Pilot, eine Buchung).
Die Urteile:
| Urteil | Bedeutung |
|---|---|
| Incomplete | noch keine Zahlen: /burn-test anbieten |
| Not yet | eine Prüfung schlägt fehl; jeder Fehler wird mit seiner Nummer aufgelistet |
| Unproven | die Rechnung geht auf dem Papier auf, aber kein echter Käufer hat sich verpflichtet |
| Profitable | die Rechnung geht auf und mindestens ein echter Käufer hat sich verpflichtet |
Führe zuerst ledger.py summary aus, damit der Evidenzabschnitt aktuell ist:
python3 "${CLAUDE_SKILL_DIR}/../receipts/ledger.py" summary
Wenn keine Zahlen vorhanden sind, lautet das Urteil Incomplete: Biete an, /burn-test auszuführen. Liste die anderen fehlenden Abschnitte mit dem Skill auf, der sie füllt. Fülle keinen fehlenden Abschnitt selbst durch Schätzungen.
Schritt 2: Die Zusammenfassung
Schreibe founder/summary.md, eine halbe Seite, klare Worte, beginnend mit Die harte Wahrheit: der wahrscheinlichste Grund, warum dies scheitert.
- Was das Geschäft ist und für wen es ist, in zwei Sätzen.
- Das Urteil und die drei Zahlen dahinter (Marge, Break-even, Jahr 1).
- Was real ist: die Anzahl der
MEASURED- undTHEY SAID IT-Nachweise und worum es sich handelt. Dann, was noch eine Annahme ist. - Worauf sich das simulierte Gremium und das Board geeinigt haben und wo sie unterschiedlicher Meinung waren, gekennzeichnet als simuliert.
- Das größte Risiko und was dagegen unternommen wird.
- Was der Gründer zum Start braucht (Geld vom CFO, der erste Test vom Launch).
- Die eine Sache, die diese Woche zu tun ist.
Wenn das Urteil Not yet lautet, beginnt die Zusammenfassung mit dem, was sich ändern muss, und welcher Skill es ändert. Wenn es Unproven lautet, beginnt sie mit dem einen realen Test, der es diesen Monat beweisen oder widerlegen würde. Schwäche niemals eine fehlschlagende Prüfung ab und schreibe niemals einen Unproven-Plan so, als wäre er validiert.
Schritt 3: Kompilieren
python3 "${CLAUDE_SKILL_DIR}/compile.py" --dir founder
schreibt founder/business-plan.md: Titel, das Urteil und seine Prüfungen, die Tabelle mit den wichtigen Zahlen, die Idee, dann jeden Abschnitt, den das Paket erstellt hat (Zusammenfassung, Board, Wettbewerb, Gremium, Preisgestaltung, Angebot, Zahlen, Marketing, Marke, Betrieb, Launch), und was noch nicht erledigt ist.
Schritt 4: Die einseitige Kurzversion
Schreibe founder/one-pager.md für den Gründer und enge Partner: das Problem, der Kunde, das Angebot und der Preis, die Zahlentabelle, die echten Nachweise (und das Gremium, gekennzeichnet als simuliert), wofür das Geld gedacht ist und die Bitte. Dieselben Zahlen wie im Plan, Wort für Wort.
Für Außenstehende (einen Kunden, einen Geldgeber, einen Kreditgeber) sende weder den Plan noch diese Seite: Führe /handshake aus, das nur aus Nachweisen erstellt, die dieses Publikum sehen darf, und überprüft das Ergebnis.
Regeln
- Das Urteil stammt von
compile.py. Schreibe niemals „Profitable“ von Hand, runde niemals eine fehlschlagende Zahl zu einer bestehenden auf und bezeichne niemals „Unproven“ als „fast geschafft“. - Sage einmal deutlich: Das Gremium und das Board sind simuliert und die Zahlen sind Prognosen; nur echte Kunden und echte Angebote bestätigen sie. Keine Finanz-, Rechts- oder Steuerberatung.
- Wenn der Benutzer ein PDF oder eine Präsentation möchte, biete an, den Plan zu exportieren, behalte aber das Markdown als Quelle der Wahrheit.
Ausgabe
founder/summary.md, founder/business-plan.md, founder/one-pager.md. Gib dem Benutzer dann das Urteil in einer Zeile, die harte Wahrheit und die eine reale Sache, die diese Woche zu tun ist. Als nächstes: /handshake für den Empfänger, der ja sagen muss.