| name | flow-domain-creator |
| description | Cria Domain Documents (Nível 1) para domínios específicos de um sistema complexo. Use esta skill sempre que o usuário quiser detalhar um domínio, módulo ou bounded context após o Vision Doc estar aprovado. Dispare quando o usuário mencionar "domain doc", "detalhar o domínio X", "documentar o módulo X", "bounded context", "quais features do domínio X", "vamos detalhar o financeiro/RH/estoque" ou qualquer variação que indique a necessidade de aprofundar um domínio específico antes de criar PRDs. Esta skill é o Nível 1 do pipeline Vision → Domain → PRD → TechSpec → Tasks. Requer que o Vision Doc já exista em `vision.md`. O documento gerado serve como entrada para a skill `flow-prd-creator`.
|
| pipeline_stage | domain |
| consumed_by | ["planning"] |
| requires | ["vision.md"] |
| produces | ["domains/[dominio]/domain.md"] |
Domain Creator
Detalha um domínio específico do sistema com bounded context claro, entidades de negócio, features
priorizadas, regras de negócio e mapa de dependências. O documento gerado serve como entrada
para a skill flow-prd-creator ao criar PRDs das features deste domínio.
Template
Antes de redigir, leia o template em templates/domain-template.md.
Entradas e Saída
- Entrada obrigatória:
vision.md (deve estar disponível no contexto ou fornecido pelo usuário)
- Documento de saída:
domains/[nome-do-dominio]/domain.md
Pré-requisitos
Antes de começar, confirme:
-
O vision.md foi fornecido?
- Se não: solicite ao usuário antes de continuar. Sem ele, não há como garantir coerência de escopo.
- Se sim: leia-o completamente antes de qualquer pergunta.
-
O domínio a detalhar foi identificado?
- Se não: liste os domínios disponíveis no Vision Doc e peça ao usuário para escolher.
- Se sim: confirme o nome exato conforme registrado no Vision Doc.
Fluxo de Trabalho
1. Analisar o Vision Doc
Antes de fazer qualquer pergunta, extraia do Vision Doc:
- Responsabilidade declarada do domínio
- Dependências já identificadas no mapa de interdependências
- Fase do roadmap em que o domínio está inserido
- Perfis de usuário que interagem com este domínio
- Termos do glossário relevantes para este domínio
2. Esclarecer (Não pule esta etapa)
Faça perguntas focadas apenas no que não está claro no Vision Doc. Não repita o que já foi respondido.
Responsabilidade e fronteiras:
- Qual é a responsabilidade exata em uma frase?
- O que parece pertencer a este domínio mas está explicitamente excluído?
- Onde termina este domínio e começa o próximo?
Usuários e uso:
- Quais perfis interagem com este domínio? Com que frequência?
- Qual é a ação mais crítica que cada perfil executa?
Entidades e regras:
- Quais são os objetos de negócio centrais? (não schemas — entidades de negócio)
- Existem regras de negócio importantes que governam este domínio?
- Há regras que variam por cliente, região ou configuração?
Features:
- Quais funcionalidades este domínio precisa entregar?
- Qual seria a feature mínima para o domínio ser utilizável?
- Alguma feature tem dependência direta de outro domínio?
Integrações:
- Há sistemas externos com os quais este domínio precisa se comunicar?
- Há eventos assíncronos entre este domínio e outros?
Se houver informações críticas ausentes, continue perguntando. Não gere o Domain Doc ainda.
3. Planejar
Apresente ao usuário antes de redigir:
- Bounded context proposto — responsabilidade em uma frase + fronteiras
- Lista de entidades principais com descrições curtas
- Lista de features com prioridade MoSCoW sugerida
- Mapa de dependências — upstream, downstream, externas
- Regras de negócio identificadas (numeradas RN-01, RN-02...)
- Eventos do domínio — produz e consome
- Ordem de implementação sugerida
- Riscos e questões em aberto
Aguarde confirmação antes de redigir.
4. Redigir o Domain Doc
Use o template templates/domain-template.md.
Diretrizes obrigatórias:
- Linguagem de negócio, não técnica — entidades são objetos de negócio, não tabelas de banco
- Fronteiras explícitas — a seção "Fora do Escopo" é obrigatória e deve ser específica
- Features numeradas — use F01, F02... para rastreabilidade nos PRDs
- Regras de negócio numeradas — use RN-01, RN-02... para referenciar nos critérios de aceitação dos PRDs
- Eventos no formato
dominio.evento — ex: pagamento.realizado
- Consistência com o Vision Doc — nomes de domínios, perfis e termos devem ser idênticos ao Vision Doc
- Manter entre ~600 e 1.200 palavras no corpo principal (excluindo tabelas)
5. Validação Interna
Antes de finalizar, execute a autoavaliação:
Se houver falhas, corrija antes de prosseguir.
6. Salvar e Confirmar
- Salvar como:
domains/[nome-do-dominio]/domain.md
- Confirmar operação de escrita e caminho
7. Protocolo de Saída
A resposta final deve conter:
- Resumo das decisões principais — bounded context definido, features priorizadas, dependências críticas
- Conteúdo completo do Domain Doc em Markdown
- Caminho do arquivo salvo
- Próximos passos — quais features estão prontas para ter PRD criado, em ordem sugerida
- Questões em aberto que precisam de validação antes dos PRDs
- Indicação de próximo passo: "Para criar PRDs das features deste domínio, use a skill
flow-prd-creator fornecendo o vision.md e este domain.md como contexto"
Como Usar nos PRDs
Ao iniciar uma sessão de PRD para uma feature deste domínio, forneça:
vision.md — contexto global do sistemadomains/[nome]/domain.md — contexto do domínio- ID da feature a detalhar (ex: "Vamos criar o PRD da feature F02 — Aprovação de Pagamentos")
O agente flow-prd-creator usará as entidades, regras de negócio (RN-XX) e perfis de usuário já definidos, evitando retrabalho de discovery.
Princípios Fundamentais
- Um domínio, uma responsabilidade — se não cabe em uma frase, o domínio é grande demais
- Fronteiras são contratos — o que está fora do escopo é tão importante quanto o que está dentro
- Entidades são vocabulário de negócio — evite termos como "tabela", "registro", "endpoint"
- Dependências são riscos — minimize-as sempre que possível no design do domínio
- Coerência com o Vision Doc é inegociável — qualquer divergência deve ser resolvida atualizando o Vision Doc primeiro
