super-review-council

Super Review Council / 超级审查会

Execute um fluxo estruturado de revisão e correção multiagente quando o usuário solicitar explicitamente este workflow super-review-council. Isso é principalmente revisão de código, mas bundles explícitos de destino não-código congelados são suportados; não é o roteamento de aprovação auto_review do Guardian e não é o comando codex review embutido.

Para execuções explícitas de nível superior, a forma padrão é um fluxo de trabalho de quatro agentes para cada fase substantiva. Quatro agentes inspecionam o mesmo bundle de alterações congelado, quatro agentes ajudam na triagem das descobertas, quatro agentes participam do planejamento/implementação de correções onde a propriedade de escrita pode ser separada, e quatro agentes verificam o resultado antes que o loop se repita. O agente principal coordena, atribui propriedade, integra resultados e toma a decisão final sobre correções aceitas.

Use quando:

• o usuário disser explicitamente super-review-council
• o usuário disser explicitamente Super Review Council
• o usuário disser explicitamente 超级审查会
• o usuário solicitar explicitamente este fluxo de trabalho pesado de conselho de revisão multiagente
• um fluxo de trabalho coordenador de nível superior carregado invocar explicitamente super-review-council como uma passagem filha somente leitura limitada

Não acione esta skill para "revisão" simples, codex review embutido, auto_review do Guardian, auto-revisão pós-edição normal, respostas finais, commits, envio, verificações de CI, menções a nomes de skills antigas ou manutenção comum deste arquivo de skill, a menos que o usuário tenha solicitado este workflow super-review-council para esse trabalho.

Quando acionada, primeiro declare que a skill super-review-council está ativa e identifique o alvo da revisão antes de iniciar o trabalho do revisor.

Atribuição

Esta skill é derivada da skill skills/autoreview com licença MIT do repositório openclaw/agent-skills. O nome legado autoreview aparece aqui apenas para atribuição MIT, compatibilidade de caminho de helper/saída/ambiente e contextos de proibição de fluxo de trabalho aninhado.

Fluxo de Trabalho de Quatro Agentes

Quando o usuário disser super-review-council ou 超级审查会, use quatro agentes em paralelo para cada fase quando o ambiente suportar subagentes. Prefira agentes do tipo explorer para fases somente leitura e agentes do tipo worker para fases de implementação. Agentes de revisão, triagem e planejamento de correções somente leitura padrão têm contexto mínimo de escopo de fase: identidade do alvo congelado, função, ferramentas permitidas, proibições e descobertas/evidências relevantes apenas. Agentes de verificação também padrão têm contexto mínimo de escopo de fase, mais quaisquer comandos de verificação explicitamente aprovados, caminhos de saída, limites de escrita e requisitos de auditoria de desvio para aquela fase. Aprovações antigas e instruções de execução podem ser passadas apenas como evidência/procedência, devem ser explicitamente rotuladas como contexto histórico apenas e sem autoridade, e não podem conceder permissões, aprovar execução degradada ou arriscada, autorizar escrita, teste, correção ou fluxos de trabalho aninhados, ou substituir o contrato da fase atual, ferramentas permitidas ou proibições. Agentes workers podem receber contexto mais rico apenas quando a correção aceita exigir, e esse contexto mais rico está sujeito aos mesmos limites de evidência/procedência apenas.

Fase 0: pré-voo do alvo. Antes de congelar o bundle ou gerar agentes, identifique o alvo da revisão:

• se o usuário ou um fluxo de trabalho coordenador fornecer um arquivo, diretório ou bundle de revisão congelado explícito, esse alvo explícito tem precedência sobre a detecção git do diretório de trabalho atual; canonize o alvo e use manifesto de conteúdo/identidade hash mesmo quando o shell atual estiver dentro de um repositório git
• se dentro de um repositório git, registre a raiz do repositório, branch atual, estado sujo/staged/não rastreado, upstream/base ou PR base quando disponível, e se o alvo deve ser modo local, branch ou commit
• se não estiver dentro de um repositório git, prossiga apenas quando o usuário forneceu um arquivo, diretório ou bundle revisável explícito; canonize caminhos absolutos, rejeite alvos ausentes, enumere conteúdos de diretório deterministicamente e pare para perguntar por um repositório ou alvo explícito quando nenhum foi fornecido
• registre a identidade imutável do alvo antes da Fase 1: SHA de commit para modo commit; refs base/head mais um hash de diff para modo branch; hash de manifest de diff local/não rastreado para modo local; ou um hash de manifest de conteúdo para arquivos não git, diretórios e bundles
• congele o bundle/fonte selecionados antes da Fase 1 e relate a identidade/hash do alvo na primeira atualização voltada ao usuário
• antes da triagem, planejamento de correções e implementação, recalcule a identidade/hash do alvo selecionado e compare-a com a linha de base atual do loop de revisão congelado; inicialmente, esta linha de base é o valor da Fase 0; este recálculo é apenas uma verificação de igualdade e não autoriza substituir a linha de base, regenerar manifests, recongelar ou reiniciar
• após a Fase 4 correções aceitas serem aplicadas, audite a identidade do alvo/espaço de trabalho resultante contra a linha de base pré-Fase 4, escopos de escrita aceitos, saídas aprovadas e caminhos proibidos antes de registrar a identidade/hash do alvo resultante como a linha de base de verificação da Fase 5 e identidade inicial para o próximo loop de revisão; desvios inesperados, fora do escopo ou proibidos devem ser colocados em quarentena e divulgados, e bloqueiam a adoção da linha de base a menos que explicitamente aprovados
• se qualquer comparação de identidade de alvo diferir devido a alteração externa não aprovada, pare essa fase, divulgue a identidade/hash esperada e observada mais os caminhos alterados quando conhecidos, e exija aprovação explícita do usuário ou coordenador antes de recongelar, reiniciar ou adotar uma nova linha de base; no modo filho somente leitura, retorne isso como um bloqueador para o coordenador

