Spike

¿Qué hace Spike?

Usa esta skill cuando el usuario quiera tantear una idea antes de comprometerse a una implementación real — validando factibilidad, comparando enfoques, o sacando a la luz incógnitas que ninguna cantidad de investigación resolverá. Los spikes están diseñados para ser desechables. Tíralos una vez que hayan cumplido su propósito.

Carga esto cuando el usuario diga cosas como "déjame probar esto", "quiero ver si X funciona", "has un spike de esto", "antes de comprometerme con Y", "prototipo rápido de Z", "¿esto siquiera es posible?", o "compara A vs B".

Cuándo NO usar esto

• La respuesta se puede obtener de la documentación o leyendo código — solo investiga, no construyas
• El trabajo es para producción — usa la skill plan en su lugar
• La idea ya está validada — salta directamente a la implementación

Si el usuario tiene el sistema GSD completo instalado

Si gsd-spike aparece como una skill hermana (instalada mediante npx get-shit-done-cc --hermes), prefiere gsd-spike cuando el usuario quiera el flujo de trabajo GSD completo: estado persistente en .planning/spikes/, seguimiento con MANIFEST entre sesiones, formato de veredicto Dado/Cuando/Entonces, y patrones de commit que se integran con el resto de GSD. Esta skill es la versión ligera independiente para usuarios que no tienen (o no quieren) el sistema completo.

Método central

Sin importar la escala, cada spike sigue este ciclo:

descomponer  →  investigar  →  construir  →  veredicto
   ↑_________________________________________________↓
                 iterar sobre hallazgos

1. Descomponer

Divide la idea del usuario en 2-5 preguntas de factibilidad independientes. Cada pregunta es un spike. Preséntalas como una tabla con formato Dado/Cuando/Entonces:

#	Spike	Valida (Dado/Cuando/Entonces)	Riesgo
001	websocket-streaming	Dada una conexión WS, cuando el LLM transmite tokens, entonces el cliente recibe fragmentos < 100ms	Alto
002a	pdf-parse-pdfjs	Dado un PDF de varias páginas, cuando se analiza con pdfjs, entonces se puede extraer texto estructurado	Medio
002b	pdf-parse-camelot	Dado un PDF de varias páginas, cuando se analiza con camelot, entonces se puede extraer texto estructurado	Medio

Tipos de spike:

• estándar — un enfoque que responde una pregunta
• comparación — misma pregunta, diferentes enfoques (número compartido, sufijo de letra a/b/c)

Buenas preguntas de spike: factibilidad específica con resultado observable. Malas preguntas de spike: demasiado amplias, sin resultado observable, o solo "leer la documentación sobre X".

Ordena por riesgo. El spike con más probabilidad de matar la idea se ejecuta primero. No tiene sentido crear prototipos de las partes fáciles si la parte difícil no funciona.

Omite la descomposición solo si el usuario ya sabe exactamente qué quiere spike y lo dice. Entonces toma su idea como un solo spike.

2. Alinear (para ideas con múltiples spikes)

Presenta la tabla de spikes. Pregunta: "¿Construir todo en este orden, o ajustamos?" Deja que el usuario elimine, reordene o reformule antes de que escribas cualquier código.

3. Investigar (por spike, antes de construir)

Los spikes no están exentos de investigación — investigas lo suficiente para elegir el enfoque correcto, luego construyes. Por spike:

1. Resúmelo. 2-3 frases: qué es este spike, por qué importa, riesgo clave.

2. Presenta enfoques competidores si hay una elección real:

   Enfoque	Herramienta/Biblioteca	Pros	Contras	Estado
   ...	...	...	...	mantenido / abandonado / beta

3. Elige uno. Indica por qué. Si 2 o más son creíbles, construye variantes rápidas dentro del spike.

4. Omite la investigación para lógica pura sin dependencias externas.

Usa herramientas de Hermes para el paso de investigación:

• web_search("python bibliotecas streaming websocket 2025") — encuentra candidatos
• web_extract(urls=["https://websockets.readthedocs.io/..."]) — lee la documentación real (devuelve markdown)
• terminal("pip show websockets | grep Version") — verifica qué está instalado en el entorno virtual del proyecto

Para bibliotecas sin páginas de documentación, clona y lee su README.md / examples/ mediante read_file. Context7 MCP (si el usuario lo tiene configurado) también es una buena fuente — mcp_*_resolve-library-id luego mcp_*_query-docs.

4. Construir

Un directorio por spike. Mantenlo independiente.

spikes/
├── 001-websocket-streaming/
│   ├── README.md
│   └── main.py
├── 002a-pdf-parse-pdfjs/
│   ├── README.md
│   └── parse.js
└── 002b-pdf-parse-camelot/
    ├── README.md
    └── parse.py

