agent-team

Transforme o mecanismo de colaboração "várias sessões = vários departamentos" em pastas de projeto. Não se trata de role-play, mas de um sistema de cargos: cada sessão tem responsabilidades fixas, limites de escrita, caixa de entrada, handoff e portões de auditoria.

Limites a serem respeitados primeiro

Primeiro, tenha uma base de projeto adequada ao cenário de negócios, depois construa a camada de colaboração. O diretório de destino padrão = diretório de trabalho atual; se faltar docs/ ou arquivos claros de objetivo/progresso/handoff, primeiro julgue o tipo de projeto: produtos de internet / Vibe Coding têm prioridade para sugerir vibe-project-foundation; outros cenários de negócios devem usar skills de base de negócios dedicados existentes ou a estrutura de arquivos atual. Se não houver uma base adequada, primeiro pergunte sobre o objetivo do negócio, entregáveis, critérios de aceitação, recursos de processo, riscos/métodos de revisão, depois ajude o usuário a criar uma base de negócios mínima e, em seguida, construa a camada de colaboração.
As três camadas devem estar completas: Gerência / Execução / Auditoria. A configuração mínima é lead, do, review; não divida departamentos à força apenas para ter "vários agentes".
Antes de criar docs/collaboration/, adicionar/remover/substituir departamentos, criar a primeira sessão de departamento, alterar roteamento entre sessões ou modos de notificação, primeiro obtenha a confirmação do usuário; despertares curtos já registrados como automáticos/manuais seguem tabela_de_departamentos.md e não precisam de confirmação repetida.
Não escreva código de negócios diretamente; este skill faz apenas diagnóstico de equipe, construção de camada de colaboração, registro de sessões e manutenção de regras de colaboração.
Se docs/collaboration/ já existir, não o sobrescreva; leia o estado atual primeiro, depois decida se é para adicionar departamentos incrementalmente, registrar sessões, atualizar regras ou reconstruir.
Portão rígido antes de iniciar: não assuma diretamente a partir de "me ajude a montar uma equipe/departamento" que é para desenvolvimento de produto de internet. Primeiro, confirme o entregável final do projeto e o modo de criação de sessão, depois recomende departamentos.

Regras de ferro da operação

Essas regras devem ser escritas nos artefatos gerados e seguidas em todas as tarefas subsequentes:

Portão de três tipos de nó: Cada funcionalidade/etapa avança apenas um nó de aceitação. Após a conclusão do nó do departamento, reporte primeiro ao departamento de coordenação; o departamento de coordenação julga por três tipos: nós de percepção de produto/limite importante devem ser confirmados pelo usuário, nós processuais/técnicos podem ser avançados de forma autônoma, nós que podem ser avançados autonomamente mas afetam a visibilidade do projeto devem ser relatados com um cartão de nó curto.
Caixa de entrada é a fonte da verdade: Os detalhes da tarefa e os relatórios são escritos na caixa_de_entrada.md do departamento correspondente; cada sessão de departamento faz o registro da capacidade de notificação apenas uma vez ao iniciar/trocar turno e, em seguida, segue o modo "automático/manual" registrado. As notificações expressam apenas três estados: nova tarefa / tarefa concluída / bloqueio encontrado.
Pacote de quatro itens para relatório de conclusão: Caminho do artefato, resultado da verificação (incluindo itens não verificados), recibo de log, autoinspeção de erros. Se faltar qualquer item, o departamento de coordenação não pode considerar o ciclo concluído.
Coordenação não consome contexto longo: O departamento de coordenação lê primeiro sua própria caixa de entrada, verificando apenas a existência do recibo de log; só lê o corpo mínimo necessário quando o relatório é insuficiente, o recibo está errado, as conclusões dos departamentos entram em conflito ou o usuário solicita.
Camada de auditoria independente não é igual a auditoria cega suficiente: O departamento de auditoria verifica pessoalmente, não herda o contexto longo do departamento de execução e não confia em relatos de "aprovado". Mas também não pode apenas repetir o caminho feliz do departamento de execução. Qualquer coisa que envolva o que o usuário vê/aviso/texto de erro/progresso/estado/pop-up/resumo de resultado/nome de arquivo exportado/janela de estado de empacotamento deve ser testada até o trabalhador/UI/saída final do usuário; testar apenas a camada engine/API/helper não conta. Para cada risco chave, pelo menos uma sonda reversa deve ser projetada.
Atribuição deve escrever saída de aceitação e caminhos de falha obrigatórios: A atribuição do departamento de coordenação deve escrever claramente saída_de_aceitação e caminhos_de_falha_obrigatórios. Saída de aceitação refere-se a onde o usuário vê o resultado/aviso/erro/estado/pop-up/resumo de resultado/nome de arquivo exportado/janela de estado de empacotamento; qualquer coisa visível ao usuário não deve ser escrita apenas na camada engine/API/helper. Caminhos de falha obrigatórios listam pelo menos 1-3 cenários de falha, exceção ou limite que quebram o caminho feliz. Se faltar, o departamento receptor retorna ao departamento de coordenação para complementar, não podendo preencher sozinho.
Experiência antes do teste: Funcionalidades executáveis são dadas primeiro para o usuário experimentar; ao entrar no nó "precisa que o usuário experimente o App", o departamento de coordenação por padrão abre o App diretamente para o usuário, sem perguntar primeiro "quer abrir?", depois dá um breve cartão de experiência. Somente após o usuário confirmar claramente "experiência OK / pode entrar em teste" é que o departamento de teste faz a verificação profissional de qualidade.
Intenção de design deve ser visualizada: Qualquer nó envolvendo UI, interação, apresentação visual, layout de página, esboço de design, caminho de experiência do usuário, o departamento de design não pode entregar apenas descrições de texto, wireframes ASCII, tabelas Markdown ou conclusões abstratas; deve fornecer uma prévia da intenção de design que o usuário possa julgar diretamente. A prévia de design não deve afirmar ser equivalente à UI real do App; a aceitação da UI real é baseada no App em execução / rota real / captura de tela do build ou pacote.
Confirmação de design independente da confirmação de funcionalidade: O usuário confirmar que a direção funcional está OK não é igual à aprovação visual/interação. Antes de o usuário confirmar a direção visual/interação do design, o departamento de coordenação não pode atribuir ao departamento de desenvolvimento para implementação formal; no máximo, pode avançar na viabilidade funcional ou avaliação técnica.
Auditoria cega/inspeção por amostragem acionada por gatilho: Quando uma cadeia de funcionalidades passa várias rodadas consecutivas sem bloqueio (padrão 3 rodadas, ajustável com explicação), o link cruza engine→trabalhador→UI→saída do usuário, envolve texto de erro/estado/publicação/empacotamento/segurança/custo de alto risco, ou o usuário/coordenação sente que a base da conclusão é insuficiente, um subagente aciona auditoria cega/inspeção por amostragem. O subagente apenas relata a conclusão da auditoria cega/inspeção, não modifica o código diretamente nem libera automaticamente.
Risco/custo acionado por gatilho: O departamento de segurança só intervém em grandes fases, antes de implantação/envio externo, ou quando surgem riscos de privacidade, permissão, chave secreta, autorização, plataforma de terceiros, configuração de produção; o departamento financeiro só intervém em nós de custo, apenas alertando e reportando sem bloquear a publicação.
Liberação decidida pelo usuário: Após as três portas de auditoria serem aprovadas, o departamento de coordenação dá apenas uma recomendação de liberação; marcação como concluída, publicação externa, pagamento, etc., são confirmados pelo usuário.
Regra de roteamento: Esclarecimentos (que não alteram artefatos, não decidem, não avançam estado) conectam-se diretamente à caixa de entrada da outra parte; para alterar/decidir/mudar estado/liberar/adicionar/remover departamentos, passe pelo departamento de coordenação.
Desvio de reprovação no teste: Após o usuário confirmar que a experiência está OK e entrar em teste, se o departamento de teste encontrar problemas puramente de código/qualidade/caminho anômalo, o departamento de teste escreve para a caixa de entrada do departamento de coordenação, que primeiro sincroniza com o usuário via cartão de nó e, em seguida, pode atribuir autonomamente ao departamento de desenvolvimento para retrabalho; só para e espera confirmação do usuário quando envolve trade-offs de experiência, mudança de escopo, custo/segurança/liberação, seleção de solução ou itens importantes.

Decisão do departamento de coordenação para três tipos de nós

O princípio de julgamento do departamento de coordenação:

O usuário é responsável pela experiência do produto, trade-offs de funcionalidade, julgamento de design e decisões de risco importantes; o departamento de coordenação é responsável pelo fluxo técnico, despacho de departamentos, portões de qualidade regulares e avanço sem controvérsias. O avanço autônomo deve manter um breve relatório; quando ocorrer percepção de produto ou mudanças de limite importante, deve parar e confirmar.

A. Deve ser confirmado pelo usuário

Qualquer nó que afete a experiência do produto, percepção do usuário, trade-offs de funcionalidade, design de interface, fluxo de interação, apresentação visual, limite do MVP, roteiro do produto, lançamento, entrega externa, aumento significativo de custo, privacidade/segurança/nuvem/chave secreta/autorização, o departamento de coordenação deve parar e deixar o usuário confirmar.

Situações típicas:

Após a funcionalidade ser concluída, o usuário precisa experimentar.
Após a UI/interação/esboço de design ser concluído, o usuário precisa ver a prévia visual.
Quando a saída do departamento de design contém apenas descrições de texto, wireframes ASCII, tabelas Markdown ou conclusões abstratas, isso não conta como conclusão do nó de design.
Quando o usuário apenas confirma que a direção funcional está OK, mas não confirma a direção visual/interação, não se pode entrar no desenvolvimento de implementação formal.
Quando funcionalidades precisam ser adicionadas, removidas, adiadas ou ter o escopo alterado, o usuário precisa decidir.
Se após o teste aprovado deve-se finalizar oficialmente ou entrar no próximo grande estágio, o usuário precisa confirmar.
Quando envolve nuvem, upload, chave de API, download de rede, custo, mudança significativa no tamanho do pacote, o usuário precisa confirmar.

B. O departamento de coordenação pode avançar autonomamente

Qualquer nó processual/técnico que o usuário não é adequado para julgar e que não muda a experiência do produto nem limites importantes, o departamento de coordenação pode avançar com base no julgamento profissional, sem perguntar repetidamente.

Situações típicas:

Após a confirmação do limite do produto, atribuir ao departamento de design para fazer um rascunho mínimo de interação.
Após o rascunho de design ser concluído, atribuir ao departamento de desenvolvimento para avaliação de implementação.
Quando o design visual/interação já foi confirmado pelo usuário, a avaliação técnica é clara e o risco é controlável, atribuir ao departamento de desenvolvimento para implementação formal; antes da confirmação da UI, apenas a avaliação de implementação/viabilidade técnica pode ser avançada.
Após a experiência do usuário estar OK, atribuir ao departamento de teste para verificação de qualidade.
Quando o departamento de teste, após o usuário confirmar que a experiência está OK, encontra problemas puramente de código/qualidade/caminho anômalo, o departamento de coordenação sincroniza com cartão de nó e atribui ao departamento de desenvolvimento para retrabalho.
Quando o teste não tem bloqueios P0/P1/P2, o departamento de coordenação pode recomendar aprovação e entrar em confirmação de fechamento.
Ações regulares como logs, handoffs, compartilhamento de erros, registro de progresso, verificação leve, commit após confirmação de fechamento pelo usuário.

C. Pode avançar autonomamente, mas deve reportar

Este tipo não precisa da aprovação do usuário, mas o departamento de coordenação deve informar ao usuário com um breve cartão de nó "a que passo eu avancei".

Exemplo de cartão de nó:

"Avaliação de desenvolvimento concluída, mas UI não confirmada; atribuí apenas avaliação de viabilidade técnica ao desenvolvimento."
"Design visual/interação confirmado e risco da avaliação de desenvolvimento controlável; já atribuí implementação formal ao desenvolvimento."
"Após sua experiência OK, já atribuí verificação de qualidade ao teste."
"Teste encontrou problema na camada de código, não envolve trade-off de produto; já atribuí retrabalho ao desenvolvimento."
"Teste sem bloqueios; me preparo para fechar e arquivar."
"Segurança/Financeiro não foram acionados neste nó, portanto não intervieram."

Saída de aceitação, caminhos de falha e auditoria cega/inspeção

A atribuição do departamento de coordenação deve escrever "onde verificar a aceitação" e "como quebrar o caminho feliz" na tarefa, não apenas um objetivo de aceitação abstrato.

Campos obrigatórios na atribuição:

saída_de_aceitação: Onde o usuário vê o resultado/aviso/erro/estado/pop-up/resumo de resultado/nome de arquivo exportado/janela de estado de empacotamento. Qualquer coisa visível ao usuário não deve ser escrita apenas na camada engine/API/helper.
caminhos_de_falha_obrigatórios: Pelo menos 1-3 cenários de falha, exceção ou limite para quebrar o caminho feliz.

Se faltar qualquer item, o departamento receptor deve retornar ao departamento de coordenação para complementar, não pode preencher sozinho.

Campos obrigatórios no relatório de auditoria/teste:

nível_de_verificação: engine / adapter-service / trabalhador-tarefa de fundo / UI-saída visível ao usuário / estado de empacotamento / níveis não cobertos.
saída_visível_ao_usuário: A saída final realmente testada.
sonda_reversa_do_próprio_design: Pelo menos uma para cada risco chave, explicando como provar que não se trata apenas de repetir o caminho feliz.
níveis_não_cobertos: Níveis não cobertos devem ser explicitamente escritos; se nenhum, escreva "nenhum".
auditoria_cega_ou_inspeção_por_amostragem_acionada_por_subagente: Escreva a conclusão e a justificativa.

Camada de auditoria independente não é igual a auditoria cega suficiente. O departamento de auditoria não pode apenas repetir o caminho feliz do departamento de execução; qualquer coisa que envolva o que o usuário vê/aviso/texto de erro/progresso/estado/pop-up/resumo de resultado/nome de arquivo exportado/janela de estado de empacotamento deve ser testada até o trabalhador/UI/saída final do usuário; testar apenas a camada inferior não conta.

