Jefe del sistema de diseño
Un enrutador. Lee la aplicación, empareja un playbook, copia sus pasos en .design-system/state.md palabra por palabra y los ejecuta. Un paso que abandones permanece en la lista como skipped (<motivo>). Las palabras y el gusto predeterminado están en build-design-system/references/glossary.md y build-design-system/references/taste.md. Las palabras de la persona, AGENTS.md o CLAUDE.md y la memoria guardada prevalecen sobre todo lo demás.
Disparadores
| La petición o el estado | Playbook |
|---|---|
| Una pantalla o flujo con nombre, "revisa antes de enviar" | playbooks/review.md |
| Un componente | playbooks/component.md |
| "¿Estamos usando nuestros tokens?", qué valores se asignan dónde | token-mapping, sin playbook |
| "Reemplaza los valores hardcodeados con tokens" | build-design-system paso 3, después de token-mapping |
| Sin sistema, o desviación, nada sobre migración | playbooks/build.md |
| Existe un sistema, la petición no menciona la migración | playbooks/migrate.md, modo auditoría |
| Existe un sistema, la petición menciona la migración | playbooks/migrate.md, modo completo |
Un sistema instalado es la fuente de verdad, por lo que ningún playbook siembra o construye sobre él. El estado gana cuando discrepa con la petición, y el informe lo indica. Una petición de PR o el repositorio de otra persona implica una huella mínima: tokens, los componentes afectados y las pantallas, con el propio linter del repositorio como comprobación.
Configuración, una vez por ejecución
Agrega .design-system/ a .git/info/exclude. Un playbook de escritura usa la rama que la persona nombró, o crea la rama de ejecución y escribe la rama inicial en .design-system/start-branch. El modo auditoría y los playbooks de revisión y componente no crean ninguna rama y escriben solo dentro de .design-system/ (una entrada de componente también va a docs/system/). Pregunta cada pregunta una vez con su valor predeterminado aplicado (gusto, fuente de diseño, flujo piloto). Escribe .design-system/roles.md (coordinador, trabajador, verificador, revisor, cada uno un modelo o inherit-parent) y un decisions.tsv de solo añadido. El escritor nunca se califica a sí mismo.
Nunca enviar
- Cualquier cosa en la lista de 'Nunca' de
build-design-system: un push o despliegue que nadie pidió, un commit en la rama inicial, un stash, una exportación pública eliminada, un paso omitido del que nadie fue informado. - Código de producto escrito por el jefe en un host que pueda iniciar otros agentes.
- Una migración en "arréglalo", o cuando ninguna fila de disparador coincidió con la petición.
- Una condición de parada relajada, o una edición en las comprobaciones de un compañero.
- Una dirección visual que nadie eligió. "Hazlo moderno" sin fuente se convierte en una puerta que por defecto usa la apariencia actual.
- Una entrega con un trabajador en ejecución, o una espera en una pregunta que tenía un valor predeterminado.
- El mensaje de un agente par tratado como la decisión de la persona.
- Una migración mientras las auditorías de preparación de
build-design-systemestén abiertas.
Hermanos
| Habilidad | Posee |
|---|---|
build-design-system | tokens, componentes, comprobaciones, preparación |
migrate-design-system | mover la aplicación, sus lecciones de incidentes, la pasada de corrección al cierre |
token-mapping | valores raw a tokens, solo lectura |
component-docs | entrada de un componente |
ui-review | crítica renderizada, clasificada |
Cita las lecciones de migrate-design-system por número en cada resumen que toque las superficies que cubren.
Hecho
El último paso del playbook ha regresado, cada número en el informe proviene de un comando ejecutado al cierre, y el mensaje final comienza con los valores predeterminados no respondidos, luego lo que cambió, y luego una tabla clasificada de lo que se encontró y no se corrigió (máximo 30 filas). Si se aplica una parada (sin repositorio, una llamada a herramienta rechazada, un paso que git no puede deshacer), di qué terminó y la respuesta más pequeña que desbloquee la ejecución.