CommunityCodierung & Entwicklunggithub.com

handshake

Verwandelt den Gründerordner in das, was eine reale Person dazu bringt, dem nächsten Schritt zuzustimmen: ein einseitiges Pilotangebot für einen Kunden, einen NSF-Projektentwurf oder eine Förderantwort, ein einseitiges Investoren- oder Kreditgeberdokument, ein Business Case für einen Vorgesetzten oder eine Einladung für die Nutzer. Schreibt zuerst die Ein-Satz-, Drei-Satz- und Drei-Minuten-Versionen. Baut nur auf Behauptungen aus dem Evidenz-Ledger auf, die das Publikum sehen darf, niemals auf simulierten Käufern, und prüft den fertigen Pitch mit dem Ledger, bevor er rausgeht. Verwenden Sie es, wenn der Benutzer sagt: „Pitch dies“, „schreibe ein Pilotangebot“, „Einseiter“, „Förderantrag“, „NSF-Antrag“, „Deck für“, „E-Mail an diesen Kunden“, „Business Case“ oder „was soll ich ihnen schicken“.

Was ist handshake?

Dieses Skill, genannt „handshake“, erstellt aus den tatsächlich vorhandenen Daten eines Gründers einen zielgerichteten Pitch für eine einzelne Person, der auf eine konkrete Zustimmung abzielt – sei es ein Kunde, ein Geldgeber, ein Investor oder ein interner Entscheider. Es ist für KI-Agenten wie Claude Code, Cursor oder Codex konzipiert und stellt sicher, dass keine erfundenen Zahlen oder simulierten Käufer verwendet werden: Der Pitch basiert ausschließlich auf Behauptungen aus dem Evidence Ledger, die das jeweilige Publikum einsehen darf. Der Workflow umfasst vier Schritte: Identifikation von Empfänger und gewünschtem „Ja“, Prüfung der unterstützbaren Behauptungen via Ledger, Erstellung des Pitch (inklusive Ein-Satz-, Drei-Satz- und Drei-Minuten-Version) und abschließende Validierung durch einen Scan, der nicht autorisierte Behauptungen oder übertriebene Formulierungen ablehnt. Das Skill ist besonders nützlich für Gründer, die einen überzeugenden, faktenbasierten und versendbaren Entwurf benötigen, ohne sich auf unsichere Annahmen zu stützen.

Funktioniert mit✓Claude Code~Codex CLI~Cursor
npx skills add https://github.com/peaknr35/shark-Tank-proof/tree/main/skills/handshake

Installed? Explore more Codierung & Entwicklung skills: steipete/bluebubbles, steipete/eightctl, steipete/blucli · View all 6 →

In Ihrer bevorzugten KI fragen

Öffnet einen neuen Chat, in dem dieser Agent-Skill bereits geladen ist.

Dokumentation

Was macht handshake?

Ein Plan ist für den Gründer. Ein Pitch ist für eine Person und ein Ja. Dieses Skill schreibt ihn aus dem, was tatsächlich bekannt ist, damit der Gründer ihn versenden kann, ohne eine Zahl verteidigen zu müssen, die er nicht belegen kann.

Was der Benutzer nach /handshake eingegeben hat: $ARGUMENTS

Lies zuerst ${CLAUDE_SKILL_DIR}/../receipts/rules.md. Das Ledger-Tool:

python3 "${CLAUDE_SKILL_DIR}/../receipts/ledger.py" <gate | scan | summary>

Im Folgenden bedeutet LEDGER genau das.

Schritt 1: Wer und welches Ja

Frage, für wen es ist und welches Ja der Gründer möchte, falls nicht angegeben. Benenne den Empfänger: einen Kunden, einen Geldgeber, einen Investor, einen Kreditgeber, jemanden innerhalb seines Unternehmens oder die Personen, die es nutzen werden. Lies ${CLAUDE_SKILL_DIR}/receivers.md, um zu erfahren, was dieser Empfänger sehen muss.

