steve-swanson/execute-work

Executar Trabalho

Execute o trabalho acordado autonomamente em um branch significativo a partir do develop. Delegue a implementação a subagentes em worktrees separados e, em seguida, faça o fast-forward dos branches concluídos para o branch coordenador, limpe e abra um pull request pronto para revisão a partir do branch coordenador concluído no develop.

A invocação autoriza branches de tarefa locais, worktrees, commits, rebase de seus próprios branches de tarefa não publicados, merges fast-forward no branch coordenador, remoção de worktrees e branches de tarefa limpos e totalmente integrados, envio do branch coordenador concluído e criação de seu PR no develop. Prossiga sem outra confirmação para essas ações. Siga o escopo do usuário e as instruções do repositório, incluindo uma substituição explícita de apenas local ou sem PR. Fazer merge do PR e implantação estão fora da autorização desta skill. Mantenha quaisquer proibições existentes em vigor.

1. Preparar o branch coordenador

Leia o plano acordado, o AGENTS.md aplicável e a orientação do projeto necessária. Se o trabalho já estiver definido, execute-o sem outra rodada de design ou aprovação. Faça apenas uma pergunta focada para um requisito ausente material.

Inspecione o status, as referências e os worktrees existentes. Preserve edições e checkouts não relacionados; não os redefina, esconda ou redirecione. Busque o develop do seu remote configurado quando disponível e use esse ponto obtido. Se a busca estiver indisponível, divulgue a limitação e use uma referência develop local existente; se nenhum existir, pergunte pela base. Nunca substitua silenciosamente por outro branch.

Antes de criar qualquer branch ou worktree, capture git worktree list --porcelain, nomes de branches locais e anexos de worktree gerenciados quando disponíveis. Mantenha um inventário de propriedade da execução na lista de verificação da tarefa: branch, caminho absoluto, proprietário/agente, tipo de gerenciamento e identidade, commit final e status de limpeza. Inclua toda tarefa, auxiliar, revisor, repetição e checkout de agente descendente criado para esta execução, mesmo se abandonado ou sem alterações. O coordenador é responsável pela limpeza de todo este inventário. Preserve branches e worktrees pré-existentes e não relacionados; um prefixo de nome correspondente não é prova de propriedade.

Crie um worktree e branch coordenador dedicados. Nomeie-o com o estilo de Branch Convencional, <tipo>/<descrição-curta>, minúsculo com hífens, como feat/store-invitation-recovery. Escolha o tipo que se adequa ao trabalho: feat (novo comportamento), fix (correção de bug), refactor, perf, docs, test, chore (ferramentas ou manutenção) ou ci. Se o usuário ou repositório nomear uma convenção diferente (por exemplo, em AGENTS.md), siga essa. Não inclua integration em seu nome. Registre o commit base do coordenador. Em uma invocação retomada, reutilize o branch/worktree e inventário do coordenador desta execução, inspecionando seu estado em vez de começar do zero.

2. Dividir e delegar

Divida por entregável e propriedade de arquivo. Execute tarefas independentes em simultâneo dentro da capacidade de agente disponível; sequencie dependências e edições sobrepostas. Crie cada branch/worktree de tarefa a partir do ponto atual do branch coordenador. Após uma dependência ser integrada, inicie as tarefas dependentes a partir do ponto atualizado.

Gere subagentes reais com os requisitos da tarefa, seções de plano relevantes, caminho absoluto do worktree, branch, arquivos de propriedade, contratos de dependência, critérios de aceitação e verificações necessárias. Cada agente trabalha apenas em seu checkout atribuído, faz commit de suas alterações e relata seu commit, verificações, preocupações restantes e quaisquer branches/worktrees adicionais que criou. Registre-os no inventário de gestão da execução imediatamente. O coordenador sozinho integra e remove worktrees. Os subagentes não devem invocar recursivamente esta skill de orquestração ou enviar seus branches. Use diretórios de trabalho explícitos ou git -C; os agentes podem compartilhar um diretório padrão. Se a delegação não estiver disponível, relate essa limitação em vez de substituir silenciosamente por execução solo.

3. Revisar tarefas concluídas

Inspecione o diff real de cada tarefa e os commits em relação aos seus critérios de aceitação. Aborde as falhas com o agente proprietário. Exija um checkout de tarefa limpo, commits concluídos e verificações relevantes aprovadas antes da integração; relate bloqueadores pré-existentes ou ambientais com precisão. Não faça merge do trabalho apenas porque um agente relata conclusão.

4. Integrar serialmente com merges fast-forward

