Abrí dos repos en GitHub: al-grano y brand-guide-kit, y por qué el resto sigue privado

Casi todo lo que construyo para la agencia lo hago con Claude Code y Codex, y casi todo se queda privado. No por secreto: la mayoría de esas herramientas cargan datos de clientes, rutas de mi computadora o reglas que solo tienen sentido en mi forma de trabajar. Si las abro así, le sirven a nadie y exponen a alguien.

Pero de vez en cuando una herramienta deja de depender de todo eso. Funciona igual en la computadora de otra persona, no trae nada de un cliente y la puedo explicar en un párrafo. Esa la abro. Hoy son dos, y en este post te cuento qué hace cada una, a quién le sirve, cómo la pruebas y qué reviso antes de abrir la próxima.

Por qué abro algunos y otros no

El 22 de octubre conté los repos de la organización de SVDIGINET en GitHub con gh repo list svdiginet: 11 repos, 2 públicos. Los otros 9 son privados por una de tres razones: tienen material de un cliente, dependen de mi configuración personal, o todavía no les escribí la documentación que necesita alguien que no soy yo.

La tercera razón es la más común y la más honesta. Un repo que solo yo entiendo no es una herramienta pública, es mi desorden con la puerta abierta. Antes de abrir uno tiene que poder contestar tres preguntas en el README: qué hace, qué no hace y cómo lo pruebas sin pedirme ayuda.

Cómo lo conté: gh repo list svdiginet --json name,visibility,stargazerCount, corrido el 22 oct 2026. Las estrellas que cito más abajo salen de esa misma salida. Mi cuenta personal tiene sus propios repos públicos, pero no son herramientas de la agencia y no entran aquí.

al-grano: respuestas que van al punto

Qué es. Un estilo de respuesta para tu asistente de código (Claude Code o Codex). Le dice que conteste primero y explique después, que quite el relleno, que numere los pasos y que cierre una tarea en 10 líneas o menos. El código, los comandos y los mensajes de error se quedan tal cual.

Por qué lo hice. Leo respuestas de IA todo el día. Cuando cada una empieza con «buena pregunta» y termina con un resumen de lo que acabo de leer, pierdo minutos buscando la línea que importa. Lo escribí el 18 de septiembre para mí. Este mismo post lo armé con al-grano activo.

A quién le sirve. A quien usa un agente de código a diario y quiere menos texto que leer sin perder sustancia técnica. Funciona en español y en inglés: contesta en el idioma en que le hablas.

Así cambia una respuesta. Es el ejemplo del README, escrito por nosotros:

Buena pregunta. Hay varias cosas pasando con tu build. El paso que falla probablemente es el type check, aunque también podría ser el lint o un cache viejo. Podrías limpiar el cache, volver a correrlo, y si eso no funciona revisar el tsconfig. ¡Espero que eso te ayude a avanzar!

Build falla en el type check: flag strict en tsconfig.json.
1. Arregla los 3 errores que lista (o pon "strict": false).
2. Corre npm run build.

Aparte: el cache está viejo. ¿Lo limpio después?

Cómo funciona por dentro. Son dos hooks. Uno corre al abrir la sesión y carga las reglas completas; el otro corre en cada mensaje tuyo y deja un recordatorio corto, para que el estilo sobreviva cuando la conversación se compacta. Los corrí con una configuración de Claude vacía para medir cuánto texto meten:

    1037

AL-GRANO MODE ACTIVE. Answer first (command/path/decision on line 1). Drop dead words. ...

(nada: la bandera se borró y el siguiente mensaje ya no lleva recordatorio)

Eso es el costo real: unas 1,037 palabras al abrir la sesión y 33 palabras por cada mensaje. A cambio, las respuestas salen más cortas. No he medido cuánto más cortas en mis sesiones, así que no te doy un porcentaje. Según el repo, si los hooks fallan, no bloquean nada: la sesión abre normal, sin el estilo.

Cómo lo pruebas.

1. Clona el repo en una carpeta tuya.
2. Sigue INSTALL.md: en Claude Code van dos hooks en ~/.claude/settings.json; en Codex apuntas tu AGENTS.md al archivo skills/al-grano/SKILL.md.
3. Abre una sesión nueva y pide algo normal. Para apagarlo, escribe para al-grano, stop al-grano o normal mode.

github.com/svdiginet/al-grano →

A fondo: las 11 reglas de al-grano, cuánto contexto cuesta y cómo instalarlo en Claude Code y Codex.

brand-guide-kit: la marca, con evidencia

Qué es. Un kit para escribir guías de marca y auditar los archivos que hay detrás: el logo en SVG, los colores y el texto de la marca. Trae un estándar, plantillas (guía, auditoría y especificación 3D), una skill para Claude Code y Codex, y dos scripts en Python sin dependencias externas.

