Crear un DESIGN.md aprobado por el propietario para Claude Code

Un agente de programación con IA solo puede seguir una referencia visual en la medida en que sus decisiones estén definidas. Si el proyecto es tuyo y ya tienes reglas de marca aprobadas, puedes reunirlas en un archivo DESIGN.md que se pueda revisar y después usar Claude Code para dos pequeños cambios que inspeccionarás personalmente. El entregable es tu especificación aprobada. Los dos cambios comprueban si resultó útil para esas piezas concretas; no permiten determinar cómo saldrá un cambio posterior.

Este procedimiento se basa en documentación. BIG CHANGE revisó una colección de archivos de diseño fijada a una revisión y los manuales de Claude Code de Anthropic el 20 de octubre de 2026. No ejecutamos Claude Code, modificamos ni renderizamos las dos piezas, ni medimos el coste o la calidad del diseño.

El cambio principal

• Qué cambió: El propietario puede redactar una especificación visual con versiones a partir de decisiones aprobadas y entregar ese archivo exacto a Claude Code antes de un cambio acotado.
• Por qué importa: Una única fuente comprobada permite comparar las reglas de color, tipografía y composición con dos revisiones reales, mientras el propietario decide si acepta cada resultado.
• Qué vigilar: El archivo debe leerse completo antes de cada cambio. Su presencia en el proyecto, la mención de una ruta o la afirmación de Claude no demuestran que se haya cargado o seguido.

Antes de empezar

Necesitas un proyecto propio, permiso para editarlo, dos piezas pequeñas ya existentes que puedas renderizar y una copia de trabajo o punto de control de versiones recuperable. Pueden ser dos páginas o una página y una presentación, siempre que conozcas el proceso real de edición y renderizado de cada proyecto. Elige un cambio visual limitado para cada una. Conserva los textos actuales, enlaces e interacciones funcionales para compararlos.

Reúne los valores de color aprobados por el propietario y sus funciones, las fuentes con licencia o permitidas y sus alternativas, las reglas de uso de logotipos e imágenes, el público destinatario, las dimensiones y los requisitos de accesibilidad. Utiliza el registro real de aprobación o pide al propietario que resuelva las decisiones pendientes. El sitio público de una empresa o el análisis de diseño de otra persona no autoriza valores ni recursos para tu proyecto. Aprobar un recurso tampoco autoriza automáticamente su envío a un proveedor de modelos.

Configura Claude Code con una cuenta o proveedor apto y revisa las condiciones de uso de datos y los permisos de herramientas de la cuenta antes de exponer código, textos o recursos privados. Un proyecto almacenado localmente puede enviar contenido a un servicio de modelos. Comprueba quién puede ver el material, qué herramientas pueden leer o modificar archivos y si puedes enviar cada elemento. Las indicaciones de costes dependen de la cuenta y el proveedor; esta guía no puede asignar un precio fijo a tu sesión.

La colección Awesome DESIGN.md fijada a una revisión es una inspiración opcional para las secciones del archivo. Analiza sitios públicos; no es un manual de marca aprobado por el propietario. Puedes escribir el archivo directamente a partir de tus decisiones aprobadas. Si copias texto del repositorio, conserva su aviso de derechos de autor y permiso MIT. Ese aviso no concede derechos sobre las marcas, archivos de fuentes o imágenes de otro sitio.

Crear la referencia aprobada por el propietario

1. Crea brand-reference/DESIGN.md en tu proyecto. Rellena este esquema mínimo con el registro de aprobación. El texto entre corchetes identifica la información que debe aportar el propietario; no propone una marca. Mantén un elemento marcado como UNRESOLVED hasta que el propietario lo decida. No pidas a Claude que invente un valor para rellenar un vacío.

# Visual specification

Owner: [owner or approving role]
Approved version/date: [version and approval date, or UNRESOLVED]
Audience and artifact purpose: [owner-approved description]
Approval evidence: [internal record or location, without private data in a shared copy]

## Color roles and values
- Background: [approved value and color format, or UNRESOLVED]
- Text: [approved value and color format, or UNRESOLVED]
- Primary action: [approved value and color format, or UNRESOLVED]
- Link, border and status roles: [each approved value, or UNRESOLVED]

## Typography and scale
- Heading family and permitted fallback: [approved names, or UNRESOLVED]
- Body family and permitted fallback: [approved names, or UNRESOLVED]
- Heading/body sizes, weights and line heights: [approved scale, or UNRESOLVED]
- Font license or use restriction: [approved terms, or UNRESOLVED]

## Spacing and layout
- Spacing scale, content width and grid: [approved values, or UNRESOLVED]
- Target artifact dimensions: [approved sizes, or UNRESOLVED]

## Components and states
- Buttons, links, inputs and navigation: [approved appearance and behavior]
- Hover, focus, disabled and error states: [approved rules, or UNRESOLVED]

## Responsive and accessibility rules
- Desktop/phone behavior and breakpoints: [approved rules, or UNRESOLVED]
- Contrast, readable type, focus order and touch use: [approved requirements]

