Skill Herdr — o que mudou e por quê

Skill reescrita de 268 → 148 linhas + 4 scripts novos; NADA aplicado e nenhum registro criado no Git — aprovação pendente.

Essência

A matriz congelada de comandos saiu; a sintaxe agora é descoberta no binário em uso. Antes de qualquer mutação, a versão exata 0.7.5 e um subconjunto declarado da ajuda da CLI são conferidos.

Quatro scripts antecipam falhas no lançamento, no envio de tarefa e na verificação; o quarto confere somente o subconjunto de compatibilidade que declara.

O envio paralelo ganhou limite de capacidade, contratos sem sobreposição e um retorno fixo: STATUS / CHANGED / VERIFY / BLOCKER.

Conclusão de executor deixou de significar “pronto”: sucesso exige código de saída zero, revisão das diferenças e suíte completa após as integrações.

Topologia, estados e seis invariantes foram trazidos para a frente; receitas duplicadas e tutoriais de CLI foram removidos.

§1 O que mudou na skill

As 20 mudanças semânticas abaixo explicam o resultado sem depender do diff. A numeração é canônica; a ordem de apresentação é temática. Cada item mostra o estado anterior, o contrato novo, a razão e a origem.

Documentação congelada → descoberta e compatibilidade em tempo de execução

1. Gatilho mais preciso e versão legível por máquina

Antes
A descrição falava genericamente em controlar panes, tabs e workspaces; a versão da CLI existia só em prosa.
Depois
O cabeçalho YAML nomeia pedidos concretos — iniciar, inspecionar, enviar tarefa ou executar comandos — preserva o limite de ativação explícita e registra metadata.herdr-cli-version: "0.7.5".
Por quê
O gatilho fica menos ambíguo e o verificador de compatibilidade recebe um alvo estável.
Origem
A revisão de comunidade de skills F4/F10, apoiada no guia de escrita da Anthropic e no guia completo de skills.

5. Uma verificação delimitada de compatibilidade entrou na barreira de ambiente

Antes
A única barreira era HERDR_ENV=1; lembrar incompatibilidades dependia da leitura humana.
Depois
check-compat.sh também exige HERDR_ENV=1 e exatamente herdr 0.7.5. Na ajuda de pane, procura pane split, --direction right|down, --cwd PATH, --no-focus, pane run, pane read, pane wait-output e --regex PATTERN. Na ajuda de agent, procura agent list, agent get, agent start <name> --kind KIND --pane ID, agent prompt <target> <text> e agent wait <target> [--until STATUS].
Por quê
Esse teste transforma desvios desse subconjunto em interrupção anterior à mutação. Ele não comprova toda a superfície usada pelos scripts, nem semântica, formatos de resposta ou o vocabulário aceito para os estados; por exemplo, não procura pane get, pane rename, várias opções de leitura/tempo limite nem os valores working, idle, done e blocked.
Origem
Revisão de comunidade F3/F10 e revisão final F9; princípio da Anthropic de mover trabalho determinístico para scripts executáveis.

7. Descoberta limitada ao que será usado

Antes
Toda sessão imprimia nove grupos e provocava deliberadamente o erro de herdr wait.
Depois
A versão é lida uma vez; normalmente só herdr pane e herdr agent são consultados, com grupos adicionais apenas sob demanda. O comando inexistente é documentado, não executado.
Por quê
Inventários não usados consomem contexto e um erro conhecido pode parecer falha do ambiente.
Origem
Revisões de comunidade F2, didática F8, adversarial F10 e enforcement F7; Pocock sobre instruções focadas.

8. Matriz de CLI e assinaturas copiadas foram eliminadas

Antes
A skill reproduzia gramáticas e uma matriz estática de suporte a --json, sugerindo uniformidade que não existe.
Depois
O binário instalado é a autoridade; a ajuda de grupo prova apenas sintaxe, nenhuma opção é inferida entre comandos e os scripts auxiliares validam os formatos de resposta de que dependem.
Por quê
A suposição de --json uniforme causou uma falha real; documentação duplicada envelhece e obscurece regras de segurança.
Origem
Revisão minimalista F1/F2 e comunidade F1; Mario Zechner sobre “ceremony and bloat” e Anthropic sobre progressive disclosure. Preservar a matriz em referência foi rejeitado conscientemente.

9. Fatos de controle de agente foram corrigidos para 0.7.5

Antes
A interação era ensinada por comandos de pane, herdr wait no topo e pressupostos da antiga API agent send.
Depois
A superfície suportada é agent start, prompt, get/read e wait; agent send saiu, texto vai atomicamente por agent prompt e send-keys fica reservado a teclas.
Por quê
Comandos removidos ou deslocados falham imediatamente e confundem controle de terminal com controle de agente.
Origem
Revisão adversarial F10/F12 e auditoria do binário 0.7.5 registrada nas decisões.

10. Contexto do chamador foi condensado e protegido

Antes
IDs, foco, descoberta e exemplos de contexto estavam espalhados.
Depois
IDs injetados, duas leituras de estado, opacidade dos IDs e releitura após mutação ficam juntos; blocos bash são executáveis e blocos text exigem substituir os marcadores.
Por quê
A forma curta mantém as propriedades de segurança e evita executar placeholders literalmente.
Origem
Revisão minimalista F2/F6, revisão didática F10 e revisão de enforcement F8; Pocock sobre incrementos concretos.

Prosa de disciplina → scripts com falha antecipada

2. Scripts auxiliares relativos à própria skill viraram obrigatórios

Antes
Receitas de terminal eram diretas e não havia regra estável para localizar auxiliares.
Depois
O diretório absoluto do SKILL.md carregado vira <herdr-skill-dir>; nunca se muda para ele. Script auxiliar ausente ou sem permissão de execução interrompe a operação, sem reconstrução manual.
Por quê
scripts/... relativo resolve contra o projeto e pode falhar silenciosamente; a alternativa manual recolocaria o caminho inseguro.
Origem
Revisão final F3/F8.

6. Seis invariantes viraram o contrato de segurança visível

Antes
Descoberta, alvo explícito, não bloquear, isolamento, verificação e propriedade estavam dispersos e repetidos.
Depois
Seis regras numeradas aparecem logo após a barreira de ambiente e mandam interromper, não improvisar, quando alguma não puder ser cumprida.
Por quê
Das 57 regras normativas, 52 dependiam apenas de disciplina (91,2%), e regras dessa classe foram violadas duas vezes na prática; a parte irredutível precisava de alta saliência.
Origem
Revisão de enforcement F1 e revisão de harness builders F10; Cursor sobre regras essenciais e Anthropic sobre ferramentas claras e econômicas.

11. Lançamento interativo virou start-executor.sh

Antes
Era preciso lembrar divisão de pane, nome, cinco executáveis possíveis, opções, estado inicial e como recuperar uma mutação parcial.
Depois
O script auxiliar valida aridade, nome, tipo, esforço, cwd, direção, contexto, formato e colisão antes de lançar apenas Codex ou Claude; aguarda idle e revela pane_id= em falha parcial.
Por quê
Ordem e política eram disciplina pura; falhar fechado impede interpretar erro de listagem como nome livre e preserva diagnóstico.
Origem
Enforcement F4, adversarial F4–F6 e revisão final F1/F2/F11.

12. Envio de tarefa ficou não bloqueante por construção

Antes
Uma receita de terminal pedia registrar espera em segundo plano e enviar o texto; um uso real congelou o primeiro plano com --wait.
Depois
dispatch.sh exige arquivo novo, inicia o acompanhamento working → idle|done|blocked antes da instrução, retorna o PID e encerra a espera se o envio falhar. A interface não oferece --wait.
Por quê
A sequência é repetível em pedidos iniciais e complementares, e o caminho mais fácil para bloquear deixa de existir.
Origem
Enforcement F2/F3, comunidade F7, didática F3 e revisão final F4; Pocock sobre anti-exemplos de falhas reais.

13. Limites da observação e recuperação ficaram explícitos

Antes
A receita prometia uma ordem mais forte do que o terminal de comandos garante, sem identidade por pedido nem laço claro para coletar o primeiro resultado.
Depois
Cada instrução recebe arquivo e PID distintos; a checagem ocorre em passagens curtas, transições rápidas exigem estado + transcrição, ambiguidades não geram novo envio automático e três falhas materialmente iguais são escaladas.
Por quê
Um processo vivo não prova inscrição pronta; explicitar a corrida evita trabalho duplicado, esperas órfãs e repetição infinita.
Origem
Adversarial F1–F3/F7, harness builders F6/F7 e revisão final F4; HumanLayer sobre controle e escalada limitada.

