4. Templates de Prompt

Templates copiáveis para gerar apps completos (CRM, ERP, Helpdesk, OKRs e mais).

Copie um template. Ajuste os placeholders. Gere o app. Depois itere em cima da especificação.

Quer ver o fluxo completo (prompt → deploy)? Combine com Demonstrações.

Como usar (30s)

1

Escolha um template e defina o escopo

Decida módulos e o “mínimo que precisa funcionar”. Evite pedir tudo na primeira geração.

2

Troque os placeholders e cole no Madrix

Troque {{NOME_DO_PROJETO}}, {{IDIOMA_UI}} e {{PERFIS}}. Cole o prompt e clique em Gerar.

3

Aprove a especificação e valide no Preview

Valide entidades, regras e permissões. Depois valide o básico no Preview com dados de teste.

4

Itere em mudanças pequenas

Peça ajustes por bloco. Exemplo: “adicione campo X + validação + ajuste formulário”.

Placeholders (padrão)

Use estes marcadores para personalizar rápido.

• {{NOME_DO_PROJETO}}: nome do projeto.

• {{IDIOMA_UI}}: pt-BR ou en-US.

• {{PERFIS}}: papéis do sistema. Ex: Admin, Gestor, Operador.

• {{REGRAS_DE_NEGOCIO}}: regras “se/então” e transições.

• {{INTEGRACOES}}: webhooks, importação, APIs externas.

Exemplos genéricos (copiar e colar)

Use quando você ainda não tem um template por domínio. São blocos neutros para compor seu app.

Genérico — CRUD + permissões (rápido)

Crie um projeto chamado: {{NOME_DO_PROJETO}}

Objetivo: app CRUD simples, com permissões por perfil e validações básicas.
Idioma da UI: {{IDIOMA_UI}}.

Perfis (RBAC):
- Admin: acesso total
- Operador: criar/editar registros
- Leitor: somente leitura

Entidades:
- Registro:
  - titulo (obrigatório)
  - descricao
  - status (Ativo | Inativo)
  - criadoEm (data/hora)
  - criadoPor (1 Usuario)

Regras de negócio:
- Operador só pode editar registros que criou.
- Leitor não pode criar/editar/excluir.

Telas mínimas:
- Lista de registros (filtros por status + busca por titulo)
- Criar/editar registro (validações)
- Detalhe do registro

Critérios de aceitação:
- Admin vê tudo.
- Operador cria e edita apenas o que criou.
- Leitor consegue listar e abrir detalhe, sem editar.

Genérico — workflow (estados + transições)

Crie um projeto chamado: {{NOME_DO_PROJETO}}

Objetivo: app com workflow e trilha de aprovação simples.
Idioma da UI: {{IDIOMA_UI}}.

Perfis (RBAC):
- Admin
- Solicitante
- Aprovador

Entidades:
- Solicitacao:
  - titulo (obrigatório)
  - descricao
  - valor (moeda, opcional)
  - status (Rascunho | Enviada | Aprovada | Reprovada | Cancelada)
  - solicitante (1 Usuario)
  - aprovadoPor (0..1 Usuario)
  - criadoEm (data/hora)

- HistoricoStatus:
  - solicitacao (1 Solicitacao)
  - deStatus
  - paraStatus
  - autor (1 Usuario)
  - comentario
  - criadoEm (data/hora)

Regras de negócio:
- Transições permitidas:
  - Rascunho -> Enviada
  - Enviada -> Aprovada | Reprovada
  - Rascunho -> Cancelada
  - Enviada -> Cancelada (somente Admin)
- Somente Aprovador pode aprovar/reprovar.
- Sempre registrar HistoricoStatus em qualquer transição.

Telas mínimas:
- Minhas solicitações (solicitante)
- Fila de aprovações (aprovador)
- Detalhe da solicitação + histórico de status

Critérios de aceitação:
- Solicitante envia e não edita após Enviada.
- Aprovador aprova/reprova com comentário.
- Histórico lista todas as mudanças de status.

Genérico — integrações (webhook/API + log + reprocessar)

Crie um projeto chamado: {{NOME_DO_PROJETO}}

Objetivo: app com integração externa via webhook/API, com logging e reprocessamento.
Idioma da UI: {{IDIOMA_UI}}.

Perfis (RBAC):
- Admin
- Operador

Entidades:
- EventoIntegracao:
  - tipo (Outbound | Inbound)
  - sistema (obrigatório)
  - evento (obrigatório)
  - payload (texto/json)
  - status (Pendente | Sucesso | Erro)
  - tentativas (numero)
  - ultimoErro
  - criadoEm (data/hora)
  - processadoEm (data/hora, opcional)

