gener8v/gener8v.claude-skills.engineering

Comandos de desenvolvimento

1. Encontre os comandos

Use a primeira fonte que responder. Informe o comando antes de executá-lo.

1. Instruções do repositório: CLAUDE.md, CONTRIBUTING.md, README.md. Em um repositório de pipeline gener8v, .gener8v/context.md lista os comandos de verificação para cada repositório.
2. Executor de tarefas: Makefile, justfile, Taskfile.yml, scripts de package.json, seções de ferramentas de pyproject.toml, tox.ini, noxfile.py.
3. Workflow de CI: .github/workflows/*.yml. O que o CI executa define "os testes passam".
4. Padrão do ecossistema: resources/ecosystems.md.

Se o projeto for executado em contêineres (compose.yaml, docker-compose.yml, um dev container), execute os comandos dentro do contêiner da maneira que o projeto documenta. Consulte resources/ecosystems.md.

2. Execute

• Comece de forma restrita: um arquivo de teste ou um pacote. Em seguida, execute a suíte completa antes de relatar.
• Não inicie o modo watch. Muitos executores de teste observam por padrão. Use o formulário "executar uma vez" (resources/ecosystems.md).
• Mantenha o código de saída ao encurtar a saída:

  set -o pipefail
  <comando> 2>&1 | tail -n 60
  echo "exit=$?"
  

• Inicie um servidor de desenvolvimento em segundo plano. Aguarde até que sua URL responda. Pare-o quando terminar.

3. Leia o resultado

• O código de saída decide. Texto como "concluído" não significa sucesso.
• Conte. Relate os testes passados, falhos e ignorados. Ignorados, esperados para falhar e "nenhum teste coletado" não são passes.
• Testes instáveis. Execute um teste falho mais uma vez, sozinho. Se passar, relate como instável. Não o esconda.
• Falhas que já existiam antes. Verifique o branch base: a execução de CI mais recente (gh run list --branch <base> --limit 3) ou uma execução em uma worktree separada. Relate essas falhas como "já falhando em <base>". Não as use para justificar suas próprias falhas.
• Não enfraqueça um teste para fazê-lo passar. Se o teste estiver errado, diga o porquê e altere-o em um commit separado e visível.

4. Dados para trabalho de UI

Quando a UI precisar de dados realistas, siga resources/throwaway-data.md. A regra resumida: semeie apenas um banco de dados que você criou para essa finalidade. Nunca semeie o banco de dados real, padrão ou compartilhado do projeto.

5. Relate

Informe o comando, o código de saída, as contagens e o primeiro erro real de cada falha. Se você não executou algo (por exemplo, testes de ponta a ponta que precisam de credenciais), diga isso.

Skills relacionadas

• engineering:github-pr-merge e engineering:github-issue-workflow chamam esta skill antes de um PR.
• engineering:documentation-bootstrap a utiliza para encontrar os comandos que a documentação deve listar.