Empieza aquí 🌱

Abre esta carpeta con Claude Code o Cowork y dile a tu asistente: "siembra esta semilla 🌱"

Con eso basta. Tu asistente hace todo lo técnico por ti (vas a ver algunas palabras en inglés en la pantalla; ni caso, él te guía). Tú solo confirmas cuando te pregunte.

¿Otras formas de pedirlo? "instala esta semilla", "activa este agente", "pon el test-writer a funcionar". Te entiende igual.

Esta semilla instala un agente (subagente): un ayudante especializado que tu asistente puede invocar para escribir tests con método TDD. En lugar de tirar el código primero y ver si funciona, escribe primero el test que describe lo que debe pasar, luego la implementación mínima, y no dice "los tests pasan" hasta pegarte la salida verde real del programa que corre los tests.

¿Qué es TDD, en cristiano?

TDD (siglas en inglés de "desarrollo guiado por tests") es un hábito de trabajo con tres pasos que se repiten:

1. Rojo: primero escribes una prueba pequeña que dice "esto es lo que el código debería hacer". Como el código aún no existe, la prueba falla (sale en rojo). Eso es lo esperado.
2. Verde: escribes lo mínimo para que esa prueba pase (sale en verde).
3. Refactor: ya con la red de seguridad de la prueba en verde, limpias el código sin miedo a romperlo.

La gracia: nunca escribes código "a ciegas". Cada línea existe porque una prueba la pidió, y siempre tienes evidencia de que funciona.

Para el asistente que siembra 🤖

Eres el asistente. Sigue estos pasos con precisión. Esto es un agente de Claude Code / Cowork (un subagente con nombre propio), no un hook ni un script: se instala copiando un solo archivo Markdown a la carpeta de agentes del usuario. La plataforma lo descubre automáticamente al leer esa carpeta.

Paso 1 · Copiar el archivo del kernel

El kernel es un solo archivo: kernel/test-writer.md. Cópialo a la carpeta de agentes del usuario según su plataforma.

• macOS / Linux (Claude Code o Cowork):

  mkdir -p ~/.claude/agents
  cp kernel/test-writer.md ~/.claude/agents/test-writer.md
  

• Windows (Claude Code o Cowork, con Git Bash):

  mkdir -p "$USERPROFILE/.claude/agents"
  cp kernel/test-writer.md "$USERPROFILE/.claude/agents/test-writer.md"
  

  Estos son comandos de Git Bash (la terminal que Claude Code usa en Windows). Si estás en PowerShell o CMD, ábrelos en Git Bash o pídele al asistente que haga la copia por ti.

Sin chmod y sin settings.json. A diferencia de un hook, un agente es un archivo de texto que la plataforma lee, no un programa que se ejecute. No necesita permisos de ejecución ni cablearse en settings.json. Con copiarlo a la carpeta agents es suficiente: Claude Code y Cowork lo detectan solos.

Paso 2 · Verificación post-siembra (obligatoria)

No declares "listo" sin correr esto. Confirma que el archivo llegó a su sitio y que su encabezado (frontmatter) quedó bien formado.

grep -m1 '^name:' ~/.claude/agents/test-writer.md

Salida esperada:

name: test-writer

En Windows, cambia ~ por "$USERPROFILE". Si no imprime nada, revisa que el archivo se haya copiado a la carpeta agents (no a hooks) y que el nombre sea exactamente test-writer.md.

Como comprobación adicional en una sesión interactiva de Claude Code, el comando /agents debe listar test-writer entre los agentes disponibles. Si aparece ahí, ya se puede invocar.

Placeholders y configuración

El kernel trae un solo placeholder, y es opcional:

• <TU-ARCHIVO-DE-APRENDIZAJES> — aparece en las secciones "Consulta tus aprendizajes" y "Mejora continua". Sirve si el usuario quiere que el agente vaya acumulando mocks, fixtures y patrones de test ya probados en un archivo propio (por ejemplo ~/.claude/agents/learnings/test-writer.md), para no reinventarlos. Si al usuario no le interesa esa memoria manual, déjalo tal cual o borra esas secciones: el agente funciona igual, porque ya trae memory: project para memoria automática por proyecto.

Ajustes opcionales que el usuario puede pedirte más adelante (edítalos dentro del .md):

• Modelo — la línea model: sonnet. Escribir tests es una tarea que un modelo intermedio resuelve bien y a buen costo, por eso es el default; cámbiala si el usuario prefiere otro.
• Plugin superpowers (opcional): si el usuario lo tiene instalado, el agente aprovecha automáticamente sus habilidades test-driven-development y verification-before-completion. Si NO lo tiene, no pasa nada: el agente trae el mismo método por dentro y funciona igual. No necesitas instalar nada extra para sembrar esta semilla.

¿Cómo sé que funcionó?

Cuando tu asistente termine, pídele que corra la verificación de arriba y te muestre el resultado. Si aparece name: test-writer, ya quedó sembrado.

Para probarlo de verdad, la próxima vez que escribas una función o un componente, dile algo como: "escríbele tests a esto" o "cubre esta función con tests antes de seguir". Tu asistente invocará al test-writer, que primero escribirá el test que describe el comportamiento esperado (y lo verás fallar, en rojo, a propósito), luego la implementación mínima que lo pone en verde, y te entregará al final la salida real del runner con los ✓ verdes. Lo que no hará —y ese es justo el punto— es decir "los tests pasan" sin mostrarte la prueba.