Inclínate hacia algo con lo que el usuario pueda interactuar. Los spikes fallan cuando la única salida es una línea de registro que dice "funciona". El usuario quiere sentir que el spike funciona. Opciones predeterminadas, en orden de preferencia:

1. Una CLI ejecutable que toma entrada e imprime salida observable
2. Una página HTML mínima que demuestre el comportamiento
3. Un pequeño servidor web con un endpoint
4. Una prueba unitaria que ejercite la pregunta con aserciones reconocibles

Profundidad sobre velocidad. Nunca declares "funciona" después de una ejecución feliz. Prueba casos límite. Sigue hallazgos sorprendentes. El veredicto solo es confiable cuando la investigación fue honesta.

Evita a menos que el spike lo requiera específicamente: gestión compleja de paquetes, herramientas de compilación/empaquetadores, Docker, archivos de entorno, sistemas de configuración. Hardcodea todo — es un spike.

Construir un spike — una secuencia típica de herramientas:

terminal("mkdir -p spikes/001-websocket-streaming")
write_file("spikes/001-websocket-streaming/README.md", "# 001: websocket-streaming\n\n...")
write_file("spikes/001-websocket-streaming/main.py", "...")
terminal("cd spikes/001-websocket-streaming && python3 main.py")
# Observa la salida, itera.

Spikes de comparación en paralelo (002a / 002b) — delega. Cuando dos enfoques pueden ejecutarse en paralelo y ambos requieren ingeniería real (no prototipos de 10 líneas), distribuye con delegate_task:

delegate_task(tareas=[
    {"objetivo": "Construir 002a-pdf-parse-pdfjs: ...", "conjuntos_herramientas": ["terminal", "file", "web"]},
    {"objetivo": "Construir 002b-pdf-parse-camelot: ...", "conjuntos_herramientas": ["terminal", "file", "web"]},
])

Cada subagente devuelve su propio veredicto; tú escribes la comparación cara a cara.

5. Veredicto

El README.md de cada spike cierra con:

## Veredicto: VALIDADO | PARCIAL | INVALIDADO

### Lo que funcionó
- ...

### Lo que no funcionó
- ...

### Sorpresas
- ...

### Recomendación para la implementación real
- ...

VALIDADO = la pregunta central fue respondida afirmativamente, con evidencia. PARCIAL = funciona bajo las restricciones X, Y, Z — documéntalas. INVALIDADO = no funciona, por esta razón. Este es un spike exitoso.

Spikes de comparación

Cuando dos enfoques responden la misma pregunta (002a / 002b), constrúyelos uno tras otro, luego haz una comparación cara a cara al final:

## Cara a cara: pdfjs vs camelot

| Dimensión | pdfjs (002a) | camelot (002b) |
|-----------|--------------|----------------|
| Calidad de extracción | 9/10 estructurado | 7/10 solo tablas |
| Complejidad de configuración | npm install, 1 línea | pip + ghostscript |
| Rendimiento en PDF de 100 págs | 3s | 18s |
| Maneja texto rotado | no | sí |

**Ganador:** pdfjs para nuestro caso de uso. Camelot si necesitamos extracción centrada en tablas más adelante.

Modo frontera (elegir qué spike hacer a continuación)

Si ya existen spikes y el usuario dice "¿qué debería spike a continuación?", recorre los directorios existentes y busca:

• Riesgos de integración — dos spikes validados que tocan el mismo recurso pero fueron probados de forma independiente
• Transferencias de datos — la salida del spike A se asumió compatible con la entrada del spike B; nunca se demostró
• Vacíos en la visión — capacidades asumidas pero no probadas
• Enfoques alternativos — diferentes ángulos para spikes PARCIALES o INVALIDADOS

Propón 2-4 candidatos como Dado/Cuando/Entonces. Deja que el usuario elija.

Salida

• Crea spikes/ (o .planning/spikes/ si el usuario está usando las convenciones de GSD) en la raíz del repositorio
• Un directorio por spike: NNN-nombre-descriptivo/
• README.md por spike captura la pregunta, el enfoque, los resultados y el veredicto
• Mantén el código desechable — un spike que tarde 2 días en "limpiarse para producción" fue un mal spike

Atribución

Adaptado del flujo de trabajo /gsd-spike del proyecto GSD (Get Shit Done) — MIT © 2025 Lex Christopherson (gsd-build/get-shit-done). El sistema GSD completo ofrece estado de spike persistente, seguimiento con MANIFEST e integración con un pipeline de desarrollo impulsado por especificaciones más amplio; instálalo con npx get-shit-done-cc --hermes --global.