Fronteira, topologia e propriedade

14. A fronteira ganhou capacidade, contratos e fases

Antes
Toda tarefa sem dependência era iniciada de uma vez, sem limite de recursos, contrato pontuável ou forma fixa de retorno.
Depois
A fronteira inteira continua sendo a unidade de planejamento, mas a onda ativa respeita geometria, CPU, memória, serviços mutáveis e capacidade de revisão. Cada executor recebe escopo sem sobreposição, não objetivos, aceite, verificação e STATUS / CHANGED / VERIFY / BLOCKER; criação de worktrees, lançamentos e instruções são fases separadas.
Por quê
Independência de dependência não implica independência de recurso; contratos reduzem sobreposição e fases preservam paralelismo sem o padrão serial-pull.
Origem
Harness builders F1/F2/F8/F11, enforcement F6/F11, didática F4 e revisão final F7; Factory sobre paralelizar quando a coordenação é baixa, Anthropic sobre contratos de delegação e OpenAI sobre instruções completas.

15. Topologia visível foi separada da propriedade do worktree

Antes
A política fixava um workspace por projeto e uma tab por tarefa; o workspace criado pelo worktree podia esconder o executor da superfície pretendida.
Depois
O pedido explícito do humano vence; por padrão, executores são divisões na tab atual, enquanto cada trabalho de código mantém ramificação e diretório de trabalho próprios. O workspace automático serve apenas como registro administrativo.
Por quê
Isolamento do diretório de trabalho e topologia visível são preocupações distintas.
Origem
Revisão didática F11 e enforcement F11; anti-exemplo baseado na falha de topologia observada.

19. Propriedade de recursos virou manifesto por execução

Antes
A proibição de fechar recursos alheios não tinha registro verificável de propriedade.
Depois
Pane, workspace e worktree criados são registrados por nome e ID; verify.sh acrescenta sua pane. A limpeza alcança apenas IDs do manifesto após nova leitura; falhas preservam recursos.
Por quê
Herdr 0.7.5 não oferece identificador do criador nem fechamento condicionado; o manifesto é a fronteira de auditoria disponível.
Origem
Enforcement F9 e revisão final F6.

Verificação e integração

16. A integração exige revisão do diff

Antes
Conclusão e testes podiam levar diretamente à integração.
Depois
Cada ramificação é comparada à base para verificar contrato, arquivos alheios, segredos e artefatos gerados; só então é integrada, com a suíte completa após a última integração.
Por quê
Testes verdes e declaração de conclusão não demonstram correção de escopo nem conteúdo seguro.
Origem
Revisão de harness builders F4/F9; Cursor sobre comparação e revisão e Simon Willison sobre operadores qualificados.

17. Comandos ordinários foram reduzidos a regras de evidência

Antes
Um tutorial duplicava divisão, execução, espera e leitura e dizia que detection servia para leitura de pane.
Depois
Comandos de terminal, testes, servidores e registros permanecem em panes comuns; conserva-se apenas que pane wait-output pode encontrar histórico antigo, como escolher fontes de leitura e que detection só existe em agent read.
Por quê
A ajuda em tempo de execução já ensina a gramática; as regras restantes previnem falso positivo e fonte inválida.
Origem
Revisão minimalista F8 e adversarial F9; princípio de superfície mínima de pi.

18. Verificação passou a depender do código de saída

Antes
Palavras na saída, sinal do terminal ou declaração do executor podiam ser tomadas como sucesso sem estado confiável do processo.
Depois
verify.sh executa o comando em um Bash filho, emite pelo pai um marcador único TOKEN:<exit-code>, imprime a transcrição, registra a pane e só retorna zero para código de saída zero.
Por quê
Texto pode aparecer em falha ou histórico antigo; exit, exec, comentários, traps e erro de sintaxe podem suprimir um marcador anexado ingenuamente.
Origem
Enforcement F5, adversarial F8/F9, harness builders F3/F5 e revisão final F5/F6; Simon Willison sobre código provado e Factory sobre verificações como barreira.

Estrutura e didática

3. Modelo de propriedade e ciclo de vida foi para o topo

Antes
A divisão entre recursos do terminal e controle do agente precisava ser inferida de procedimentos posteriores.
Depois
Um espaço de trabalho contém abas; uma aba contém panes; cada pane possui um processo e seu cwd. Comandos pane e agent têm responsabilidades separadas, e o ciclo mínimo termina em verificação independente.
Por quê
A propriedade precisa ser entendida antes da escolha do comando e do lugar onde o estado vive.
Origem
Revisão didática F1, baseada no padrão conceito → exemplo → erro → correção de Matt Pocock.

4. Prosa sobre estados virou tabela de ação

Antes
Vários parágrafos explicavam as transições de idle/done dependentes de foco.
Depois
Cinco linhas mapeiam unknown, working, blocked, idle e done para significado e ação; conclusão aceita idle e done.
Por quê
O fluxo crítico precisa de uma decisão operacional, não de um tutorial sobre foco.
Origem
Revisão didática F7 e comunidade F6; Pocock sobre mapear estados a ações.

20. O documento foi comprimido em torno dos trabalhos do operador

Antes
Topologia, lançamento, espera, verificação e segurança se repetiam em procedimentos e em “local conventions”.
Depois
Os títulos são orientados a tarefas — iniciar, enviar, executar fronteira, verificar — e a política da máquina permanece integrada no único arquivo sincronizado.
Por quê
Menos cerimônia duplicada torna regras de prevenção mais localizáveis sem descartar política necessária.
Origem
Revisão minimalista F7/F10 e didática F6; princípio minimalista de Zechner. Meta rígida de ~120 linhas e referência separada de política foram rejeitadas.

Os quatro scripts: erro impedido, falha motivadora e validação

start-executor.sh

O que torna impossível de errar pela interface
Tipo não suportado, esforço ausente ou indevido, nome/direção/cwd inválidos, colisão de nome e lançamento antes de validar a listagem. Depois da divisão, qualquer falha revela e preserva pane_id=; Codex e Claude usam apenas opções permitidas.
Falha real que motivou
agent_pane_busy imediatamente após a divisão; a revisão final também encontrou colisão com falha aberta, mutação antes da validação e pane parcial escondida.
Como foi validado
Uma nova tentativa, baseada na falha observada; bash -n sem erros no Bash 3.2 do macOS.

dispatch.sh

O que torna impossível de errar pela interface
Não existe opção --wait; arquivo reutilizado é recusado; destino é validado; a espera é criada antes da instrução e é encerrada se o envio falhar.
Falha real que motivou
O primeiro plano já foi congelado por --wait; a revisão final encontrou uma espera órfã e uma falsa alegação de prontidão.
Como foi validado
A sequência do script foi executada com envio de tarefas e acompanhamento de conclusão; bash -n sem erros no Bash 3.2. A corrida de transição rápida permanece declarada porque 0.7.5 não oferece uma operação atômica de inscrição e envio.

verify.sh

O que torna impossível de errar pela interface
Sucesso não pode vir de palavra, sinal do shell, tempo limite ou declaração; o Bash pai sempre emite o marcador e o script auxiliar só retorna zero diante de código de saída zero. A pane é registrada e preservada em falha.
Falha real que motivou
A revisão final mostrou que exit, exec, comentário, trap ou erro de sintaxe suprimiam o marcador anexado e que um tempo limite perdia a pane.
Como foi validado
Testes rápidos nos caminhos de saída 0 e 1; bash -n sem erros no Bash 3.2.

check-compat.sh

O que torna impossível de errar pela interface
O fluxo documentado não prossegue sem HERDR_ENV=1, com uma versão diferente de herdr 0.7.5 nem quando falta uma das 13 sequências textuais específicas procuradas na ajuda de pane e agent: oito da primeira lista e cinco da segunda.
Limite do que comprova
Não verifica toda a superfície usada pelos outros scripts e não comprova semântica, formatos de resposta ou vocabulário de estados. Em particular, não procura pane get, pane rename, opções como --source, --lines e vários --timeout, nem valida os valores de --until.
Falha real que motivou
A descoberta manual não protege contratos codificados de forma fixa; a omissão da barreira foi identificada pela revisão de comunidade e pela revisão final.
Como foi validado
Passou contra o binário Herdr 0.7.5 instalado; bash -n sem erros no Bash 3.2.