## Assets and forbidden substitutions
- Permitted logo/image assets and usage: [approved paths and permissions]
- Do not substitute: [owner-approved prohibited colors, fonts, marks or patterns]

## Owner approval and changes
- Approved by: [person or role and date, or UNRESOLVED]
- Version: [version]
- Changelog: [date, change, approver]
- Unresolved decisions: [list, or "none" after owner review]

2. Comprueba cada línea completada frente a las decisiones originales del propietario, incluidos los derechos de uso de fuentes e imágenes. Resuelve con él los conflictos entre los estilos antiguos del proyecto y las reglas aprobadas actuales. Pide que apruebe este archivo exacto y registra su versión. Detén cualquier cambio que dependa de un valor sin resolver. Guarda el archivo aprobado y las dos piezas iniciales en el control de versiones o en otra copia recuperable.

Usar el archivo en dos cambios acotados

3. En tu proyecto, inicia una sesión de Claude Code con la cuenta y los permisos comprobados. Indica las rutas exactas de brand-reference/DESIGN.md y de la primera pieza. Pide primero a Claude que lea toda la referencia y la pieza y se detenga antes de editar. Revisa el resultado real de lectura o de la herramienta para verificar la ruta y el contenido completo. Una lectura denegada, un resultado truncado, la mera mención de la ruta o un resumen verbal no bastan. Anthropic documenta los archivos de instrucciones del proyecto como una opción de configuración independiente; no supongas que cualquier DESIGN.md se descubre automáticamente ni confíes en que una referencia @ se comporte igual en todas las versiones.
4. Cuando la lectura completa sea visible, solicita el único cambio visual elegido para la primera pieza utilizando solo las reglas aprobadas. Limita los archivos afectados; conserva textos, enlaces, controles y código ajeno al cambio. Pide ver las diferencias propuestas y el método establecido del proyecto para renderizar la pieza. Inspecciona cada archivo modificado antes de aceptarlo. Rechaza colores, fuentes, recursos, dependencias o cambios adicionales no aprobados.
5. Renderiza la primera pieza mediante su proceso real de proyecto. Compara el resultado con el archivo aprobado y la pieza inicial en tamaños de ordenador y móvil adecuados para ese proyecto. Comprueba los valores de los tokens en los archivos modificados, el contraste legible, la jerarquía de títulos y tipografía, recortes o desbordamiento horizontal, foco visible, teclado e interacciones afectadas, y que los textos y enlaces sigan iguales. Registra la versión de referencia, la revisión de la pieza, las comprobaciones y las correcciones. Describir un renderizado no equivale a verlo.
6. Para la segunda pieza, indica de nuevo su ruta exacta y brand-reference/DESIGN.md. Solicita una nueva lectura completa antes de editarla e inspecciona el resultado de la herramienta. Después solicita un cambio acotado, revisa las diferencias, renderiza con el proceso propio de la segunda pieza y repite las mismas comprobaciones. Compara ambas revisiones con la misma versión del archivo aprobado. Registra cada regla como cumplida, incumplida o pendiente de una revisión aprobada por el propietario; corrige las desviaciones y vuelve a comprobar ambas piezas si cambia la referencia.

El trabajo termina con la especificación aprobada y versionada, dos revisiones inspeccionadas y renderizadas y un breve registro de las reglas cumplidas o incumplidas. Conserva las revisiones originales para poder volver atrás. Si falla una lectura, comprueba la ruta exacta, los permisos y el tamaño del archivo o un posible truncamiento antes de pedir un cambio. Si la especificación entra en conflicto con los estilos o la accesibilidad del proyecto, consigue la decisión del propietario y reduce el alcance. Si una pieza no se puede renderizar o una interacción no se puede comprobar, deja el cambio sin aceptar hasta poder verificarlo. Los cambios futuros de marca requieren una nueva revisión deliberada de los resultados anteriores.

Para una tarea distinta que usa un archivo comunitario como referencia para una página, consulta nuestra guía de DESIGN.md fijado a una revisión. Aquí el trabajo consiste primero en crear y aprobar tu propia especificación.

Fuentes y lecturas adicionales

• El README de Awesome DESIGN.md fijado a una revisión ofrece secciones de ejemplo y describe sus archivos como análisis de sitios públicos entregados tal cual. Sus afirmaciones sobre calidad no constituyen un resultado probado aquí. La licencia MIT regula el material copiado del repositorio, no la identidad ni los recursos de terceros.
• La guía de inicio de Anthropic explica la configuración de cuenta y proyecto. Sus flujos de trabajo habituales y su manual de memoria del proyecto describen los procesos de archivos e instrucciones; ninguno prueba que este archivo independiente se haya leído completo en la sesión del lector.
• Los manuales de Anthropic sobre permisos, uso de datos y costes explican los controles y las condiciones según la cuenta. No demuestran una edición observada, procesamiento exclusivamente local, una factura fija ni una mejora de calidad para esta guía.