Condições de gatilho para auditoria cega/inspeção:

Uma cadeia de funcionalidades passa várias rodadas consecutivas sem bloqueio, padrão 3 rodadas, ajustável conforme descrição do projeto.
O link cruza engine→trabalhador→UI→saída do usuário.
Envolve texto de erro, estado, publicação/empacotamento, segurança, custo, etc., de alto risco.
Usuário ou coordenação sente que a base da conclusão é insuficiente.

Após o gatilho, o subagente apenas faz o relatório de conclusão da auditoria cega/inspeção, não modifica o código diretamente nem libera automaticamente.

Desvio de retrabalho após falha no teste

O usuário ter aprovado a experiência do App significa apenas que o fluxo de experiência, expectativas de funcionalidade e percepção do usuário podem entrar em teste profissional; não significa que a qualidade do código, caminhos anômalos, estado de empacotamento, logs, condições de limite já foram aprovados. Se o departamento de teste encontrar problemas P0/P1/P2 ou outros de qualidade, primeiro escreve um relatório de auditoria e [relatório] para a caixa de entrada do departamento de coordenação. O departamento de coordenação deve primeiro sincronizar a conclusão com o usuário via cartão de nó e, em seguida, desviar por natureza do problema:

Pode atribuir autonomamente ao departamento de desenvolvimento para retrabalho: Bugs puramente de código, caminhos anômalos, texto de erro, logs, estado de empacotamento, inconsistência de saída trabalhador/UI, lacunas de cobertura de teste, etc.; esses problemas não exigem que o usuário faça julgamento de código.
Deve parar e esperar confirmação do usuário: Precisa alterar experiência do produto, escopo de funcionalidade, plano de design, limite do MVP, estratégia de retenção de dados, custo, segurança, privacidade, método de publicação, ou existem múltiplos planos de correção que sacrificariam experiência/escopo/custo/velocidade.

O cartão de nó deve escrever claramente: conclusão do teste, impacto, motivo do retrabalho, se envolve trade-off do usuário, julgamento da coordenação, próximo passo. Retrabalho autônomo significa apenas que entrou no ciclo de correção, não que a liberação final foi dada; após a correção, retorna ao nó de experiência do usuário/teste.

Fechamento e commit de arquivamento

Troca de turno não é igual a git commit. Quando um departamento conclui um nó, primeiro atualiza handoff, logs, relatório da caixa de entrada e artefatos necessários; commit é a ação de arquivamento no repositório após o usuário confirmar o fechamento formal.

Quando o teste não tem bloqueios P0/P1/P2, e as portas de risco/custo não têm bloqueios, o departamento de coordenação pode dar uma recomendação de liberação e solicitar que o usuário confirme o fechamento formal. Após a confirmação do usuário, o departamento de coordenação deve executar:

Executar git status --short.
Se a área de trabalho tiver apenas alterações relacionadas a este nó, executar commit para arquivar.
Se houver alterações não relacionadas, alterações não confirmadas pelo usuário ou não for possível determinar a qual pertencem, explicar primeiro ao usuário, não fazer commit misto.
Se o projeto não for um repositório git, explicar que não é possível fazer commit, apenas registrar o fechamento da camada de colaboração.

O commit de arquivamento não representa publicação externa; publicação, envio externo, pagamento, implantação ainda são decididos pelo usuário.

Nó de experiência do App

Ao entrar no nó "precisa que o usuário experimente o App", o departamento de coordenação, por padrão, abre o App diretamente para o usuário, sem perguntar primeiro "quer abrir?". Se o ambiente atual puder iniciar/abrir o App, executa diretamente; se a inicialização falhar, explica o motivo da falha, os comandos tentados e a entrada que o usuário pode abrir manualmente.

Padrão do cartão de experiência:

Entrada:
Foco:
Método sugerido:
Critério de julgamento:

Requisitos do cartão de experiência:

Entrada: Diga ao usuário por onde entrar, como "Dublagem/Clonagem de voz → IndexTTS2 Dublagem emocional → Intensidade emocional".
Foco: Diga ao usuário o que observar desta vez, apenas 1-2 focos.
Método sugerido: Dê 2-4 ações específicas para que o usuário não tenha que pensar em como testar.
Critério de julgamento: Diga ao usuário que basta responder "Experiência OK" ou indicar onde está ruim.

Exemplo:

Entrada: Dublagem/Clonagem de voz → IndexTTS2 Dublagem emocional → Intensidade emocional
Foco: Ouvir se a diferença entre os três níveis é óbvia e natural.
Método sugerido:
- Testar Feliz + Contido / Padrão / Vívido.
- Testar Spot de voz animado se assume Feliz + Vívido.
- Mudar para Natural e ver se fixa em Padrão e dá dica.
Critério de julgamento: Se achar bom, diga "Experiência OK"; se não, diga onde está ruim.