§2 Consenso e divergências

Consenso explícito

As seis perspectivas — a revisão de comunidade de skills, a revisão de harness builders, a revisão minimalista (pi), a revisão didática (Pocock), a revisão adversarial e a revisão de enforcement — atacaram dois problemas em comum: a matriz congelada/assinaturas copiadas da CLI e a receita de terminal embutida de acompanhamento. O consenso foi substituir documentação duplicada pela autoridade em tempo de execução e mover sequências frágeis para interfaces determinísticas.

A revisão adversarial e a revisão de enforcement chegaram, por ângulos diferentes, aos mesmos defeitos: corrida entre inscrição e instrução; identidade por arquivo/PID; risco de primeiro plano bloqueado; alvo e ID não validados; fronteira parcialmente criada; verificação sem código de saída; e descoberta inválida sujeita a divergência.

Verificação por correspondência de texto foi condenada independentemente por três perspectivas: revisão adversarial (saída comum e histórico antigo), revisão de enforcement (ausência de estado do processo) e revisão de harness builders (o sucesso precisa ser provado por uma barreira executável).

Divergências e resolução

DivergênciaResoluçãoRacional
A revisão minimalista propôs ~120 linhas; a revisão didática e a de comunidade pediram modelo mental, exemplos e orientação adicional.148 linhas. Cortes, scripts auxiliares e dois anti-exemplos foram mantidos; o alvo numérico rígido foi rejeitado.As quatro seções que carregam invariantes ficaram salientes; reduzir por número removeria semântica de prevenção.
A revisão de harness builders pediu uma barreira de capacidade; a regra local exige toda a fronteira pronta em paralelo.Limite + fila. Toda a fronteira continua planejada; a onda ativa é limitada por capacidade e o excesso aguarda.Fila por recurso não é o padrão serial-pull; esperar um executor no primeiro plano continua proibido.
A revisão de comunidade sugeriu mover a matriz a references/; a revisão minimalista pediu apagá-la.Matriz removida. Descoberta seletiva no binário e check-compat.sh substituem a referência.Uma fotografia versionada da CLI rápida envelheceria e competiria com a autoridade instalada.
Comunidade, revisão didática e harness builders pediram avaliações de comportamento e gatilho.Rejeitado por agora; trabalho futuro.Custo de manutenção. As falhas observadas viraram invariantes e scripts auxiliares, mas não há um conjunto formal de avaliações.

§3 Quem disse o quê

As fontes externas abaixo sustentam recomendações específicas. A disposição mostra o que entrou na skill ou foi conscientemente recusado.

Anthropic docs

AfirmaçãoA divulgação progressiva manda carregar detalhes apenas quando necessários; trabalho repetitivo ou determinístico pertence a scripts; a descrição deve nomear contextos concretos de ativação. Fontes: progressive disclosure, anatomia de uma skill, skill writing guide e guia completo em PDF.

AfirmaçãoDelegação eficaz define objetivo, formato de saída e limites; regras críticas devem ser curtas e ferramentas devem devolver contexto útil sem desperdiçar espaço de contexto. Fontes: multi-agent research system, writing effective tools for agents e Claude Code best practices.

Virou: descoberta apenas dos grupos usados, quatro scripts auxiliares, gatilho concreto, versão em metadata, contratos de executor e seis invariantes. Não virou: referências congeladas nem avaliações formais; HERDR_ENV=1 permaneceu na descrição.

Mario Zechner / pi

AfirmaçãoZechner defende desempenho “without all the ceremony and bloat”; pi usa uma superfície pequena, lê documentação sob demanda, guarda comportamento específico em skills e carrega comandos do projeto por AGENTS.md. Fontes: post de Zechner, system prompt, skills, philosophy e context files.

Virou: matriz/assinaturas apagadas, descoberta seletiva, receita de acompanhamento movida a script e comandos de projeto delegados ao AGENTS.md. Não virou: meta de ~120 linhas nem remoção das políticas de esforço/permissão.

Matt Pocock

AfirmaçãoEnsino eficaz não assume conhecimento nem apresenta conceitos na ordem errada; um modelo mental precisa mapear estado abstrato à próxima ação. Anti-exemplos e contratos verificáveis tornam falhas reproduzíveis. Fontes: mental model, Total TypeScript, evals skill-building, AFK agent e what are evals.

Virou: modelo mental + tabela de ação no topo, anti-exemplos de bloqueio e workspace, contratos pontuáveis e notação bash/text. Parcial: não há um exemplo completo único nem um conjunto formal de avaliações.

Simon Willison

AfirmaçãoO entregável é código “proven to work”; agentes de código exigem operadores qualificados e revisão humana. Fontes: code proven to work e coding agents require skilled operators.

Virou: verify.sh condicionado ao código de saída e revisão obrigatória do diff antes de cada integração.

Cursor

AfirmaçãoCódigo gerado pede uma etapa dedicada de comparação e revisão; agentes paralelos isolam mudanças em worktrees; regras devem ficar focadas; notificação de conclusão reduz disputa por atenção. Fontes: agent best practices, agent computer use e cloud agent lessons.

Virou: barreira de revisão do diff, isolamento por worktree/ramificação/nome, arquivos e PIDs distintos, seis invariantes e separação de recursos mutáveis. Parcial: sem VM dedicada, notificação na área de trabalho ou variáveis por pane.

Factory

AfirmaçãoParalelizar faz sentido quando “coordination overhead is low”; a validação deve ser uma barreira, e restrições executáveis devem substituir a confiança na declaração do executor. Fontes: Introducing Missions, Using Linters to Direct Agents e Agent Native Development.

Virou: limite de capacidade, verificação independente por código de saída e suíte após a última integração. Parcial: não há verificação obrigatória após cada integração nem localização automática da primeira integração problemática.

HumanLayer / 12-factor

AfirmaçãoO controlador deve possuir o fluxo, compactar eventos e escalar após um limite de erros consecutivos; iniciar, pausar e retomar devem ser APIs simples. Fontes: 12 Factor Agents e repositório.

Virou: escalada após três falhas materialmente iguais, retorno compacto STATUS / CHANGED / VERIFY / BLOCKER e dispatch.sh como interface simples. Parcial: sem convenção obrigatória de mktemp.

OpenAI

AfirmaçãoMais agentes trazem “complexity and overhead”; boas instruções para Codex parecem solicitações de trabalho e incluem caminhos, componentes, diferenças e documentação. Fontes: practical guide to building agents e how OpenAI uses Codex.

Virou: capacidade limitada, proibição de sobreposição sem reconciliação e contrato completo incluído literalmente na instrução.

obra/superpowers

AfirmaçãoSkills modificadas devem ser testadas pelo comportamento, não aceitas apenas como prosa, e versões maduras registram mudanças. Fontes: contributing e release notes.

Parcial: quatro scripts auxiliares executáveis e validações reais foram incorporados; avaliações comportamentais, notas de versão e versão própria da skill foram recusadas por agora.

awesome-claude-code

AfirmaçãoA coleção distingue skills reutilizáveis, regras/configuração e orquestradores. Fonte: hesreallyhim/awesome-claude-code.

Rejeitado: separar a política local em references/local-orchestration.md; o modelo de sincronização de agents-config usa um único arquivo por skill.

§4 Rastreabilidade

Os 30 itens Top-5 das seis perspectivas e os 11 achados da revisão final têm destino explícito. “Parcial” identifica a parte não adotada; “rejeitado” inclui o racional.