Falls ein Dokument von ihnen vorliegt (eine Ausschreibung, ein Förderaufruf, eine E-Mail, eine Stellenausschreibung), lies es zuerst, extrahiere genau das, was sie verlangen, und speichere es als founder/opportunities/<name>.md (Format: ${CLAUDE_SKILL_DIR}/../first-dollar/opportunity.md).

Reduziere die Bitte auf das kleinste echte Ja (Regel 7). Wenn der Gründer einen Fremden um eine große Vorabvergütung bitten möchte, sage deutlich, dass ein zeitlich begrenzter Pilot auf Basis der eigenen Zahlen des Empfängers eher ein Ja erhält, und biete beide Optionen an.

Schritt 2: Was der Ordner unterstützen kann

LEDGER check
LEDGER gate --audience <public | anonymised | permission>

Wähle das Publikum danach aus, wie der Pitch versendet wird: public für alles, was weitergeleitet werden könnte, anonymised für einen privaten Versand, permission nur, wenn jede Person einer ASK FIRST-Behauptung in founder/evidence/people.md zugestimmt hat.

Baue nur aus dem, was gate ausgibt. Wenn der Empfänger etwas benötigt, das der Ordner nicht unterstützen kann, schreibe nicht drum herum: Liste es unter Lücken am Ende der Ausgabe, zusammen mit der Möglichkeit, es zu beschaffen (/receipts Job 4 geht tiefer). Fülle eine Lücke niemals mit einer Schätzung, einem Panel-Zitat oder einer Vorstandsmeinung.

Wenn nichts zur Nachfrage GEMESSEN ist, sagt der Pitch dies ehrlich durch seine Formulierung: „Wir suchen drei Firmen für einen Piloten“, nicht „Firmen stehen Schlange“.

Schritt 3: Schreiben

  1. Der eine Satz, die drei Sätze, die Drei-Minuten-Gliederung.
  2. Das Format des Empfängers aus receivers.md. Antworte in den eigenen Überschriften des Empfängers, wenn er einen Anruf oder eine Ausschreibung gegeben hat. Respektiere deren Grenzen (zähle Zeichen für die NSF-Abschnitte und nenne die Anzahl).
  3. Zitiere jede Tatsache mit ihrer Behauptungs-ID, wie [c04], im Arbeitsentwurf. Schreibe GEPLANTE Behauptungen als Ziele („wir erwarten“, „der Pilot wird testen“), niemals als Ergebnisse.
  4. Ein kurzer Abschnitt Was schiefgehen könnte in einfachen Worten. Empfänger vertrauen ihm.
  5. Lücken: Was dieser Pitch bräuchte, um stärker zu sein, und der günstigste Weg, dies zu erreichen.

Speichere es als founder/outputs/<YYYY-MM-DD>-<empfänger>.md.

Schritt 4: Prüfe es, bevor es rausgeht

LEDGER scan founder/outputs/<datei>.md --audience <das gleiche Publikum>

scan weist jede zitierte Behauptung zurück, die das Publikum nicht sehen darf (eine SIMULIERTE oder PRIVATE, ein ASK FIRST ohne Erlaubnis) und markiert Beweiswörter („validiert“, „bewährt“, „starke Nachfrage“), wenn kein echter Käufer gezahlt oder unterschrieben hat. Behebe jedes Problem, das es ausgibt, und führe es erneut aus, bis es sauber ist. Erstelle dann eine versandfertige Kopie ohne die [c..]-IDs, wenn der Gründer eine möchte, und behalte den zitierten Entwurf.

