Una guía de marca bonita no prueba nada. La guía dice qué logo usar, qué colores y qué fuente; los archivos que circulan después pueden decir otra cosa, y nadie lo compara. El PDF se aprueba una vez. Los archivos cambian cada vez que alguien los toca.
brand-guide-kit es lo que armé para eso. Es el segundo de los dos repos que la agencia tiene abiertos en GitHub. En el post de los repos públicos lo presenté en una sección. Aquí va completo: qué produce, las reglas que usa para decir «esto está listo», cómo correrlo, cómo se ve un resultado y lo que todavía no puede comprobar.
El problema que resuelve
Una marca pasa por muchas manos: diseñadores, imprentas, quien construye la web. El problema casi nunca es la guía. Pasa así: alguien exporta el logo otra vez desde un archivo viejo, alguien mete en el CSS un color «parecido», alguien usa una fuente que no estaba aprobada. Cada cambio es pequeño y nadie lo ve hasta que ya está impreso o publicado.
El resumen del producto en el repo lo dice en una línea: las páginas de una guía pueden no coincidir con los archivos reales. La promesa del kit es poner evidencia donde antes había confianza: qué archivo es el aprobado, cómo lo compruebas y qué no se pudo comprobar. Lo creé el 19 de octubre, y el 20 escogí la licencia MIT para que cualquiera lo use.
Qué produce
El kit no hace logos. Produce documentos y una revisión de archivos:
| Pieza | Qué te da |
|---|---|
| templates/brand-guide.md | La guía de la marca en 9 secciones: intención, identidad, tipografía, uso a tamaños pequeños, color, íconos, versión 3D, aplicaciones y entrega. |
| templates/audit.md | La auditoría: una fila por puerta, cada una marcada VERIFIED, MISSING o UNKNOWN, con la evidencia exacta y el arreglo. |
| templates/3d-spec.md | La especificación para una versión en 3D del logo, sacada de un solo modelo con sus parámetros anotados. |
| scripts/brand.py | El auditor y el exportador. Compara tus archivos contra un contrato (brand.json) y copia solo los SVG aprobados. |
| skills/brand-guide-kit | Una skill para Claude Code y Codex que trabaja con las mismas reglas, sin una copia aparte. |
Todo está en Markdown y en Python sin dependencias externas. No hay servicio, no hay cuenta, no hay nada que se actualice solo.
Las 9 puertas antes de entregar
El corazón del kit es docs/brand-system-standard.md: nueve puertas que una marca tiene que pasar antes de decir que está lista. Las escribí tomando principios de las guías públicas de cinco marcas grandes (Dropbox, IBM, Atlassian, Spotify y Slack), pero los criterios son nuestros y el archivo lo dice: no se copian sus medidas, colores ni íconos.
| # | Puerta | Lo que pide |
|---|---|---|
| 1 | Fidelidad | Una referencia aprobada y un archivo maestro; todo lo demás sale de ahí |
| 2 | Tipografía portátil | El logo final en trazos, no dependiendo de una fuente instalada |
| 3 | Tamaños pequeños | Revisarlo a 16, 24, 32, 48 y 64 px en fondo claro, oscuro y un solo color |
| 4 | Color y contraste | Valores numéricos y prueba física para impresión y bordado |
| 5 | Íconos | Rejilla, grosor de línea, tamaños y estados definidos |
| 6 | 3D | Todas las vistas de un mismo modelo, con sus parámetros |
| 7 | Aplicaciones | Medidas reales en ropa, web e impresión; un mockup no es prueba |
| 8 | Integridad de la guía | Lo escrito coincide con lo que se ve en el PDF final |
| 9 | Gobierno | Cada archivo con dueño, versión, estado y uso |
Cada puerta termina en una de tres palabras. VERIFIED: lo revisé y aquí está la evidencia. MISSING: falta, y así lo busqué. UNKNOWN: no se ha comprobado. La tercera es la que más importa: una aprobación que nadie confirmó se queda en UNKNOWN, no se asume.
El contrato: brand.json
Para la parte que sí se puede revisar con un script, cada marca lleva un archivo brand.json al lado de sus archivos. Este es el de la marca de prueba que trae el repo, inventada a propósito:
demos/sample-brand/brand.json
{
"schema_version": 1,
"name": "Sample Frame (fictional test fixture)",
"colors": { "accent": "#F5C518", "ink": "#0A0A0A" },
"assets": [
{
"path": "mark.svg",
"approval": "approved",
"sha256": "bd607e14873f6170e6dd4fb22ae52348c77908ee9ee32db6b84bc9a9dadba62b",
"expected_fills": ["#F5C518", "#0A0A0A"]
}
],
"css_files": ["site.css"]
}Lo que declara: dos colores, un logo (mark.svg) marcado como aprobado, su huella SHA-256 (un número que cambia si cambia un solo byte del archivo), los dos colores de relleno que debe tener ese SVG y la hoja de estilos que se revisa contra la paleta. La aprobación la declaras tú; el script no la puede probar, y la documentación lo dice.
Cómo correrlo
Solo necesitas Python 3. Desde la carpeta del repo:
- Clona el repo: git clone https://github.com/svdiginet/brand-guide-kit ~/brand-guide-kit.
- Audita la marca de prueba: python3 scripts/brand.py audit demos/sample-brand/brand.json. Si lo vas a usar en una automatización, añade --json.
- Corre las pruebas: python3 -m unittest discover -s tests.
- Para tu marca, copia ese brand.json a la carpeta de tus archivos, cambia nombre, colores y rutas, y calcula la huella de tu logo con shasum -a 256 tu-logo.svg. Ese archivo no va dentro del repo público.
- Cuando todo pase, exporta los SVG aprobados a una carpeta nueva: python3 scripts/brand.py export ruta/brand.json carpeta-nueva. Copia los bytes originales; si la carpeta ya existe, se niega.
Cómo se ve un resultado
Así salió la marca de prueba el 22 de octubre:
Bash(python3 scripts/brand.py audit demos/sample-brand/brand.json)
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
Bash(python3 -m unittest discover -s tests)
Ran 14 tests in 0.150s OK
Cuatro líneas verificadas y una que no. La última siempre sale: un script no puede decirte si el logo se ve bien a 16 píxeles, si el contraste aguanta o cómo sale en tela. Por eso el código de salida es 2 y no 0. Los códigos están escritos en docs/brand-contract.md: 0 si no hay nada pendiente, 1 si falta algo o no coincide, 2 si solo quedan cosas sin comprobar, 3 si el contrato o la ruta están mal.
Un detalle que vi leyendo el código: la línea visual se añade siempre, así que una auditoría nunca devuelve 0. Lo mejor que puedes recibir es un 2. Si lo pones en una automatización, tienes que aceptar el 2 a propósito y fallar con el 1 o el 3, no esconder el error.
¿Qué pasa cuando algo cambia? Las pruebas del repo lo cubren. Esta tabla sale de tests/test_brand.py y de las reglas del auditor:
| Si alguien... | El auditor dice | Salida |
|---|---|---|
| Reemplaza el logo por otro archivo | MISSING: Integrity mismatch against declared baseline | 1 |
| Pone en el CSS un color fuera de la paleta | MISSING: Hex literals outside palette: #445566 | 1 |
| Usa un color por nombre (red) en el CSS | UNKNOWN: Non-hex values may exist; no full CSS parser or variable resolution | 2 |
| Edita el logo y le deja texto vivo | UNKNOWN: Live SVG text requires font portability and visual verification | 1 (la huella ya no coincide); 2 si el SVG aprobado ya traía texto |
| Apunta a un archivo fuera de la carpeta | ERROR en la salida de errores, no audita nada | 3 |
Lo que no hace, y el README lo dice: no compara imágenes, no calcula el estilo final de una página, no revisa accesibilidad, no genera logos, no confirma que una marca se pueda registrar y no reemplaza una prueba impresa.
Con Claude Code o Codex
La skill es la misma para las dos herramientas. Se instala con dos enlaces simbólicos a la carpeta del repo, como dice el README. Si la carpeta de la skill ya existe en alguno de los dos lugares, revísala antes: no sobrescribas una instalación que ya tengas.
terminal
mkdir -p ~/.claude/skills ~/.codex/skills ln -s ~/brand-guide-kit/skills/brand-guide-kit ~/.claude/skills/brand-guide-kit ln -s ~/brand-guide-kit/skills/brand-guide-kit ~/.codex/skills/brand-guide-kit
Con eso, cuando le pides al agente que revise o arme una guía, sigue un orden fijo: primero revisa lo que ya existe y marca cada hallazgo como VERIFIED, MISSING o UNKNOWN; después propone cambios pequeños; no altera un logo para que sea más fácil de calcar; y no publica ni cambia una marca en vivo sin tu permiso. Si le falta una referencia, pregunta en vez de inventarla.
Esa última regla es la que más me importa. Un agente que no tiene reglas escritas rellena los huecos con lo que cree recordar. Con la skill, el hueco se queda en UNKNOWN y te lo dice.
Para quién es, y para quién no
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 revise contra reglas escritas.
No es para ti si buscas un generador de logos, una plataforma con usuarios o un sello que diga «marca aprobada». El kit no certifica nada. Te dice qué está comprobado, qué falta y qué nadie ha revisado todavía.
Lo que todavía no sé
- Cómo se comporta con una marca real publicada. El roadmap tiene ese punto abierto: documentar un ejemplo aprobado y con derechos claros antes de anunciar resultados de producción. Por eso aquí solo ves la marca de prueba.
- Si vale la pena comparar imágenes y revisar el estilo calculado de una página. El roadmap lo deja fuera de la versión 0.2 a propósito.
- Cuánta gente lo usa. Tiene una estrella al 22 de octubre y no tengo otra métrica.
Si lo pruebas con tu marca y algo no cuadra, abre un issue en el repo. Sin datos de tu marca: describe el caso y el mensaje del auditor.
github.com/svdiginet/brand-guide-kit
Lee también: los dos repos públicos de SVDIGINET y lo que reviso antes de abrir uno.
Si quieres esto en tu negocio
brand-guide-kit sale del trabajo 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 revisemos tu marca nosotros, la información está en svdiginet.com.
Fuentes: github.com/svdiginet/brand-guide-kit, leído el 22 oct 2026; docs/brand-system-standard.md; docs/brand-contract.md