PerspectivaAchadoDestino
Revisão de comunidade de skillsF3 — adicionar script de compatibilidade somente leituraAceito com escopo delimitado: check-compat.sh exige 0.7.5 e procura as 13 sequências textuais listadas na mudança 5; não comprova toda a superfície nem semântica/vocabulário de estados. Mudança 5.
F7 — transformar o protocolo não bloqueante em scriptAceito: dispatch.sh cria um arquivo novo, inicia a espera antes da instrução, retorna o PID e encerra a espera órfã quando o envio falha. Mudança 12.
F1 — mover a matriz congelada para referência versionadaParcial — matriz e assinaturas saíram do corpo; preservar references/cli-0.7.5.md foi rejeitado porque documentação congelada de uma CLI rápida envelhece. A descoberta em tempo de execução a substitui. Mudança 8.
F5 — separar operação portátil da política localRejeitado — o modelo de sincronização de agents-config usa um arquivo único por skill; a política permaneceu integrada na seção de fronteira. Mudanças 14 e 20.
F9 — adicionar avaliações de comportamento e gatilhoRejeitado por agora — custo de manutenção; registrado como trabalho futuro. As falhas observadas viraram invariantes e scripts auxiliares, sem um conjunto formal de avaliações. Mudanças 5, 6, 11, 12 e 18.
Revisão didática (Pocock)F1 — modelo mental antes da CLIAceito: propriedade, superfícies e ciclo de vida no topo. Mudança 3.
F2 — caminho principal mínimo, executável e autoverificávelParcial — modelos pequenos de início/envio e resultados observáveis foram incluídos; não há um fluxo único de ponta a ponta. Mudanças 11 e 12.
F3 — exemplo errado/correto do bloqueioAceito: anti-exemplo agent prompt --wait ao lado de dispatch.sh. Mudança 12.
F4 — contrato de trabalho e retornoAceito: objetivo, propriedade, não objetivos, aceite, verificação e formato fixo. Mudança 14.
F5 — falhas históricas como regressões executáveisParcial — invariantes e scripts auxiliares incorporados; o conjunto formal de avaliações foi rejeitado por agora pelo custo de manutenção. Mudanças 5, 6, 11, 12 e 18.
Revisão de harness buildersF2 — contratos não sobrepostos com aceite explícitoAceito: escopo, não objetivos, aceite e verificação são incluídos literalmente na instrução. Mudança 14.
F3 — marcador de sucesso ligado ao código de saída zeroAceito: verify.sh usa um marcador único e só retorna sucesso diante de código zero. Mudança 18.
F4 — revisão do diff antes de cada integraçãoParcial — a barreira confere contrato, arquivos alheios, segredos e artefatos; a checagem explícita de commits focados não foi retida. Mudança 16.
F1 — limitar concorrência por recursos e coordenaçãoAceito: limite por geometria, CPU, memória, serviços mutáveis e revisão; excesso em fila. Mudança 14.
F10 — promover comportamentos críticos a um bloco curto de invariantesAceito: seis invariantes aparecem imediatamente após a barreira de ambiente; os detalhes executáveis ficam nos scripts auxiliares. Mudança 6.
Revisão minimalista (pi)F1 — apagar inventário congeladoAceito: matriz removida; ajuda de grupo sob demanda. Mudança 8.
F10 — reduzir de 257 para aproximadamente 120 linhasRejeitado — o alvo rígido foi recusado para preservar as quatro seções que carregam invariantes; o resultado tem 148 linhas. Mudança 20.
F4 — trocar a receita de 31 linhas por um contrato não bloqueanteParcial — a mecânica foi para dispatch.sh, mas semântica da corrida, identidade de cada espera e coleta limitada permaneceram por prevenirem falhas observadas. Mudanças 12 e 13.
F7 — condensar topologia, worktree e fronteiraParcial — a política foi consolidada numa seção, mas a lista de cinco fases permaneceu para preservar a regra de fronteira e impedir execução serial. Mudanças 14, 15 e 20.
F2 — apagar assinaturas copiadasAceito: a sintaxe vem do grupo atual; scripts auxiliares validam os formatos de que dependem. Mudanças 8–10.
Revisão adversarialF1 — corrida de transição rápidaParcial — acompanhamento iniciado antes da instrução e ambiguidade resolvida por transcrição; atomicidade depende de mudança no Herdr. Mudança 13.
F2 — arquivo e PID compartilhadosAceito: arquivo novo e PID distinto por instrução e complemento. Mudanças 12 e 13.
F3 — ausência de coleta não bloqueanteAceito: passagens curtas com kill -0, seguidas de get/read. Mudança 13.
F4 — nomes de executor ambíguosAceito: nome único e colisão com falha fechada antes da mutação. Mudança 11.
F5 — início falho seguido de instruçãoAceito: o script auxiliar espera idle, retorna valor diferente de zero, revela a pane parcial e proíbe instrução após falha. Mudança 11.
Revisão de enforcement1 — exigir herdr-dispatch-monitoredAceito como dispatch.sh a interface remove --wait, inicia a espera antes de cada instrução e complemento e encerra a espera se o envio falhar. Mudança 12.
2 — criar agent dispatch atômico no HerdrParcial — dispatch.sh reduz a corrida, mas não a elimina; o primitivo atômico não foi implementado e ficou fora da skill como pedido de evolução do Herdr. Mudança 13.
3 — script auxiliar transacional de fronteira orientado por manifestoParcial — contratos, limite de capacidade e barreiras de fase entraram na mudança 14; o script transacional não foi implementado e permaneceu como pedido de evolução, pois 0.7.5 não oferece aplicação atômica da fronteira.
4 — pane run --wait --exit-code no HerdrParcial — verify.sh usa marcador de código de saída enquanto o primitivo estruturado não existe; a mudança no Herdr ficou fora da skill como pedido de evolução. Mudança 18.
5 — metadados de propriedade e fechamento protegidoParcial — o manifesto local limita a limpeza aos IDs registrados, mas proveniência imutável e fechamento condicionado não existem em 0.7.5 e ficaram como pedido de evolução. Mudança 19.
Revisão finalF1 — colisão com falha abertaCorrigido: valida .result.agents como vetor e falha fechado. Mudança 11.
F2 — mutação prematura e pane escondidaCorrigido: política validada antes da divisão; trap informa pane_id=. Mudança 11.
F3 — caminhos relativos ao cwdCorrigido: resolução por <herdr-skill-dir>, sem cd. Mudança 2.
F4 — prontidão falsa e espera órfãCorrigido: melhor esforço declarado; processo encerrado se o envio falhar. Mudanças 12 e 13.
F5 — marcador suprimívelCorrigido: comando em Bash filho, marcador emitido pelo pai. Mudança 18.
F6 — pane de verificação sem registroCorrigido: manifesto, ID e transcrição em falha, pane preservada. Mudanças 18 e 19.
F7 — capacidade omitidaCorrigido: limite + fila sem o padrão serial-pull. Mudança 14.
F8 — alternativa manual contornava scripts auxiliaresCorrigido: alternativa removida; instalação quebrada exige parar. Mudança 2.
F9 — compatibilidade/avaliações ausentesParcial — check-compat.sh incorporado com o escopo limitado descrito na mudança 5; avaliações foram rejeitadas por agora pelo custo.
F10 — rejeições e estado posterior às correções não registradosCorrigido: decisões registram matriz/referência, política separada, avaliações, alvo ~120 e pedidos de evolução; não exigiu mudança adicional na skill.
F11 — validações de forma tardias ou opacasCorrigido: aridade e formatos validados antes da mutação; nome e destino restringidos. Mudanças 11 e 12.

Apêndice

O relatório é completo sem abrir estes blocos. Eles preservam os artefatos técnicos para auditoria.

Diferenças completas (353 linhas)
--- /Users/fernandodudata/agents-config/shared/skills/herdr/SKILL.md	2026-07-21 11:42:25
+++ /Users/fernandodudata/Documents/Codex/2026-07-21/herdr-skill-swarm/proposal/SKILL.md	2026-07-21 19:02:57
@@ -1,268 +1,148 @@
 ---
 name: herdr
-description: "Control Herdr, a terminal multiplexer for coding agents. Use only when the user explicitly mentions Herdr or asks to use Herdr to inspect or control panes, tabs, workspaces, terminals, commands, or communication with another agent. Do not use merely because a task could benefit from a background terminal, delegation, or parallel work. Requires HERDR_ENV=1."
+description: "Control Herdr, a terminal multiplexer for coding agents. Use when the user explicitly mentions Herdr or asks to start an agent in Herdr, inspect or prompt a Herdr pane, dispatch parallel executors through Herdr, or run commands in Herdr panes. Do not use merely because a task could benefit from a background terminal, delegation, or parallel work. Requires HERDR_ENV=1."
+metadata:
+  herdr-cli-version: "0.7.5"
 ---
 
 # Herdr
 
-Herdr is a terminal multiplexer and runtime for coding agents. It organizes terminals into workspaces, tabs, and panes, detects agent identity and status, and exposes the running session through the `herdr` CLI.
+Herdr is a terminal multiplexer and runtime for coding agents. A workspace contains tabs; a tab contains panes; a pane owns one terminal process and its working directory. Herdr detects the agent running in a pane and exposes the running session through the `herdr` CLI.
 
