Frontend Project Bootstrap
Converte o protótipo UI/UX entregue em um "projeto frontend padronizado pela equipe + documentação preenchida + tarefas prontas para início". Isso garante que, posteriormente, diferentes pessoas e diferentes agentes de codificação escrevam código como se fosse a mesma pessoa.
Versão: veja a primeira entrada em CHANGELOG.md.
Princípios Centrais
- O protótipo é material de requisitos, não código a ser copiado para o projeto. Extraia dele telas, dados, paleta de cores e interações, sem copiar sua implementação; o arquivo original e as capturas de tela vão para o repositório como critério de aceitação.
- Os padrões da equipe são copiados na íntegra; o conteúdo do projeto é preenchido a partir do protótipo. O tratamento é diferente para esses dois tipos de arquivo (veja a "Tabela de Arquivos" abaixo).
- Em caso de dúvida, pergunte; não adivinhe. Faça perguntas em rodadas nos pontos de parada, cada pergunta com uma sugestão; "sim" significa aceitar a sugestão.
- Não implemente funcionalidades de negócio. Este Skill cria apenas a estrutura, páginas em branco e documentação; as funcionalidades de negócio serão desenvolvidas posteriormente pelo
/implementcom base nas tarefas. - Só é concluído com validação. lint, typecheck, test, build tudo verde, sem placeholders residuais, cada tela com sua captura.
Entradas Necessárias
- Protótipo (HTML único, HTML com múltiplas páginas, link de arquivo de design ou capturas de tela) com sua versão / data de entrega
- Nome do projeto e uma frase de descrição
- Localização da pasta do novo projeto (deve ser uma pasta vazia ou um novo repositório; se já tiver conteúdo, pare e confirme)
As demais informações (ambiente de deploy, situação do backend, idioma, modo escuro) são perguntadas na Etapa 1; detalhes em references/workflow-detail.md.
Preparação Inicial (uma vez por máquina)
cd <skill> && npm ci && npx playwright install chromium # Playwright e Prettier usados em scripts/; não entram no esqueleto do projeto
# Se já tiver Chromium na máquina, pode pular o download; ao rodar o script de captura, use CHROMIUM_EXECUTABLE=<caminho>
Fluxo
Crie uma lista de tarefas para acompanhar as cinco etapas abaixo. Marque cada etapa como concluída ao finalizar.
Etapa 1: Recepção
Primeiro, confirme se a pasta do projeto não existe ou está vazia (se tiver conteúdo, pare e pergunte). Em seguida, confirme o arquivo do protótipo, a versão e o local compartilhado pela equipe. Pergunte os itens da tabela da Etapa 1 em references/workflow-detail.md que ainda não foram fornecidos nas mensagens.
Etapa 2: Análise do Protótipo e Captura de Tela
Leia references/prototype-analysis.md, siga seu método de análise e produza docs/_bootstrap/prototype-analysis.md (formato: templates/prototype-analysis.md). Quando o protótipo for HTML, ao mesmo tempo coloque o arquivo original em docs/prototype/, preencha docs/prototype/screens.json (formato: templates/prototype-screens.json) e execute o script de captura para gerar um PNG de cada tela.
⏸ Ponto de Parada: De acordo com o "Ponto de Parada" em references/prototype-analysis.md, faça perguntas em rodadas: questões a confirmar, comportamento padrão para estados omissos, modo de roteamento (history / hash), situação do backend. Após receber as respostas, registre-as nas seções 11 e 12 do arquivo de análise antes de prosseguir.
Etapa 3: Criação do Esqueleto
Copie assets/skeleton/ (excluindo node_modules), execute npm ci, e então, conforme a Etapa 3 de references/workflow-detail.md, altere nome, paleta de cores, modo de roteamento, rotas e menu, páginas em branco, e códigos de permissão. Mantenha a funcionalidade de exemplo do Item até que a primeira funcionalidade real seja concluída.
Etapa 4: Geração de Documentação
Conforme a tabela de correspondência da Etapa 4 em references/workflow-detail.md, copie e preencha os templates. Todos os <!-- FILL: --> devem ser preenchidos conforme as instruções e os comentários removidos; todos os {{PLACEHOLDER}} devem ser substituídos. Quando não souber, escreva "a confirmar" – não invente.
Etapa 5: Validação, Commit e Relatório
npm run lint && npm run typecheck && npm test && npm run build
node <skill>/scripts/check-placeholders.mjs <project>
A etapa só é concluída quando todas as quatro verificações estiverem verdes (lint sem warnings) e o script de verificação não apresentar nenhum ERROR. Em seguida, faça o primeiro commit.
Formato do relatório: veja a Etapa 5 em references/workflow-detail.md.
Quando o usuário não estiver presente: adote as sugestões com resposta sugerida e marque como "Adotado (provisório)"; para itens sem sugestão, escreva "a confirmar". Ambos devem ser listados no relatório. A única situação que deve interromper o fluxo é quando a pasta do projeto já possui conteúdo.
Tabela de Arquivos
Copiados na Íntegra (apenas substituir o nome, sem alterar o conteúdo)
| Caminho | Copiar Para | Conteúdo |
|---|---|---|
assets/skeleton/ | Raiz do projeto | Esqueleto executável: configs, camada de API, hooks de dados, DataBoundary, permissões, i18n, theme, MSW, testes, CI (Azure DevOps), template de PR, funcionalidade exemplo Item |
references/standards/ | docs/conventions/ | 18 padrões de desenvolvimento da equipe + índice |
references/adr-baseline/ | docs/adr/ | ADR 0001–0016 + índice |
templates/agents/ | docs/agents/ | Configuração de tracker e domain docs do mattpocock skills (local markdown, single-context) |
Preenchidos a Partir do Protótipo
| Template | Saída |
|---|---|
templates/prototype-analysis.md | docs/_bootstrap/prototype-analysis.md |
templates/prototype-screens.json | docs/prototype/screens.json (entrada para o script de captura) |
templates/README.md, AGENTS.md, ARCHITECTURE.md, GLOSSARY.md | Raiz do projeto |
templates/CLAUDE.md | Raiz do projeto (arquivo de ponte do Claude Code: uma linha de comentário seguida de @AGENTS.md, copiado na íntegra) |
templates/prototype-README.md | docs/prototype/README.md |
templates/adr-router-mode.md | docs/adr/0017-router-mode.md |
templates/api-interface-auth.md, api-interface.md, api-checklist.md | docs/api/ |
templates/feature-spec.md | docs/specs/<feature>.md |
templates/task.md, tasks-README.md, task-remove-example.md | docs/tasks/ |
templates/adr.md, bug-report.md, etc. | Salvar uma cópia em docs/templates/ para uso futuro |
Documentação e Ferramentas
| Caminho | Quando Ler |
|---|---|
references/workflow-detail.md | Para cada etapa, com instruções e tabelas |
references/prototype-analysis.md | Etapa 2 |
scripts/screenshot-prototype.mjs | Etapa 2 (re-executar se o protótipo mudar) |
scripts/check-placeholders.mjs | Etapa 5 |
Integração com mattpocock skills
A saída deste Skill é a entrada direta para mattpocock/skills; o projeto não precisa executar /setup-matt-pocock-skills novamente (se executar, ele apenas atualizará ## Agent skills em AGENTS.md e docs/agents/; não permita que ele escreva em CLAUDE.md).
| Skill deles | Correspondência Aqui |
|---|---|
/grill-with-docs, grilling | O ponto de parada da Etapa 2 é o mesmo tipo de entrevista; use-o diretamente para mudanças de design futuras; termos vão para GLOSSARY.md, decisões para docs/adr/0018+ |
domain-modeling | Lê e escreve em GLOSSARY.md (mesmo formato) e docs/adr/ (formato da equipe, veja docs/agents/domain.md) |
/to-spec, /to-tickets | Não usar. As especificações já estão em docs/specs/ (Gherkin numerado), as tarefas já estão em docs/tasks/ (com caminhos de arquivo por camada e componentes reutilizáveis) |
/implement | Modo de implementação da primeira versão: uma docs/tasks/<ID>-*.md por vez, a partir do main branch criado pela tarefa; ele chamará tdd e code-review |
tdd | Seams já estão documentados em "Test seams" em AGENTS.md; não é necessário discutir novamente |
/implement-spec | Pode ser usado, mas não testado: cada worktree precisa de npm ci (husky prepare); Azure DevOps não tem integração com draft PR |
Compatibilidade com Ferramentas de Agente
AGENTS.md é a única fonte de regras. Opencode e Kimi Code CLI leem diretamente o AGENTS.md na raiz do projeto; Claude Code lê CLAUDE.md, por isso o esqueleto inclui um arquivo de ponte contendo apenas @AGENTS.md. Não escreva regras adicionais no arquivo de ponte.
Atualizando Este Skill
Se os padrões da equipe mudarem, altere este Skill (standards, adr-baseline, skeleton juntos), registre a mudança em CHANGELOG.md e aumente a versão; não faça alterações apenas em projetos individuais. Desvios em projetos específicos devem ser documentados como ADRs próprios do projeto (a partir de 0017).
Após modificar o skeleton, execute sempre lint, typecheck, test, build em assets/skeleton/; após modificar Markdown, execute npm run format.