El stack de IA que uso para programar con Claude Code (gstack, gbrain, GSD y más)

Un agente de IA que programa sin memoria, sin proceso y sin frenos escribe código que otra persona depura a las 3am. Casi siempre esa persona eres tú, tres semanas después.

Después de meses usando Claude Code en producción, dejé de tratarlo como un autocompletado con esteroides y empecé a tratarlo como un equipo: alguien que investiga, alguien que planifica, alguien que ejecuta, alguien que recuerda lo que decidimos ayer y alguien que impide que todo se convierta en una fábrica de abstracciones innecesarias.

Ese “equipo” no es un solo producto. Son seis integraciones open-source que se combinan. Este artículo es el mapa: qué hace cada una, por qué se gana su lugar, su repositorio y cómo encajan entre sí. Es técnico a propósito: si apenas estás empezando y todavía no programas a diario, quizá te sirva más mi guía sobre las mejores maneras de aprender a programar antes de montar este stack.

El problema que todas resuelven: context rot

Todo se reduce a una sola enfermedad. Los modelos de lenguaje tienen una ventana de contexto finita, y su calidad se degrada a medida que esa ventana se llena de logs, archivos, resultados de búsqueda y conversación. Es lo que la comunidad llama context rot: el agente que a las 9am razonaba con claridad, a las 11am ha olvidado la decisión que tomó, reescribe lo que ya existía y contradice su propio plan.

Cada herramienta de este stack ataca el context rot desde un ángulo distinto:

Vamos una por una.

1. gstack — la sala de juntas

Repo: garrytan/gstack · Qué es: la configuración exacta de Claude Code de Garry Tan, empaquetada.

gstack es un conjunto de skills (slash commands) opinionados que le dan a Claude distintos roles profesionales. En lugar de pedirle “revisa esto”, invocas al rol adecuado:

/gstack-office-hours      # modo YC Office Hours: cuestiona tu producto
/gstack-plan-ceo-review   # revisión del plan en modo fundador/CEO
/gstack-plan-eng-review   # revisión en modo Eng Manager
/gstack-design-review     # ojo de diseñador: inconsistencias, "AI slop"
/gstack-review            # revisión de PR antes de hacer merge
/gstack-ship              # detecta base branch, corre tests, bump de versión, PR

El valor no está en cada comando aislado, sino en que el proceso completo de un sprint —planear, revisar como CEO, revisar como ingeniería, diseñar, hacer QA, lanzar y documentar— ya está codificado. /gstack-autoplan incluso encadena las revisiones de CEO, diseño, ingeniería y DX de forma secuencial con decisiones automáticas.

Se instala clonando el repo en ~/.claude/skills/ y corriendo su ./setup. Los skills quedan disponibles con prefijo (/gstack-*).

Cuándo lo uso: siempre que una tarea es más grande que “arregla este bug”. El costo es que son muchos comandos que memorizar; la ventaja es que cada uno trae una checklist senior que yo olvidaría.

2. gbrain — la memoria de largo plazo

Repo: garrytan/gbrain · Qué es: un cerebro de conocimiento persistente para agentes.

Este es, para mí, el que más cambia el juego. Claude olvida todo entre sesiones. gbrain le da memoria con dos superpoderes:

a) Búsqueda semántica del código. En lugar de grep de coincidencia exacta, gbrain indexa el repo con voyage-code-3 (embeddings de 1024 dimensiones especializados en código) y devuelve regiones de archivo rankeadas por significado:

gbrain search "portfolio filter isotope"
# → src/lib/portfolio-filter.ts  (score 0.88)

Preguntas qué hace algo aunque no sepas cómo se llama. Eso es imposible con grep.

b) Grafo de llamadas por símbolo. Cuando sí conoces el símbolo:

gbrain code-def   miFuncion   # dónde se define
gbrain code-refs  miFuncion   # quién la referencia
gbrain code-callers miFuncion # quién la llama (análisis de impacto)

Y no solo indexa código: guarda decisiones. En mis proyectos, un hook de SessionStart inyecta al arrancar el último puntero de sesión y los commits recientes, de modo que cada sesión nueva empieza sabiendo qué se decidió la última vez. Se instala vía gstack:

/gstack-setup-gbrain   # instala el CLI, inicializa el brain, registra el MCP

Soporta un motor PGLite embebido (cero configuración) o Postgres + pgvector en Supabase para escritura concurrente. Yo migré a Supabase justo por eso: poder capturar memoria mientras un MCP tiene el brain abierto.

Cuándo lo uso: en cada repo serio. Es la diferencia entre un agente que “conoce” mi código y uno que lo redescubre desde cero cada mañana.

3. GSD (Get Shit Done) — el proceso

Repo: gsd-build/get-shit-done por TÂCHES · Qué es: un sistema de desarrollo spec-driven y meta-prompting para Claude Code.

Si gstack son los roles, GSD es el método. Ataca el context rot de raíz con un ciclo por fases, y cada fase corre con una ventana de contexto fresca:

discutir → planear → ejecutar → verificar   (por cada fase del roadmap)

/gsd:new-project      # preguntas, configuración, roadmap aprobado
/gsd:discuss-phase    # fija preferencias antes de planear
/gsd:plan-phase       # investiga + planea + verifica el plan
/gsd:execute-phase    # ejecución en paralelo con subagentes
/gsd:verify-work      # UAT conversacional
/gsd:ship             # crea el PR desde trabajo verificado

Lo notable de su ingeniería: no hay runtime propietario. Son ~50 archivos Markdown, un CLI en Node y unos hooks, orquestando subagentes con planes en XML y commits atómicos. El overhead de tokens por turno se reduce drásticamente precisamente porque cada subagente arranca con contexto limpio y devuelve solo el resultado, no el ruido.

La pieza clave son los subagentes: en lugar de que el hilo principal lea 40 archivos y se sature, despacha un agente que lee, deriva la conclusión y regresa solo eso. El contexto principal se mantiene delgado.

Cuándo lo uso: en proyectos multi-fase donde un solo prompt gigante se desmoronaría. Para un one-liner es demasiada ceremonia (para eso existe /gsd:fast).

4. superpowers — la disciplina

Repo: obra/superpowers por Jesse Vincent · Qué es: una biblioteca de skills que imponen buenas prácticas antes de escribir código.

superpowers invierte el orden natural del agente. Su regla central: invoca el skill relevante antes de cualquier acción, incluso antes de hacer preguntas. Los que más uso:

• brainstorming — obligatorio antes de cualquier trabajo creativo: explora intención y requisitos antes de tocar código.
• systematic-debugging — método científico ante un bug, en vez de parchear el primer síntoma.
• test-driven-development — test primero, implementación después.
• verification-before-completion — prohíbe decir “está arreglado” sin correr el comando y ver la salida. Evidencia antes que afirmaciones.
• writing-plans / executing-plans — planes escritos con checkpoints de revisión.

El patrón mental es “skills de proceso primero, skills de implementación después”: brainstorming define el enfoque, luego el skill de frontend o el que sea lo ejecuta. Es lo que evita que el agente salte directo a codear una solución equivocada con mucha seguridad.

Cuándo lo uso: siempre está activo. El costo es que a veces se siente lento (“¿otra vez brainstorming?”); la ventaja es que ese minuto evita una hora de deshacer.

5. context-mode — piensa en código, no en bytes

Repo: mksglu/context-mode · Qué es: un plugin que mantiene los datos crudos fuera de la conversación.

Principio central: cada byte que una herramienta devuelve entra a la memoria del agente y cuesta capacidad de razonamiento el resto de la sesión. context-mode da tools que ejecutan el análisis en un sandbox y solo devuelven la respuesta derivada:

ctx_batch_execute  → corre comandos en paralelo, los auto-indexa (FTS5)
ctx_execute        → deriva la respuesta: filtra, cuenta, agrega, parsea
ctx_search         → busca en lo ya indexado + memoria de sesión
ctx_fetch_and_index→ trae una URL, la indexa, la página cruda nunca entra

En lugar de cat archivo-enorme.log (que vuelca 5.000 líneas a tu contexto), le dices que ejecute código que cuenta los errores y solo imprime 142 errores, 3 tipos. El log entero se queda en el sandbox. Para un agente que trabaja horas, esto es la diferencia entre razonar con claridad al final del día o ahogarse en su propio historial. Incluye una base de conocimiento FTS5 persistente entre sesiones.