Registro de subagente nativo: o gerenciamento do lado do coordenador é o controle primário, não o bloqueio de sistema de arquivos. Antes de cada subagente nativo iniciar, o coordenador registra fase e função, ferramentas declaradas, ações permitidas e proibidas explícitas, caminhos de leitura/escrita permitidos, caminhos proibidos, perfil de sandbox e permissão quando disponível, identidade/hash de linha de base do alvo e status do repositório/espaço de trabalho e manifests, ou uma linha de base de mutação de todo o espaço de trabalho equivalente suficiente para descobrir escritas fora do alvo. Após o subagente retornar, compare a identidade do alvo, manifests de caminhos permitidos/proibidos, status do repositório/espaço de trabalho e metadados de ferramenta/sandbox/permissão com essa captura instantânea. Coloque em quarentena, não confie e divulgue qualquer incompatibilidade de alvo, escrita inesperada dentro ou fora do alvo, desvio de caminho permitido, toque em caminho proibido, desvio de ferramenta, expansão de permissão ou sandbox, mutação inexplicada, desvio não autorizado ou escritas inesperadas antes de continuar. Modos somente leitura do sistema de arquivos, diretórios imutáveis e restrições de sandbox são salvaguardas úteis ou evidência quando disponíveis, mas nunca substituem o contrato de prompt do coordenador, registro, auditoria de captura/desvio, decisão de quarentena, revisão de integração e decisão final.

Tratamento de falha de fase: se qualquer agente necessário, engine helper ou worker errar, expirar, violar o contrato da fase, retornar campos obrigatórios ausentes ou produzir saída inutilizável, essa fase está incompleta. Coloque em quarentena ou ignore a saída suspeita, divulgue a falha e tente novamente ou substitua o participante apenas dentro do mesmo contrato de fase e restrições do engine/modelo, ou pare para aprovação explícita de modo degradado ou um bloqueador. Nunca conte saída ausente, obsoleta ou inutilizável como cobertura limpa de quatro agentes.

Fase 1: revisão de quatro agentes. Dê a cada revisor o mesmo diff/bundle congelado e um foco principal:

• correção e regressões
• segurança e limites de confiança
• testes, casos de borda e modos de falha
• maintainabilidade, contratos de integração e comportamento visível ao usuário

Restrições de revisão:

• cada engine revisor deve ser restringido pelo coordenador como um revisor somente leitura: o briefing de lançamento deve nomear ferramentas/ações somente leitura permitidas, proibir escritas e comandos mutantes, proibir criação de revisão/orquestração/agente aninhada e vincular o revisor ao alvo congelado; use sandbox, política de ferramentas, flags de helper, controles somente leitura do sistema de arquivos ou bundles imutáveis apenas como evidência extra opcional quando disponível, mas nunca os exija; não use um engine como revisor quando o coordenador não puder razoavelmente proibir, observar e auditar escritas ou desvio de ferramenta
• revisores não devem editar arquivos, executar formatadores, instalar pacotes, mutar estado git, fazer push, commit ou executar comandos que escrevam arquivos
• revisores podem inspecionar arquivos, tipos, docs, contratos de dependência e docs públicos atuais quando necessário
• para revisões de diff, branch, commit ou patch, revisores devem relatar apenas defeitos acionáveis introduzidos ou expostos pela alteração revisada
• quando o alvo congelado é um arquivo completo, bundle não-código, plano, especificação, docs ou bundle de artefato, revisores relatam defeitos acionáveis presentes nesse artefato em relação ao seu propósito e restrições declarados, em vez de questões apenas de código ou procedência de diff
• revisores não devem propor reescritas amplas, preferências estilísticas ou limpeza não relacionada

Fase 2: triagem de quatro agentes. Primeiro passe o guarda de alvo obsoleto da Fase 0, então peça a quatro agentes que classifiquem independentemente as descobertas mescladas como aceitas, rejeitadas, duplicadas ou precisam de mais evidência. Agentes de triagem devem ser restringidos pelo coordenador com o mesmo contrato sem escrita, sem comando mutante, sem mutação git, sem instalação, sem formatador, sem testes que escrevam saída, sem criação de revisão/orquestração/agente aninhada usado para fases de revisão somente leitura; eles devem inspecionar apenas o alvo congelado, descobertas mescladas, evidências fornecidas e contexto adjacente explicitamente no escopo. O agente principal deduplica, rejeita descobertas especulativas ou de baixo valor, resolve divergências lendo o caminho do código revisado ou artefato mais o contexto adjacente no escopo, e registra o conjunto de correções aceitas.