Pare as gravações em um branch de tarefa concluído antes de fazer rebase dele. Para cada tarefa, inspecione a ancestralidade em relação ao ponto atual do branch coordenador. Brancos irmãos paralelos divergem após o primeiro merge: faça rebase de cada branch de tarefa não publicado restante no branch coordenador atualizado antes de fazer o merge. Resolva conflitos em relação aos requisitos acordados, preservando o comportamento já integrado; execute novamente as verificações afetadas após o rebase ou resolução de conflitos.

Exemplo usando caminhos absolutos e nomes de branch registrados:

git -C "$task_path" rebase "$work_branch"
git -C "$task_path" status --short
# Execute as verificações necessárias em task_path e, em seguida, verifique a ancestralidade.
git -C "$work_path" merge-base --is-ancestor HEAD "$task_branch"
git -C "$work_path" merge --ff-only "$task_branch"

Inspecione o resultado de cada comando antes de continuar. Se o fast-forward falhar, reinspecione a ancestralidade e faça rebase novamente conforme necessário. Não substitua por um commit de merge, squash, cherry-pick, push forçado ou reset do branch coordenador. Se a resolução segura exigir uma decisão de produto, mantenha ambos os branches e pergunte. Após cada integração de tarefa bem-sucedida e suas verificações necessárias, realize a limpeza necessária abaixo para essa tarefa imediatamente. Revise o trabalho combinado a partir do checkout do coordenador; checkouts de tarefa mesclados não são necessários para revisão PR. Aplique a mesma limpeza a auxiliares abandonados ou substituídos da execução assim que seu trabalho for contabilizado.

5. Verificar, limpar e abrir o PR

Execute as verificações combinadas relevantes no branch coordenador final e reconcilie o resultado com o plano completo. Corrija regressões de integração antes da conclusão.

Limpeza necessária: executar e verificar

A limpeza faz parte da entrega, não uma sugestão para o usuário realizar posteriormente. A invocação já autoriza a remoção dos worktrees e branches de tarefa/auxiliar limpos e totalmente integrados desta execução; não peça novamente para essas remoções.

1. Pare o agente proprietário e qualquer processo em segundo plano gravando no checkout. Registre o commit final do branch após o rebase, verifique se é um ancestral do ponto atual do coordenador e inspecione arquivos rastreados, não rastreados e ignorados. Para um auxiliar sem commits, verifique se seu ponto já está contido também. Contabilize o trabalho não concluído com o proprietário: integre as alterações necessárias e preserve artefatos locais valiosos em um local retido antes de prosseguir. Caches ou logs descartáveis gerados pela execução podem ser removidos por caminho exato; eles não são motivo para deixar um checkout de outra forma finalizado indefinidamente.

2. Para um worktree Git simples, execute estas operações usando caminhos exatos e nomes registrados, verificando cada resultado antes de continuar:

   git -C "$work_path" merge-base --is-ancestor "$task_tip" "$work_branch"
   git -C "$task_path" status --porcelain --untracked-files=all
   git -C "$work_path" worktree remove "$task_path"
   git -C "$work_path" branch -d "$task_branch"
   

   A remoção de um worktree não exclui seu branch. Ambas as operações são necessárias. Exclua também branches de propriedade da execução que não tenham mais um worktree restante. Nunca use remoção forçada, git branch -D, exclusão ampla de diretório ou descarte de edições desconhecidas. Diagnostique comandos com falha e corrija problemas comuns de limpeza dentro do escopo em vez de ignorá-los silenciosamente.

3. Para um worktree gerenciado por aplicativo, use sua API de gerenciamento em vez de excluir o diretório diretamente. No Codex, use list_artifacts para resolver a identidade exata do worktree de propriedade da execução, então archive_worktree; inspecione o resultado e liste novamente para confirmar que não está mais ativo. Exclua seu branch local de propriedade da execução posteriormente com git branch -d quando ele permanecer. Um snapshot de arquivamento ou anexo de aplicativo não substitui a verificação de registro Git e remoção de branch.

4. Marque uma entrada de inventário como limpa somente após verificar que seu caminho exato está ausente, não está mais registrado por git worktree list --porcelain, seu branch está ausente das referências locais e qualquer anexo gerenciado não está mais ativo. Inspecione outros checkouts se o Git disser que o branch ainda está com checkout. Não trate uma solicitação de remoção bem-sucedida ou o relatório de um agente como prova.

5. Imediatamente antes da resposta final, após a criação do PR ou qualquer trabalho de revisão tardia, repita os inventários de branch/worktree Git e de anexo gerenciado. Compare-os com a linha de base e o inventário de propriedade da execução; contabilize novas entradas omitidas dos relatórios do agente sem excluir trabalho não relacionado simultâneo. O branch/worktree coordenador deve ser o único branch/worktree restante de propriedade da execução. Preserve-o para o PR e teste, juntamente com checkouts pré-existentes ou não relacionados. Esta auditoria final é necessária mesmo se a criação do PR for bloqueada ou ignorada, e em caso de falha/interrupção antes de renderizar quando seguro.