-Before issuing any control command, check that this agent is running inside a Herdr-managed pane:
+Resolve the absolute directory containing this loaded `SKILL.md` as `<herdr-skill-dir>`; wrapper paths below are relative to that directory, never to the project cwd. Never `cd` into the skill directory — pass the executor or verification cwd as the wrapper argument. If a required wrapper is missing or non-executable, stop before any mutation and report a broken skill installation; do not reconstruct split/start/dispatch/verify sequences from prose.
 
-```bash
-test "${HERDR_ENV:-}" = 1
-```
+## Mental model
 
-If the check fails, say that you are not running inside Herdr and stop. Do not inspect or control the focused Herdr session from outside Herdr.
+- `pane` commands create, place, read, and control terminal processes. Target panes by ID.
+- `agent` commands address a supported agent already running in a pane: start, prompt, inspect, wait. Target agents by unique name (preferred) or by the hosting pane ID.
+- Minimal lifecycle: create a pane → start an agent in it → wait `idle` → arm a monitor → prompt without blocking → observe `working` → accept `idle`, `done`, or `blocked` → verify the work yourself.
 
-When the check passes, the `herdr` binary in `PATH` talks to the running session. Use it to inspect neighboring work, create isolated terminal contexts, start agents and commands, read their output, and wait for state changes.
+| Status | Meaning | Your action |
+| --- | --- | --- |
+| `unknown` | No supported agent detected yet | Read the pane, investigate startup; do not prompt |
+| `working` | Processing | Keep orchestrating; monitor in background |
+| `blocked` | Needs input or approval | Read the transcript, arm a fresh monitor, answer it |
+| `idle` | Ready, or finished with result seen | Before first prompt: ready. After observed `working`: complete |
+| `done` | Finished, result unseen | Complete; read the result |
 
-## Learn the current CLI
+Completion monitors must accept both `idle` and `done`: which one appears depends only on whether the human has seen the result.
 
-The installed binary is the authority for command syntax. Begin with:
+## Environment gate
 
-```bash
-herdr --help
-```
+Run before any control command; if either fails, stop and report instead of adapting ad hoc:
 
-Then print the relevant command group by running it without a subcommand:
-
-```bash
-herdr pane
-herdr workspace
-herdr worktree
-herdr tab
-herdr wait
-herdr terminal
-herdr notification
-herdr integration
-herdr session
+```text
+test "${HERDR_ENV:-}" = 1
+<herdr-skill-dir>/scripts/check-compat.sh
 ```
 
-Do not run bare `herdr` for discovery; it launches or attaches the TUI. Do not probe a mutating nested command by omitting arguments; some commands, including `herdr workspace create`, are valid with defaults and will execute. Use the command-group output above instead.
+`check-compat.sh` is read-only: it requires the audited herdr version and verifies that the `pane` and `agent` groups still advertise every command and flag the wrappers rely on.
 
-Most control commands print JSON. Read identifiers and state from those responses instead of predicting either one.
+## Non-negotiable invariants
 
-## IDs and current context
+1. The installed binary is the authority. Before first use of a command group in a session, run the bare group (`herdr agent`, `herdr pane`, …) and follow its current usage. Never infer a flag — including `--json` — from another command or from this skill.
+2. Target the caller with `--current` or an explicit ID parsed from a JSON response. Never rely on any client's focus; never construct an ID.
+3. Never block the orchestrator foreground on an executor: no `agent prompt --wait` for dispatch — use `scripts/dispatch.sh`.
+4. Give each parallel code-writing executor its own worktree, unique branch, and unique agent name.
+5. `idle`/`done` is not "shippable". Verify with `scripts/verify.sh` (exit-code gated) and review the diff before merging.
+6. Do not close resources you did not create in this run. Never run `herdr server stop` from an active session.
 
-Public IDs are short stable handles:
+If an invariant cannot be satisfied, stop that operation and report the blocker instead of improvising around it.
 
-- workspace: `w1`
-- tab: `w1:t1`
-- pane: `w1:p1`
-- terminal: `term_...`
+## Discover syntax at runtime
 
-The encoded suffix can contain letters and can grow beyond one character. Treat every ID as an opaque string.
+Run `herdr --version` once per session. This skill was audited against 0.7.5; when the binary and this skill disagree, follow the binary and report the mismatch. Print only the groups you will actually use:
 
-Closed tab and pane IDs are not reused and do not retarget later resources. A pane moved into another workspace receives a new public pane ID. Re-read create, split, move, list, or get responses after mutations; never construct an ID from a workspace or display number.
-
-Herdr injects the caller's stable context into every managed pane:
-
 ```bash
-printf '%s\n' "$HERDR_WORKSPACE_ID" "$HERDR_TAB_ID" "$HERDR_PANE_ID"
+herdr pane
+herdr agent
 ```
 
-Prefer `--current` when a pane command should target the calling pane. Omitting a target can use the UI-focused pane, which may belong to the user or another client.
+Add `herdr worktree`, `herdr tab`, etc. only when the task needs them. Do not run bare `herdr` — it launches or attaches the TUI. Do not probe a mutating nested command by omitting arguments; some (e.g. `herdr workspace create`) are valid with defaults and will execute. In 0.7.5 there is no top-level `herdr wait` (use `herdr agent wait` and `herdr pane wait-output`) and `agent send` is gone (submit task text atomically with `herdr agent prompt`; reserve `send-keys` for raw key events).
 
-Discover live state with:
+Group help proves syntax only — not semantics, output schemas, or exit codes. Most control commands print JSON by default: parse IDs and state from those responses, and pass `--json` only where the group inventory advertises it. The wrappers validate the response shapes they depend on and fail closed on schema drift.
 
-```bash
-herdr workspace list
-herdr tab list --workspace "$HERDR_WORKSPACE_ID"
-herdr pane current --current
-herdr pane list --workspace "$HERDR_WORKSPACE_ID"
-```
+## Caller context
 
-## Control agents through panes
+Herdr injects the caller's identity into every managed pane:
 
-An agent runs inside a pane. Use the pane ID as the control target for agents, shells, servers, tests, and logs. This keeps spawning, input, reads, waits, and cleanup on one stable control surface.
-
-Use workspace and tab commands for organization. Use worktree commands only when you intentionally want Herdr to create, open, or remove a Git checkout.
-
-Pane records expose `agent`, `agent_status`, and native session metadata when available. Agent status is `idle`, `working`, `blocked`, `done`, or `unknown`.
-
-`idle` and `done` are the same underlying semantic state with different attention state:
-
-- `idle`: the agent is waiting and its result is considered seen.
-- `done`: the agent finished and its result has not been seen.
-
-An agent that first opens at its prompt reports `idle`, including in a background pane. After a working or blocked agent completes, it reports `done` when its tab or workspace is in the background. It reports `idle` when it completes in the active tab while the foreground client is focused. If the foreground client is explicitly unfocused, completion can become `done` even in the active tab.
-
-Focusing a pane, switching to its tab, or regaining outer terminal focus marks the visible tab as seen, so `done` becomes `idle`. Switching away does not turn an existing `idle` status into `done`; `done` is created by a later completion while the pane is unseen. With no foreground client, a new completion in the globally active tab is treated as seen while completions in background tabs still become `done`.
-
-## Start agents interactively
-
-Default to a sibling pane in the current tab and current working directory. Do not create a workspace, tab, worktree, or different cwd unless the user explicitly requests that topology or location.
-
-Honor a direction requested by the user. Otherwise inspect the caller pane's current rectangle:
-
 ```bash
