TheStreamCode/agentic-rd-skill

Fluxo de Trabalho de P&D Agentic

Use este pacote de skill autocontido para automatizar um fluxo de trabalho de laboratório multiagente, com foco em Markdown, dentro do espaço de trabalho atual.

Esta é uma adaptação de propósito geral do padrão Agent Laboratory: revisão independente de evidências, formulação colaborativa de planos, execução ou investigação de tarefas, análise de resultados, revisão de qualidade e redação do relatório final. Não se limita à pesquisa científica; aplique o mesmo fluxo de laboratório para casos de uso de produto, negócios, técnico, estratégia, jurídico, conformidade, segurança, UX, mercado e operacional.

Projetado para agentes de codificação compatíveis com skills e com acesso ao sistema de arquivos. Prefira subagentes paralelos reais sempre que o ambiente os suportar; use passes simulados isolados apenas quando subagentes reais não estiverem disponíveis.

Conteúdo do Pacote

• SKILL.md: regras de ativação e instruções operacionais principais.
• references/generalized-lab-model.md: modelo universal de Laboratório de Agentes e mapeamento de casos de uso.
• references/workflow.md: sequência completa de fases e gate de aprovação.
• references/agent-roles.md: orientação para seleção de papéis especialistas.
• references/quality-rules.md: padrões de evidência, incerteza, revisão e segurança.
• references/implementation-notes.md: notas sobre instalação, scaffolding, subagentes e manipulação de arquivos.
• references/example-run.md: um exemplo compacto de ponta a ponta mostrando o rastro de arquivos esperado e a qualidade da saída.
• assets/templates/: modelos Markdown para todos os arquivos do fluxo de trabalho.
• scripts/init-rd-workflow.mjs: script opcional de scaffolding.
• scripts/validate-skill.mjs: validação do repositório para o pacote de skill público.

Primeira Ação

1. Procure por project-brief.md no espaço de trabalho atual.
2. Se existir, leia-o completamente antes de qualquer outra etapa do fluxo de trabalho.
3. Se não existir e o usuário forneceu contexto suficiente, crie-o usando assets/templates/project-brief.md.
4. Se faltar contexto essencial, faça apenas as perguntas mínimas que estão bloqueando o andamento.
5. Após o briefing existir, continue sem pedir permissão entre as fases normais do fluxo de trabalho.

Execute scripts/init-rd-workflow.mjs para criar o scaffolding de project-brief.md e os arquivos work/ necessários. O script não deve criar work/06-final-output.md.

Saídas Obrigatórias

Crie e use esta estrutura no espaço de trabalho ativo:

work/
├── 00-lab-notes.md
├── 01-orchestration-plan.md
├── 02-specialist-outputs/
├── 03-team-collaboration.md
├── 04-cross-review-notes.md
├── 05-stage-gate-review.md
└── 06-final-output.md

Cada fase do fluxo de trabalho mapeia para um caminho de saída específico. As fases numeradas do laboratório (revisão de evidências, formulação do plano, execução, análise de resultados) não são arquivos separados: elas são materializadas como um arquivo por especialista dentro de work/02-specialist-outputs/.

Fase	Caminho de saída
Configuração do laboratório	work/00-lab-notes.md
Orquestração	work/01-orchestration-plan.md
Revisão de evidências, plano, execução, resultados (um arquivo por especialista)	work/02-specialist-outputs/NN-<papel>.md
Colaboração da equipe (consolidada pelo orquestrador)	work/03-team-collaboration.md
Revisão cruzada	work/04-cross-review-notes.md
Revisão de gate	work/05-stage-gate-review.md
Síntese final	work/06-final-output.md

Não crie ou escreva work/06-final-output.md até que work/05-stage-gate-review.md diga Aprovado.

Fluxo de Trabalho

1. Leia references/workflow.md para a sequência canônica de fases.
2. Leia references/generalized-lab-model.md para mapear o caso de uso do usuário nas fases do laboratório.
3. Leia references/agent-roles.md antes de selecionar especialistas.
4. Leia references/quality-rules.md antes da revisão cruzada, revisão de gate e síntese final.
5. Use references/implementation-notes.md para uso de scripts, comportamento de subagentes e detalhes de manipulação de arquivos.
6. Use modelos de assets/templates/ para os arquivos gerados do fluxo de trabalho.
7. Consulte references/example-run.md para um exemplo trabalhado de ponta a ponta quando não tiver certeza sobre a qualidade esperada da saída.