Fluxo de integração:
- Ao criar/atualizar um Registro, disparar um evento Outbound.
- Enviar payload para um endpoint configurável (por ambiente).
- Registrar sucesso/erro em EventoIntegracao.
- Permitir “Reprocessar” eventos com status Erro.

Regras de negócio:
- Máximo de 5 tentativas por evento.
- Somente Admin pode reprocessar manualmente.

Telas mínimas:
- Configurações: endpoints por ambiente (Dev/Staging/Prod)
- Log de integrações (filtro por status + sistema + período)
- Detalhe do evento (payload + erros + botão reprocessar)

Critérios de aceitação:
- Uma falha cria evento Erro com mensagem.
- Admin consegue reprocessar e ver status virar Sucesso.

---

Clínica 360

Quando usar

• Clínica ou consultório.

• Agenda + atendimento + faturamento simples.

• Controle por perfil e auditoria básica.

Prompt base (copiar e colar)

Crie um projeto chamado: {{NOME_DO_PROJETO}}

Objetivo: sistema de clínica com agenda, atendimento e faturamento simples.
Idioma da UI: {{IDIOMA_UI}}.

Perfis (RBAC):
- Admin: acesso total
- Recepcao: agenda e cadastro de pacientes
- ProfissionalSaude: prontuário e atendimentos
- Financeiro: faturamento e pagamentos

Módulos:
- Agenda
- Pacientes
- Atendimentos (prontuário)
- Faturamento

Entidades:
- Paciente:
  - nomeCompleto (obrigatório)
  - cpf (único, obrigatório)
  - dataNascimento (data)
  - telefone
  - email
  - observacoes

- Profissional:
  - nomeCompleto (obrigatório)
  - especialidade
  - registroConselho

- Agendamento:
  - paciente (relacionamento: 1 Paciente)
  - profissional (relacionamento: 1 Profissional)
  - inicio (data/hora)
  - fim (data/hora)
  - status (Agendado | Confirmado | EmAtendimento | Concluido | Cancelado)
  - motivoCancelamento

- Atendimento:
  - paciente (1 Paciente)
  - profissional (1 Profissional)
  - dataHora (data/hora)
  - queixaPrincipal
  - evolucao
  - prescricao
  - anexos (opcional)

- Fatura:
  - paciente (1 Paciente)
  - atendimento (0..1 Atendimento)
  - valor (moeda)
  - status (Aberta | Paga | Cancelada)
  - dataVencimento (data)
  - formaPagamento (Pix | Cartao | Dinheiro | Boleto)

Regras de negócio:
- Impedir duplo agendamento do mesmo profissional no mesmo horário.
- Recepcao não pode ver campos clínicos do Atendimento.
- Financeiro não pode editar Atendimentos.

Telas mínimas:
- Calendário de agenda (dia/semana) com criação rápida
- Lista de pacientes + cadastro/edição
- Check-in: converter Agendamento em Atendimento
- Prontuário do paciente (timeline de atendimentos)
- Faturamento: lista de faturas + marcar como paga

Critérios de aceitação:
- Usuário com perfil Recepcao consegue agendar e confirmar.
- ProfissionalSaude consegue registrar atendimento e concluir.
- Financeiro consegue registrar pagamento e listar pendências.

Extensões comuns

• Lembretes (WhatsApp/email) para agendamentos.

• Termos e consentimentos com aceite.

• Multi-unidade (filial) e agenda por unidade.

CRM 360

Quando usar

• Vendas B2B.

• Pipeline com atividades.

• Dashboard de metas.

Prompt base (copiar e colar)

Crie um projeto chamado: {{NOME_DO_PROJETO}}

Objetivo: CRM de vendas com pipeline, atividades e relatórios.
Idioma da UI: {{IDIOMA_UI}}.

Perfis (RBAC):
- Admin: acesso total
- GestorComercial: gerencia pipeline e metas
- Vendedor: gerencia seus leads e oportunidades
- SDR: qualifica leads e agenda reuniões

Módulos:
- Cadastros
- Pipeline
- Atividades
- Relatórios

Entidades:
- Empresa:
  - nome (obrigatório)
  - cnpj (único, opcional)
  - segmento
  - tamanho (Pequena | Media | Grande)

- Contato:
  - empresa (1 Empresa)
  - nome (obrigatório)
  - email
  - telefone
  - cargo

