gstack, auditado: 139.339 estrellas para un «todo es Markdown» que esconde 689.039 líneas de TypeScript, 122 versiones de retraso frente a la última etiqueta y 20.616 tokens antes de que /review lea tu diff

El discurso de venta es limpísimo. gstack son «23 herramientas con opinión que hacen de CEO, diseñador, jefe de ingeniería, responsable de releases, ingeniero de documentación y QA», y el README cierra la frase con las tres palabras que lo venden todo: «todo son comandos de barra, todo es Markdown, todo es gratis». Tiene 139.339 estrellas, licencia MIT y el autor es el presidente de Y Combinator. Un fundador de YC que lanza diez sprints en paralelo y regala la maquinaria es exactamente la historia que el ecosistema quiere creerse.

Así que lo cloné. No la página de presentación: el repositorio, con profundidad 1, 120 MB, en una máquina Linux, y después ejecuté la propia puerta de calidad del proyecto sobre él. Tres hallazgos sobrevivieron al contacto:

1. «Todo es Markdown» describe el artefacto, no el repositorio. La instalación entrega 64 archivos de skill (1.706.591 bytes de SKILL.md); el repositorio que los genera son 689.039 líneas de TypeScript en 2.704 archivos, con 1,59 líneas de test por línea de código y 155 plantillas alimentando un compilador.
2. Escribir un comando de barra no es gratis. /review carga 82.466 bytes —60.070 bytes de SKILL.md más un preámbulo de 22.396 bytes— antes de que el modelo lea una sola línea de tu diff. Son unos 20.616 tokens, y esa es la mitad pequeña de la historia del coste.
3. El «canal estable» que el README recomienda a los equipos está 122 versiones publicadas por detrás de main. Hay 797 entradas de versión en el changelog, tres etiquetas de git y un archivo VERSION que ha avanzado cuatro líneas menores desde que se cortó la última etiqueta.

Nada de esto convierte a gstack en un fraude. Lo convierte en un tipo concreto de artefacto —un sistema personal de ingeniería de prompts que se transformó en producto— y los números te dicen qué partes del marketing siguen en pie.

Lo que el repositorio declara de verdad

Todo lo siguiente procede de la API de GitHub el 2026-11-05, más un clon de profundidad 1 medido con git ls-files, wc -l y du.

Dos de esas filas merecen sospecha y una merece defensa.

El ratio de watchers del 0,55% es la señal más débil de la tabla. Los watchers son la única métrica de GitHub que exige una segunda acción deliberada: una estrella se da desde el timeline con un toque, pero seguir un repositorio significa «avísame cuando esto cambie». En este sitio he usado el mismo ratio con otros proyectos: Worktrunk está en 0,22%, delta entre 0,31% y 0,94% en el grupo comparable. El 0,55% de gstack, por tanto, no es un valor atípico. Es el aspecto que tiene un repositorio que se difundió por timelines sociales y no porque la gente ejecutara el código.

El 14,8% de forks es lo contrario: es justo lo que cabe esperar de un repo cuyo README dice «bifúrcalo, mejóralo, hazlo tuyo». Los forks son la vía de adopción prevista, no una señal de alarma. Un ratio de forks alto solo resulta sospechoso cuando el proyecto es una biblioteca que se consume como dependencia, porque ahí bifurcar implica «no pude usarlo tal como viene».

Las 1.110 ramas son la fila de la que nadie habla. Para un proyecto con 982 commits y 14 contribuidores vinculados, mil cien ramas no son colaboración: son el residuo de un flujo de trabajo con agentes que crea una rama por tarea y no la borra nunca. Es un estilo legítimo, pero significa que git branch -r | wc -l no te dice nada sobre la salud de este repositorio, y que un git fetch cuesta más que el propio checkout.

«Todo es Markdown» es un artefacto de compilación

La descripción del repositorio dice «todo es Markdown», y esa frase trabaja mucho. Esta es la composición del árbol, medida sobre el clon.

Lee el ratio: 422.522 líneas de test frente a 266.517 líneas de código fuente, 1,59 a 1. Para una carpeta de prompts en Markdown, eso es una cantidad extraordinaria de maquinaria. La explicación está en los nombres de archivo: SKILL.md.tmpl en la raíz, 49 directorios sections/, 155 plantillas y un archivo de test llamado gen-skill-docs.test.ts que es más grande que cualquier otro archivo del repositorio.