Se a limpeza não puder ser concluída com segurança, continue limpando outras entradas elegíveis e relate limpeza bloqueada, com cada branch/caminho retido, a operação exata que falhou ou trabalho valioso/não mesclado, e a menor ação necessária para resolvê-lo. Não relate o fluxo de trabalho geral como concluído enquanto branches/worktrees temporários de propriedade da execução permanecerem. Continue trabalhando na limpeza de rotina em vez de terminar em um merge bem-sucedido, testes aprovados ou criação de PR.

Enviar e abrir o PR

Mantenha o branch/worktree coordenador com todo o trabalho com commit pronto para revisão. Após a integração e validação necessária serem bem-sucedidas, inspecione o diff final e envie apenas o branch coordenador para o remote do repositório pretendido. Crie um PR pronto para revisão com develop como base e o branch coordenador como head; use um rascunho apenas quando o usuário solicitar explicitamente. Verifique se há um PR aberto existente para esta head/base antes de criar um, inclusive após um resultado de criação incerto, e reutilize ou atualize-o em vez de criar um duplicado.

Siga os modelos de PR do repositório, convenções de título e requisitos de link de ticket. Descreva o comportamento final, verificações e seus resultados, e etapas de teste manual concretas. Essas etapas devem descrever o exercício do produto e/ou inspeção do estado persistido, não outra lista de comandos de teste do repositório. Prefira Git local para o push e um conector de repositório disponível para criação PR; use uma CLI autenticada quando apropriado. Verifique a base real do PR, head e commit publicado em relação ao branch coordenador concluído. Anexe cada PR criado ao chat atual quando a ferramenta de anexo de artefato estiver disponível. Deixe o PR aberto para revisão.

Se o push ou a criação do PR estiver bloqueado, preserve o branch/worktree coordenador concluído e relate o bloqueador exato e a ação restante. Não reivindique que um PR existe sem uma URL confirmada ou force-push para contornar uma rejeição.

Relatório de conclusão

A resposta final deve começar com o nome exato do branch coordenador e o caminho absoluto do worktree. Inclua um link Markdown para o PR confirmado, ou informe por que a criação do PR está bloqueada ou explicitamente ignorada, então inclua:

• O que agora funciona: o comportamento concluído e qualquer escopo restante.
• Verificações já executadas: comandos exatos e resultados reais, identificando verificações ignoradas ou bloqueadas.
• Como testar: um procedimento de validação curto, numerado e executável pelo usuário a partir do worktree coordenador. Isso é separado das verificações automatizadas e não deve ser satisfeito repetindo pnpm test, lint, build ou comandos semelhantes. Inclua, conforme aplicável:
  • configuração: URL do ambiente/aplicativo, login e função, serviços, semente ou dados de fixture, IDs de registro e o diretório de trabalho;
  • o fluxo principal do produto: tela ou endpoint exato, entradas realistas e ações de UI, o comportamento a ser acionado e o resultado visível esperado;
  • fluxos de borda ou regressão relevantes: dados inválidos, vazios, duplicados, restritos ou concluídos anteriormente quando esses casos importam;
  • verificação de estado persistido para alterações que escrevem ou fazem transição de dados: forneça uma inspeção de DB/API somente leitura com a tabela ou recurso, filtros ou identificadores, campos/status para verificar e o resultado esperado. Conecte a ação do usuário ao registro armazenado em vez de apenas dizer "verifique o DB." Por exemplo, uma alteração de prospecção deve dizer para criar uma varredura de território para uma área e raio nomeados, encontrar um local específico, confirmar seu atributo necessário, concluir a ação de revisão/alcance e verificar a revisão ou estado de alcance resultante no aplicativo e registros relevantes. Use o mesmo nível de especificidade para outros fluxos de trabalho do produto. Mantenha comandos automatizados em Verificações já executadas. Marque cada etapa manual como executada ou sugerida; se o aplicativo ou banco de dados estava indisponível, informe o bloqueador exato e a menor configuração necessária para executá-lo. A inspeção do banco de dados é somente leitura, a menos que o trabalho aprovado autorize explicitamente a mutação de dados de teste.
• Limpeza e bloqueadores: contagens verificadas de worktrees temporários removidos ou arquivados e branches locais excluídos; o branch/worktree restante de propriedade da execução da auditoria final (normalmente apenas o coordenador). Liste cada branch/caminho temporário bloqueado e seu motivo exato; inclua qualquer etapa de push ou PR incompleta.

Mantenha as atualizações de progresso concisas e termine com uma próxima ação concreta que possa ser feita em menos de dois minutos.