Cuándo lo uso: en cualquier tarea que procese salidas grandes —analizar logs, tests, git log, respuestas de API. Para observar una salida corta y fija (git status en un árbol limpio) el shell normal sigue siendo lo correcto.

6. ponytail — el freno contra la sobre-ingeniería

Repo: DietrichGebert/ponytail · Qué es: un modo que fuerza la solución más simple que realmente funciona.

Los agentes tienen un sesgo brutal hacia construir de más: una interfaz con una sola implementación, una factory para un solo producto, config para un valor que nunca cambia. ponytail canaliza a un senior perezoso —perezoso significa eficiente, no descuidado— que sube por una escalera y se detiene en el primer escalón que aguanta:

1. ¿Esto necesita existir? (YAGNI)
2. ¿Ya está en el codebase? Reúsalo.
3. ¿Lo hace la librería estándar?
4. ¿Una feature nativa de la plataforma lo cubre? (<input type="date"> antes que una librería)
5. ¿Una dependencia ya instalada lo resuelve?
6. ¿Puede ser una línea?
7. Solo entonces: el mínimo código que funciona.

La regla de oro: la corrección de un bug es la causa raíz, no el síntoma. Un guard en la función compartida es un diff más pequeño que un guard en cada caller. Trae comandos de auditoría (/ponytail-audit escanea todo el repo buscando qué borrar) y deja comentarios ponytail: marcando los atajos deliberados con su techo conocido.

Cuándo lo uso: como modo por defecto. Nunca lo dejo “ser perezoso” con validación de entradas, manejo de errores que previene pérdida de datos, seguridad o accesibilidad. La pereza acorta la solución, nunca la comprensión del problema.

Bonus: codebase-memory-mcp — el grafo de arquitectura

Junto a gbrain uso un servidor MCP de grafo de código (codebase-memory-mcp) para preguntas de arquitectura e impacto: search_graph (encontrar funciones/rutas por patrón), trace_path (cadenas de llamadas cross-service), get_architecture (estructura del proyecto). Donde gbrain destaca en búsqueda semántica y code-def/code-refs, este brilla en el grafo de llamadas completo (“¿quién llama a X y qué se rompe si lo cambio?”).

Cómo encajan: un flujo real

Ninguna funciona sola. Un sprint típico se ve así:

1. gbrain arranca la sesión inyectando qué decidí la última vez (hook de SessionStart).
2. superpowers/brainstorming me obliga a aclarar la intención antes de codear.
3. GSD convierte eso en un roadmap por fases con commits atómicos.
4. Dentro de cada fase, los subagentes de GSD + context-mode hacen que la lectura de código no sature el contexto principal.
5. ponytail vigila que la implementación no invente abstracciones.
6. gstack corre las revisiones (CEO, ingeniería, diseño) y hace el /ship.
7. Al terminar, gbrain captura las decisiones para la próxima sesión.

El hilo conductor de todo es el mismo: mantener la ventana de contexto delgada y de alta señal. Memoria fuera del contexto (gbrain), bytes crudos fuera del contexto (context-mode), fases con contexto fresco (GSD), menos código que razonar (ponytail).

Lo que este stack no es

No es magia y tiene fricción real. Son muchas piezas que configurar y mantener actualizadas; algunas se pisan entre sí (dos “modos de proceso” activos a la vez confunden al agente); y sobre-instalar skills contamina el propio contexto que intentas proteger. Mi recomendación honesta si empiezas: gbrain + una sola herramienta de proceso (GSD o gstack, no las dos de golpe) + ponytail. Añade el resto cuando sientas el dolor que resuelven, no antes. Es, apropiadamente, un consejo muy ponytail.

Repositorios

Este stack es cómo yo, como desarrollador, saco provecho de la IA a diario. Si vienes del lado educativo y te interesa el mismo cambio de mentalidad aplicado a la enseñanza, lo cuento en IA para educadores.

Si te sirvió o usas un stack distinto, escríbeme — me interesa mucho ver cómo otros devs organizan su equipo de agentes.