-herdr pane layout --pane "$HERDR_PANE_ID"
+printf '%s\n' "$HERDR_WORKSPACE_ID" "$HERDR_TAB_ID" "$HERDR_PANE_ID"
 ```
 
-Split a wide pane to the right and a narrow or tall pane down. Avoid repeated same-direction splits that would create unusably narrow columns or short rows. Keep the user's focus in the calling pane:
+Inspect live state with `herdr pane list --workspace "$HERDR_WORKSPACE_ID"` and `herdr agent list`. Closed IDs are never reused; a pane moved to another workspace gets a new ID — re-read list/get responses after every mutation.
 
-```bash
-herdr pane split --current --direction right --no-focus
-```
+Example notation: blocks labeled `bash` are runnable as-is; blocks labeled `text` are templates — replace every `<angle-bracket-token>` before running.
 
-Replace `right` with `down` when the layout calls for it.
+## Start an executor
 
-Read `result.pane.pane_id` from the JSON response. Give the pane a useful label, then start the requested agent by running only its normal executable so its interactive TUI opens:
+The wrapper validates its arguments and the launch policy before touching anything, splits the caller pane with the executor's final cwd and `--no-focus`, validates the returned pane, checks the name is free (failing closed if the check itself fails), and launches the agent with an allowlisted command line:
 
-```bash
-herdr pane rename <returned-pane-id> "reviewer"
-herdr pane run <returned-pane-id> "codex"
+```text
+<herdr-skill-dir>/scripts/start-executor.sh <name> codex <cwd> <right|down> <low|medium|high>
+<herdr-skill-dir>/scripts/start-executor.sh <name> claude <cwd> <right|down>
 ```
 
-Use the executable that belongs to the requested agent:
+It prints the executor's pane ID on success. On nonzero exit do not prompt: if stderr contains `pane_id=...`, a pane was created and preserved — inspect it with `herdr pane get`/`herdr pane read --source recent-unwrapped --lines 80` and `herdr agent get <name>`, then report; never clean up automatically. A validation failure before splitting created nothing.
 
-- Codex: `codex`
-- Claude Code: `claude`
-- pi: `pi`
-- OpenCode: `opencode`
-- OMP: `omp`
+Codex effort is selected only through profiles (`-p effort-low|medium|high`; never edit base Codex config): low for mechanical/low-risk work, medium for domain invariants or authorization, high only when the human asks or the task is high-stakes and underspecified. Claude Code always launches with `--permission-mode auto` — an AI approver, NOT `--dangerously-skip-permissions`/`bypassPermissions`; never substitute those.
 
-Do not pass the task as an argv prompt by default. Do not add non-interactive flags. Only change the normal interactive launch when the user explicitly asks for a different launch mode or command.
+Split a wide pane `right` and a narrow or tall pane `down` (`herdr pane layout --pane "$HERDR_PANE_ID"` shows the rectangle); avoid repeated same-direction splits that produce unusable panes.
 
-Inspect the pane after launch. If `agent_status` is not yet `idle`, wait for the idle transition. Once it is idle, submit the task with `pane run`:
+## Dispatch without blocking the orchestrator
 
-```bash
-herdr pane get <returned-pane-id>
-herdr wait agent-status <returned-pane-id> --status idle --timeout 30000
-herdr pane run <returned-pane-id> "Review the current diff and report only actionable findings."
-```
+### Common mistake: freezing the orchestrator
 
-Status waits match the current status immediately or wait for a future matching transition.
+Wrong — occupies the orchestrator's foreground until the executor changes state or times out:
 
-`pane run` sends the text and Enter together. Use it for initial prompts and follow-ups instead of coordinating `send-text` and `send-keys` separately.
-
-For normal background work, wait for the agent to start working. If the pane remains in a background tab or workspace, wait for `done` before reading its transcript:
-
-```bash
-herdr wait agent-status <returned-pane-id> --status working --timeout 30000
-herdr wait agent-status <returned-pane-id> --status done --timeout 120000
-herdr pane read <returned-pane-id> --source recent-unwrapped --lines 120
+```text
+herdr agent prompt ex-a "Implement the task." --wait --until done --timeout 120000
 ```
 
-If the user is watching that tab, completion reports `idle` instead, so wait for `idle`. Always treat either `idle` or `done` as completed when inspecting `pane get`; the difference is whether the result has been seen.
+Correct — arm a per-executor monitor, then submit and return immediately:
 
-If a wait times out, inspect `herdr pane get <returned-pane-id>` and `pane read` before deciding what to do. A `blocked` agent needs input; an `unknown` pane may not yet contain a detected or integrated agent.
-
-Submit follow-ups the same way:
-
-```bash
-herdr pane run <returned-pane-id> "Now check the failing test."
+```text
+<herdr-skill-dir>/scripts/dispatch.sh ex-a 1800000 <fresh-monitor-file-path> "<contract prompt>"
 ```
 
-## Run an ordinary command in another pane
+The wrapper validates the target, creates the monitor file (which must not already exist), starts a background `working` → `idle|done|blocked` wait chain writing to it, checks the monitor has not already exited (this is not a readiness handshake), submits the prompt — stopping the monitor if submission fails — and prints the monitor PID. Use a distinct monitor file and PID per executor, and use the wrapper again for every follow-up; a follow-up to a `blocked` agent needs a fresh monitor first.
 
-Split the calling pane using the same geometry rule without moving the user's focus:
+Herdr 0.7.5 has no atomic subscribe-and-prompt primitive, so this narrows but does not eliminate the fast-transition race. If the `working` wait times out, run `herdr agent get <name>` and `herdr agent read <name> --source recent-unwrapped --lines 120`; accept a quiescent state only when the transcript shows your prompt completed, otherwise report the ambiguity — do not re-prompt automatically.
 
-```bash
-herdr pane split --current --direction right --no-focus
-```
+To notice completions without blocking, poll the recorded monitor PIDs with `kill -0` in short bounded passes between other work, then inspect `agent get` and `agent read`. Use `--wait` only for a human-requested foreground one-off. After three materially identical failures on one executor, stop prompting it, preserve its pane and worktree, and escalate to the human.
 
-Read the new `pane_id` from the JSON response, then run and inspect the command:
+## Dispatch a ready frontier at once (local policy)
 
-```bash
-herdr pane run <returned-pane-id> "just test"
-herdr wait output <returned-pane-id> --match "test result" --timeout 120000
-herdr pane read <returned-pane-id> --source recent-unwrapped --lines 120
-```
+The human's explicit topology request outranks everything in this section. Absent one: executor panes are splits inside the orchestrator's own tab — no per-task tabs or workspaces — and Herdr panes, not agent-internal subagents, are the parallelism layer (one interactive agent process per pane).
 
-Inspect existing output before waiting for future output. A wait timeout exits with status `1`.
+For N tasks with no unresolved dependency between them, dispatch the frontier at once — the serial-pull pattern (start one, wait, pull the next) is not allowed. If N would exhaust usable pane geometry, CPU, memory, mutable services, or review capacity, cap the wave at the safe limit and queue the remainder — queueing for capacity is not serial-pull; foreground-waiting on one executor is. Phase-separated:
 
-Use the read source that matches the task:
+1. Write one short contract per executor: objective, owned files/subsystem, non-goals, acceptance checks, required verification, and this fixed report shape: `STATUS: complete|blocked`, `CHANGED: <paths|none>`, `VERIFY: <commands and exit codes>`, `BLOCKER: <concrete need|none>`. Contracts in the same frontier must not claim the same writable files, ports, databases, or caches unless the orchestrator plans reconciliation. Include the contract verbatim in the prompt.
+2. Create all worktrees: `herdr worktree create --branch <b> --base main --path <p> --label <l> --no-focus --json` — unique branch and path per executor.
+3. Start all executors with `scripts/start-executor.sh`.
+4. Dispatch all prompts with `scripts/dispatch.sh`.
+5. Service whichever monitor finishes first. A `blocked` pane is a pull request for a follow-up, not a reason to stall the others. A genuine dependency defers only the dependent task to a later frontier.
 
-- `visible`: the current rendered viewport
-- `recent`: recent scrollback as rendered, including soft wraps
-- `recent-unwrapped`: recent scrollback with soft wraps joined; prefer it for logs and transcripts
-- `detection`: the bottom-buffer snapshot used by agent detection
+### Common mistake: the worktree-owned workspace
 
-Use `--format ansi` when colors and terminal styling are evidence. Otherwise use text.
+`worktree create` auto-creates a workspace to own and track the checkout. That is bookkeeping, not executor topology. Do not start the executor there: the wrapper splits a pane in the orchestrator's tab with `--cwd <checkout-path>` and passes that pane to `agent start --pane`.
 
-If the user explicitly asks for another tab, workspace, or worktree, discover that command group and use returned IDs. Do not infer a larger topology from a request to start an agent or command.
+Merge reviewed branches sequentially in dependency-safe order. Before each merge, review the executor's diff against its base: contract satisfied, no unrelated files, no secrets or generated artifacts. Run the full integration suite once after the final merge. Project-specific verification and merge commands belong to the project's AGENTS.md, not here.
 
