project-bootstrap (inicialização de projeto)

Project Bootstrap (Inicialização de Projeto)

Um orquestrador enxuto. Esta skill não contém outras skills — ela carrega a skill certa na etapa certa, executa um script determinístico para criação de arquivos e preenche templates com as respostas do usuário. Se uma etapa abaixo conflitar com uma skill copiada, esta skill prevalece.

Regras de precedência — apenas na sessão de configuração

Esta ordenação se aplica apenas durante a sessão de configuração, enquanto esta skill estiver ativa. Quando instruções conflitarem durante a configuração, aplique nesta ordem:

1. Esta skill (project-bootstrap) — escopo de configuração, regras de segurança, regra de parada.
2. O próprio CLAUDE.md do projeto — conforme ele é criado.
3. A skill da stack — por exemplo, a skill SwiftUI ou de design para este tipo de projeto.
4. O checklist de fluxo de trabalho — references/workflow.md, o processo padrão.

Quando a configuração terminar, esta skill não estará mais ativa e a ordenação expira: o CLAUDE.md do projeto (mais seus documentos) é o único conjunto de instruções permanente para sessões futuras.

Nunca instale dois frameworks de fluxo de trabalho concorrentes (por exemplo, não instale tanto um framework pesado orientado a especificações quanto o checklist de fluxo de trabalho desta skill). Se o usuário nomear explicitamente um framework de fluxo de trabalho, use esse em vez do checklist padrão e registre a escolha em docs/SETUP.md.

Regras de segurança (nunca substituídas)

• Nunca escreva segredos, chaves de API ou tokens em nenhum arquivo gerado, e nunca coloque um segredo do lado do servidor (ex: segredo de API bancária) dentro de um aplicativo cliente.
• Nunca sobrescreva um arquivo existente sem a autorização do usuário (scripts/bootstrap.py recusa por padrão; --force é apenas opt-in, e com --force o script primeiro faz backup de cada arquivo para <nome-do-arquivo>.pre-bootstrap.bak).
• Apenas configuração: não comece a construir funcionalidades de produto nesta sessão.

Fluxo de Trabalho

Execute estas etapas em ordem. Não pule etapas.

1. Entrevista

Carregue references/interview.md. Faça suas perguntas uma de cada vez, e escreva cada resposta no documento relevante à medida que chegar — não armazene tudo na memória da conversa. Se o usuário responder várias perguntas de uma vez, registre cada resposta dada, marque essas perguntas como respondidas e continue a partir da primeira não respondida — nunca refaça uma pergunta já respondida. Pare de entrevistar quando toda pergunta tiver uma resposta ou o usuário explicitamente a adiar (registre itens adiados em docs/STATE.md).

2. Execute o script

A partir do diretório desta skill:

python3 scripts/bootstrap.py \
  --project-name "<nome da entrevista>" \
  --type <ios|web|python|generic> \
  --purpose "<propósito de uma linha da entrevista>" \
  --target <caminho para o repositório do projeto novo> \
  --allow-placeholders

--allow-placeholders é obrigatório aqui: neste estágio, os templates ainda contêm tokens de preenchimento {{...}} propositalmente (a Etapa 3 os preenche), então o script passa na verificação com um aviso de token por arquivo em vez de falhar. O diretório de destino já deve existir (o repositório do projeto novo); o script gera erro em destino ausente em vez de criar um caminho com erro de digitação — passe --create-target apenas se o usuário quiser explicitamente que o script crie esse diretório.

Isso cria os diretórios e renderiza os templates deterministicamente. Relate exatamente o que foi criado, pulado ou sobrescrito — nunca afirme que um arquivo existe se o script não o relatou.

3. Preencha os templates com as respostas da entrevista

Substitua os prompts de preenchimento restantes nos arquivos gerados pelas respostas reais: stack e comandos de build/teste em CLAUDE.md / AGENTS.md, escopo em docs/PRD.md, fases em docs/ROADMAP.md, termos do glossário em docs/CONTEXT.md. Mantenha CLAUDE.md curto — se passar de ~80 linhas, mova detalhes para docs/ e deixe um ponteiro.