- Lead:
  - nome (obrigatório)
  - origem (Inbound | Outbound | Indicacao | Evento)
  - status (Novo | Qualificado | Descartado | Convertido)
  - responsavel (relacionamento: 1 Usuario)
  - empresa (0..1 Empresa)
  - contato (0..1 Contato)

- Oportunidade:
  - titulo (obrigatório)
  - empresa (1 Empresa)
  - valorEstimado (moeda)
  - probabilidade (0..100)
  - etapa (Prospeccao | Diagnostico | Proposta | Negociacao | FechadaGanha | FechadaPerdida)
  - responsavel (1 Usuario)
  - motivoPerda
  - dataFechamentoPrevista (data)

- Atividade:
  - tipo (Ligacao | Email | Reuniao | Tarefa)
  - relacionadaA (Lead ou Oportunidade)
  - responsavel (1 Usuario)
  - dataHora (data/hora)
  - status (Pendente | Concluida | Cancelada)
  - notas

Regras de negócio:
- Vendedor só vê e edita registros onde é responsavel.
- GestorComercial vê tudo do time.
- Etapa só pode avançar. Não permitir voltar.

Telas mínimas:
- Kanban de Oportunidades por etapa
- Lista de Leads + qualificar/descartar/convertê-lo em Oportunidade
- Agenda de Atividades (minhas atividades)
- Dashboard: pipeline por etapa + receita prevista por mês

Critérios de aceitação:
- SDR consegue qualificar lead e converter.
- Vendedor consegue movimentar oportunidade no Kanban.
- GestorComercial consegue ver pipeline consolidado do time.

Extensões comuns

• Importação de leads (CSV).

• Integração com WhatsApp.

• Comissões por vendedor.

ERP 360

Quando usar

• Operação com vendas, compras e estoque.

• Financeiro básico (contas a pagar/receber).

Prompt base (copiar e colar)

Crie um projeto chamado: {{NOME_DO_PROJETO}}

Objetivo: ERP simples com cadastro, compras, vendas, estoque e financeiro básico.
Idioma da UI: {{IDIOMA_UI}}.

Perfis (RBAC):
- Admin: acesso total
- Compras: pedidos de compra e fornecedores
- Vendas: pedidos de venda e clientes
- Estoque: movimentações e inventário
- Financeiro: contas a pagar/receber

Módulos:
- Cadastros
- Compras
- Vendas
- Estoque
- Financeiro

Entidades:
- Produto:
  - sku (único, obrigatório)
  - nome (obrigatório)
  - unidade (UN | CX | KG | LT)
  - precoVenda (moeda)
  - custoPadrao (moeda)
  - ativo (boolean)

- Cliente:
  - nome (obrigatório)
  - documento (cpf/cnpj)
  - email
  - telefone

- Fornecedor:
  - nome (obrigatório)
  - documento (cpf/cnpj)
  - email
  - telefone

- PedidoVenda:
  - cliente (1 Cliente)
  - status (Rascunho | Aprovado | Faturado | Cancelado)
  - dataPedido (data)
  - total (moeda)

- ItemPedidoVenda:
  - pedidoVenda (1 PedidoVenda)
  - produto (1 Produto)
  - quantidade (numero)
  - precoUnitario (moeda)

- PedidoCompra:
  - fornecedor (1 Fornecedor)
  - status (Rascunho | Aprovado | Recebido | Cancelado)
  - dataPedido (data)
  - total (moeda)

- ItemPedidoCompra:
  - pedidoCompra (1 PedidoCompra)
  - produto (1 Produto)
  - quantidade (numero)
  - custoUnitario (moeda)

- MovimentoEstoque:
  - produto (1 Produto)
  - tipo (Entrada | Saida | Ajuste)
  - quantidade (numero)
  - dataHora (data/hora)
  - referencia (PedidoCompra ou PedidoVenda, opcional)

- TituloFinanceiro:
  - tipo (Pagar | Receber)
  - status (Aberto | Pago | Cancelado)
  - valor (moeda)
  - dataVencimento (data)
  - dataPagamento (data, opcional)
  - origem (PedidoCompra ou PedidoVenda, opcional)

Regras de negócio:
- Ao receber PedidoCompra: gerar Entrada de estoque.
- Ao faturar PedidoVenda: gerar Saida de estoque e Titulo a receber.
- Impedir estoque negativo.

Telas mínimas:
- Cadastro de produto/cliente/fornecedor
- Pedido de compra (com itens) + recebimento
- Pedido de venda (com itens) + faturamento
- Estoque: posição por produto + lista de movimentos
- Financeiro: títulos em aberto (pagar/receber)

