🌱 Empieza aquí · Decidir antes de construir, con scoring ponderado

Imagina que alguien te pide "constrúyeme una herramienta para el equipo". El instinto es arrancar a construir de una vez. Y ahí está la trampa más cara: si te lanzas sin decidir bien el camino, puedes pasar semanas programando algo a la medida que una plataforma lista para usar habría resuelto en una tarde. O montar algo ligero que a los tres meses se queda chico y toca migrar todo.

Esta semilla le enseña a tu asistente a hacerlo al revés: primero decidir, luego construir. Antes de tocar nada, compara los caminos posibles (hacerlo a la medida, usar una plataforma no-code, o un híbrido) con evidencia y una tabla de puntajes con pesos, y no deja construir nada hasta que la decisión esté justificada y tú la firmes. Solo entonces construye el ganador, lo prueba de verdad (no "se ve bien", sino "lo usé y funcionó") y lo empaca con un manual para que quien lo va a usar lo estrene sin ser técnico.

Para instalarla

Abre esta carpeta con Claude Code o Cowork y dile a tu asistente:

"Siembra esta semilla 🌱"

Con eso basta de tu parte. Tu asistente hace todo lo demás y al final te dice cómo comprobar que quedó. Vas a ver algunas palabras en inglés en la pantalla; ni caso, él te guía.

¿Otras formas de pedírselo? "instala esta semilla", "pon a funcionar el método de decidir antes de construir", "haz el setup de esto". Te entiende igual.

Para el asistente que siembra 🤖

Este componente es un workflow (método de trabajo), no un programa ejecutable. No es un hook (gancho de automatización): no lleva chmod, no lleva entrada en settings.json y no ejecuta ningún script. Se "siembra" colocando el método donde tú, el asistente, lo leas de forma automática para poder correrlo cuando la persona te pida construir algo.

1. Copia el método donde lo leas siempre

El kernel trae dos archivos:

• kernel/decidir-antes-de-construir.md — el método en sí (las 6 reglas + las 4 fases + los dos gates).
• kernel/criterios-y-alcance.ejemplo.md — una plantilla para aterrizar el método a los criterios, los pesos y el alcance reales de la persona.

Coloca decidir-antes-de-construir.md en el lugar que tu plataforma carga como instrucción permanente:

Claude Code (macOS / Linux / Windows con Git Bash):

mkdir -p "$HOME/.claude/rules"
cp kernel/decidir-antes-de-construir.md "$HOME/.claude/rules/decidir-antes-de-construir.md"

Los archivos dentro de ~/.claude/rules/ se cargan solos al inicio de cada sesión. Copia ahí solo el método. La plantilla de criterios NO va en esa carpeta (no es una regla, es una guía que usas en el paso 2).

Cowork: usa la misma carpeta de reglas si tu proyecto la soporta (.claude/rules/decidir-antes-de-construir.md). Si no, coloca el método dentro del proyecto y agrega una línea que apunte a él en el archivo de instrucciones del proyecto (el CLAUDE.md), por ejemplo: "Antes de construir cualquier herramienta, aplica el método de decidir-antes-de-construir.md: decide el camino con scoring ponderado antes de construir."

Codex: Codex lee su archivo de instrucciones AGENTS.md. Copia el contenido del método dentro de AGENTS.md (o agrégale un puntero al archivo si lo guardas aparte en el proyecto), para que se cargue con el resto de tus instrucciones.

2. Aterriza los criterios y el alcance a ESTE caso (recomendado)

Abre kernel/criterios-y-alcance.ejemplo.md. Con la persona (o detectándolo tú), llena la plantilla reemplazando los placeholders:

• <QUÉ-HERRAMIENTA> → qué se pide construir y quién la va a usar.
• Los tres caminos a puntuar → cómo se vería cada uno en este caso.
• Los criterios y sus pesos → suman 100%, se firman ANTES de puntuar.
• El alcance, el listón de calidad y el caso de prueba.

Guarda esa plantilla llena junto al método. Con eso, cuando la persona te diga "constrúyeme X", ya sabes con qué criterios decidir y con qué caso de prueba verificar. Si la persona no tiene todo claro todavía, deja los placeholders y márcalos "por confirmar"; el método sigue funcionando.

3. Verificación post-siembra (obligatoria)

Como es un método (texto), la verificación tiene dos partes: que el archivo quedó en su lugar, y que el método se aplica de verdad.

a) El archivo quedó colocado (ejemplo Claude Code):

ls -la "$HOME/.claude/rules/decidir-antes-de-construir.md"; echo "exit=$?"

Salida esperada: una línea que lista el archivo (con su tamaño) y exit=0. Si sale No such file or directory, la copia no se hizo; repite el paso 1.

b) El método se aplica (prueba de comportamiento, en una conversación nueva): pídele a la persona que abra una sesión nueva y diga algo como "constrúyeme una herramienta para llevar a mi equipo". La conducta correcta es que tú, ANTES de construir nada, decidas primero el camino: investigues las opciones con fuentes, propongas criterios y pesos para que la persona los firme, armes una tabla de scoring, y no empieces a construir hasta que la decisión esté firmada. Si en vez de eso te lanzas a construir de golpe sin comparar caminos, el método no se cargó: revisa que decidir-antes-de-construir.md esté en la carpeta de reglas (o dentro de AGENTS.md en Codex).

Cuando ambas partes pasen, avísale a la persona en una línea qué gana con esto.

✅ ¿Cómo sé que funcionó?

De ahora en adelante, cuando le pidas a tu asistente construir algo de peso, en vez de lanzarse a ciegas va a:

1. Decidir primero el camino (a la medida, plataforma no-code, o híbrido) con evidencia fechada, no por corazonada.
2. Proponerte criterios y pesos para que los firmes ANTES de puntuar, y armar una tabla de scoring donde se ve por qué gana el que gana.
3. No construir nada hasta que tú firmes el camino ganador (el candado que te ahorra construir la cosa equivocada).
4. Construir el ganador y probarlo de verdad con un caso real (no "se ve bien", sino "lo usé y funcionó").
5. Entregártelo con un manual en lenguaje llano para que quien lo va a usar lo estrene sin ser técnico.

El resultado: dejas de quemar semanas construyendo por el camino equivocado, y lo que se construye llega funcionando y usable. Eso es todo. 🌱