Lo hice porque en la agencia entregamos marcas a diseñadores, a imprentas y a quien construye la web. El problema nunca es la guía en PDF; es que tres meses después alguien usa un logo con un color cambiado o una fuente que nadie aprobó, y nadie lo nota. Quería una forma de decir «este archivo es el aprobado» y comprobarlo con un comando. Por eso le sirve a agencias, diseñadores independientes y equipos que le pasan una marca a otra persona y necesitan que llegue igual. También a quien usa un agente de IA para hacer piezas de marca y quiere que el agente revise contra reglas escritas, no contra lo que recuerda.

Cómo funciona. Cada marca lleva un archivo brand.json con sus colores y sus archivos aprobados, cada uno con su huella SHA-256. El auditor compara: si alguien cambió un byte del logo, o metió en el CSS un color que no está en la paleta, lo marca. Lo corrí sobre la marca de prueba que trae el repo (ficticia a propósito):

VERIFIED: mark.svg: File exists
VERIFIED: mark.svg: SHA256 matches declared baseline
VERIFIED: mark.svg: Explicit fill attributes match
VERIFIED: site.css: Hex literals use declared palette (not a computed-style audit)
UNKNOWN: visual: No visual fidelity, small-size, contrast, 3D or physical production certification
exit=2

Ran 14 tests in 0.150s

OK

La línea que más me gusta es la última del auditor: UNKNOWN. El kit no dice que tu marca se ve bien. Dice qué pudo comprobar (los bytes, los colores declarados) y qué no puede comprobar un script (cómo se ve a tamaño pequeño, el contraste, una pieza impresa). Por eso sale con código 2 a propósito: si lo metes en una automatización, tienes que decidir tú qué hacer con lo que no se pudo verificar, en vez de que pase en silencio.

Lo que no hace, y el README lo dice: no genera logos, no confirma que una marca esté libre para registrar (trademark clearance) y no reemplaza una prueba física de impresión.

Cómo lo pruebas.

1. Clona el repo. Solo necesitas Python 3.
2. Corre python3 scripts/brand.py audit demos/sample-brand/brand.json y lee las cinco líneas.
3. Copia demos/sample-brand/brand.json al lado de los archivos de tu marca, cambia los colores y los archivos, y vuelve a correr el auditor. No pongas un brand.json privado dentro de un repo público.

github.com/svdiginet/brand-guide-kit →

A fondo: las 9 puertas de brand-guide-kit, el contrato brand.json y qué significa cada resultado.

Los dos, lado a lado

Si solo vas a probar uno, esta tabla te ayuda a escoger:

Lo que reviso antes de abrir un repo

Para este post volví a pasar los dos por la lista que uso antes de abrir un repo. La comparto porque sirve para cualquier repo, tuyo o de tu agencia:

1. Nada de un cliente. Ni nombres, ni logos, ni notas. Por eso la marca de prueba de brand-guide-kit es inventada y lo dice en su propio nombre.
2. Nada de mi computadora. Ni llaves, ni tokens, ni rutas que solo existen en mi Mac. Reviso el historial completo, no solo la última versión, porque un secreto borrado sigue en un commit viejo. El 22 de octubre corrí gitleaks sobre todo el historial de los dos: cero hallazgos.
3. Una licencia escogida. Los dos son MIT. Sin licencia, un repo público se puede leer pero no se puede usar con tranquilidad.
4. Un README que dice qué no hace. Es lo que más confianza da, y lo que más se olvida.
5. Una prueba que corre sola. brand-guide-kit trae 14 tests y un chequeo de su propia documentación; al-grano se prueba con los comandos de arriba.
6. Un archivo SECURITY.md. Dice cómo avisarnos si alguien encuentra un problema. Los dos lo tienen.

Si un repo falla en el primer o el segundo punto, no se abre, aunque el código esté bien. Los demás se arreglan en una tarde.

Lo que todavía no sé

• Cuánta gente los usa. Una estrella cada uno no dice nada todavía, y no tengo otra métrica.
• Cuánto más cortas salen mis respuestas con al-grano. Lo siento en el día a día, pero no lo he medido.
• Qué repo abro después. Tengo otros en revisión con la lista de arriba; saldrán cuando la pasen completa.

Si pruebas alguno y algo no funciona, abre un issue en GitHub. Es la forma más rápida de que lo arregle, y la única manera de que sepa que alguien lo usa.

Si quieres esto en tu negocio

Estos repos salen del trabajo diario de SVDIGINET, mi agencia de marketing local en Central Florida: perfiles de Google, reseñas, webs y automatizaciones para negocios de aquí. Si prefieres que lo hagamos nosotros en vez de clonar un repo, la información está en svdiginet.com. Y si quieres la historia de por qué existe la agencia, está en este post.

Fuentes: github.com/svdiginet, consultado el 22 oct 2026; al-grano; brand-guide-kit