CommunityDéveloppement et programmationgithub.com

kill-or-build

Votre planificateur d'entreprise. Il compile tout ce que les autres compétences de Shark Tank Proof ont écrit (le verdict du conseil, les concurrents, le panel d'acheteurs, la tarification, l'offre, les chiffres du CFO, le marketing, la marque, les opérations, le plan de lancement et le registre de preuves) en un seul plan d'affaires avec un verdict calculé automatiquement en haut : Rentable (les chiffres passent et un vrai acheteur a payé, signé ou réservé), Non prouvé (fonctionne sur le papier, pas encore de vrai acheteur), Pas encore (avec les chiffres défaillants) ou Incomplet. Un panel simulé peut faire échouer un plan mais jamais le faire passer. Ajoute un résumé exécutif et une version une page. À utiliser lorsque l'utilisateur dit « écris mon business plan », « rassemble tout », « est-ce rentable », « donne-moi le plan », ou à la fin du pack Shark Tank Proof.

Qu'est-ce que kill-or-build ?

`kill-or-build` est la compétence finale du pack Shark Tank Proof pour Claude Code et autres agents IA. Elle transforme toutes les données collectées par les compétences précédentes (verdict du conseil, analyse concurrentielle, panel d'acheteurs, tarification, offre, chiffres du CFO, marketing, marque, opérations, plan de lancement et preuves) en un plan d'affaires unique et cohérent. Son point fort est un verdict automatique, calculé via Python, qui classe le projet comme Rentable, Non prouvé, Pas encore ou Incomplet. Les vérifications incluent la rentabilité unitaire, le profit d'exploitation, le seuil de rentabilité, un panel simulé d'acheteurs et la demande réelle (paiement, dépôt, signature). La compétence génère trois documents : un résumé exécutif honnête qui commence par la « dure vérité », le plan complet avec toutes les sections, et une version une page pour les partenaires proches. Elle insiste sur la transparence : les verdicts favorables ne sont jamais écrits à la main, les chiffres défaillants ne sont pas arrondis, et les simulations sont clairement étiquetées. Pour les parties externes (clients, investisseurs), il recommande d'utiliser `/handshake` à la place.

Compatible avec✓Claude Code~Codex CLI~Cursor
npx skills add https://github.com/peaknr35/shark-Tank-proof/tree/main/skills/kill-or-build

Installed? Explore more Développement et programmation skills: steipete/bluebubbles, steipete/eightctl, steipete/blucli · View all 6 →

Voir l'original→Voir toutes les compétences

Demander à votre IA préférée

Ouvre une nouvelle conversation avec cette compétence d'agent déjà préchargée.

OpenAIChatGPTClaudeClaudeGeminiGeminiGrokGrokPerplexityPerplexityDeepSeekDeepSeek

Documentation

Que fait kill-or-build ?

La dernière étape. Un document sur lequel un fondateur peut agir, construit uniquement à partir de ce que le pack a trouvé, et honnête sur les parties qui sont réelles.

Lire d'abord ${CLAUDE_SKILL_DIR}/../receipts/rules.md.

Outil dans ce dossier :

python3 "${CLAUDE_SKILL_DIR}/compile.py" --dir founder

Étape 1 : voir ce qui existe

python3 "${CLAUDE_SKILL_DIR}/compile.py" --dir founder --check

affiche le verdict et chaque vérification. Les vérifications, toutes calculées :

  1. Chaque unité génère de l'argent avant les coûts fixes (founder/numbers.json).
  2. L'année 1 dégage un bénéfice d'exploitation.
  3. Le seuil de rentabilité tient dans la capacité, si une capacité a été donnée.
  4. Suffisamment d'acheteurs simulés achètent (founder/panel/results.json ; seuil par défaut 25 %, modifiable avec --min-buy-rate en expliquant pourquoi). Un panel faible fait échouer le plan ; un panel élevé ne prouve rien.
  5. Demande réelle : au moins une revendication MEASURED dans founder/evidence/claims.csv (un paiement, un acompte, un pilote signé, une réservation).

Les verdicts :

verdictsignification
Incompletpas encore de chiffres : proposer /burn-test
Pas encoreune vérification échoue ; chaque échec est listé avec son numéro
Non prouvéles maths fonctionnent sur le papier, mais aucun vrai acheteur ne s'est engagé
Rentableles maths fonctionnent et au moins un vrai acheteur s'est engagé

Exécuter d'abord ledger.py summary pour que la section des preuves soit à jour :

python3 "${CLAUDE_SKILL_DIR}/../receipts/ledger.py" summary

S'il n'y a pas de chiffres, le verdict est Incomplet : proposer d'exécuter /burn-test. Lister les autres sections manquantes avec la compétence qui remplit chacune. Ne pas remplir une section manquante à partir de suppositions.

Étape 2 : le résumé

Écrire founder/summary.md, une demi-page, mots simples, en commençant par La dure vérité : la raison la plus probable pour laquelle cela échoue.

  • Ce qu'est l'entreprise et à qui elle s'adresse, en deux phrases.
  • Le verdict et les trois chiffres derrière (marge, seuil de rentabilité, année 1).
  • Ce qui est réel : le nombre de revendications MEASURED et THEY SAID IT, et ce qu'elles sont. Puis ce qui est encore une supposition.
  • Ce sur quoi le panel simulé et le conseil se sont accordés, et où ils ont divergé, étiqueté comme simulé.
  • Le plus grand risque et ce qui sera fait pour y remédier.
  • Ce dont le fondateur a besoin pour démarrer (argent du CFO, premier test du lancement).
  • La seule chose à faire cette semaine.

Si le verdict est Pas encore, le résumé commence par ce qui doit changer et quelle compétence le change. S'il est Non prouvé, il commence par le seul test réel qui le prouverait ou le tuerait ce mois-ci. Ne jamais adoucir une vérification défaillante, et ne jamais écrire un plan Non prouvé comme s'il était validé.

Étape 3 : compiler

python3 "${CLAUDE_SKILL_DIR}/compile.py" --dir founder

écrit founder/business-plan.md : titre, le verdict et ses vérifications, le tableau des chiffres clés, l'idée, puis chaque section produite par le pack (résumé, conseil, concurrence, panel, tarification, offre, chiffres, marketing, marque, opérations, lancement), et ce qui n'est pas encore fait.

Étape 4 : la page unique

Écrire founder/one-pager.md pour le fondateur et les partenaires proches : le problème, le client, l'offre et le prix, le tableau des chiffres, les preuves réelles (et le panel, étiqueté simulé), à quoi sert l'argent, et la demande. Mêmes chiffres que le plan, mot pour mot.

Pour toute personne extérieure (un client, un financeur, un prêteur), ne pas envoyer le plan ni cette page : exécuter /handshake, qui construit uniquement à partir des revendications que ce public peut voir et vérifie le résultat.

Règles

  • Le verdict provient de compile.py. Ne jamais écrire Rentable à la main, ne jamais arrondir un chiffre défaillant pour le faire passer, et ne jamais qualifier Non prouvé de « presque là ».
  • Dire une fois, clairement : le panel et le conseil sont simulés et les chiffres sont des projections ; seuls les vrais clients et les vraies citations les confirment. Ce n'est pas un conseil financier, juridique ou fiscal.
  • Si l'utilisateur veut un PDF ou une présentation, proposer d'exporter le plan, mais garder le markdown comme source de vérité.

Résultat

founder/summary.md, founder/business-plan.md, founder/one-pager.md. Ensuite donner à l'utilisateur le verdict en une ligne, la dure vérité, et la seule chose réelle à faire cette semaine. Suite : /handshake pour le destinataire qui doit dire oui.

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.

handshake

Turns the founder folder into the thing that gets one real person to say yes to the next step: a one-page pilot offer for a customer, an NSF Project Pitch or grant answer for a funder, an investor or lender one-pager, a business case for a boss, or an invite for the people who will use it. Always writes the one-sentence, three-sentence and three-minute versions first. Builds only from claims in the evidence ledger that the audience may see, never from simulated buyers, and checks the finished pitch with the ledger before it goes out. Use when the user says "pitch this", "write a pilot offer", "one-pager", "grant pitch", "NSF pitch", "deck for", "email this customer", "business case", or "what do I send them".

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".

Skills associés

steipete/bluebubbles

Send and manage iMessages via BlueBubbles, including attachments, tapbacks, edits, replies, and groups.

community

steipete/eightctl

Control Eight Sleep pods (status, temperature, alarms, schedules).

community

steipete/blucli

BluOS CLI (blu) for discovery, playback, grouping, and volume.

community

steipete/bear-notes

Create, search, and manage Bear notes via grizzly CLI.

community

steipete/camsnap

Capture frames or clips from RTSP/ONVIF cameras.

community

steipete/gifgrep

Search GIF providers with CLI/TUI, download results, and extract stills/sheets.

community
← More Développement et programmation skills