worktrees-hives

Skill worktrees-hives

Skill de agente instalável para o orquestrador híbrido worktrees-hives.

Quando usar

Use este skill quando:

• Descobrir trabalho a partir de issues do GitHub ou Linear
• Criar subagentes trabalhadores para alterações de código
• Monitorar pull requests durante o CI
• Reportar resultados de volta ao operador

Barreiras de Segurança

Estas regras são INEGOCIÁVEIS. Nenhum agente, orquestrador ou plataforma pode ignorá-las.

Lista de negação (nunca executar)

Comando / Operação	Motivo
gh pr merge	Agentes nunca fazem merge de PRs. Um humano deve fazer o merge.
gh pr merge --auto	Mesma proibição; auto-merge é um merge.
git push --force (simples)	Destrutivo; perde histórico. Use --force-with-lease apenas.
git push -f (simples)	Forma abreviada do mesmo push destrutivo.
GraphQL mergePullRequest	Merge via API ainda é um merge.
REST PUT /repos/.../merge	Merge via REST ainda é um merge.
Criação de qualquer commit de merge	git merge na working tree para combinar branches de PR.

Lista de permissão para force-with-lease

git push --force-with-lease é permitido apenas quando:

1. O agente está fazendo rebase do seu próprio branch de feature em uma base atualizada.
2. O agente está corrigindo um force-push que falhou devido a uma ref remota desatualizada.
3. O operador instrui explicitamente um force-push.

Antes de usar --force-with-lease, o agente DEVE:

• Verificar se o branch atual é o branch da worktree designada (não main, master ou branch de outro agente).
• Confirmar que a ref remota é a que o agente espera (sem pushes inesperados de outros).

Semântica de limite de correções

Regra: Cada PR recebe no máximo 3 commits de correção de código por ciclo de babysit.

• O que conta: Commits que alteram código-fonte, testes, configuração ou documentação que afeta o comportamento.
• O que não conta: Commits de merge provenientes de rebase, commits acionados por CI (ex.: atualizações de lock file), comentários de resposta no PR.
• Quando o limite é atingido: O agente DEVE parar de commitar e relatar problemas residuais como comentários no PR. O agente continua a responder a comentários de revisão e monitorar o CI, mas não faz push de novas alterações de código.
• Relato de problemas residuais: Quando o limite é atingido, o agente publica um comentário listando: falhas restantes de CI, threads de revisão não resolvidas e próximos passos recomendados para um humano ou próximo ciclo.
• Reset: O limite é reiniciado quando o operador inicia um novo ciclo de babysit (reinicialização explícita, não automática).

Checklist de pré-edição de branch/worktree

Antes de fazer qualquer alteração de código, o agente DEVE verificar:

1. Isolamento da worktree: pwd está dentro do caminho da worktree designada ({worktree_root}/{owner}/{repo}/{job_id}).
2. Correção do branch: git branch --show-current corresponde ao branch de feature designado.
3. Estado limpo: git status mostra que não há alterações não commitadas de outro trabalho.
4. Alinhamento remoto: git fetch && git status confirma que o branch rastreia o remoto esperado.
5. Sem edições fora do limite: Nenhum arquivo fora da worktree é modificado (nem caminhos ../, nem caminhos absolutos fora da raiz da worktree).

Se alguma verificação falhar, o agente DEVE abortar e relatar a incompatibilidade.

Orientações de status final

Quando um ciclo de babysit termina (com sucesso ou pelo limite), o agente relata:

• Status do PR: Aberto / Pronto para revisão / Bloqueado
• Contagem de correções: Número de commits de correção de código enviados neste ciclo (ex.: "2/3")
• Problemas residuais: Lista de falhas de CI não resolvidas, comentários de revisão ou bloqueadores
• Atribuição do agente: Todo comentário de PR e mensagem de commit inclui identificação do agente

O agente NÃO DEVE afirmar que fez o merge do PR. Se o PR parecer ter sido mergeado, o agente relata "PR foi mergeado por um humano" e para.

Template de prompt de worker neutro de plataforma

Ao criar um subagente trabalhador, inclua estas instruções de segurança no prompt:

REGRAS DE SEGURANÇA (não negociáveis):
- NUNCA faça merge de um PR ou invoque qualquer API/CLI de merge
- NUNCA use `git push --force` ou `git push -f` simples
- `git push --force-with-lease` é permitido apenas para rebase do seu próprio branch
- NUNCA edite arquivos fora da sua worktree designada
- NUNCA faça commit de mais de 3 commits de correção de código por ciclo de babysit
- Antes de editar, verifique: caminho da worktree, nome do branch, estado limpo
- Após fazer push, responda com o SHA e a atribuição do agente
- Quando o limite for atingido, relate problemas residuais; não faça push de mais código

Camadas de execução

Estas barreiras de segurança são aplicadas em múltiplas camadas:

1. Skill do agente (este arquivo): Documentação portável e templates de prompt. Não é um limite de segurança — agentes podem ignorar se não estiverem restritos pela plataforma.
2. Orquestrador Python: Aplicação da política via ponte de subprocesso. Conta commits de correção, valida caminhos e bloqueia comandos da lista de negação antes que cheguem ao Rust.
3. Núcleo Rust (wh-core): Aplicação rígida. Rejeita operações inseguras de git/GitHub no limite do processo. Esta é a camada de segurança autoritativa.

Defesa em profundidade: todas as três camadas aplicam as mesmas regras. Uma falha em uma camada é capturada por outra.