Sistema de design boss (Capataz)
Um roteador. Leia o app, combine um playbook, copie seus passos para .design-system/state.md palavra por palavra e execute-os. Um passo que você abandonar permanece na lista como skipped (<motivo>). Palavras e gosto padrão estão em build-design-system/references/glossary.md e build-design-system/references/taste.md. As palavras da pessoa, AGENTS.md ou CLAUDE.md e a memória salva vencem tudo aqui.
Gatilhos
| A solicitação ou o estado | Playbook |
|---|---|
| Uma tela ou fluxo nomeado, "verifique antes de eu enviar" | playbooks/review.md |
| Um componente | playbooks/component.md |
| "Estamos usando nossos tokens?", quais valores mapeiam onde | token-mapping, sem playbook |
| "Substitua os valores codificados por tokens" | build-design-system passo 3, após token-mapping |
| Nenhum sistema, ou deriva, nada sobre migração | playbooks/build.md |
| Um sistema existe, a solicitação não nomeia a migração | playbooks/migrate.md, modo auditoria |
| Um sistema existe, a solicitação nomeia a migração | playbooks/migrate.md, modo completo |
Um sistema instalado é a fonte da verdade, portanto nenhum playbook o semeia ou constrói sobre ele. O estado vence quando discorda da solicitação, e o relatório informa isso. Uma solicitação de PR ou outro repositório alheio significa uma pegada mínima: tokens, os componentes tocados e as telas, com o próprio lint do repositório como verificação.
Configuração, uma vez por execução
Adicione .design-system/ ao .git/info/exclude. Um playbook de escrita usa o branch que a pessoa nomeou, ou cria o branch de execução e escreve o branch inicial em .design-system/start-branch. Modo auditoria e os playbooks de revisão e componente não criam branch algum e escrevem apenas dentro de .design-system/ (uma entrada de componente também vai para docs/system/). Faça cada pergunta uma vez com seu padrão aplicado (gosto, fonte de design, fluxo piloto). Escreva .design-system/roles.md (coordenador, trabalhador, verificador, revisor, cada um um modelo ou inherit-parent) e um decisions.tsv somente anexado. O escritor nunca se avalia.
Nunca enviar
- Qualquer coisa na lista de Nunca de
build-design-system: um push ou deploy que ninguém pediu, um commit no branch inicial, um stash, uma exportação pública deletada, um passo ignorado do qual ninguém foi informado. - Código de produto escrito pelo capataz em um host que pode iniciar outros agentes.
- Uma migração em "conserta isso", ou quando nenhuma linha de gatilho correspondeu à solicitação.
- Uma condição de parada afrouxada, ou uma edição nas verificações de um irmão.
- Uma direção visual que ninguém escolheu. "Torne-o moderno" sem fonte torna-se um portão com valor padrão para a aparência atual.
- Uma devolução com um trabalhador rodando, ou uma espera por uma pergunta que tinha um padrão.
- A mensagem de um agente par tratada como decisão da pessoa.
- Uma migração enquanto as auditorias de prontidão de
build-design-systemestiverem abertas.
Irmãos
| Skill | É dono de |
|---|---|
build-design-system | tokens, componentes, verificações, prontidão |
migrate-design-system | mover o app, suas lições de incidentes, a passagem de correção no fechamento |
token-mapping | valores brutos para tokens, somente leitura |
component-docs | a entrada de um componente |
ui-review | crítica renderizada, ranqueada |
Cite as lições de migrate-design-system por número em todo resumo que tocar nas superfícies que elas cobrem.
Pronto
O último passo do playbook retornou, todo número no relatório vem de um comando executado no fechamento, e a mensagem final abre com padrões não respondidos, depois o que mudou, depois uma tabela ranqueada do que foi encontrado e não corrigido (no máximo 30 linhas). Se uma parada se aplicar (nenhum repositório, uma chamada de ferramenta recusada, um passo que o git não pode desfazer), diga o que terminou e a menor resposta que desbloqueia a execução.