brooks-lint — Ferramenta de Manutenção (Orquestrador)

Quando Usar

Use esta habilidade quando precisar de um orquestrador de manutenção para o próprio plugin brooks-lint. Executa um pipeline sequencial de subagentes — autor → avaliação → QA → auditoria-de-gatilho → lançamento — para adicionar ou editar uma habilidade, atualizar o conjunto de avaliações, manter os quatro manifestos + README + CHANGELOG + AGENTS/GEMINI sincronizados, auditar gatilhos...

Esta habilidade orquestra o trabalho no próprio repositório brooks-lint. Ela executa um pipeline sequencial de subagentes: cada estágio é um agente dedicado definido em .claude/agents/. Inicie cada um com a ferramenta Agent, subagent_type definido como o nome do agente e sempre model: "opus". Os estágios dependem uns dos outros em ordem, então este é um pipeline, não uma equipe paralela.

Pipeline

[orchestrator]
   Phase 0  context check
   Phase 1  classify request → select stages
   Phase 2  run selected stages in order, with a QA loop-back:
            skill-author → eval-curator → consistency-qa ─(FAIL)→ back to author
                                              │ PASS
                                              ▼
                            trigger-boundary-auditor   (only if a description changed)
                                              ▼
                                      release-manager  (only if release requested)
   Phase 3  report + collect feedback

Fase 0 — Verificação de Contexto

Determine o modo de execução antes de fazer qualquer coisa:

• _workspace/brooks-harness/ existe + o mantenedor pede para refazer parte de uma execução anterior → reexecução parcial: invoque apenas os estágios afetados, reutilizando notas anteriores.
• _workspace/brooks-harness/ existe + uma nova solicitação → nova execução: mova a pasta antiga para _workspace/brooks-harness_prev/, comece do zero.
• Nenhum _workspace/brooks-harness/ → execução inicial: crie-o.

As notas da execução e o relatório de QA ficam em _workspace/brooks-harness/. Os artefatos reais são os próprios arquivos do repositório — os agentes editam skills/, evals/, os manifestos diretamente; _workspace/ apenas contém as notas da execução e o veredito PASS/FAIL para auditoria.

Fase 1 — Classificar a Solicitação

Escolha o conjunto mínimo de estágios. O estágio de QA nunca é pulado — toda mudança é controlada.

Fase 2 — Executar o Pipeline

Inicie cada estágio selecionado como um subagente em ordem. Passe para cada agente (a) o contrato da tarefa e (b) o resumo do estágio anterior. Os agentes escrevem seus resumos em _workspace/brooks-harness/; leia-os entre os estágios.

1. skill-author — cria/edita o conteúdo. Para uma habilidade totalmente nova, invoca o scaffold new-skill. Retorna a lista de arquivos modificados + escolhas relevantes para convenção (novos códigos de risco, novos números de Passo, frases de gatilho description alteradas).
2. eval-curator — se skill-author relatou códigos de risco ou modos novos/alterados, adiciona os cenários correspondentes de caminho feliz + falso positivo e executa npm run evals.
3. consistency-qa (controle — nunca pulado) — executa npm run validate + npm test + npm run evals, então as verificações de sincronização entre documentos (manifestos, selo do README, CHANGELOG, contagem de livros AGENTS/GEMINI, contagem de avaliações). Escreve um veredito PASS/FAIL. Em caso de FAIL: retorne ao agente nomeado no veredito (autor ou eval-curator), corrija e reexecute o QA. Repita uma vez; se ainda falhar, pare e reporte ao mantenedor.
4. trigger-boundary-auditor — execute apenas se um campo description mudou. Ele audita somente leitura as superfícies de gatilho das seis habilidades enviadas para falsos gatilhos e colisões de roteamento. Apresente suas descobertas; se ele sinalizar uma colisão real, retorne ao skill-author.
5. release-manager — execute apenas se um lançamento foi solicitado, e apenas após QA PASS. Realiza o lançamento através da habilidade release.

Fase 3 — Relatório e Feedback

Relatório: estágios executados, arquivos alterados, veredito do QA, descobertas da auditoria de gatilho (se houver) e o URL de lançamento (se houver). Em seguida, ofereça ao mantenedor uma abertura para feedback: "Algo a ajustar

…