kktbur/VibeCoding-Start

VibeCoding Start

Use esta Skill para dar ao Codex um sistema de engenharia leve desde a primeira sessão do projeto até o lançamento e observação. O resultado desejado é um projeto que uma sessão posterior possa entender, revisar, verificar, aceitar e continuar com segurança sem repetir todo o chat.

Primeira ação

Leia o AGENTS.md do projeto e siga esta ordem de Contexto Quente:

1. docs/INDEX.md
2. docs/CURRENT.md
3. docs/PRODUCT.md
4. docs/PRD.md
5. docs/ACCEPTANCE.md

Leia docs/CODEMAP.md, ADRs ativos, planos, registros de trabalho, padrões e evidências brutas locais apenas quando a tarefa precisar deles. Se o esqueleto de seis documentos estiver faltando, use o modo INIT da Skill complementar vibecoding-project-knowledge antes da implementação.

Limite de projeto inegociável

• Todo projeto recebe o mesmo esqueleto mínimo: AGENTS.md, docs/INDEX.md, PRODUCT.md, PRD.md, ACCEPTANCE.md, CURRENT.md e CODEMAP.md.
• A complexidade altera a profundidade do documento e a força do portão; não remove o esqueleto.
• PRODUCT.md explica o porquê, PRD.md explica o quê e ACCEPTANCE.md explica como provar. Não mescle silenciosamente essas responsabilidades.
• Atualize PRD.md quando a sessão alterar um requisito, recurso, não objetivo, restrição ou cenário de usuário significativo.
• Mantenha sessões brutas, logs, tentativas fracassadas, investigações e evidências localmente por padrão em .project-memory/. Promova apenas exemplos editados e intencionalmente selecionados para docs/examples/.
• Prefira capacidades existentes do projeto, a biblioteca padrão, SDKs/APIs/ferramentas oficiais, projetos open-source maduros, pacotes, adaptadores ou composição antes de infraestrutura personalizada.
• Não construa um banco de dados de memória, banco de dados vetorial, mecanismo de busca, estrutura de teste, estrutura de implantação, serviço de CI ou backend de observabilidade como parte deste fluxo de trabalho.

Portões de engenharia

Use o mesmo vocabulário para cada projeto enquanto dimensiona a profundidade conforme o risco:

G0 Escopo
→ G1 Intenção
→ G2 Reuso
→ G3 Plano
→ G4 Construção
→ G5 Revisão Adversarial
→ G6 Verificação
→ G7 Aceitação Humana
→ G8 Lançamento
→ G9 Observação

G0 Escopo

Classifique o trabalho como aplicação/produto, integração/adaptador ou infraestrutura/segurança/ambiente de execução. Quanto mais próximo da infraestrutura, mais fortes devem ser as evidências de reuso, revisão e recuperação.

G1 Intenção

Torne a cadeia explícita:

PRODUCT (Porquê) → PRD (O quê) → ACCEPTANCE (Como provar)

Registre o problema, usuários, estados atual e desejado, requisitos funcionais, não objetivos, restrições, aceitação e riscos antes da implementação.

G2 Reuso

Para qualquer capacidade geral não trivial, pesquise antes de construir e decida nesta ordem:

USAR → ADAPTAR → COMPOR → CONSTRUIR → PARAR

Se CONSTRUIR for selecionado, registre alternativas pesquisadas, caminhos de reuso rejeitados, responsabilidade de manutenção e o método de aceitação do proprietário em um ADR. A capacidade de um modelo escrever código não é evidência de que código personalizado seja a escolha certa.

G3 Plano

Divida o trabalho complexo em pequenos marcos com um ponto de verificação após cada marco. Pare e replaneje quando o escopo, arquitetura ou risco mudar materialmente.

G4 Construção

Mantenha a implementação pequena e reversível. Use o conjunto de ferramentas existente e evite abstrações, dependências e infraestrutura especulativas.

G5 Revisão Adversarial

Um revisor independente examina PRODUCT.md, PRD.md, ACCEPTANCE.md, decisões ativas, estrutura relevante, o diff e os testes. Procure por omissões, suposições erradas, regressões, capacidade duplicada, excesso de engenharia, riscos de segurança/dados, lacunas de teste e falhas de reversão. O autor não deve ser o revisor final para uma alteração importante.

G6 Verificação

Cubra caminhos normal, de erro, de limite, de entrada inválida, de regressão e de recuperação na proporção do risco. Relate evidência de máquina e uma explicação legível pelo proprietário; uma marca verde prova apenas o invariante que realmente verifica.

G7 Aceitação Humana

O proprietário confirma que o resultado é o produto pretendido e que seu comportamento observável é compreensível. Verificações automatizadas e revisão independente não substituem esta etapa.

G8 Lançamento

Registre a versão, o último estado conhecido bom, notas de lançamento, backup, método de reversão, risco de migração e destino exato do lançamento antes do uso real.

G9 Observação

Após o lançamento, observe a saúde e as evidências do usuário. Continue apenas quando saudável; pare e reverta ou avance quando a evidência mostrar um problema. Alimente o resultado de volta para testes, registro de trabalho, ADR, intenção do produto, aceitação ou uma post-mortem conforme apropriado.

Encerramento de conhecimento

Ao final de cada sessão substantiva, use o modo UPDATE da Skill complementar vibecoding-project-knowledge:

1. Preserve detalhes brutos da sessão e saídas grandes no diretório .project-memory/ local.
2. Selecione CURRENT.md e os documentos ativos relevantes.
3. Atualize CODEMAP.md quando a estrutura mudar.
4. Atualize PRD.md quando requisitos, recursos, não objetivos, restrições ou cenários de usuário mudarem.
5. Registre escolhas materiais em um ADR.
6. Atualize índices e o registro de trabalho.
7. Execute as auditorias determinísticas relevantes.

Não reivindique conclusão sem evidência de máquina, uma explicação legível por humanos e um método de aceitação do proprietário.

Referências

• Leia Standard v1.3 para as regras normativas e limite de lançamento.
• Leia a Skill complementar vibecoding-project-knowledge para procedimentos de INIT, UPDATE ou AUDIT.