Modo de execução em que cada etapa do trabalho tem um agente responsável — com papel definido, contexto mínimo carregado e handoff explícito para a etapa seguinte. Usado quando a demanda cruza domínios (escopo, produto, arquitetura, execução, qualidade), tem alto risco de interpretação ou exige rastreabilidade por papel.
Fonte: Manual/02AGENTS.md + Manual/05SCENARIOS-AGENTS.md + Manual/17EXECUTION-BASELINE.md
Pré-requisito: Manual/17EXECUTION-BASELINE.md (Execution Baseline)
Alternativa sem agentes: Docs/without-agents.md
Como ler este documento
O Manual de Agentes usa a arquitetura Baseline + Delta:
- Baseline (
Manual/17EXECUTION-BASELINE.md) — fluxo comum a todos os modos - Delta (
Manual/02AGENTS.md) — o que muda especificamente quando se usa agentes
Este documento consolida os dois para uso direto na web.
Baseline — Fluxo Comum de Execução
Antes de qualquer agente, a sequência base é sempre a mesma:
1. Definir objetivo, escopo e restrições da task
2. Selecionar 1 workflow principal em Workflows/
3. Definir skills de suporte técnico em Skills/
4. Editar os artefatos oficiais de Docs/ da demanda
5. Executar o trabalho técnico (com ou sem agente)
6. Aplicar Quality Gate e registrar evidências
7. Encerrar a task com rastreabilidade em Docs/control.mdRegra de Ouro (Baseline)
Templates em Templates/ são modelo.
Artefatos oficiais do projeto são editados em Docs/.
Protótipos HTML ficam em Prototype/.Artefatos mínimos por task
Docs/plan.md — plano da fase em andamento
Docs/tasks.md — lista de tasks com critérios de aceite
Docs/control.md — painel de rastreabilidade e statusGovernança obrigatória
- Bootstrap estrutural apenas na primeira task
- Após bootstrap: apenas edição de arquivos existentes
- Exatamente 1 commit por task concluída
- Quality Gate obrigatório antes de fechar taskDelta — O que muda no modo com agentes
Com agentes, a sequência baseline ganha 4 passos adicionais:
1. Selecionar o agente principal conforme o objetivo da task
2. Carregar contexto base + contexto de especialidade do agente
3. Declarar o formato de saída esperado antes da execução
4. Quando a próxima etapa mudar de domínio → fazer handoff para agente complementarCatálogo de Agentes
Quando usar cada agente
| Agente | Responsabilidade | Documentos que usa |
|---|---|---|
| ScopeAgent | Descoberta, escopo, brief, problem statement | brief.md, project.md |
| ProductAgent | US, pages, flow, protótipo, design system | user-stories.md, pages.md, flow.md, design-system.md |
| SystemAgent | Arquitetura, contrato, entities, structure, tokens | architecture.md, contract.yaml, entities.md, structure.md |
| ExecutionAgent | Plan, tasks, control, implementação técnica | plan.md, tasks.md, control.md |
| QualityAgent | Quality gate, validação de evidências, fechamento | quality-gate.md, tasks.md |
| ReleaseAgent | Deploy, rollback, entrega e estabilização | deploy.md, control.md |
| RecoveryAgent | Incidente, hotfix, análise de causa raiz | control.md, deploy.md |
Regra de seleção
Objetivo da task → agente principal:
Escopo não está claro → ScopeAgent
Produto, UI ou fluxo → ProductAgent
Arquitetura, API, domínio → SystemAgent
Implementação e código → ExecutionAgent
Validação e encerramento → QualityAgent
Publicação e entrega → ReleaseAgent
Incidente ou correção urgente→ RecoveryAgentHandoffs — Cadeia de Execução
Cadeia padrão por tipo de cenário
| Cenário | Cadeia de agentes |
|---|---|
| Nova feature com API e UI | ScopeAgent → ProductAgent → SystemAgent → ExecutionAgent → QualityAgent |
| Bug crítico em produção | RecoveryAgent → QualityAgent |
| Release planejada | ReleaseAgent → QualityAgent |
| Refatoração de módulo | ExecutionAgent → QualityAgent |
| Feature só de produto (sem backend novo) | ProductAgent → ExecutionAgent → QualityAgent |
O que registrar em cada handoff
Entrada: contexto recebido do agente anterior
Saída: artefatos produzidos e onde foram salvos
Risco: o que ficou indefinido ou pode gerar retrabalho
Próximo: qual agente assume e com qual objetivoPrompt canônico — Chamada de agente
Atue como [AgentName].
Objetivo: [objetivo da task]
Workflow: Workflows/[workflow].md
Carregue contexto base:
- GUIDE.md
- Skills/01GUIDE.md
- Workflows/01GUIDE.md
- Quality/01GUIDE.md
- Templates/Full/01GUIDE.md
Carregue contexto especializado:
- agents/[role]-agent.md
Carregue contexto de execução:
- Docs/plan.md
- Docs/tasks.md
- Docs/control.md
Aplique governança:
- bootstrap apenas na primeira task
- edit-only após bootstrap
- 1 commit por task
- Quality Gate obrigatório
Entregue:
1) plano da execução
2) execução com evidências
3) riscos e pendências
4) handoff (se houver próxima etapa)Prompt mínimo — Chamada rápida
Atue como [AgentName].
Objetivo: [objetivo]
Workflow: Workflows/[workflow].md
Contexto de execução: Docs/plan.md, Docs/tasks.md, Docs/control.md
Saída: plano, execução, evidências, riscos e pendênciasCenários com Agentes
Card de cenário (template)
# [Nome do cenário]
## Contexto
[o que motivou — gatilho]
## Objetivo
[resultado esperado]
## Workflow
Workflows/[workflow].md
## Agente principal
[AgentName]
## Skills
- Skills/[skill].md
## Docs editados
- Docs/plan.md
- Docs/tasks.md
- Docs/control.md
## Etapas
1. Planejar
2. Executar
3. Validar
4. Encerrar
## Evidências
- Quality Gate aprovado
- hash do commit
- riscos e pendênciasRegras dos cenários com agentes
1. Toda etapa do cenário deve ter dono explícito por agente
2. Cada handoff deve registrar entrada, saída e risco residual
3. O QualityAgent valida o fechamento em todos os cenários
4. O contexto de execução sempre em Docs: plan.md, tasks.md, control.mdEvidências de fechamento
Docs oficiais atualizados: Docs/tasks.md e Docs/control.md refletem a task encerrada
Quality Gate aprovado: Quality/gate.md critérios cumpridos
Hash do commit: 1 commit por task, hash registrado no control
Riscos e pendências: documentados em Docs/control.md
Handoff registrado: se houve passagem de agente, consta no controlChecklist do modo com agentes
( ) Agente principal correto para a demanda
( ) Contexto base carregado: GUIDE.md, Skills/01GUIDE.md, Quality/01GUIDE.md
( ) Contexto especializado carregado: agents/[role]-agent.md
( ) Workflow declarado explicitamente
( ) Handoff definido quando há mudança de domínio
( ) Saída registrada em Docs/tasks.md e Docs/control.md
( ) Quality Gate aprovado antes de fechar a task
( ) 1 commit com hash registrado no controlQuando usar agentes vs sem agentes
| Critério | Com agentes | Sem agentes |
|---|---|---|
| Demanda cruza múltiplos domínios | ✓ | — |
| Alto risco de interpretação | ✓ | — |
| Time quer clareza de responsabilidade por papel | ✓ | — |
| Demanda simples e bem definida | — | ✓ |
| Time pequeno e demanda de baixa complexidade | — | ✓ |
| Bootstrap de projeto | ✓ ou ✗ (indistinto) | ✓ ou ✗ |
Erros comuns
| Erro | Correção |
|---|---|
| Chamar agente sem declarar workflow | Workflow é obrigatório — orienta as etapas do agente |
| Pular contexto documental | Agente sem Docs/ trabalha por intuição — não por governança |
| Misturar múltiplos papéis em uma chamada vaga | Um agente, um objetivo, um workflow por turno |
| Não registrar handoff | Handoff sem registro gera contexto perdido na próxima etapa |
| Fechar task sem Quality Gate | Gate é obrigatório — aprovação documenta rastreabilidade |
| Mais de 1 commit por task | 1 task = 1 commit = 1 entrada no control |