Critérios de aceitação:
- Compras consegue aprovar e receber um pedido.
- Vendas consegue faturar e baixar estoque.
- Financeiro consegue listar títulos em aberto e marcar como pago.

Extensões comuns

• Múltiplos depósitos.

• Lotes e validade.

• Centro de custo e plano de contas.

ERP Satélites

Quando usar

• Você já tem um ERP.

• Precisa de apps satélites rápidos.

• Quer evitar “mexer no core”.

Prompt base (copiar e colar)

Crie um projeto chamado: {{NOME_DO_PROJETO}}

Objetivo: app satélite integrado ao ERP atual, focado em um processo específico.
Idioma da UI: {{IDIOMA_UI}}.

Processo alvo (descreva com clareza):
- Exemplo: requisição de compra e aprovação por alçada.

Perfis (RBAC):
- Admin
- Solicitante
- Aprovador
- Compras

Entidades:
- RequisicaoCompra:
  - solicitante (1 Usuario)
  - centroCusto
  - status (Rascunho | Enviada | Aprovada | Reprovada | EnviadaAoERP)
  - valorEstimado (moeda)
  - justificativa
  - criadoEm (data/hora)

- ItemRequisicao:
  - requisicao (1 RequisicaoCompra)
  - descricao (obrigatório)
  - quantidade (numero)
  - unidade (UN | CX | KG | LT)
  - precoEstimado (moeda)

Integrações:
- {{INTEGRACOES}}
- Exemplo: ao aprovar, chamar API do ERP para criar solicitação oficial.

Regras de negócio:
- Aprovação por alçada:
  - valor <= 5.000: 1 aprovador
  - valor > 5.000: 2 níveis
- Não permitir edição após Enviada.

Telas mínimas:
- Criar/editar requisição com itens
- Tela de aprovação (fila do aprovador)
- Histórico e trilha (quem aprovou, quando, comentário)
- Integrações: log das chamadas ao ERP (sucesso/erro)

Critérios de aceitação:
- Solicitante cria e envia.
- Aprovador aprova/reprova com comentário.
- Após aprovar, a requisição é enviada ao ERP e registra o status.

Extensões comuns

• Upload de anexos (3 cotações).

• SLA e notificações.

• Reprocessamento de integrações com falha.

HelpDesk 360

Quando usar

• Suporte interno ou ao cliente.

• SLAs e filas.

• Base de conhecimento simples.

Prompt base (copiar e colar)

Crie um projeto chamado: {{NOME_DO_PROJETO}}

Objetivo: helpdesk com tickets, filas, SLAs e macros.
Idioma da UI: {{IDIOMA_UI}}.

Perfis (RBAC):
- Admin
- Agente: atende tickets
- Supervisor: gerencia filas e relatórios
- Solicitante: abre e acompanha tickets

Módulos:
- Tickets
- SLAs
- Base de conhecimento
- Relatórios

Entidades:
- Ticket:
  - numero (único)
  - assunto (obrigatório)
  - descricao
  - prioridade (Baixa | Media | Alta | Critica)
  - status (Aberto | EmAtendimento | AguardandoCliente | Resolvido | Fechado)
  - solicitante (1 Usuario)
  - agente (0..1 Usuario)
  - fila (1 Fila)
  - categoria
  - tags
  - criadoEm (data/hora)
  - atualizadoEm (data/hora)

- ComentarioTicket:
  - ticket (1 Ticket)
  - autor (1 Usuario)
  - visibilidade (Interno | Publico)
  - texto (obrigatório)
  - criadoEm (data/hora)

- Fila:
  - nome (obrigatório)
  - slaPrimeiraRespostaHoras (numero)
  - slaResolucaoHoras (numero)

- Macro:
  - nome (obrigatório)
  - textoPadrao
  - mudaStatusPara (opcional)

Regras de negócio:
- Solicitante só vê os próprios tickets.
- Agente vê tickets da sua fila.
- Status só avança. Não permitir voltar de Fechado.

Telas mínimas:
- Abrir ticket (solicitante)
- Minhas solicitações (solicitante)
- Fila de tickets (agente)
- Tela do ticket com comentários internos vs públicos
- Dashboard: backlog por fila, SLA violado, tempo médio de resolução

Critérios de aceitação:
- Solicitante abre ticket e acompanha status.
- Agente responde usando Macro.
- Supervisor vê relatório de SLAs por fila.