Regeln

  • Kein simulierte Käufer, Vorstandsmitglied oder Modellausgabe wird jemals zitiert, gezählt oder als Kunde, Benutzer, Berater oder Marktforschung von echten Personen beschrieben.
  • Keine erfundenen Berater, Partner, Logos, Kundennamen oder Zahlen. „Berater im Rechnungswesen“ benötigt einen echten Berater in people.md, der zugestimmt hat, aufgeführt zu werden.
  • Keine Marktgröße ohne Quelle; schreibe sie andernfalls als Schätzung mit der Methode.
  • Der Versand ist Aufgabe des Gründers. Verfasse die E-Mail oder Nachricht; sende sie nicht ab.

Ausgabe

founder/outputs/<datum>-<empfänger>.md (plus eine bereinigte Kopie, wenn gewünscht), und founder/opportunities/<name>.md, falls es einen Anruf oder eine Ausschreibung gab. Ende mit dem einen Satz, den Lücken und der nächsten Aktion: wem diese Woche senden, und was mit /receipts protokollieren, wenn sie antworten.

Individual skills in this repo

This repo contains 5 individual skills — each has its own dedicated page.

burn-test

Your CFO. Builds the unit economics of a business before money is spent: what one unit earns after its direct costs, the real profit margin at the planned volume, the break-even point in units a day, year 1 month by month, the cash needed before it pays for itself, how long the startup spend takes to earn back, and what happens if the price drops, sales come in low or costs rise. Every number traces to an input the user can check. Use when the user says "find the profit margins", "do the numbers", "is this profitable", "break-even", "unit economics", "how much do I need to start", or "run the CFO".

dealbreaker

Builds an offer too good to refuse. Lists every problem the buyer hits on the way to the result they want, turns each into a solution, trims to what is cheap to deliver and valuable to the buyer, and stacks it with honest bonuses, a guarantee the CFO can afford, real urgency and a clear name. Scores it on the value equation (outcome, likelihood, time, effort) and re-tests it on a quick buyer panel. Use when the user says "make my offer better", "why won't people buy", "what should I include", "guarantee", "bonuses", "grand slam offer", or after the panel shows people passing.

kill-or-build

Your business planner. Compiles everything the other Shark Tank Proof skills wrote (the board's verdict, the competitors, the buyer panel, pricing, the offer, the CFO's numbers, marketing, brand, operations, the launch plan and the evidence ledger) into one business plan with a verdict at the top that is computed, never written by hand: Profitable (the numbers pass and a real buyer has paid, signed or booked), Unproven (works on paper, no real buyer yet), Not yet (with the failing numbers) or Incomplete. A simulated panel can fail a plan but never pass one. Adds an executive summary and a one-page version. Use when the user says "write my business plan", "put it all together", "is it profitable", "give me the plan", or at the end of the Shark Tank Proof pack.

shark-board

Your board of directors, built to disagree with you. Puts a business idea in front of a four-member board, each a sub-agent reading the idea through one published framework: the Offers lens (from Alex Hormozi's $100M Offers), the Monopoly lens (from Peter Thiel's Zero to One), the Product lens (from Walter Isaacson's biography of Steve Jobs) and the Evidence lens (from Rob Fitzpatrick's The Mom Test), which scores only what real people have done. Each member scores the idea, names what would kill it and the cheapest test that would prove it, and votes fund, fund with conditions, or pass. Use when the user says "test my business idea", "would this work", "pressure-test this", "what would a board say", "is this a good business", or starts the Shark Tank Proof pack on a new idea.

truth-serum

The consumer panel. Spins up a swarm of buyer sub-agents (default 100, --quick for 20) trained on the user's target customer, each with a different income, age, buying behaviour and objection, shows every one the same pitch, and runs the business through 100 buyer scenarios to see who buys, who doesn't, and why. Tallies the answers into buy rates by segment, the reasons people pass in their own words, what would flip a no, and price answers for litmus. Every result is labelled SIMULATED: it finds objections and the questions to ask real buyers, and never counts as demand. Use when the user says "would people buy this", "test it on customers", "run the consumer panel", "simulate buyers", "who is my customer", or "validate demand".

Verwandte Skills