Design: $ARGUMENTS
Siga cada etapa de docs/design-process.md — esse arquivo é a regra; esta skill apenas organiza o trabalho. Se houver conflito, prevalece o arquivo.
- Precisa de design? — Compare com a tabela do tópico 1 de
docs/design-process.md- Não: Justifique em uma linha e volte a usar
new-feature - Não tem certeza: Pergunte primeiro
- Não: Justifique em uma linha e volte a usar
- Iniciar (tópico 3.0): issue épica (label
design), branchdocs/<id>-design-<slug>, copiedocs/design/template.md→docs/design/<slug>.md(system.mdou<número da épica>-<slug>.md), definastatus: drafte adicione uma linha emdocs/design/README.md - Leia antes de perguntar:
CONTEXT.md,docs/adr/,docs/architecture.md, outro design emdocs/design/— fatos que você pode descobrir sozinho, pesquise por conta própria; não pergunte - Entreviste em rodadas (tópico 3.1) no formato
Qn — Tópico: Pergunta+Sugestão: …em cada item, 1–2 casos de borda por rodada — percorra os ramos A–H (tópico 3.2) completamente e aguarde a pessoa nos pontos de aprovação 1, 2 (sistema), 3 - Escreva no arquivo após cada rodada: tópicos no arquivo de design, novas palavras em
CONTEXT.md, ADRproposedemdocs/adr/(+ índice), diagramas C4 emdocs/architecture.mdse contêineres/sistemas externos mudarem - Verifique (tópico 3.3):
make docs-checkdeve passar (repositório sem esse target no Makefile:python3 <caminho do web-template>/scripts/check-docs.py <repo>— time Hermes:/home/opc/projects/web-template) + checklist manual, depois definastatus: proposed - PR exclusivo de documentação:
docs(design): <slug>, corpo comRefs #<epic>, resumo das alternativas ainda abertas e tópico## CHANGELOGcomo-— sem código, sem merge - Aprovação (tópico 3.4): quando a pessoa aprovar, commit com
status: approved+approved-by+ ADR comoacceptedno mesmo PR (make docs-checkdeve passar), então a pessoa faz o merge - Após o merge (tópico 3.5): abra issues filhas conforme o tópico 13, uma por vez, cada uma linkando a épica e o arquivo de design — o trabalho de código começa com
new-feature