gstack no entrega prompts escritos a mano. Entrega un compilador de prompts: las plantillas, más las secciones por skill, más los guiones resolutores producen el SKILL.md que acaba en ~/.claude/skills/gstack/, y un test de 5.209 líneas comprueba la salida generada. Es una decisión de ingeniería defendible —editar a mano 64 archivos de prompt que comparten 22 KB de preámbulo es la receta de la incoherencia—, pero no es «todo es Markdown». El Markdown es la salida.

Que los prompts sean ingeniería o teatro es otra pregunta, y tiene respuesta. review/SKILL.md funciona como un procedimiento numerado, no como un personaje:

## Step 0: Detect platform and base branch
## Step 1: Check branch
## Step 1.5: Scope Drift Detection
## Step 2: Read the checklist
## Step 2.5: Check for review bot comments
## Step 3: Get the diff
## Step 3.5: Diff scans
### Gate scan
### Banned terms
### Slop scan (advisory)
## Step 4: Critical pass (core review)

Hay puertas deterministas ahí dentro: un escaneo de puertas, un escaneo de términos prohibidos y un escaneo de relleno marcado explícitamente como orientativo. Eso es una lista de comprobación codificada como máquina de estados, que es lo más útil que puede ser un prompt de revisión. El artículo que llamara a esto «solo roleplay» estaría equivocado.

La parte que te cuesta dinero cada vez que escribes un comando

Esta es la medición que no esperaba que importara tanto. El repositorio contiene su propio test de presupuesto —test/skill-size-budget.test.ts— que mide los bytes que un skill carga al arrancar: su SKILL.md más, para un skill de nivel 2, el sections/preamble.md compartido. Apliqué la misma definición a los cinco comandos principales.

El preámbulo compartido son 22.396 bytes —unos 5.600 tokens— y se paga en cada llamada de nivel 2. Por eso el mismo preámbulo aparece en toda la columna central: es un impuesto fijo encima de lo que añada el skill concreto.

Ahora pasémoslo a dinero, con la advertencia que lo hace honesto. A 3 dólares por millón de tokens de entrada, 20.616 tokens son 0,062 dólares de contexto antes de que el modelo lea una línea de tu diff. Diez revisiones al día en cinco ingenieros, 22 días laborables, son 1.100 llamadas y unos 68 dólares al mes, y eso suponiendo una sola pasada por revisión. Con caché de prompts, el preámbulo repetido se factura a una fracción de eso, así que la factura real es menor. El número que no se reduce es el contexto: 20.616 tokens de instrucciones ocupan 20.616 tokens de una ventana de 200.000 en cada llamada, y el seguimiento de instrucciones se degrada a medida que ese prefijo crece.

Si de verdad ejecutas diez sprints en paralelo, como dice el autor, multiplica. El coste es el problema menor; el mayor es que un tercio del contexto de un modelo pequeño se gasta en instrucciones de rol antes de que aparezca tu código.

Esta es también la respuesta honesta al argumento sobre el relleno de contexto que expuse en el análisis del superagente DSH: los presupuestos solo son reales si algo los hace cumplir, y aquí algo lo hace. Lo cual nos lleva a la puerta.

Ejecuté su puerta de calidad. Pasa, y el aprobado es interesante

El repositorio exige Bun 1.4.2 o superior y rechaza cualquier versión anterior a la 1.3.3, con el argumento declarado de que las versiones antiguas «permitirían que las herramientas compiladas leyeran el .env de un proyecto». Instalé Bun 1.4.4 en el clon y ejecuté el test de presupuesto tal como está escrito.

$ bun test test/skill-size-budget.test.ts
(pass) SKILL.md size budget regression (gate, free) > parity-baseline-v1.81.0.0.json exists
(pass) SKILL.md size budget regression (gate, free) > no skill exceeds v1.81.0.0 baseline size × ratio
[skill-size-budget] corpus OK: 3114885 -> 2718207 bytes (×0.873)
(pass) SKILL.md size budget regression (gate, free) > total corpus byte count does not regress
(pass) SKILL.md size budget regression (gate, free) > no skill shrinks past 80% of v1.69.1.0 baseline
[skill-size-budget] catalog OK: ~5754 tokens (target ≤7000, 63 tracked skills)
(pass) SKILL.md size budget regression (gate, free) > catalog token estimate stays compressed

 5 pass
 0 fail
Ran 5 tests across 1 file. [566.00ms]

Hay tres cosas en esa salida que valen más que la palabra «pass».