-## Safety and coordination rules
+## Ordinary commands and verification
 
-- Use `--no-focus` for background work unless the user asked to switch context.
-- Use `--current` or an explicit ID. Do not rely on another client's focused pane.
-- Parse IDs from JSON responses. Do not derive them from sidebar order or examples.
-- Inspect before waiting. Read current output first, then wait for the next state or output you expect.
-- Do not close workspaces, tabs, panes, or sessions you did not create unless the user explicitly asked.
-- Never run `herdr server stop` from an active session unless the user explicitly intends to stop the server and its pane processes.
-- Never kill the main Herdr process. Use named test sessions for experiments that need an isolated server.
+Keep shells, tests, servers, and logs pane-native — never prompt an agent to run them. `pane wait-output` matches text already present in scrollback; it is not a future-transition primitive. Gate on a unique exit-code sentinel, never on output words:
 
----
-
-## Local conventions (this machine)
-
-These layer on top of the upstream skill above. They are generic and reusable across any Herdr + Codex orchestration on this machine; nothing here is project-specific.
-
-### Parallelism lives in Herdr, not in Codex subagents
-
-This machine's Codex config carries a layered v1/v2 subagent setup that is fragile to drive for parallel work. Do not use Codex's internal subagent delegation (`spawn_agent`, the `normalize_spawn_agent` hook, `fork_turns`, `max_threads`) as the parallelism layer for multi-task work. Herdr is the parallelism layer: one Codex process per pane, one pane per task, Herdr owns topology and state. Each executor is a fresh `codex` TUI process started in its own worktree pane.
-
-### Parallel dispatch discipline
-
-When the work has multiple tasks ready to start at the same time — a "frontier" of tasks with no unresolved dependency between them — dispatch ALL of them at once, in parallel. This is a rule on this machine, not a preference. The serial-pull pattern (start one task, wait, pull the next) defeats the purpose of running Herdr and is not allowed: if N tasks are ready, N worktrees and N executor panes are created up front, then all N prompts are submitted, then all N are monitored in parallel.
-
-Concrete sequence for a frontier of N ready tasks:
-
-1. Create all N worktrees first.
-2. Start all N executor panes (one Codex TUI per worktree), each with its effort profile.
-3. Submit all N initial prompts.
-4. Monitor all N in parallel — `wait`/`read` per pane — and service whichever blocks first. A `blocked` pane is a pull request for a follow-up, not a reason to stall the others.
-5. Merge sequentially in any order the contracts allow; run the full integration suite once after the last merge, not after each.
-
-Effort per task is chosen by the orchestrator. Default heuristic when the human does not say otherwise: `effort-low` for mechanical/low-risk tasks (rename, doc edits, pure config); `effort-medium` for tasks that touch domain invariants or authorization; `effort-high` only when the human asks, or the task is high-stakes and underspecified. A task that is genuinely blocked by another (a real dependency, not convenience) is not part of the frontier — it waits and is dispatched in a later round once its dependency merges. "Blocked by" is a dependency/merge-order signal, never a license to run the rest serially.
-
-### Select executor effort with a Codex profile, never by editing config
-
-Reasoning effort is selected per-invocation via Codex profiles that layer on top of `~/.codex/config.toml` (which keeps `model = "gpt-5.6-sol"` and its own default effort):
-
-- `codex -p effort-low`
-- `codex -p effort-medium`
-- `codex -p effort-high`
-
-The orchestrator chooses the profile per task; the base config is never edited for this. Each profile only overrides `model_reasoning_effort`, so model, sandbox, approval policy, and hooks all inherit from base.
-
-### Launching Claude Code agents: Auto Mode by default
-
-When the agent being started is Claude Code, always launch it with Auto Mode:
-
-```bash
-claude --permission-mode auto
+```text
+<herdr-skill-dir>/scripts/verify.sh <cwd> <timeout-ms> <manifest-file> "<verification command>"
 ```
 
-Auto Mode (the yellow "auto mode" indicator) uses an AI approver that judges each tool call against the prompt. It is NOT `--dangerously-skip-permissions` / `bypassPermissions` — never use those for this purpose. Without this flag Claude opens in manual mode and every permission prompt blocks the pane until a human or the orchestrator services it, which defeats background orchestration. Combine with other explicit requests as flags (e.g. `claude --model opus --permission-mode auto`).
+The wrapper splits a pane down from the caller, records the pane in the manifest, runs the command inside a child bash (so `exit`, `exec`, comments, traps, and syntax failures cannot suppress the exit marker), waits for a unique `TOKEN:<exit-code>` trailer, prints the transcript, and exits 0 only when the command's exit code was 0. On failure or timeout it prints the pane ID and transcript to stderr and preserves the pane. A timeout, a shell prompt, or an executor's claim of success is not evidence.
 
-### Start agents in an explicit tab, never the default
+For reads: `--source recent-unwrapped` for logs and transcripts, `visible` for the current viewport, `--format ansi` only when styling is evidence. (`detection` exists on `agent read` only, not `pane read`.)
 
-`herdr agent start` without `--tab` can drop the pane into whatever tab is active/last — including another orchestrator's tab. Always pass an explicit target: `--tab "$HERDR_TAB_ID"` to open next to the caller, or create a dedicated tab first (`herdr tab create --workspace "$HERDR_WORKSPACE_ID" --label <label> --no-focus`) and pass its returned tab_id.
+## Safety rules
 
-### Always start an executor in its own worktree
-
-Parallel executors never share a checkout. Create the worktree before starting the agent, then start Codex in that worktree as a TUI (not `codex exec`), so Herdr detects it and follow-ups stay possible:
-
-```bash
-herdr worktree create --branch <branch> --base main --path <worktree-path> --label <label> --no-focus
-herdr agent start <agent-name> --cwd <worktree-path> --workspace <ws> --no-focus -- codex -p effort-<level>
-```
-
-### Topology
-
-- One Herdr workspace per project.
-- One tab per parallel task; one pane per executor in that tab.
-- Name agent targets stably (e.g. `ex-<id>`) and address them by name parsed from JSON responses, never by sidebar order or guessed IDs.
-
-### Treat an executor as done only after the project verifies
-
-Before reading `done`/`idle` as shippable, run the project's own verification (tests/typecheck/build) in a split pane, not by stealing the executor's focus:
-
-```bash
-herdr pane split --current --no-focus   # then herdr pane run <split-pane-id> "<verify command>"
-```
-
-Project-specific verify commands belong to the project's AGENTS.md, not here.
+- `--no-focus` for background work; keep the human's focus in their pane.
+- Record every pane, workspace, and worktree you create (name + ID) in a per-run manifest file (`verify.sh` appends its panes automatically); close only IDs listed there, and only after `get` confirms them.
+- Never run `herdr server stop` or kill the main Herdr process from an active session. Use a named test session (`herdr --session <name>`) for experiments that need an isolated server.
start-executor.sh — fonte completa
#!/usr/bin/env bash
# Start an executor agent in a new split of the caller's pane.
# Usage: start-executor.sh <name> codex <cwd> <right|down> <low|medium|high>
#        start-executor.sh <name> claude <cwd> <right|down>
# Prints the executor's pane ID on success. On partial failure it prints
# "start failed; created pane_id=..." to stderr and preserves the pane.
set -euo pipefail

usage() { echo "usage: start-executor.sh <name> <codex|claude> <cwd> <right|down> [low|medium|high]" >&2; exit 64; }

[ "$#" -ge 4 ] && [ "$#" -le 5 ] || usage
name=$1 kind=$2 cwd=$3 direction=$4 effort=${5:-}

test "${HERDR_ENV:-}" = 1
test -n "${HERDR_PANE_ID:-}"
test -d "$cwd"
case "$direction" in right|down) ;; *) usage ;; esac
case "$name" in ''|-*|*[!A-Za-z0-9._-]*) echo "invalid agent name: $name" >&2; exit 64 ;; esac

# Validate launch policy BEFORE any mutation.
case "$kind" in
  codex)  case "$effort" in low|medium|high) ;; *) echo "codex requires effort low|medium|high" >&2; exit 64 ;; esac ;;
  claude) [ -z "$effort" ] || { echo "claude takes no effort arg" >&2; exit 64; } ;;
  *) echo "unsupported kind: $kind" >&2; exit 64 ;;
esac

# Name-collision check fails CLOSED: a failed list or changed schema aborts.
agents_json=$(herdr agent list) || { echo "herdr agent list failed" >&2; exit 69; }
printf '%s\n' "$agents_json" | jq -e '.result.agents | type == "array"' >/dev/null \
  || { echo "unsupported agent-list response schema" >&2; exit 69; }
if printf '%s\n' "$agents_json" | jq -e --arg n "$name" '.result.agents[] | select(.name == $n)' >/dev/null; then
  echo "agent name already in use: $name" >&2
  exit 65
fi

pane_id=""
report_partial_failure() {
  rc=$?
  if [ "$rc" -ne 0 ] && [ -n "$pane_id" ]; then
    printf 'start failed; created pane_id=%s; resource preserved\n' "$pane_id" >&2
  fi
  exit "$rc"
}
trap report_partial_failure EXIT

split_json=$(herdr pane split --pane "$HERDR_PANE_ID" --direction "$direction" --cwd "$cwd" --no-focus)
pane_id=$(printf '%s\n' "$split_json" | jq -er '.result.pane.pane_id')
herdr pane get "$pane_id" >/dev/null
herdr pane rename "$pane_id" "$name" >/dev/null

start_agent() {
  case "$kind" in
    codex)  herdr agent start "$name" --kind codex --pane "$pane_id" --timeout 60000 -- -p "effort-$effort" >/dev/null ;;
    claude) herdr agent start "$name" --kind claude --pane "$pane_id" --timeout 60000 -- --permission-mode auto >/dev/null ;;
  esac
}
# The fresh pane's shell can report agent_pane_busy for a moment; retry once.
if ! start_agent; then
  sleep 2
  start_agent
fi

herdr agent wait "$name" --until idle --timeout 30000 >/dev/null
trap - EXIT
printf '%s\n' "$pane_id"
dispatch.sh — fonte completa
#!/usr/bin/env bash
# Dispatch a prompt to an executor without blocking the caller.
# Starts a best-effort working -> idle|done|blocked monitor BEFORE submitting.
# Herdr 0.7.5 has no atomic subscribe-and-prompt primitive, so a fast working
# transition can still be missed; SKILL.md describes the ambiguity procedure.
# Usage: dispatch.sh <target> <completion-timeout-ms> <monitor-file> <prompt>
# Prints the monitor PID on success. Use a fresh monitor file per prompt.
set -euo pipefail

usage() { echo "usage: dispatch.sh <target> <completion-timeout-ms> <monitor-file> <prompt>" >&2; exit 64; }
[ "$#" -eq 4 ] || usage
target=$1 timeout_ms=$2 monitor_file=$3 prompt=$4

test "${HERDR_ENV:-}" = 1
case "$timeout_ms" in ''|*[!0-9]*) usage ;; esac
[ ! -e "$monitor_file" ] || { echo "monitor file already exists: $monitor_file" >&2; exit 64; }
(umask 077; : >"$monitor_file")

herdr agent get "$target" >/dev/null

(
  herdr agent wait "$target" --until working --timeout 60000 &&
  herdr agent wait "$target" --until idle --until done --until blocked --timeout "$timeout_ms"
) >"$monitor_file" 2>&1 &
monitor_pid=$!
# Confirms only that the monitor has not already exited; not a readiness handshake.
kill -0 "$monitor_pid"

if ! herdr agent prompt "$target" "$prompt" >/dev/null; then
  kill "$monitor_pid" 2>/dev/null || true
  wait "$monitor_pid" 2>/dev/null || true
  echo "prompt submission failed; monitor stopped" >&2
  exit 70
fi
printf '%s\n' "$monitor_pid"
verify.sh — fonte completa
#!/usr/bin/env bash
# Run a verification command in a fresh split pane and gate on its EXIT CODE,
# never on output text. The command runs in a child bash so exit/exec/comments/
# traps/syntax errors cannot suppress the exit marker. Prints the transcript;
# exits 0 only if the command exited 0. Records the pane in the manifest and
# preserves it on failure.
# Usage: verify.sh <cwd> <timeout-ms> <manifest-file> <command>
set -euo pipefail

usage() { echo "usage: verify.sh <cwd> <timeout-ms> <manifest-file> <command>" >&2; exit 64; }
[ "$#" -eq 4 ] || usage
cwd=$1 timeout_ms=$2 manifest_file=$3 command=$4

test "${HERDR_ENV:-}" = 1
test -n "${HERDR_PANE_ID:-}"
test -d "$cwd"
case "$timeout_ms" in ''|*[!0-9]*) usage ;; esac

pane_id=""
on_exit() {
  rc=$?
  if [ "$rc" -ne 0 ] && [ -n "$pane_id" ]; then
    printf 'verification pane_id=%s (preserved)\n' "$pane_id" >&2
    herdr pane read "$pane_id" --source recent-unwrapped --lines 200 >&2 || true
  fi
  exit "$rc"
}
trap on_exit EXIT

token="HERDR_VERIFY_${RANDOM}_$$"
split_json=$(herdr pane split --pane "$HERDR_PANE_ID" --direction down --cwd "$cwd" --no-focus)
pane_id=$(printf '%s\n' "$split_json" | jq -er '.result.pane.pane_id')
herdr pane get "$pane_id" >/dev/null
printf '%s\t%s\n' verification-pane "$pane_id" >>"$manifest_file"

printf -v quoted_command '%q' "$command"
pane_command="bash -c $quoted_command; rc=\$?; printf '%s:%s\\n' '$token' \"\$rc\""
herdr pane run "$pane_id" "$pane_command" >/dev/null
herdr pane wait-output "$pane_id" --regex "${token}:[0-9]+" --source recent-unwrapped --lines 200 --timeout "$timeout_ms" >/dev/null
output=$(herdr pane read "$pane_id" --source recent-unwrapped --lines 200)
printf '%s\n' "$output"
printf '%s\n' "$output" | grep -Fq "${token}:0"
trap - EXIT
check-compat.sh — fonte completa
#!/usr/bin/env bash
# Read-only compatibility gate for this skill's wrappers.
# Verifies the herdr version and that the pane/agent groups still advertise
# every command and flag the wrappers rely on. Never mutates anything.
# Usage: check-compat.sh
set -euo pipefail

test "${HERDR_ENV:-}" = 1

version=$(herdr --version)
case "$version" in
  "herdr 0.7.5") ;;
  *) echo "unsupported herdr version: $version (audited: herdr 0.7.5)" >&2; exit 69 ;;
esac

fail=0
need() { # need <group-help-text> <needle> <group-label>
  case "$1" in
    *"$2"*) ;;
    *) echo "missing from 'herdr $3': $2" >&2; fail=1 ;;
  esac
}

# Bare groups print usage and exit nonzero; capture regardless.
pane_help=$(herdr pane 2>&1 || true)
agent_help=$(herdr agent 2>&1 || true)

need "$pane_help" "pane split" pane
need "$pane_help" "--direction right|down" pane
need "$pane_help" "--cwd PATH" pane
need "$pane_help" "--no-focus" pane
need "$pane_help" "pane run" pane
need "$pane_help" "pane read" pane
need "$pane_help" "pane wait-output" pane
need "$pane_help" "--regex PATTERN" pane
need "$agent_help" "agent list" agent
need "$agent_help" "agent get" agent
need "$agent_help" "agent start <name> --kind KIND --pane ID" agent
need "$agent_help" "agent prompt <target> <text>" agent
need "$agent_help" "agent wait <target> [--until STATUS]" agent

[ "$fail" -eq 0 ] || exit 69
echo "herdr compatibility: ok (herdr 0.7.5)"
5 pedidos de evolução do Herdr
  1. agent dispatch atômico: inscrever, enviar, rejeitar --wait, ignorar idle anterior e retornar um ID de tarefa numa operação.
  2. frontier apply transacional: validar manifesto e barreiras de fase antes da primeira instrução.
  3. Metadados de propriedade + fechamento protegido: proveniência imutável e fechamento somente se o recurso pertencer à execução.
  4. pane run --wait --exit-code: conclusão estruturada sem sentinels de texto.
  5. Modo de política com lista de permissões: rejeitar alvo implícito, ausência de --no-focus, prompt --wait no controlador, opções perigosas e parada do servidor em sessão ativa.

Esses itens ficaram fora da skill: são um plano de evolução do Herdr, não instruções de tempo de execução.