Nó de confirmação visual de design

Qualquer nó envolvendo UI, interação, apresentação visual, layout de página, esboço de design, caminho de experiência do usuário, o departamento de design deve entregar uma prévia da intenção de design que o usuário possa julgar diretamente, não apenas descrições de texto, wireframes ASCII, tabelas Markdown ou conclusões abstratas. A prévia da intenção de design é usada para julgar direção, layout, hierarquia de informação e sensação de interação, e não deve afirmar ser equivalente à UI real do App.

A aceitação da UI real deve vir do App em execução, rota real, artefato de build ou captura de tela do pacote. O OpenDesign / Figma / HTML mock / PNG do departamento de design só podem servir como base da intenção de design; após a implementação, o departamento de desenvolvimento deve marcar as diferenças em relação à intenção de design, e o departamento de teste usa a interface do App real para verificar se houve desvio.

Prioridade de entrega do departamento de design:

Priorizar o uso de ferramentas de design dedicadas, como OpenDesign, para gerar artefatos de design editáveis ou artifact.
Se a sessão atual não tiver hot-load do MCP OpenDesign, o OpenDesign não tiver um projeto ativo, permissões insuficientes ou falha de conexão da ferramenta, o departamento de design deve explicar claramente o motivo da falha no relatório.
Quando a ferramenta não estiver disponível, deve usar fallback local com HTML + captura de tela PNG, Figma, prévia de imagem que possa ser aberta, etc., garantindo que o usuário veja a intenção de design, mas não prometer que isso é a UI final real.
Se o usuário não quiser instalar, iniciar, autorizar, registrar ou reparar o OpenDesign, ou não quiser recarregar/abrir nova sessão para a sessão atual, o departamento de design não pode travar; deve escolher diretamente conforme preferência do usuário: HTML local + PNG, Figma ou prévia de imagem que possa ser aberta.

O item "caminho do artefato" no pacote de quatro itens do relatório de conclusão do departamento de design deve incluir simultaneamente:

Caminho do documento de especificação de design.
Caminho da prévia da intenção de design, como link do artifact OpenDesign / HTML local / captura de tela PNG / link Figma / imagem que possa ser aberta.
Se usar plano de fallback, deve escrever claramente o estado atual do OpenDesign e as condições para recuperação posterior.

Regras de integração do OpenDesign:

Primeiro, confirme se o App OpenDesign local está em execução, depois confirme o status de saúde do daemon.
Não presuma que a porta padrão é sempre 7456; deve confirmar a URL real do daemon a partir dos logs do OpenDesign ou da porta de escuta local.
Após confirmação, registre o MCP open-design no Codex; a sessão atual pode não conseguir hot-load de novo MCP; se necessário, oriente o usuário a recarregar/abrir nova sessão.
Se a gravação do artifact OpenDesign indicar que não há projeto ativo, solicite que o usuário crie ou entre em um projeto no OpenDesign, ou use HTML/PNG local como fallback para entrega, não travando o nó.
Se for detectado que o OpenDesign não está instalado/em execução, permissões insuficientes, falha de conexão ou MCP não hot-loadado, o departamento de design deve perguntar ativamente ao usuário se precisa de ajuda para instalar/iniciar/autorizar/registrar MCP/recarregar ou abrir nova sessão; se o usuário não resolver, vá imediatamente para o plano de visualização de fallback.
Ordem mínima de solução de problemas: Verificar se o App está em execução → Verificar a porta de escuta ou URL do daemon nos logs → Verificar se o MCP está registrado / se a sessão atual já o hot-loadou → Verificar projeto ativo → Verificar permissão/erro de conexão; qualquer falha em uma etapa deve fornecer simultaneamente um plano de prévia de fallback.
O OpenDesign é apenas uma capacidade aprimorada para expressão de design e confirmação visual, não representa expansão automática para redesign completo de UI, atualização de marca ou implementação de desenvolvimento.

Quando o departamento de coordenação recebe o relatório de design:

Primeiro, exiba a prévia da intenção de design, depois dê ao usuário um breve cartão de nó.
Estrutura sugerida do cartão de nó: Resultado / Pontos de julgamento / Sugestão / Risco / Próximo passo.
Não jogue longas explicações técnicas ou corpo de design diretamente para o usuário julgar.
Antes de o usuário confirmar a direção visual/interação do design, não atribua ao departamento de desenvolvimento para implementação formal; se o usuário apenas confirmar que a direção funcional está OK, mas a UI não foi confirmada, avance apenas na viabilidade funcional ou avaliação técnica.
O julgamento de UI após a conclusão do desenvolvimento não deve continuar citando a prévia da intenção de design em vez da interface real; deve retornar ao App real / rota real / captura de tela do build ou pacote.

Condições de parada para avanço autônomo

O avanço autônomo da coordenação não significa avanço contínuo ilimitado. Pode avançar nós processuais continuamente, mas nas seguintes situações deve parar e perguntar ao usuário:

A conclusão tem incerteza significativa.
Conflito de julgamento entre departamentos.
Precisa sacrificar qualquer item entre experiência, escopo, custo, velocidade.
Precisa adicionar nova dependência, nuvem, rede, modelo, custo.
Precisa mudar a direção do produto que o usuário confirmou anteriormente.
Precisa entrar em experiência de funcionalidade executável, confirmação visual de UI, publicação/empacotamento/envio externo, fechamento de grande fase.

Processo de diagnóstico

Se o usuário já explicou o tipo de projeto, entregável e modo de criação de sessão, diagnostique diretamente; não pergunte repetidamente. Quando faltar informação, faça apenas uma pergunta chave por vez.

Primeira pergunta:

O que este projeto vai entregar? Um software executável, conteúdo/curso, resultado de operação, plano de pesquisa, fluxo automatizado, entrega offline, ou outro?

Segunda pergunta:

Como as sessões dos departamentos serão criadas? Serão criadas automaticamente por um agente com ferramenta de gerenciamento de sessão (como o Codex), ou você criará manualmente as janelas de sessão de cada departamento primeiro, e eu só gero os arquivos do departamento e o guia de onboarding?

Antes de a primeira pergunta ser respondida claramente, não recomende o disco comum de software product/design/dev/test. Antes de a segunda pergunta ser respondida claramente, não afirme que criou sessões de departamento. Se o projeto estiver faltando arquivos de base, primeiro julgue se já existe um skill de base de cenário aplicável; se não, crie uma base de negócios mínima genérica, não direcione todos os projetos para vibe-project-foundation.

Durante o diagnóstico, fixe as três camadas, apenas julgue quantos departamentos de execução dividir e quantas portas de auditoria abrir:

Dimensão de gatilho	Impacto se acionado	Departamento
Software / Produto de internet / Vibe Coding / Tem artefato executável	Ativar disco de software	`product/design/dev/test`
UI/interação/visual pesado	Reforçar design	`design`
Coleta de dados, verificação de usuário/mercado/concorrente/fato pesada	Adicionar pesquisa	`research`
Plano, fluxo, cronograma, alocação de recurso pesado	Adicionar planejamento	`planning`
Coleta/limpeza/importação/exportação/precisão de dados pesada	Adicionar dados	`data`
Execução automatizada em lote, agendada, multiplataforma	Adicionar automação	`auto`
Produção contínua de texto/imagem/vídeo/relatório	Adicionar conteúdo	`content`
Operações de crescimento, conversão, retenção, monetização	Adicionar crescimento	`growth`
Conta, login, privacidade, conformidade, plataforma de terceiros, chave secreta, configuração de produção	Abrir porta de risco	`security`
Orçamento, custo sensível, itens pagos	Abrir porta de custo	`finance`
Funcionalidade complexa, precisa de cobertura de bug/exceção	Porta de qualidade independente	`test` ou `review`
Nenhum dos acima é forte	Disco mínimo genérico	`lead,do,review`

Projetos não-software não devem forçar produto/design/desenvolvimento/teste; primeiro julgue por entregável, critério de aceitação, recursos de processo, risco e método de revisão. Se não puder classificar, use lead,do,review, depois adicione research/planning/content/data/auto/security/finance conforme risco.

Seleção de base

A camada de colaboração depende de uma base de projeto que permita que os departamentos leiam o objetivo e os limites, mas base não é igual a um diretório de software fixo.

Ordem de processamento:

Primeiro, veja se o projeto já tem uma base utilizável: como docs/, plano de negócios, descrição do projeto, lista de entrega, arquivo de progresso/handoff, diretório específico da indústria. Se já existir, planeje as responsabilidades dos departamentos e os escopos de escrita com base na base existente, não force a mudança para estrutura de software.
Se for produto de internet, software, Vibe Coding ou claramente tiver artefatos como app/ design/ docs/spec.md, então priorize sugerir ou usar vibe-project-foundation.
Se for curso, conteúdo, operação, consultoria, entrega offline, pesquisa, processo interno, etc., projetos não-software, primeiro veja se há um skill de base de negócios dedicado ou modelo existente; se houver, use-o.
Se não houver base dedicada, não pare em "primeiro instale tal base de software". Primeiro, pergunte sobre o objetivo do negócio, entregável final, critério de aceitação, recursos de processo, risco/método de revisão, depois crie uma base de negócios mínima.

A base de negócios mínima contém apenas arquivos genéricos que suportam a colaboração:

docs/overview.md: Objetivo do projeto, entregável, público-alvo/usuário, limites.
docs/progress.md: Fase atual, concluído, em andamento, próximo passo.
docs/agent-guide.md: Regras de colaboração deste projeto, divisão de arquivos, notas.
Se necessário, crie diretórios como deliverables/, materials/, research/, operations/, scratch/ conforme o negócio; não crie diretórios de software irrelevantes.

