--- title: "Sistema de diseño para Claude Code: 4 piezas" canonical: https://wavect.io/es/blog/claude-code-design-system-files/ language: es description: "Crea un sistema de diseño para Claude Code con REFERENCE.md, CLAUDE.md, DESIGN.md y ejemplos. Incluye prompts, controles QA y un plan de adopción para equipos." image: "https://wavect.io/img/blog/headers/header_claude-code-design-system-files.png" --- [**Volver**](/es/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/es/team/kevin-riedl/) [Kevin Riedl](/es/team/kevin-riedl/) https://linkedin.com/in/wsdt 12 min de lectura · 2 de septiembre de 2026 Última revisión 2 de septiembre de 2026 [**Siguiente**](/es/blog/ai-coding-agents-context-not-intelligence/) # Sistema de diseño para Claude Code: 4 piezas para una UI de marca Resumen Un sistema de diseño para Claude Code puede vivir como un flujo de cuatro partes dentro del repositorio: REFERENCE.md registra evidencia visual y reglas de marca innegociables, CLAUDE.md indica a Claude cuándo cargar y comprobar esas reglas, DESIGN.md las traduce en tokens y decisiones de componentes listas para implementar, y examples/ conserva trabajos aprobados para reutilizarlos. Solo CLAUDE.md es un mecanismo nativo de Claude Code; los demás nombres son convenciones útiles del proyecto, no requisitos de Anthropic. Empieza con trabajo real, separa hechos observados de reglas elegidas, nombra los tokens por función, pide varias variantes y valida el resultado con capturas, accesibilidad y pruebas automatizadas. En equipos, asigna responsables, versiona los archivos y pilota el flujo con tareas representativas antes de estandarizarlo. **Un sistema de diseño para Claude Code es un stack de contexto dentro del repositorio que muestra al agente cómo es tu marca, cómo debe implementarla y cómo comprobar el resultado.** Una versión práctica utiliza tres archivos Markdown y un directorio `examples/`. Sustituye los prompts repetidos por evidencia, reglas y patrones aprobados que se pueden versionar. El flujo ganó visibilidad gracias al [sistema de marca en cuatro partes y los prompts de Charlie Hills](https://charliehills.substack.com/p/ai-design-system). Lo útil no es que los nombres de archivo sean mágicos. Es que la evidencia visual, las reglas de implementación y los controles de calidad se convierten en entradas duraderas del proyecto, en lugar de perderse en un chat. Esta guía convierte la idea en un flujo que un equipo de producto puede revisar, probar y mantener. Responde a la búsqueda específica **cómo hacer que Claude Code siga un sistema de diseño**. No compite con nuestro análisis general sobre [contexto para agentes de programación](/es/blog/ai-coding-agents-context-not-intelligence/) ni con la [checklist de software generado con IA](/es/blog/vibe-code-production-readiness-checklist/), enfocada en producción. ## ¿Cuáles son las cuatro piezas del sistema? | Pieza | Función | Qué contiene | Qué no contiene | | --- | --- | --- | --- | | `REFERENCE.md` | Evidencia | Colores, tipografía, espacios, uso del logo, layouts recurrentes y patrones prohibidos observados | Suposiciones sin verificar o código | | `CLAUDE.md` | Enrutamiento | Una instrucción breve para leer las fuentes antes de trabajar en UI y verificar después | Todo el manual de marca | | `DESIGN.md` | Contrato de implementación | Tokens semánticos, componentes, responsive, accesibilidad y decisiones | Un moodboard con adjetivos vagos | | `examples/` | Patrones aprobados | Pantallas o recursos representativos que tu equipo posee y puede reutilizar | Una colección de inspiración sin curar | En sentido estricto, son cuatro piezas y no cuatro archivos, porque la cuarta es un directorio. Solo `CLAUDE.md` tiene un significado especial para Claude Code. La [documentación oficial sobre memoria de Claude Code](https://code.claude.com/docs/en/memory) explica que los archivos `CLAUDE.md` del proyecto se cargan como instrucciones persistentes y recomienda que sean concretos, concisos y estructurados. `REFERENCE.md`, `DESIGN.md` y `examples/` funcionan porque indicas expresamente a Claude que los lea. ## ¿Cómo debe organizarse el proyecto? ``` tu-proyecto/ ├── CLAUDE.md ├── REFERENCE.md ├── DESIGN.md ├── examples/ │ ├── README.md │ ├── dashboard-aprobado.png │ ├── landing-aprobada.png │ └── pricing-card-aprobada.html ├── src/ └── tests/ ``` Añade a `examples/README.md` una fila por artefacto con responsable, fecha de aprobación, origen, partes reutilizables y excepciones conocidas. Así, una campaña antigua o una pantalla experimental no se convierte por accidente en regla permanente. ## Prompt 1: convertir trabajo aprobado en REFERENCE.md Elige entre tres y cinco ejemplos que representen bien la marca actual. Prioriza pantallas de producción propias, el brand deck, gráficos de marketing o la biblioteca de componentes. No copies al repositorio recursos protegidos de competidores. La inspiración puede orientar una decisión, pero los ejemplos reutilizables deben ser tuyos o tener una licencia adecuada. ``` Revisa todos los archivos de examples/. Separa lo observable de lo que debes preguntar. Redacta REFERENCE.md con: 1. inventario de fuentes y estado de aprobación 2. colores con valores medidos y funciones observadas 3. tipografía, tamaños y jerarquía 4. patrones de espaciado, grid y alineación 5. posición del logo y espacio de protección 6. componentes y composiciones recurrentes 7. cinco patrones que la marca debe evitar 8. preguntas abiertas No inventes valores que falten. Muestra el borrador antes de guardarlo. ``` El mejor resultado separa evidencia y política. “Las tres pantallas aprobadas usan 24 px entre tarjetas” es una observación. “Todos los grupos de tarjetas deben usar 24 px” es una regla que una persona debe aprobar. Mezclarlas convierte decisiones históricas accidentales en doctrina. ## Prompt 2: usar CLAUDE.md como router Mantén el puntero corto. Un archivo enorme consume contexto en cada sesión, aunque el material de diseño solo sea necesario al trabajar en la interfaz. ``` ## Trabajo de interfaz Antes de crear o cambiar una UI, lee REFERENCE.md y DESIGN.md. Después, inspecciona el ejemplo aprobado más cercano en examples/. Reutiliza componentes y tokens semánticos antes de crear otros. Si las fuentes se contradicen o no cubren una decisión importante, pregunta en lugar de adivinar. Antes de terminar, compara el resultado renderizado con las reglas y comunica cada excepción intencionada. ``` Esta capa indica cuándo leer, qué fuente tiene prioridad y cómo verificar. Si tu `CLAUDE.md` ya es largo, usa reglas limitadas a las rutas del frontend. Un import ordena mejor el contenido, pero la documentación de Anthropic aclara que el texto importado también entra en el contexto inicial. ## Prompt 3: convertir la referencia en DESIGN.md `DESIGN.md` es el contrato de construcción. El emergente [formato DESIGN.md de Google Labs](https://github.com/google-labs-code/design.md/blob/main/docs/spec.md) define un archivo autónomo con tokens opcionales y legibles por máquinas en el frontmatter YAML, más razonamiento de diseño en Markdown. Puedes seguirlo para ganar portabilidad, pero Claude Code no lo exige. ``` Lee REFERENCE.md y examples/README.md. Después, revisa todos los ejemplos aprobados. Redacta DESIGN.md como contrato de implementación con: 1. tokens de color semánticos nombrados por función 2. escalas tipográficas y de espacio con valores exactos 3. reglas de layout, grid y breakpoints 4. anatomía, estados y política de reutilización de componentes 5. interacción, movimiento y comportamiento reduced-motion 6. requisitos de accesibilidad 7. ejemplos responsive y casos límite 8. registro de decisiones con fecha, responsable y motivo Marca cada regla inferida y no aprobada. Pregunta cuando las fuentes discrepen. Muestra el archivo antes de guardarlo. ``` Los nombres basados en función sobreviven mejor a un rediseño. `color-text-primary` explica la intención; `dark-gray` solo describe el valor actual. Si los valores deben circular por herramientas de diseño y build, conserva además una fuente de tokens legible por máquinas. ## ¿Por qué importan más los ejemplos que un prompt largo? Las reglas muestran lo permitido. Los ejemplos aprobados enseñan proporción, densidad, jerarquía y composición funcionando juntas. Anthropic ofrece un consejo parecido para su producto separado Claude Design: la [guía oficial de configuración del sistema de diseño](https://support.claude.com/en/articles/14604397-set-up-your-design-system-in-claude-design) acepta repositorios, prototipos, presentaciones y recursos de marca, y recomienda aportar ejemplos reales, no solo especificaciones. Elige por cobertura y no por cantidad. Un dashboard denso, una página de marketing, un flujo con formularios y un estado móvil suelen enseñar más que cincuenta secciones hero casi iguales. ## ¿Debe DESIGN.md sustituir a los design tokens? **No. DESIGN.md explica la intención; un archivo de tokens ofrece un formato estricto para herramientas.** Utiliza ambos cuando los valores deban entrar en código, diseño y validación. El [formato estable del Design Tokens Community Group](https://www.designtokens.org/tr/2025.10/format/) define un modelo JSON para nombres, valores, tipos y metadatos. El archivo de tokens gobierna los valores exactos; DESIGN.md explica cuándo y por qué aplicarlos. ## ¿Cómo evitar que el sistema copie errores? 1. **Etiqueta cada fuente.** Aprobada, histórica, experimental o solo inspiración. 2. **Define precedencia.** Los tokens actuales ganan a una captura en valores exactos. Un componente revisado gana a un gráfico antiguo en comportamiento. 3. **Registra excepciones.** Si una campaña rompe el grid a propósito, anótalo en el manifiesto. 4. **Pide variantes.** Solicita tres alternativas antes de pulir. Elegir sigue siendo una decisión humana. 5. **Promociona solo lo revisado.** Añade el resultado a `examples/` después de aprobarlo, no al generarlo. ## ¿Qué debe comprobar el ciclo de validación? | Control | Método | Señal de fallo | | --- | --- | --- | | Uso de tokens | Lint de CSS o referencias del tema | Colores, espacios o tipografía hardcoded sin excepción aprobada | | Reutilización | Revisión de imports y estados renderizados | Aparece un componente casi duplicado | | Responsive | Capturas representativas de escritorio y móvil | Overflow, jerarquía rota o estados ausentes | | Accesibilidad | Controles automáticos, teclado y lector de pantalla | Fallos de contraste, foco, etiquetas, movimiento o interacción | | Coherencia visual | Comparación con el ejemplo aprobado más próximo | Desviación inexplicada en densidad, alineación, tipo o composición | | Corrección de producto | Pruebas de aceptación y revisión humana | La interfaz parece correcta, pero resuelve la tarea equivocada | No dejes que el agente que produce sea el único juez. Puede hacer la primera comparación. Después hacen falta controles deterministas y una persona con autoridad para aprobar. ## Archivos de Claude Code o Claude Design: ¿cuál conviene? | Necesidad | Flujo en repositorio | Claude Design | | --- | --- | --- | | Reglas versionadas junto al código | Muy adecuado | Puede requerir exportación o sincronización | | Componentes reales durante la implementación | Muy adecuado | Útil con el repositorio conectado | | Ideación visual con perfiles no técnicos | Requiere flujo de repositorio | Más adecuado | | Controles deterministas en CI | Muy adecuado | Ejecutarlos en el repositorio | | UI kit administrado para toda la organización | Debes construir la gobernanza | Diseñado para sistemas compartidos | ## ¿Cómo desplegarlo en un equipo? 1. **Selecciona trabajo representativo.** Incluye UI de producto, marketing y al menos un estado difícil. 2. **Redacta y revisa las fuentes.** Diseño es responsable de la verdad visual; ingeniería, de la viabilidad. 3. **Conecta el router.** Mantén `CLAUDE.md` corto y comprueba que Claude carga las fuentes. 4. **Pilota tres tareas.** Un componente nuevo, un cambio de pantalla y una reparación responsive. 5. **Mide el retrabajo.** Registra rondas de revisión, tokens no aprobados, duplicados, defectos de accesibilidad y primeras versiones aceptadas. 6. **Asigna mantenimiento.** Nombra responsables para tokens, componentes, ejemplos y decisiones. La decisión de compra no es “¿qué pack de prompts elegimos?”, sino “¿quién posee el contrato de diseño, cómo comprobamos su cumplimiento y qué cambios exigen aprobación?”. El servicio de [AI Enablement de Wavect](/es/services/ai-enablement/) ayuda a convertir el uso puntual de agentes en un flujo gobernado con contexto del repositorio, evaluaciones y gates de revisión. Si el producto generado ya necesita hardening, la [guía del prototipo vibe-coded a producción](/es/software-development-guide/vibe-coded-prototype-to-production/) ayuda a definir el siguiente paso. ## Preguntas frecuentes ### ¿Claude Code lee DESIGN.md automáticamente? No. Claude Code carga automáticamente los archivos de instrucciones CLAUDE.md compatibles. Indica allí cuándo debe leer DESIGN.md y REFERENCE.md, y compruébalo con la vista de memoria o una tarea observada. ### ¿DESIGN.md es un estándar oficial de Anthropic? No. Es una convención de proyecto y un formato abierto emergente de Google Labs. Claude Code puede utilizar cualquier archivo legible al que apunten tus instrucciones. ### ¿REFERENCE.md debe contener reglas u observaciones? Empieza con observaciones e identifica sus fuentes. Conviértelas en reglas obligatorias solo después de que una persona responsable las apruebe. Así evitas convertir patrones accidentales en política. ### ¿Cuántos ejemplos debo dar a Claude Code? Empieza con tres a cinco ejemplos aprobados que cubran problemas distintos. Añade otro solo si resuelve una ambigüedad recurrente. La cobertura y la procedencia importan más que el volumen. ### ¿Puede sustituir a una biblioteca de componentes? No. Los archivos explican decisiones y guían al agente. La coherencia en producción sigue dependiendo de componentes reutilizables, tokens legibles por máquinas, controles automáticos y responsabilidad humana. ## Límite de la investigación *Revisado el 2 de septiembre de 2026 con el flujo original, la documentación actual de memoria de Claude Code, la especificación DESIGN.md de Google Labs, la guía de Claude Design de Anthropic y el formato estable del Design Tokens Community Group. El comportamiento del producto y la disponibilidad beta pueden cambiar. No afirmamos una mejora cuantitativa porque no existe un benchmark independiente entre equipos para este flujo.* ## Reflexiones finales La ventaja duradera no es un prompt ingenioso. Es un sistema pequeño y revisable que separa evidencia, instrucciones, reglas de implementación y ejemplos aprobados. Empieza con trabajo en el que tu equipo ya confía. Haz visible la incertidumbre, mantén el enrutamiento corto y prueba el resultado renderizado. Claude puede conservar las reglas. Las personas siguen decidiendo si son buenas. ## También te puede gustar.. [**Los agentes de programación necesitan contexto, no más inteligencia** Por qué el contexto duradero del repositorio, las tareas enfocadas y la verificación independiente importan más allá del diseño visual.](/es/blog/ai-coding-agents-context-not-intelligence/) [**AI enablement frente a consultoría genérica de IA** Compara un flujo de implementación gobernado con un encargo solo estratégico.](/es/compare/ai-enablement-vs-generic-ai-consultancy/) Ingeniería de agentes ## Continúa por este clúster Agentes de código, MCP, contexto, evaluación y controles para automatización fiable. [Empieza por el artículo fundamental**Ingeniería de grafos para agentes de IA: ¿Cuándo compensa un knowledge graph?**](/es/blog/graph-engineering-ai-agents/) - [Obscura Browser: análisis, límites y uso en producción](/es/blog/obscura-rust-browser-ai-agents/) - [ChatGPT inicia sesión sin ver tu contraseña](/es/blog/chatgpt-cloud-browser-secure-login/) - [Harness de agentes de IA: la capa de fiabilidad alrededor del LLM](/es/blog/agent-harness-engineering/) - [Por qué las ediciones de agentes necesitan identidad semántica: SEMAPRAX en Rust](/es/blog/semantic-identity-rust-agent-edits/) - [LangChain Deep Agents: análisis del agent harness para producción](/es/blog/langchain-deep-agents-review/) [**Volver**](/es/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/es/team/kevin-riedl/) [Kevin Riedl](/es/team/kevin-riedl/) https://linkedin.com/in/wsdt 12 min de lectura · 2 de septiembre de 2026 Última revisión 2 de septiembre de 2026 [**Siguiente**](/es/blog/ai-coding-agents-context-not-intelligence/) ## Structured Data ```json { "@context": "https://schema.org", "@graph": [ { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ], "employee": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "founder": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "legalRepresentative": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "name": "Wavect GmbH", "subjectOf": { "@id": "https://wavect.io/verified-claims.json#dataset", "@type": "Dataset", "creator": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "description": "A machine-readable registry of quantitative and qualitative claims published by Wavect, with review dates, localized page appearances and public third-party citations where available.", "inLanguage": "en", "isAccessibleForFree": true, "license": "https://creativecommons.org/licenses/by/4.0/", "name": "Wavect verified publication claims", "url": "https://wavect.io/verified-claims.json" }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "sameAs": [ "https://www.wikidata.org/wiki/Q139796367", "https://www.linkedin.com/in/jocr77/", "https://github.com/jo-chris" ], "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/#website", "@type": "WebSite", "inLanguage": [ "en", "de", "es", "zh" ], "name": "Wavect", "potentialAction": { "@type": "SearchAction", "query-input": "required name=search_term_string", "target": { "@type": "EntryPoint", "urlTemplate": "https://wavect.io/search/?q={search_term_string}" } }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/es/blog/claude-code-design-system-files/#webpage", "@type": "WebPage", "dateModified": "2026-09-02", "inLanguage": "es", "isPartOf": { "@id": "https://wavect.io/#website", "@type": "WebSite" }, "lastReviewed": "2026-09-02", "url": "https://wavect.io/es/blog/claude-code-design-system-files/" } ] } ``` ```json { "@context": "https://schema.org", "@type": "BlogPosting", "abstract": "Un sistema de diseño para Claude Code puede vivir como un flujo de cuatro partes dentro del repositorio: REFERENCE.md registra evidencia visual y reglas de marca innegociables, CLAUDE.md indica a Claude cuándo cargar y comprobar esas reglas, DESIGN.md las traduce en tokens y decisiones de componentes listas para implementar, y examples/ conserva trabajos aprobados para reutilizarlos. Solo CLAUDE.md es un mecanismo nativo de Claude Code; los demás nombres son convenciones útiles del proyecto, no requisitos de Anthropic. Empieza con trabajo real, separa hechos observados de reglas elegidas, nombra los tokens por función, pide varias variantes y valida el resultado con capturas, accesibilidad y pruebas automatizadas. En equipos, asigna responsables, versiona los archivos y pilota el flujo con tareas representativas antes de estandarizarlo.", "articleBody": " Resumen del blog/IA y agentes/Ingeniería de agentes Sistema de diseño para Claude Code: 4 piezas para una UI de marca Resumen Un sistema de diseño para Claude Code puede vivir como un flujo de cuatro partes dentro del repositorio: REFERENCE.md registra evidencia visual y reglas de marca innegociables, CLAUDE.md indica a Claude cuándo cargar y comprobar esas reglas, DESIGN.md las traduce en tokens y decisiones de componentes listas para implementar, y examples/ conserva trabajos aprobados para reutilizarlos. Solo CLAUDE.md es un mecanismo nativo de Claude Code; los demás nombres son convenciones útiles del proyecto, no requisitos de Anthropic. Empieza con trabajo real, separa hechos observados de reglas elegidas, nombra los tokens por función, pide varias variantes y valida el resultado con capturas, accesibilidad y pruebas automatizadas. En equipos, asigna responsables, versiona los archivos y pilota el flujo con tareas representativas antes de estandarizarlo. Un sistema de diseño para Claude Code es un stack de contexto dentro del repositorio que muestra al agente cómo es tu marca, cómo debe implementarla y cómo comprobar el resultado. Una versión práctica utiliza tres archivos Markdown y un directorio examples/. Sustituye los prompts repetidos por evidencia, reglas y patrones aprobados que se pueden versionar. El flujo ganó visibilidad gracias al sistema de marca en cuatro partes y los prompts de Charlie Hills. Lo útil no es que los nombres de archivo sean mágicos. Es que la evidencia visual, las reglas de implementación y los controles de calidad se convierten en entradas duraderas del proyecto, en lugar de perderse en un chat. Esta guía convierte la idea en un flujo que un equipo de producto puede revisar, probar y mantener. Responde a la búsqueda específica cómo hacer que Claude Code siga un sistema de diseño. No compite con nuestro análisis general sobre contexto para agentes de programación ni con la checklist de software generado con IA, enfocada en producción. ¿Cuáles son las cuatro piezas del sistema? PiezaFunciónQué contieneQué no contiene REFERENCE.mdEvidenciaColores, tipografía, espacios, uso del logo, layouts recurrentes y patrones prohibidos observadosSuposiciones sin verificar o código CLAUDE.mdEnrutamientoUna instrucción breve para leer las fuentes antes de trabajar en UI y verificar despuésTodo el manual de marca DESIGN.mdContrato de implementaciónTokens semánticos, componentes, responsive, accesibilidad y decisionesUn moodboard con adjetivos vagos examples/Patrones aprobadosPantallas o recursos representativos que tu equipo posee y puede reutilizarUna colección de inspiración sin curar En sentido estricto, son cuatro piezas y no cuatro archivos, porque la cuarta es un directorio. Solo CLAUDE.md tiene un significado especial para Claude Code. La documentación oficial sobre memoria de Claude Code explica que los archivos CLAUDE.md del proyecto se cargan como instrucciones persistentes y recomienda que sean concretos, concisos y estructurados. REFERENCE.md, DESIGN.md y examples/ funcionan porque indicas expresamente a Claude que los lea. ¿Cómo debe organizarse el proyecto? tu-proyecto/ ├── CLAUDE.md ├── REFERENCE.md ├── DESIGN.md ├── examples/ │ ├── README.md │ ├── dashboard-aprobado.png │ ├── landing-aprobada.png │ └── pricing-card-aprobada.html ├── src/ └── tests/ Añade a examples/README.md una fila por artefacto con responsable, fecha de aprobación, origen, partes reutilizables y excepciones conocidas. Así, una campaña antigua o una pantalla experimental no se convierte por accidente en regla permanente. Prompt 1: convertir trabajo aprobado en REFERENCE.md Elige entre tres y cinco ejemplos que representen bien la marca actual. Prioriza pantallas de producción propias, el brand deck, gráficos de marketing o la biblioteca de componentes. No copies al repositorio recursos protegidos de competidores. La inspiración puede orientar una decisión, pero los ejemplos reutilizables deben ser tuyos o tener una licencia adecuada. Revisa todos los archivos de examples/. Separa lo observable de lo que debes preguntar. Redacta REFERENCE.md con: 1. inventario de fuentes y estado de aprobación 2. colores con valores medidos y funciones observadas 3. tipografía, tamaños y jerarquía 4. patrones de espaciado, grid y alineación 5. posición del logo y espacio de protección 6. componentes y composiciones recurrentes 7. cinco patrones que la marca debe evitar 8. preguntas abiertas No inventes valores que falten. Muestra el borrador antes de guardarlo. El mejor resultado separa evidencia y política. “Las tres pantallas aprobadas usan 24 px entre tarjetas” es una observación. “Todos los grupos de tarjetas deben usar 24 px” es una regla que una persona debe aprobar. Mezclarlas convierte decisiones históricas accidentales en doctrina. Prompt 2: usar CLAUDE.md como router Mantén el puntero corto. Un archivo enorme consume contexto en cada sesión, aunque el material de diseño solo sea necesario al trabajar en la", "articleSection": "Engineering", "author": { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/" }, "citation": [ { "@type": "WebPage", "name": "sistema de marca en cuatro partes y los prompts de Charlie Hills", "url": "https://charliehills.substack.com/p/ai-design-system" }, { "@type": "WebPage", "name": "documentación oficial sobre memoria de Claude Code", "url": "https://code.claude.com/docs/en/memory" }, { "@type": "WebPage", "name": "formato DESIGN.md de Google Labs", "url": "https://github.com/google-labs-code/design.md/blob/main/docs/spec.md" }, { "@type": "WebPage", "name": "guía oficial de configuración del sistema de diseño", "url": "https://support.claude.com/en/articles/14604397-set-up-your-design-system-in-claude-design" }, { "@type": "WebPage", "name": "formato estable del Design Tokens Community Group", "url": "https://www.designtokens.org/tr/2025.10/format/" } ], "dateModified": "2026-09-02", "datePublished": "2026-09-02", "description": "Un sistema de diseño para Claude Code puede vivir como un flujo de cuatro partes dentro del repositorio: REFERENCE.md registra evidencia visual y reglas de marca innegociables, CLAUDE.md indica a Claude cuándo cargar y comprobar esas reglas, DESIGN.md las traduce en tokens y decisiones de componentes listas para implementar, y examples/ conserva trabajos aprobados para reutilizarlos. Solo CLAUDE.md es un mecanismo nativo de Claude Code; los demás nombres son convenciones útiles del proyecto, no requisitos de Anthropic. Empieza con trabajo real, separa hechos observados de reglas elegidas, nombra los tokens por función, pide varias variantes y valida el resultado con capturas, accesibilidad y pruebas automatizadas. En equipos, asigna responsables, versiona los archivos y pilota el flujo con tareas representativas antes de estandarizarlo.", "headline": "Sistema de diseño para Claude Code: 4 piezas para una UI de marca", "image": "https://wavect.io/img/blog/headers/header_claude-code-design-system-files.svg", "inLanguage": "es", "keywords": "Ingeniería de IA, Sistemas de diseño", "mainEntityOfPage": { "@id": "https://wavect.io/es/blog/claude-code-design-system-files/", "@type": "WebPage" }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/es/blog/claude-code-design-system-files/", "wordCount": 2239 } ``` ```json { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "item": "https://wavect.io/es/", "name": "Inicio", "position": 1 }, { "@type": "ListItem", "item": "https://wavect.io/es/blog/overview/", "name": "Resumen del blog", "position": 2 }, { "@type": "ListItem", "item": "https://wavect.io/es/blog/topics/ai-agents/", "name": "IA y agentes", "position": 3 }, { "@type": "ListItem", "item": "https://wavect.io/es/blog/clusters/agent-engineering/", "name": "Ingeniería de agentes", "position": 4 }, { "@type": "ListItem", "item": "https://wavect.io/es/blog/claude-code-design-system-files/", "name": "Sistema de diseño para Claude Code: 4 piezas | ", "position": 5 } ] } ``` ```json { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "No. Claude Code carga automáticamente los archivos de instrucciones CLAUDE.md compatibles. Indica allí cuándo debe leer DESIGN.md y REFERENCE.md, y compruébalo con la vista de memoria o una tarea observada." }, "name": "¿Claude Code lee DESIGN.md automáticamente?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "No. Es una convención de proyecto y un formato abierto emergente de Google Labs. Claude Code puede utilizar cualquier archivo legible al que apunten tus instrucciones." }, "name": "¿DESIGN.md es un estándar oficial de Anthropic?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Empieza con observaciones e identifica sus fuentes. Conviértelas en reglas obligatorias solo después de que una persona responsable las apruebe. Así evitas convertir patrones accidentales en política." }, "name": "¿REFERENCE.md debe contener reglas u observaciones?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Empieza con tres a cinco ejemplos aprobados que cubran problemas distintos. Añade otro solo si resuelve una ambigüedad recurrente. La cobertura y la procedencia importan más que el volumen." }, "name": "¿Cuántos ejemplos debo dar a Claude Code?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "No. Los archivos explican decisiones y guían al agente. La coherencia en producción sigue dependiendo de componentes reutilizables, tokens legibles por máquinas, controles automáticos y responsabilidad humana." }, "name": "¿Puede sustituir a una biblioteca de componentes?" } ] } ```