Desenvolvimento Claude

O que Desenvolvimento Claude faz?

Visão Geral

Assuma a sequência de desenvolvimento da tarefa no Claude Code: implemente a mudança solicitada, execute suas verificações e, em seguida, obtenha revisão independente do Codex quando solicitado antes da entrega. Aplique-se tanto a solicitações em linguagem simples quanto a trabalhos iniciados por meio de outra skill. Trata-se de uma orquestração baseada em instruções; a seleção automática de skills e a conclusão não são garantias impostas pelo host.

Uso

Use /claude-development <tarefa> ou aplique a uma solicitação autorizada de desenvolvimento Claude, por exemplo: Corrija este bug e entregue a mudança verificada. Inclua alterações de configuração declarativas mesmo quando não precisam de TDD. Apenas planejamento, explicação e revisão não autorizam implementação.

Uma solicitação de implementação autoriza as correções locais necessárias para o resultado solicitado, incluindo correções limitadas do Codex para defeitos demonstrados nesse escopo. Preserve limites de usuário mais restritivos. Commits, pushes, publicação de PR, aprovações e merges mantêm seus requisitos de autorização existentes. Outras skills possuem suas etapas especializadas; esta skill define quando o desenvolvimento termina.

Etapas

1. Estabeleça a tarefa e os pré-requisitos. Leia instruções do repositório, estado atual do Git, fontes relevantes e ADRs. Identifique os requisitos, arquivos permitidos, alterações existentes e limites de verificação. Resolva apenas incógnitas materiais com requirements-clarification. Verifique se as verificações necessárias estão disponíveis. Se a revisão independente do Codex for solicitada, verifique code-review-fix e seu tempo de execução declarado antes dessa etapa. Mantenha as portas de revisão automática Stop desabilitadas; a ausência de ferramentas de revisão opcionais não bloqueia a implementação ou entrega comum.
2. Respeite o fluxo de trabalho envolvente. Para uma tarefa Linear, deixe linear-start e linear-workflow gerenciarem elegibilidade, branch, rastreador e estado do PR. Outros fluxos de trabalho especializados mantêm sua própria autoridade e limites. Quando esta tarefa repara um PR aberto, use o fluxo de trabalho pr-fix autorizado para reparo e revisão independente; não inicie um loop de reparo local concorrente. A implementação local comum permanece aqui mesmo quando nenhuma outra skill foi invocada.
3. Implemente o resultado definido. Preserve trabalho não relacionado. Aplique tdd para comportamento executável próprio e validação nativa ou existente para alterações declarativas. Use as skills de domínio relevantes sem transformar cada teste, chamada de ferramenta ou subtarefa em uma etapa de entrega separada. Registre o delta completo da tarefa e quaisquer alterações intencionalmente excluídas.
4. Execute as verificações relevantes. Indexe novos arquivos intencionais antes de formatação, lint e typecheck. Execute a barreira de repositório apropriada para a mudança real, com ambiente nomeado e limites. Verificações com falha são desenvolvimento inacabado, não permissão para enfraquecer asserções. Corrija apenas falhas autorizadas e mantenha evidências essenciais ausentes explícitas.
5. Execute a revisão independente solicitada uma vez. A revisão Codex é opcional; uma solicitação de implementação por si só não a exige. Quando o usuário solicitar revisão e correções limitadas, ative code-review-fix no delta local completo com requisitos, identidade do candidato e evidências brutas de verificação. Suspenda as gravações de Claude enquanto o fluxo de trabalho autorizado é executado. Uma solicitação apenas de revisão não autoriza correções e usa code-review. Não reinicie nenhuma das sequências dentro de uma correção delegada. Se pr-fix possui reparo e revisão, preserve seu escopo em vez de criar um segundo loop.
6. Entregue o resultado observado. Relate o candidato final, comportamento alterado, disposições de descobertas, verificações reais, ambiente e limites restantes. Uma revisão solicitada ausente, desatualizada ou incompleta permanece um limite explícito; uma revisão não solicitada não é um pré-requisito de entrega. Não diga que o desenvolvimento está concluído apenas porque o código foi escrito, as verificações passaram, um filho retornou ou uma tarefa foi marcada como concluída. Preserve quaisquer pontos de verificação de publicação e aprovação existentes no fluxo de trabalho envolvente.

Armadilhas

• Uma solicitação simples ignora skills especializadas — a verificação pode desaparecer; este fluxo de trabalho se aplica ao desenvolvimento Claude independentemente de como a tarefa começou.
• TDD se torna o fluxo de trabalho externo — um único teste verde encerra a entrega muito cedo; verifique a tarefa completa e realize qualquer revisão solicitada após a implementação e as verificações terminarem.
• Cada filho inicia a sequência de finalização — revisões recorrem e o contador de passagens é reiniciado; apenas o proprietário externo do desenvolvimento invoca a etapa final.
• Uma edição de configuração pula TDD — pular um teste de valor também pode pular a revisão por engano; use validação nativa e realize revisão independente quando solicitado.
• Um reparo de PR existente ganha um segundo loop — escritores concorrentes e vereditos divergem; mantenha o proprietário pr-fix e sua revisão independente final.

Restrições

• Nunca inicie implementação, reparo ou publicação a partir de uma solicitação de planejamento ou apenas revisão.
• Nunca relate uma revisão não realizada como concluída ou exija uma revisão Codex não solicitada.
• Nunca substitua limites de usuário ou expanda além do resultado solicitado e correções confirmadas.
• Nunca duplique o loop code-review-fix ou pr-fix dentro de uma correção delegada.
• Nunca ative uma porta de revisão Stop ou apresente seleção automática de skills como tecnicamente imposta.
• Nunca instale runtimes ausentes ou substitua evidências ausentes por um resultado de aparência bem-sucedida.