El corpus son 2.718.207 bytes. Ese es el texto completo de prompts que la suite puede cargar: 2,72 MB, unos 679.552 tokens si una sesión los cargara todos alguna vez. Nunca lo hace, porque los skills se cargan de uno en uno, pero el techo importa cuando consideras qué instala --host auto.

El catálogo son 5.754 tokens frente a un techo de 7.000: el 82% usado. El catálogo es la parte que siempre está cargada —el nombre y la descripción de cada skill, que Claude Code lee para decidir a qué skill te referías—. Mi propio recuento de bytes de descripción dio 5.062 bytes ≈ 1.266 tokens en 64 archivos, frente a los 5.754 en 63 del test; la diferencia es lo que el test incluye más allá de la línea de descripción, y la discrepancia en el número de skills (63 rastreados frente a 64 presentes) es de esas cosas que solo notas contando de las dos maneras.

El ratio de crecimiento es 1,50, no 1,05, y el test explica por qué en sus propios comentarios. Citando el archivo: el ratio se «ajustó en la v1.52.0.0 (auditoría del límite de la catedral) de 1,05 a 1,50: un ratio del 5% saltaba con adiciones de funcionalidad legítimas», y «el relleno real es de 2 a 3 veces; esto lo detecta sin saltar por el alcance normal de una funcionalidad». También hay una válvula de escape: GSTACK_SIZE_BUDGET_RATIO cambia el ratio y GSTACK_SIZE_BUDGET_OVERRIDE_REASON permite que una regresión pase registrando el motivo en ~/.gstack/analytics/spend-overrides.jsonl.

Es un archivo de test inusualmente sincero. También te dice el estado honesto de la disciplina de tamaño de prompts: un prompt por skill puede crecer un 50% antes de que la puerta se queje, y al catálogo siempre cargado le quedan 1.246 tokens de margen. Ninguna de las dos cosas es un escándalo. Las dos son el tipo de número que quieres antes de decidir que una suite de 64 skills es gratis.

La disciplina de publicación no es la que recomienda el README

El README asocia el modo equipo con una promesa concreta: «sin deriva de versiones, sin actualizaciones manuales», porque el modo equipo «sigue el canal stable: la versión etiquetada dos veces por semana (lunes y jueves, como mucho una cada 72 horas…)». docs/releases.md confirma la cadencia y añade un detalle que demuestra reflexión real: de lunes a jueves hay exactamente 72 horas, de jueves a lunes 96, y las ejecuciones programadas (y solo esas) tienen 3 horas de gracia por los arranques tardíos del cron.

Esto es lo que existe en GitHub:

La cadencia es real: son lunes, jueves, lunes. La disciplina que hay detrás de los números no lo es. La última etiqueta estable está 122 versiones publicadas por detrás del archivo VERSION. VERSION dice 1.95.5.0; stable resuelve a v1.92.55.0. Entre ambas hay 29 parches de la línea 1.92, los 43 de la 1.93, los 45 de la 1.94 y seis de la 1.95.

Y la velocidad que crea esa brecha se ve en los recuentos mensuales del propio changelog:

797 entradas en 232 días son 3,44 versiones al día de media. Solo octubre fueron 11 al día; los primeros cuatro días de noviembre, 43 al día. La línea menor 1.91 carga 344 versiones de parche por sí sola, lo que significa que la cadena de versión ha dejado de codificar algo que un humano pueda razonar: 1.91.242.0 y 1.91.318.0 se diferencian en 76 publicaciones y tres días.

Para quien adopta la herramienta, la consecuencia concreta es esta: si sigues la recomendación del README y usas el modo equipo con required, quedas fijado a una etiqueta que tiene 122 entradas de changelog, en un proyecto que publica 43 versiones al día. Eso no es «sin deriva de versiones». Es una deriva más lenta y deliberada, con una cadencia documentada: algo razonable de querer, pero no lo que promete la frase. La lectura honesta: stable es un canal de seguridad, no un canal de actualidad, y si necesitas un arreglo que aterrizó ayer, vas a poner update_channel main y te vas a llevar las 122 entradas de golpe.

El número de herramientas lleva subiendo desde marzo

La descripción de GitHub sigue diciendo 23 herramientas con opinión. docs/why-gstack.md dice «veintitrés especialistas y ocho herramientas de potencia». Las tablas de comandos del README listan 54 filas y 55 comandos distintos, y el sistema de archivos tiene 64 directorios SKILL.md.

Los títulos de Hacker News conservan la deriva en público, y así fue como lo detecté:

Que crezca el número de herramientas es un buen problema. Un número obsoleto en el campo que todos los agregadores raspán es otro problema distinto: es la línea que aparece en los boletines, en la página de tendencias y en la tarjeta de GitHub que la gente captura. Si eliges gstack porque «23 herramientas» suena manejable, la superficie real que instalas son 64 skills, de los cuales 49 tienen su propio directorio sections/.

Qué compran 139.339 estrellas y qué no

A Hacker News nunca le entusiasmó este proyecto. El mejor envío —«Garry Tan’s Claude Code Setup», 2026-03-17— llegó a 74 puntos y 79 comentarios. Todo lo demás está en un dígito. Para un repositorio con 139.339 estrellas y 20.633 forks, es la misma disociación que encontré en la auditoría de Worktrunk: el canal de distribución no es Hacker News, y no hay razón para que lo sea. El flujo de trabajo de un presidente de YC publicado en X llega a más desarrolladores en una hora que una portada en un día.

Así que el recuento de estrellas se explica sin conspiración, y los números siguen diciendo lo que dicen. 766 personas quieren saber cuándo cambia esto. 20.633 quieren una copia que puedan modificar. Existen 1.110 ramas. 982 commits dicen que el autor es la única persona que escribe en main.

Lo cual nos lleva a la declaración que el proyecto hace sobre sí mismo, en su propia documentación, y que me parece el párrafo más interesante del repositorio. docs/why-gstack.md aborda la crítica de las líneas de código de frente:

«Los críticos del LOC no se equivocan en que los recuentos brutos de líneas se inflan con la IA. Se equivocan en que, normalizado por la inflación, yo sea menos productivo. Soy más productivo, y por mucho.»

y después:

«En cambio lógico de código —no LOC bruto, que la IA infla— mi ritmo de 2026 es unas 810 veces mi ritmo de 2013 (11.417 frente a 14 líneas lógicas al día).»

Es una concesión real, hecha antes de que llegue la crítica, y hay que tomarla al pie de la letra: el autor te está diciendo que las 689.039 líneas de TypeScript están infladas por la IA y que la métrica defendible es otra. Bien. Entonces la pregunta que de verdad tiene un lector es la que la documentación deja abierta: si el LOC bruto no es fiable, ¿cuál es la señal de calidad? La mejor respuesta disponible en el repositorio es el ratio de 1,59:1 entre test y código y el test de 5.209 líneas del generador de prompts. Esa es la afirmación que merece comprobarse, y la comprobé, y se sostiene.

Lo que la documentación no dice, y lo que no puedo verificar desde fuera: cuánto de esas 422.522 líneas de test es fixture redundante, si la métrica de «línea lógica» tiene un analizador publicado, y si alguna de las afirmaciones de productividad se traslada a un equipo de cinco personas en lugar de a una persona con un enjambre de agentes.

La nota de procedencia es mejor que la media

Hay un archivo más que merece atención porque es justo el tipo de cosa que se omite. NOTICE.md registra que partes de gstack derivan de trabajo de prompts de terceros: impeccable, de Paul Bakaus, bajo Apache-2.0, y ai-design-skills y redesign-skill, de Elaya, bajo MIT. La redacción es cuidadosa —«reescrito con la voz de gstack y modificado»— y el archivo señala que «reescribir no es una exención: los textos de licencia están en licenses/».

Es un proyecto siendo honesto sobre el hecho de que la ingeniería de prompts tiene linaje, y de que «todo es Markdown» a veces significa «todo es Markdown, parte de él derivado». Para un repositorio de este tamaño publicado por una figura pública, esa nota es la diferencia entre una auditoría limpia y una incómoda.

Qué hacer antes de instalarlo

Si te llevas una sola cosa de esto: gstack merece probarse, y no es gratis en el sentido que implica el README. Haz estas cinco comprobaciones en tu propia máquina primero; todas son baratas y tres son comandos del propio proyecto.

1. Mide el coste de arranque del comando que vas a usar de verdad. El archivo es el archivo: cuenta sus bytes más el preámbulo.

cd ~/.claude/skills/gstack
for s in review ship qa autoplan office-hours; do
  printf "%-14s %8s bytes\n" "$s" \
    "$(( $(wc -c < "$s/SKILL.md") + $(wc -c < "$s/sections/preamble.md" 2>/dev/null || echo 0) ))"
done

2. Comprueba en qué canal estás y cuánto va por detrás. Esa brecha decide si recibes un arreglo o no.

