dealbreaker

Construit une offre irrésistible. Transforme chaque objection d'achat en solution, empile des bonus honnêtes et une garantie réaliste, puis teste l'offre sur un panel d'acheteurs.

Qu'est-ce que dealbreaker ?

Ce skill (dealbreaker) vous aide à créer une offre irrésistible en utilisant le cadre des Offres issu de *$100M Offers* d'Alex Hormozi. Il transforme chaque obstacle rencontré par l'acheteur (doutes, coût, effort, risques) en une solution concrète, puis filtre ces solutions pour ne garder que celles qui sont peu coûteuses à livrer et très valorisées par l'acheteur. Vous obtenez ainsi une offre empilée avec un cœur, des bonus, une garantie réaliste (chiffrée avec l'outil du CFO), une urgence authentique et un nom clair. L'offre est notée selon l'équation de valeur (résultat rêvé, probabilité perçue, délai, effort) avant d'être retestée via `/truth-serum --quick` sur un panel d'acheteurs simulés. Utilisez-le lorsque l'utilisateur dit « améliore mon offre », « pourquoi personne n'achète », « que dois-je inclure », « garantie », « bonus », « offre grand chelem », ou après que le panel a montré que les gens passent outre. Il fonctionne avec les fichiers du dossier `founder/` (pitch, panel, chiffres, board) et produit `founder/offer.md` et une version mise à jour de `founder/pitch.md`.

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

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

Demander à votre IA préférée

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

Documentation

Que fait dealbreaker ?

La plupart des entreprises vendent un produit. Les bonnes vendent une offre : le produit plus tout ce qui rend l'achat facile à accepter. Ce skill construit cette offre, en utilisant la perspective Offres dans ${CLAUDE_SKILL_DIR}/../shark-board/lenses.md comme méthode (un résumé du cadre du livre $100M Offers d'Alex Hormozi ; ne le présentez jamais comme ses mots).

Lisez d'abord ${CLAUDE_SKILL_DIR}/../receipts/rules.md. Une offre est un ensemble de promesses. Chaque promesse est PLANNED jusqu'à ce qu'elle ait été livrée et mesurée, et l'offre doit le dire de cette façon.

Étape 1 : lire ce qui est déjà connu

  • founder/idea.md et founder/pitch.md : ce qui est vendu aujourd'hui.
  • founder/panel/results.md : pourquoi les acheteurs passent outre, dans leurs mots. C'est la matière première : chaque objection majeure doit être répondue par quelque chose dans l'offre.
  • founder/numbers.json : combien chaque extra coûte, pour que l'empilement reste rentable.
  • founder/board.md : les conditions du board.

Étape 1b : le premier oui

Avant l'offre complète, concevez la première : le plus petit engagement réel qu'un étranger prendrait sans références. Pour un magasin, un prix de lancement ou une carte de membre fondateur. Pour une entreprise vendue à d'autres entreprises, un pilote limité dans le temps sur leurs propres chiffres (deux à huit semaines, un workflow, une ligne de succès écrite à l'avance, une fin claire : intégration dans le prix standard ou retrait sans rien devoir). Utilisez la forme de l'offre pilote dans ${CLAUDE_SKILL_DIR}/../handshake/receivers.md. L'offre complète ci-dessous est celle dans laquelle le pilote s'intègre.

Étape 2 : la liste des problèmes

Écrivez chaque obstacle entre l'acheteur et le résultat qu'il souhaite, dans les mots de l'acheteur : avant l'achat (doute, prix, effort de changement), pendant (attente, apprentissage, inconvénient), après (est-ce que ça dure, que se passe-t-il en cas d'échec). Visez 15 à 30. Tirez d'abord des objections du panel et des plaintes des concurrents.

Étape 3 : solutions, filtrées et empilées

Transformez chaque problème en solution (une fonctionnalité, un service, une garantie, un format). Notez chaque solution sur la valeur pour l'acheteur (1 à 5) et le coût de livraison (1 à 5, à partir des chiffres du CFO). Gardez ce qui a une valeur élevée et un coût faible. Empilez ce qui reste en :

  • Le cœur : la chose elle-même, décrite par le résultat, pas par les ingrédients.
  • Les bonus : deux ou trois, chacun tuant une objection spécifique.
  • La garantie : ce qui se passe si ça ne livre pas. Modélisez son coût à un taux de réclamation réaliste avec l'outil du CFO avant de la promettre.
  • L'urgence et la rareté : seulement si elles sont vraies (une semaine de lancement, un premier lot limité). Jamais de compte à rebours ou de "il n'en reste que 3" factices.
  • Le nom : un nom clair et spécifique pour l'offre, pas pour l'entreprise.

Étape 4 : noter

Sur l'équation de valeur, avant et après, de 1 à 10 chacun : résultat rêvé, probabilité perçue de l'obtenir, délai pour le résultat, effort et sacrifice. Dites quel élément de l'empilement fait bouger quel score.

Soyez strict sur la probabilité : sans résultats MEASURED, un acheteur n'a que la parole du fondateur. La probabilité est faible jusqu'à ce qu'il y ait un cas, une citation ou une démo sur le type de données de l'acheteur, et un empilement de bonus ne change pas cela.

Étape 5 : retester

Écrivez la nouvelle offre dans founder/pitch.md (gardez l'ancienne sous founder/pitch-v1.md) et lancez /truth-serum --quick avec la même graine. Rapporter le taux d'achat avant et après et quelles objections ont disparu. Si rien n'a bougé, dites-le : le problème peut être le marché ou le prix, pas l'offre. Si ça a bougé, dites-le aussi, et précisez qu'il s'agit toujours d'une simulation : le vrai retest est l'offre du premier oui présentée à de vrais acheteurs.

Enregistrez chaque promesse que l'offre fait ("résultats en 5 jours", "3x plus rapide", "zéro donnée ne quitte le bâtiment") avec ledger.py add en tant que PLANNED, type product, sauf si elle est déjà MEASURED avec des preuves.

Règles

  • Chaque promesse doit être réalisable et abordable ; vérifiez les coûts avec le CFO.
  • Une promesse qui n'a pas été mesurée est écrite comme un objectif ou un engagement ("nous mesurerons", "si nous ne l'atteignons pas, vous ne payez rien"), jamais comme un fait.
  • Pas de faux avis, témoignages, rareté, remises ou "vu à la télé".
  • Suivez les règles de publicité et de protection des consommateurs du marché de l'utilisateur pour les garanties et les allégations (les allégations de santé en particulier). Ce n'est pas un conseil juridique.

Résultat

founder/offer.md (d'abord la vérité difficile : la partie la plus faible de l'offre ; puis l'offre du premier oui, la liste des problèmes, l'empilement, les coûts, les scores de l'équation de valeur, le résultat du retest) et founder/pitch.md mis à jour. Ensuite : /burn-test pour recalculer les chiffres avec l'empilement, puis /signal, ou /handshake pour envoyer l'offre du premier oui à un vrai acheteur.

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

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

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

Skills associés