Ao recomendar a equipe, forneça:

Quais departamentos em cada uma das três camadas e a justificativa.
Responsabilidades de cada departamento, itens proibidos, entrada, saída, escopo de escrita, escopo proibido de escrita.
Roteamento entre departamentos: Esclarecimento direto ou via coordenação.
Quais nós devem ser confirmados pelo usuário.
Modo de criação de sessão: criação automática de sessão ou criação manual de janela de sessão, e os passos de execução correspondentes.

Pare antes de criar para confirmar:

Sugiro criar docs/collaboration/ com a configuração de equipe acima, modo de sessão: [Automático / Manual]. Confirma?

Construir a camada de colaboração

Após confirmação, execute o script. Se não houver base dedicada e o usuário confirmar que este skill deve complementar a base de negócios mínima, adicione --create-minimal-foundation --allow-without-foundation. Disco mínimo genérico padrão:

python3 <diretório_do_skill>/scripts/scaffold_team.py "<diretório_alvo_do_projeto>" \
  --profile "<resumo_do_diagnóstico_da_equipe>" \
  --session-mode "manual"

Ao expandir conforme diagnóstico, passe os papéis explicitamente:

python3 <diretório_do_skill>/scripts/scaffold_team.py "<diretório_alvo_do_projeto>" \
  --profile "Software + Dados fortes + Envolve privacidade/plataforma + Tem orçamento" \
  --roles "lead,product,design,dev,data,test,security,finance" \
  --session-mode "auto"

Papéis opcionais:

Gerência: lead
Execução: do/research/planning/product/design/dev/data/auto/content/growth
Auditoria: review/test/security/finance

O script criará docs/collaboration/README.md, tabela_de_departamentos.md, lista_de_inicialização_de_sessão.md, regras_de_roteamento_de_leitura.md, coleção_de_erros.md, modelo_de_handoff_de_tarefa.md, conclusões_especiais/, scripts/agent_team_read.py e, sob departamentos/<nome_do_departamento>/, descrição_do_cargo.md, guia_de_onboarding.md, documento_de_handoff.md, caixa_de_entrada.md, relatórios/, logs/<semana_ISO>.md; a camada de auditoria tem adicionalmente relatórios_de_auditoria/ (semanticamente relatório de auditoria). O script se recusa a sobrescrever uma camada de colaboração existente, recusa papéis duplicados e recusa uma nova equipe que não tenha pelo menos um departamento em cada uma das três camadas; se --session-mode auto/manual não for passado, aborta para evitar contornar a confirmação do modo de sessão.

Modo de criação de sessão

Criação automática de sessão (Codex / com ferramenta de gerenciamento de sessão)

Após o usuário confirmar o modo automático:

Primeiro, execute o script para criar docs/collaboration/.
Use tool_search para pesquisar as três ferramentas de sessão: create_thread, send_message_to_thread, set_thread_title; fixar, ordenar não são capacidades necessárias.
Se as ferramentas estiverem disponíveis, crie uma sessão para cada departamento; o título deve usar prefixo numérico para manter a ordem, como 01 Departamento de Coordenação, 02 Departamento de Produto, 03 Departamento de Desenvolvimento.
Envie o guia_de_onboarding.md de cada departamento como mensagem de inicialização para a sessão correspondente, solicitando que a sessão primeiro assuma o turno, apenas relatando responsabilidades / fase / em andamento / caixa de entrada / questões pendentes, sem fazer tarefas de negócio imediatamente.
Escreva o ID da sessão retornado em docs/collaboration/tabela_de_departamentos.md e registre o modo de notificação como automático. Se a ferramenta de envio falhar, altere o modo de notificação deste departamento para manual e explique ao usuário que a criação automática de sessão falhou.
Por fim, informe ao usuário: quais sessões foram criadas, quais IDs de sessão foram registrados, quais precisam de processamento manual pelo usuário.

Se a ferramenta não estiver disponível ou a chamada falhar, não diga "sessão criada"; finalize com modo manual.

Criação manual de janela de sessão (Outro agente / sem ferramenta de gerenciamento de sessão)

Após o usuário confirmar o modo manual:

Execute apenas o script para criar docs/collaboration/ e os arquivos de cada departamento.
Não chame ferramentas de sessão, não afirme que criou sessões.
Produza uma lista de onboarding manual: o caminho do guia_de_onboarding.md de cada departamento, nome de janela sugerido, a primeira frase que o usuário precisa colar para aquela sessão.
O ID da sessão em docs/collaboration/tabela_de_departamentos.md permanece a registrar, e o modo de notificação permanece a registrar ou altere para manual conforme instrução do usuário.
Após o usuário criar manualmente as janelas, envie o guia_de_onboarding.md de cada departamento para a sessão correspondente; a sessão do departamento primeiro executa python3 docs/collaboration/scripts/agent_team_read.py onboard --dept [nome_do_departamento], depois, conforme os arquivos obrigatórios retornados pelo script, lê a descrição do cargo, handoff, coleção de erros, caixa de entrada; a partir de então, todos os handoffs são escritos na caixa_de_entrada.md da pasta do departamento correspondente.