Extensões comuns

• Formulário dinâmico por categoria.

• Regras de roteamento para fila.

• Pesquisa e artigos na base de conhecimento.

OKR 360

Quando usar

• Gestão de metas por ciclos.

• Acompanhamento com check-ins.

• Visão por time e empresa.

Prompt base (copiar e colar)

Crie um projeto chamado: {{NOME_DO_PROJETO}}

Objetivo: sistema de OKRs com ciclos, objetivos, resultados-chave e check-ins.
Idioma da UI: {{IDIOMA_UI}}.

Perfis (RBAC):
- Admin
- Lider: cria e acompanha OKRs do time
- Membro: atualiza seus KRs e check-ins

Módulos:
- Ciclos
- OKRs
- Check-ins
- Relatórios

Entidades:
- Ciclo:
  - nome (obrigatório)
  - inicio (data)
  - fim (data)
  - status (Planejamento | EmAndamento | Encerrado)

- Objetivo:
  - ciclo (1 Ciclo)
  - titulo (obrigatório)
  - descricao
  - time
  - dono (1 Usuario)
  - status (Ativo | Pausado | Concluido)

- ResultadoChave:
  - objetivo (1 Objetivo)
  - titulo (obrigatório)
  - tipo (Numero | Percentual | Moeda)
  - baseline (numero)
  - meta (numero)
  - atual (numero)
  - status (NoCaminho | EmRisco | ForaDoCaminho | Concluido)

- CheckIn:
  - resultadoChave (1 ResultadoChave)
  - autor (1 Usuario)
  - data (data)
  - comentario
  - valorAtual (numero)

Regras de negócio:
- Encerrar ciclo bloqueia edição de Objetivos/KRs.
- Valor atual do KR deve ser atualizado via CheckIn.

Telas mínimas:
- Planejamento do ciclo (lista de objetivos + KRs)
- Visão de OKRs por time
- Check-in semanal (form simples)
- Dashboard do ciclo (progresso agregado, KRs em risco)

Critérios de aceitação:
- Lider cria objetivos e KRs para o ciclo.
- Membro faz check-in e atualiza valor do KR.
- Dashboard mostra KRs em risco e progresso.

Extensões comuns

• Pesos por KR e score do objetivo.

• Integração com Jira/Linear para evidências.

• Comentários e alinhamento (OKR pai/filho).

ProjectHub 360

Quando usar

• Projetos com tasks, sprints e roadmap.

• Um “Jira simples” interno.

Prompt base (copiar e colar)

Crie um projeto chamado: {{NOME_DO_PROJETO}}

Objetivo: gestão de projetos com backlog, sprints e roadmap.
Idioma da UI: {{IDIOMA_UI}}.

Perfis (RBAC):
- Admin
- PM: gerencia roadmap e sprints
- Dev: executa tarefas e atualiza status
- Stakeholder: leitura e comentários

Módulos:
- Backlog
- Sprints
- Roadmap
- Relatórios

Entidades:
- Projeto:
  - nome (obrigatório)
  - descricao
  - status (Ativo | Pausado | Encerrado)

- Sprint:
  - projeto (1 Projeto)
  - nome (obrigatório)
  - inicio (data)
  - fim (data)
  - status (Planejada | EmAndamento | Encerrada)

- ItemBacklog:
  - projeto (1 Projeto)
  - tipo (Epic | Story | Bug | Task)
  - titulo (obrigatório)
  - descricao
  - prioridade (Baixa | Media | Alta)
  - status (Backlog | EmProgresso | EmRevisao | Concluido)
  - responsavel (0..1 Usuario)
  - sprint (0..1 Sprint)
  - estimativaPontos (numero, opcional)

- Comentario:
  - item (1 ItemBacklog)
  - autor (1 Usuario)
  - texto (obrigatório)
  - criadoEm (data/hora)

Regras de negócio:
- Status só pode avançar: Backlog -> EmProgresso -> EmRevisao -> Concluido.
- Stakeholder não pode editar itens. Apenas comentar.

Telas mínimas:
- Backlog com filtros e criação rápida
- Board (kanban) por sprint
- Detalhe do item com comentários
- Roadmap simples (epics por período)
- Relatório: throughput por sprint + itens em WIP

Critérios de aceitação:
- PM cria sprint e puxa itens do backlog.
- Dev move itens no board respeitando transições.
- Stakeholder consegue acompanhar e comentar.

Extensões comuns

• Dependências entre itens.

• SLAs para bugs.

• Integração com GitHub (link de PR/commit).