CommunityProgramación y desarrollogithub.com

kill-or-build

Tu planificador de negocios. Compila todo lo que escribieron las otras habilidades de Shark Tank Proof (el veredicto del panel, los competidores, los compradores, los precios, la oferta, los números del CFO, marketing, marca, operaciones, el plan de lanzamiento y el libro de evidencia) en un plan de negocios con un veredicto calculado automáticamente, nunca escrito a mano: Rentable (los números cuadran y un comprador real ha pagado, firmado o reservado), No probado (funciona en papel, sin comprador real aún), Todavía no (con números fallidos) o Incompleto. Un panel simulado puede hacer fallar un plan, pero nunca aprobarlo. Añade un resumen ejecutivo y una versión de una página. Úsalo cuando el usuario diga "escribe mi plan de negocios", "ponlo todo junto", "¿es rentable?", "dame el plan", o al final del paquete Shark Tank Proof.

¿Qué es kill-or-build?

Esta habilidad, kill-or-build, es el paso final en el flujo de trabajo Shark Tank Proof. Su propósito es compilar toda la información generada por las habilidades anteriores (veredicto de la junta, análisis de competidores, panel de compradores, fijación de precios, oferta, finanzas, marketing, marca, operaciones, lanzamiento y evidencia) en un plan de negocios completo y honesto. Es particularmente útil para fundadores que necesitan una visión clara y accionable de su negocio, separando lo que está validado de lo que es especulación. La habilidad se ejecuta mediante un script de Python (`compile.py`) que calcula automáticamente el veredicto del plan basado en datos concretos. No permite escribir el veredicto manualmente, garantizando así la objetividad. Soporta la generación de tres documentos clave: un resumen ejecutivo (`summary.md`), un plan de negocios completo (`business-plan.md`) y una versión resumida de una página (`one-pager.md`). Es compatible con entornos de línea de comandos (CLI) como los usados por Claude Code o Codex. El flujo de trabajo es claro: primero verifica qué información está disponible, luego genera un resumen honesto que incluye la "verdad dura" (la razón más probable del fracaso), y finalmente compila el plan completo. También es capaz de identificar secciones faltantes y recomendar la habilidad correspondiente para completarlas, sin rellenarlas con suposiciones. Esta herramienta es ideal para emprendedores y equipos que buscan un plan de negocios basado en hechos y no en ilusiones.

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

Installed? Explore more Programación y desarrollo skills: steipete/bluebubbles, steipete/eightctl, steipete/blucli · View all 6 →

Preguntar en tu IA favorita

Abre un nuevo chat con esta habilidad de agente ya precargada.

Documentación

¿Qué hace kill-or-build?

El último paso. Un documento sobre el que un fundador puede actuar, construido únicamente a partir de lo que el paquete encontró, y honesto sobre qué partes son reales.

Lee primero ${CLAUDE_SKILL_DIR}/../receipts/rules.md.

Herramienta en esta carpeta:

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

Paso 1: ver qué hay

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

imprime el veredicto y cada verificación. Las verificaciones, todas calculadas:

  1. Cada unidad genera ganancias antes de costos fijos (founder/numbers.json).
  2. El Año 1 obtiene una ganancia operativa.
  3. El punto de equilibrio cabe dentro de la capacidad, si se proporcionó una capacidad.
  4. Suficientes compradores simulados compran (founder/panel/results.json; barra predeterminada 25%, cámbiala con --min-buy-rate y explica por qué). Un panel bajo hace fallar el plan; un panel alto no prueba nada.
  5. Demanda real: al menos una afirmación de demanda MEASURED en founder/evidence/claims.csv (un pago, un depósito, un piloto firmado, una reserva).

Los veredictos:

veredictosignifica
Incompletoaún no hay números: ofrece /burn-test
Todavía nouna verificación falla; cada falla se enumera con su número
No probadolas matemáticas funcionan en papel, pero ningún comprador real se ha comprometido
Rentablelas matemáticas funcionan y al menos un comprador real se comprometió

Ejecuta primero ledger.py summary para que la sección de evidencia esté actualizada:

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

Si no hay números, el veredicto es Incompleto: ofrece ejecutar /burn-test. Enumera las otras secciones faltantes con la habilidad que las completa. No completes una sección faltante tú mismo a partir de suposiciones.

Paso 2: el resumen

Escribe founder/summary.md, media página, palabras sencillas, comenzando con La verdad dura: la razón más probable por la que esto falla.

  • Qué es el negocio y para quién es, en dos oraciones.
  • El veredicto y los tres números detrás de él (margen, punto de equilibrio, año 1).
  • Qué es real: el recuento de afirmaciones MEASURED y THEY SAID IT, y qué son. Luego qué sigue siendo una suposición.
  • En qué estuvieron de acuerdo el panel simulado y la junta, y en qué discreparon, etiquetado como simulado.
  • El mayor riesgo y qué se hará al respecto.
  • Qué necesita el fundador para comenzar (efectivo del CFO, la primera prueba del lanzamiento).
  • La única cosa que hacer esta semana.

Si el veredicto es Todavía no, el resumen comienza con lo que tiene que cambiar y qué habilidad lo cambia. Si es No probado, comienza con la única prueba del mundo real que lo probaría o mataría este mes. Nunca suavices una verificación fallida, y nunca escribas un plan No probado como si fuera uno validado.

Paso 3: compilar

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

escribe founder/business-plan.md: título, el veredicto y sus verificaciones, la tabla de números clave, la idea, luego cada sección que el paquete produjo (resumen, junta, competencia, panel, precios, oferta, números, marketing, marca, operaciones, lanzamiento), y lo que aún no está hecho.

Paso 4: la página única

Escribe founder/one-pager.md para el fundador y socios cercanos: el problema, el cliente, la oferta y el precio, la tabla de números, la evidencia real (y el panel, etiquetado como simulado), para qué es el dinero, y la solicitud. Los mismos números que el plan, palabra por palabra.

Para cualquier persona externa (un cliente, un financiador, un prestamista), no envíes el plan ni esta página: ejecuta /handshake, que construye solo a partir de afirmaciones que esa audiencia puede ver y verifica el resultado.

Reglas

  • El veredicto proviene de compile.py. Nunca escribas Rentable a mano, nunca redondees un número fallido para que sea aprobado, y nunca llames a No probado "casi listo".
  • Di una vez, claramente: el panel y la junta son simulados y los números son proyecciones; solo los clientes reales y las cotizaciones reales los confirman. No es asesoramiento financiero, legal o fiscal.
  • Si el usuario quiere un PDF o una presentación, ofrece exportar el plan, pero mantén el markdown como la fuente de verdad.

Salida

founder/summary.md, founder/business-plan.md, founder/one-pager.md. Luego dale al usuario el veredicto en una línea, la verdad dura, y la única cosa del mundo real que hacer esta semana. Siguiente: /handshake para el receptor que tiene que decir que sí.

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 relacionados