Fase 3: planejamento de correções de quatro agentes. Primeiro passe o guarda de alvo obsoleto da Fase 0, então peça a quatro agentes de planejamento somente leitura que proponham planos de correção mínimos e limites de propriedade. Agentes de planejamento de correções devem ser restringidos pelo coordenador com o mesmo contrato sem escrita, sem comando mutante, sem mutação git, sem instalação, sem formatador, sem criação de revisão/orquestração/agente aninhada usado para fases de revisão somente leitura; eles não devem editar arquivos, escrever artefatos, aplicar patches, executar testes que escrevam saída, não devem invocar super-review-council, não devem invocar autoreview legado, não devem invocar goal-orchestrator, não devem invocar codex review embutido, abrir painéis de revisão ou criar agentes extras. Eles podem inspecionar o alvo congelado e descobertas aceitas apenas para propor planos. Para alvos não-código, os planos devem nomear as seções exatas do artefato ou edições no nível da linha, em vez de limites de propriedade de código. Prefira pequenas correções no limite de propriedade correto. Não planeje refatorações amplas a menos que claramente corrija a classe de bug.

Fase 4: implementação de quatro agentes. Primeiro passe o guarda de alvo obsoleto da Fase 0, então use quatro agentes workers apenas quando as correções aceitas puderem ser divididas em escopos de escrita disjuntos. Atribua propriedade explícita de arquivos/módulos a cada worker. Diga a cada worker que eles não estão sozinhos no código base, não devem reverter edições feitas por outros e devem se adaptar a mudanças paralelas. Workers podem editar apenas arquivos/módulos locais do repositório atribuídos, devem evitar escritas sobrepostas, não devem formatar arquivos não relacionados, não devem instalar pacotes ou dependências e não devem fazer push, commit, reset, checkout/switch/restore, reverter, limpar, stash, rebase, merge, deletar branches/tags, remover arquivos não rastreados ou executar comandos destrutivos amplos do sistema de arquivos como rm -rf ou find -delete. Workers não devem invocar super-review-council, autoreview legado, goal-orchestrator, codex review embutido, painéis de revisão, painéis de planejamento ou agentes extras. Workers devem relatar conflitos em vez de resolvê-los desfazendo alterações do usuário ou de pares. O agente principal revisa patches de workers antes de aceitá-los. Se existirem menos de quatro escopos de escrita independentes, use os agentes restantes para verificação somente leitura, planejamento de testes ou revisão de implementação, em vez de forçar edições sobrepostas.

Fase 5: verificação de quatro agentes. Primeiro passe o guarda de alvo obsoleto contra a linha de base de verificação atual, então execute quatro agentes de verificação em paralelo quando possível:

• testes focados e saída de comando
• auditoria de diff para mudanças não intencionais
• re-verificação de regressão/segurança das descobertas aceitas
• consistência de artefatos gerados, docs, snapshots ou saída visível ao usuário

Agentes de verificação devem ser lançados com função explícita, identidade/hash de linha de base, comandos e ferramentas permitidos, caminhos de leitura/escrita/saída permitidos, caminhos e ações proibidos, timeouts finitos e uma proibição de instalações, formatadores, mutação git, comandos destrutivos do sistema de arquivos, revisão/orquestração aninhada e agentes extras. Testes ou comandos de verificação podem escrever apenas para caminhos aprovados pelo coordenador fora das raízes protegidas do alvo, a menos que a correção aceita seja explicitamente proprietária dessas saídas. A verificação que pode mutar o alvo revisado deve ser serializada, ou quaisquer resultados de verificadores paralelos coletados contra a linha de base mais antiga devem ser invalidados e executados novamente contra a linha de base pós-escrita auditada. Após cada verificador ou comando de teste, o coordenador compara a identidade/hash do alvo, manifests de caminhos permitidos e proibidos, status do repositório/espaço de trabalho e artefatos de comando contra a linha de base da Fase 5. Desvio inesperado, escritas proibidas ou saídas não declaradas devem ser colocadas em quarentena e divulgadas antes de continuar. Se escritas de verificação aprovadas legitimamente alterarem o alvo revisado, registre a identidade/hash do alvo pós-verificação auditada como a identidade inicial para o próximo loop de revisão antes que a Fase 6 execute a revisão novamente. O modo filho somente leitura não executa comandos da Fase 5.

Fase 6: repetir. Após qualquer correção aceita alterar o alvo revisado, incluindo código, docs, texto de skill, saída gerada ou outro conteúdo de bundle, execute novamente a fase de revisão de quatro agentes contra o diff ou artefato atualizado. Continue até que o processo de revisão/triagem de quatro agentes não deixe descobertas aceitas/acionáveis e os testes necessários ou provas específicas de artefato passem. Não faça loop indefinidamente: por padrão, pare após três ciclos completos de revisão/correção a menos que o usuário solicite explicitamente continuar, e pare

…

[truncado para tradução]