cd ~/.claude/skills/gstack
gstack-config get update_channel
git describe --tags --abbrev=0        # la etiqueta que ejecutas de verdad
cat VERSION                            # lo que dice main

3. Ejecuta la puerta y busca las exenciones. Un test de presupuesto que pasa con un registro de exenciones lleno no es lo mismo que un test de presupuesto que pasa.

bun test test/skill-size-budget.test.ts
cat ~/.gstack/analytics/spend-overrides.jsonl 2>/dev/null | wc -l

4. Lee un skill entero antes de fiarte de la suite. review/SKILL.md son 60.070 bytes: una hora de lectura. Si los pasos son puertas numeradas con las que puedes discutir, el sistema es ingeniería. Si son adjetivos, no lo es. A mí me llevó diez minutos encontrar la respuesta para /review.

5. Decide tu postura sobre ramas y actualizaciones a propósito. Con 1.110 ramas aguas arriba y 43 versiones al día, git pull en main dentro de ~/.claude/skills/gstack es un despliegue, no un refresco. Fija la versión y actualiza a propósito.

Preguntas frecuentes

¿gstack es gratis de verdad? Sí. Licencia MIT, sin nivel de pago, sin telemetría que bloquee funciones. El coste es contexto y atención: 22.396 bytes de preámbulo compartido en cada comando de nivel 2, hasta 20.948 tokens de arranque por skill y un corpus de 2,72 MB de prompts a los que confías moldear el comportamiento de tu agente.

¿«Todo es Markdown» es una mentira? Es una descripción del artefacto, no del repositorio. Los 64 archivos que aterrizan en tu directorio de skills son Markdown. Producirlos exige 689.039 líneas de TypeScript, 155 plantillas, 49 directorios de secciones y un test generador de 5.209 líneas. Llámalo suite de prompts compilada y la frase se vuelve precisa.

¿Por qué el recuento de estrellas no coincide con el interés en Hacker News? Porque Hacker News nunca fue el canal de distribución. El mejor envío llegó a 74 puntos; la audiencia del autor está en X. 766 watchers frente a 139.339 estrellas (0,55%) es bajo, pero no anómalo en el grupo comparable: Worktrunk está en 0,22%.

¿Es un problema que una sola persona haya escrito 929 de 982 commits? No por sí solo: es un flujo de trabajo personal publicado como plantilla, y el README te invita a bifurcarlo. Sí significa que no hay hoja de ruta sobre la que votar, ni contribuidor externo que haya revisado todo el sistema, ni expectativa de que un parche tuyo se fusione. Planifica una bifurcación interna desde el primer día.

¿Cuál es el mayor riesgo para un equipo? Las 122 versiones de retraso de la etiqueta a la que se ancla el modo equipo. No es un error; es el diseño. Pero si adoptas en una semana en la que un arreglo que necesitas está en el changelog y no en la etiqueta, estarás eligiendo entre estabilidad y el arreglo, sin versión intermedia donde aterrizar.

¿El presupuesto de tamaño me protege? Protege al proyecto de un crecimiento desbocado de prompts, y en mi clon pasó con 5 de 5. Pero el ratio por skill es 1,50, no 1,05 —un skill puede crecer un 50% antes de que la puerta salte— y GSTACK_SIZE_BUDGET_OVERRIDE_REASON permite a un mantenedor dejar pasar una regresión registrándola. Ejecuta el test tú mismo y cuenta el registro de exenciones.

¿Debería usarlo? Si eres un fundador técnico en solitario ejecutando agentes en paralelo y quieres un proceso estructurado del que robar, sí: lee /review y /office-hours y quédate con las listas de comprobación. Si sois un equipo de diez buscando una dependencia con soporte, bifurcad, fijad una etiqueta y presupuestad el coste de contexto por llamada. Las dos opciones son razonables. Ninguna es «gratis» en el sentido que quiere decir el README.

El número que hay que recordar

139.339 estrellas, 766 watchers, 1.110 ramas, 982 commits, 3 etiquetas, 797 versiones, 122 versiones de retraso, 689.039 líneas de TypeScript, 1.706.591 bytes de prompts, 20.616 tokens antes de que /review vea tu diff.

El proyecto no miente sobre lo que es. Describe la salida y deja que supongas que el resto es simple. La auditoría útil consiste en separar las dos cosas, y la buena noticia es que la parte que de verdad robarías —el procedimiento numerado de revisión con sus escaneos de puertas— es la parte que sobrevive intacta a los números.