Escalone Para o Briefing

Ajuste o peso do fluxo de trabalho ao briefing. Não execute um laboratório completo de múltiplas ondas para uma pergunta pequena.

• Briefing trivial: o orquestrador pode fazer um único passe inline sem subagentes. Registre evidências, suposições e riscos em work/00-lab-notes.md, escreva uma auto-verificação curta em work/05-stage-gate-review.md e depois work/06-final-output.md. Os arquivos intermediários de especialista, colaboração e revisão cruzada são opcionais neste nível. A regra do gate ainda se aplica: não escreva 06-final-output.md até que 05-stage-gate-review.md diga Aprovado.
• Briefing pequeno ou restrito: use um ou dois especialistas, execute uma única onda e incorpore a colaboração nas notas do orquestrador em vez de uma troca separada. Mantenha a revisão cruzada, revisão de gate e síntese final como um único passe rápido cada.
• Briefing médio: use alguns especialistas em uma ou duas ondas com uma etapa leve de colaboração da equipe.
• Briefing grande ou regulado: use a sequência completa de fases, múltiplas ondas, colaboração explícita da equipe e os papéis de revisão relevantes.

Sempre mantenha o mínimo obrigatório independentemente do tamanho: revisão de evidências/contexto, formulação do plano, execução ou investigação, análise de resultados, cobertura de riscos/suposições e o gate de qualidade antes da síntese final. Todo o resto é opcional e adicionado apenas quando altera materialmente a entrega. Veja references/generalized-lab-model.md para os detalhes de escalonamento.

Regras de Execução

• Selecione o menor número de papéis especialistas que cubra bem o briefing.
• Inclua sempre revisão de evidências/contexto, formulação do plano, execução ou investigação, análise de resultados e cobertura de riscos/suposições.
• Prefira subagentes paralelos reais. Eles são o modelo de execução primário para esta skill, não uma melhoria opcional.
• Em cada fase, dispare todos os especialistas independentes antes de aguardar resultados. Não execute especialistas independentes um de cada vez quando subagentes paralelos estiverem disponíveis.
• Caso contrário, simule especialistas como passes isolados. Cada passe deve ler apenas o briefing, o plano de orquestração e seu escopo atribuído antes de escrever seu próprio arquivo.
• Nunca colapse análise de especialista, revisão cruzada, revisão de gate e síntese final em uma única resposta.
• Paralelize o trabalho de especialistas independentes, mas mantenha as gates de dependência sequenciais: revisão antes do plano, plano antes da execução, execução antes da análise de resultados, revisão antes do relatório final.
• Exija citações ou notas de fonte para alegações factuais quando fontes estiverem disponíveis.
• Marque alegações sem suporte como suposições ou inferências.
• Preserve a incerteza e os limites de revisão de domínios regulados.

Protocolo de Equipe Colaborativa

• Trate os subagentes como uma equipe colaborativa, não como redatores de relatórios desconectados.
• O Orquestrador Mestre define papéis da equipe, propriedade, dependências e regras de colaboração em work/01-orchestration-plan.md.
• Cada subagente escreve apenas seu próprio arquivo de saída especialista e retorna suas perguntas, dependências, divergências e notas de handoff ao orquestrador (em seu resultado, não editando um arquivo compartilhado).
• O orquestrador consolida essas notas retornadas em work/03-team-collaboration.md. Nunca permita que múltiplos subagentes escrevam o mesmo arquivo simultaneamente.
• A equipe deve reconciliar suposições compartilhadas antes da revisão cruzada.
• A revisão cruzada avalia tanto as saídas dos especialistas quanto o registro de colaboração da equipe.
• A síntese final deve refletir acordos resolvidos, divergências não resolvidas e visões minoritárias importantes.

Condições de Parada

Pare e pergunte ao usuário apenas quando:

• O assunto ou objetivo não for identificável.
• A saída desejada não puder ser inferida.
• Restrições-chave entrarem em conflito.
• Dados externos necessários, credenciais, sistemas privados, ferramentas pagas ou acesso de rede indisponível bloquearem o trabalho.
• Conselhos legais, médicos, financeiros, de conformidade, segurança ou críticos para a segurança não puderem ser mantidos dentro de um limite informacional seguro.

Conclusão

Quando o fluxo de trabalho for concluído, informe ao usuário quais arquivos foram criados e se o gate de etapa aprovou a síntese final. Mantenha a mensagem de conclusão concisa.