4. Instale skills da stack — fixadas, leia antes de instalar

Carregue a referência para o tipo de projeto e instale apenas as skills que ela lista:

• iOS → references/ios.md
• Web → references/web.md
• Python / genérico → nenhuma skill de stack por padrão; anote essa escolha em SETUP.

Cada skill listada é fixada a um SHA de commit exato na tabela de skills fixadas da referência. Instalar significa: clonar o repositório em .claude/skills/ do projeto e, em seguida, git checkout o SHA fixado — nunca instale a partir de uma branch móvel e nunca aumente um pin sem registrar o novo SHA.

Leia antes de instalar é obrigatório. Após clonar, antes que a instalação seja considerada completa, para cada skill:

1. Leia seu SKILL.md por completo (e observe qualquer outra coisa que ela carregue por padrão).
2. Escreva um resumo de 2 a 3 linhas: quais instruções esta skill carregará em sessões futuras.
3. Sinalize qualquer coisa que peça acesso à rede, uso de credenciais ou comandos destrutivos. Mostre sinalizações ao usuário; não instale silenciosamente uma skill que peça qualquer um desses sem a autorização do usuário.

Registre em docs/SETUP.md, por skill: nome, URL de origem exata, SHA fixado, data de instalação e o resumo da leitura. Não copie o conteúdo de uma skill para CLAUDE.md — a skill permanece uma unidade carregável separada.

5. Defina a regra de fluxo de trabalho

Escreva o loop padrão de references/workflow.md em CLAUDE.md se ainda não estiver lá: especificação → plano → construção → revisão separada, uma fase por sessão nova, docs/STATE.md atualizado ao final de cada sessão.

6. Verifique — verificação nova, não a saída da Etapa 2

Execute a verificação agora, nova, no modo --verify (ele lê o destino como está atualmente e não modifica nada):

python3 scripts/bootstrap.py --verify --target <caminho para o repositório do projeto>

Não reutilize a saída da execução da Etapa 2 — essa execução é anterior ao preenchimento da Etapa 3 e às instalações da Etapa 4. Não adicione --allow-placeholders ao comando de verificação — o script rejeita essa combinação imediatamente, porque a verificação deve ser executada em arquivos preenchidos. --verify falha em qualquer token de preenchimento remanescente nos arquivos gerados: se falhar em tokens, a Etapa 3 não foi concluída — volte, preencha os tokens restantes e execute novamente --verify até passar. --verify também verifica conteúdo, não apenas tokens: a lista de fora de escopo do PRD deve ser não vazia e docs/SETUP.md deve registrar um SHA fixado para cada skill instalada (ou dizer que nenhuma skill de stack foi instalada). Também:

• Confirme se .gitignore cobre segredos para esta stack.
• Confirme se o app vazio/modelo do projeto ainda compila com o comando de build registrado em CLAUDE.md (se um comando de build existir ainda).
• Releia docs/SETUP.md: cada skill instalada deve estar listada com sua URL de origem, SHA fixado, data de instalação e resumo da leitura.

7. Faça commit

Um commit, nada mais:

chore: configuração inicial do projeto

Inclua apenas os arquivos de configuração. Se a identidade do usuário git ou um remote não estiver configurado, informe e deixe o commit para o usuário — não invente nenhum dos dois.

8. Pare

Mostre ao usuário a árvore de arquivos criada e a Fase 1 de docs/ROADMAP.md. Em seguida, pare. Não comece a Fase 1, não construa uma funcionalidade e não se ofereça para "apenas iniciar o esqueleto" — a próxima fase pertence a uma sessão nova (veja references/workflow.md).

Válvula de escape: pare a menos que o usuário instrua explicitamente você a continuar. Se ele instruir, recomende — uma vez — que a Fase 1 ainda aconteça em uma sessão nova, depois obedeça ao usuário e continue.

Arquivos de referência — carregue sob demanda

Arquivo	Carregue quando
references/interview.md	Sempre — Etapa 1.
references/ios.md	O tipo de projeto é ios.
references/web.md	O tipo de projeto é web.
references/workflow.md	Etapa 5, e qualquer sessão futura trabalhando em um repositório inicializado.