kill-or-build

Seu planejador de negócios. Compila tudo que os outros skills do Shark Tank Proof escreveram (veredito do conselho, concorrentes, painel de compradores, precificação, oferta, números do CFO, marketing, marca, operações, plano de lançamento e livro de evidências) em um único plano de negócios com um veredito computado, nunca escrito manualmente: Lucrativo (números aprovados e um comprador real pagou, assinou ou reservou), Não Comprovado (funciona no papel, mas sem comprador real), Ainda Não (números reprovando) ou Incompleto. Um painel simulado pode reprovar um plano, mas nunca aprová-lo. Adiciona um resumo executivo e uma versão de uma página. Use quando o usuário disser "escreva meu plano de negócios", "junte tudo", "é lucrativo?", "me dê o plano", ou no final do pacote Shark Tank Proof.

O que é kill-or-build?

O skill **kill-or-build** é o passo final do fluxo Shark Tank Proof, que consolida todos os outputs gerados pelos demais skills (veredito do conselho, análise de concorrentes, painel de compradores, precificação, oferta, finanças, marketing, marca, operações, plano de lançamento e livro de evidências) em um único plano de negócios. Seu diferencial é que o veredito é **sempre computado automaticamente** pelo script `compile.py`, nunca escrito manualmente, garantindo honestidade sobre o estágio real do negócio: **Lucrativo** (números aprovados e comprador real confirmado), **Não Comprovado** (funciona no papel, sem comprador real), **Ainda Não** (números reprovando) ou **Incompleto** (sem números financeiros). O painel simulado pode reprovar um plano, mas nunca aprová-lo. O skill gera três documentos principais: um resumo executivo, o plano de negócios completo e uma versão de uma página, todos baseados exclusivamente em dados coletados, sem suposições ou otimismo artificial. É acionado quando o usuário diz "escreva meu plano de negócios", "junte tudo", "é lucrativo?", "me dê o plano" ou no final da execução do pacote Shark Tank Proof. Suporta a plataforma Claude Code e depende dos arquivos gerados pelos outros skills do mesmo pacote.

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

Installed? Explore more Programação e Desenvolvimento skills: steipete/bluebubbles, steipete/eightctl, steipete/blucli · View all 6 →

Perguntar na sua IA favorita

Abre um novo chat com esta habilidade de agente já pré-carregada.

Documentação

O que kill-or-build faz?

O último passo. Um documento no qual o fundador pode agir, construído apenas com o que o pacote encontrou, e honesto sobre quais partes são reais.

Leia ${CLAUDE_SKILL_DIR}/../receipts/rules.md primeiro.

Ferramenta nesta pasta:

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

Passo 1: ver o que existe

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

Exibe o veredito e cada verificação. As verificações, todas computadas:

  1. Cada unidade gera lucro antes dos custos fixos (founder/numbers.json).
  2. O Ano 1 obtém lucro operacional.
  3. O ponto de equilíbrio cabe dentro da capacidade, se uma capacidade foi informada.
  4. Compradores simulados suficientes compram (founder/panel/results.json; padrão 25%, mude com --min-buy-rate e explique o motivo). Um painel baixo reprova o plano; um painel alto não prova nada.
  5. Demanda real: pelo menos uma reivindicação MEASURED em founder/evidence/claims.csv (um pagamento, um depósito, um piloto assinado, uma reserva).

Os vereditos:

vereditosignificado
Incompletosem números ainda: ofereça /burn-test
Ainda Nãouma verificação falha; cada falha é listada com seu número
Não Comprovadoa matemática funciona no papel, mas nenhum comprador real se comprometeu
Lucrativoa matemática funciona e pelo menos um comprador real se comprometeu

Execute ledger.py summary primeiro para que a seção de evidências esteja atualizada:

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

Se não houver números, o veredito é Incompleto: ofereça executar /burn-test. Liste as outras seções ausentes com o skill que preenche cada uma. Não preencha uma seção ausente com suposições.

Passo 2: o resumo

Escreva founder/summary.md, meia página, linguagem simples, abrindo com A dura verdade: a razão mais provável para isso falhar.

  • O que é o negócio e para quem ele é, em duas frases.
  • O veredito e os três números por trás dele (margem, ponto de equilíbrio, Ano 1).
  • O que é real: a contagem de reivindicações MEASURED e ELES DISSERAM, e o que elas são. Depois, o que ainda é suposição.
  • O que o painel simulado e o conselho concordaram, e onde discordaram, rotulado como simulado.
  • O maior risco e o que será feito sobre ele.
  • O que o fundador precisa para começar (caixa do CFO, o primeiro teste do lançamento).
  • A única coisa para fazer esta semana.

Se o veredito for Ainda Não, o resumo começa com o que precisa mudar e qual skill muda isso. Se for Não Comprovado, começa com o único teste no mundo real que o comprovaria ou mataria este mês. Nunca suavize uma verificação reprovada e nunca escreva um plano Não Comprovado como se fosse validado.

Passo 3: compilar

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

Escreve founder/business-plan.md: título, o veredito e suas verificações, a tabela de números principais, a ideia, então cada seção que o pacote produziu (resumo, conselho, concorrência, painel, precificação, oferta, números, marketing, marca, operações, lançamento), e o que ainda não foi feito.

Passo 4: a página única

Escreva founder/one-pager.md para o fundador e parceiros próximos: o problema, o cliente, a oferta e preço, a tabela de números, a evidência real (e o painel, rotulado como simulado), para que serve o dinheiro e o pedido. Mesmos números do plano, palavra por palavra.

Para qualquer pessoa de fora (um cliente, um investidor, um credor), não envie o plano nem esta página: execute /handshake, que constrói apenas a partir de reivindicações que esse público pode ver e verifica o resultado.

Regras

  • O veredito vem do compile.py. Nunca escreva Lucrativo manualmente, nunca arredonde um número reprovado para um aprovado, e nunca chame Não Comprovado de "quase lá".
  • Diga uma vez, claramente: o painel e o conselho são simulados e os números são projeções; apenas clientes reais e citações reais os confirmam. Não é aconselhamento financeiro, jurídico ou fiscal.
  • Se o usuário quiser um PDF ou uma apresentação, ofereça-se para exportar o plano, mas mantenha o markdown como a fonte da verdade.

Saída

founder/summary.md, founder/business-plan.md, founder/one-pager.md. Em seguida, forneça ao usuário o veredito em uma linha, a dura verdade e a única coisa real do mundo a fazer esta semana. Próximo: /handshake para o receptor que precisa dizer sim.

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

Habilidades Relacionadas