Verificação pós-criação:

Estrutura de docs/collaboration/ completa, cada uma das três camadas com pelo menos um departamento.
docs/agent-guide.md já inclui descrição de colaboração multi-sessão.
docs/collaboration/lista_de_inicialização_de_sessão.md já especifica o modo automático/manual e a entrada de onboarding para cada departamento.
No modo automático, tabela_de_departamentos.md já registrou IDs de sessão reais e modos de notificação; no modo manual, já informou claramente ao usuário que as sessões ainda não foram criadas.
docs/progress.md registra a criação da camada de colaboração, resumo da configuração da equipe, próximo passo.
git status --short; se houver apenas alterações relacionadas a esta camada de colaboração, pode-se fazer commit separadamente:

git add docs/agent-guide.md docs/progress.md docs/collaboration
git commit -m "chore: construir camada de colaboração multi-sessão"

Se o repositório já tiver outras alterações não commitadas, não faça commit misto, explique ao usuário.

Modo de manutenção

Posteriormente, pode ser necessário adicionar/unir/remover departamentos, substituir sessões, registrar IDs de sessão, ajustar limites, atribuir tarefas ou fazer auditoria independente. Princípios de processamento:

Primeiro, leia docs/collaboration/tabela_de_departamentos.md, confirme as três camadas atuais e os departamentos.
Julgue se fere "pelo menos um em cada uma das três camadas" ou os limites de responsabilidade.
Envolvendo adicionar/remover/substituir departamentos, mensagens entre sessões, liberação, retrabalho, atualização de estado, primeiro confirme com o usuário.
Para adicionar departamento, use scaffold_team.py <projeto> --add-roles "<ids>"; o script apenas complementa os departamentos ausentes e adiciona à tabela; ainda é necessário sincronizar manualmente as regras de fluxo afetadas.
Para remover/unir departamentos, primeiro registre itens em andamento e histórico nos logs, depois atualize a tabela de departamentos e as descrições de cargo relevantes; não delete histórico diretamente.
Registro de capacidade de notificação é feito apenas uma vez ao iniciar/trocar turno:
- Leia o "modo de notificação" do departamento em tabela_de_departamentos.md. Se já registrado como automático ou manual, esta sessão segue esse modo para todas as ações subsequentes, não redescobrindo ferramentas a cada tarefa concluída.
- Se o modo de notificação for a registrar, quando houver tool_search, procure por ferramentas de envio como send_message_to_thread; se não houver tool_search ou não encontrar ferramenta de envio, registre como manual.
- automático: Notificações subsequentes por padrão chamam diretamente a ferramenta de envio de sessão para enviar despertar curto, sem verificação prévia de capacidade.
- manual: Notificações subsequentes por padrão fornecem ao usuário um despertar curto copiável, pedindo que o usuário lembre manualmente o departamento alvo.
- Se a chamada real do modo automático falhar, reverta para lembrete manual desta vez e peça ao usuário para informar a sessão do departamento de coordenação para atualizar tabela_de_departamentos.md.
- Se o usuário descobrir que a capacidade da ferramenta do agente mudou, peça ao usuário para informar a sessão do departamento de coordenação, que atualizará o modo de notificação em tabela_de_departamentos.md.
Prioridade de roteamento de leitura:
- Nova sessão de departamento ou troca de turno primeiro executa python3 docs/collaboration/scripts/agent_team_read.py onboard --dept [nome_do_departamento] para que o script retorne a identidade do departamento, modo de notificação, arquivos obrigatórios e limites de leitura padrão.
- Relatórios, relatórios de auditoria, conclusões especiais, decisões chave usam frontmatter YAML para escrever type / department / target / status / date / related_task / decision / tags / summary; o script apenas retorna esses campos pré-escritos manualmente, sem fazer resumo criativo.
- Antes de verificar evidências, execute prioritariamente agent_team_read.py find --type audit_report --status blocked, agent_team_read.py find --type special_conclusion --tag saída_visível_ao_usuário ou agent_team_read.py meta <caminho>; só quando o resumo for insuficiente, o caminho for anômalo, as conclusões entrarem em conflito, envolver liberação/retrabalho/segurança/custo/publicação/qualidade visível ao usuário, o usuário solicitar verificação de evidências ou a tarefa atual depender explicitamente do corpo, é que se lê o corpo mínimo necessário.

AidenXu-1/agent-team-skill

O que é agent-team-skill?

Perguntar na sua IA favorita

Documentação