# 4. Templates de Prompt

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

{% hint style="info" %}
Quer ver o fluxo completo (prompt → deploy)? Combine com [Demonstrações](https://docs.madrix.dev/br/demonstracoes).
{% endhint %}

### Como usar (30s)

{% stepper %}
{% step %}

### Escolha um template e defina o escopo

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

{% step %}

### Troque os placeholders e cole no Madrix

Troque `{{NOME_DO_PROJETO}}`, `{{IDIOMA_UI}}` e `{{PERFIS}}`. Cole o prompt e clique em **Gerar**.
{% endstep %}

{% step %}

### 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.
{% endstep %}

{% step %}

### Itere em mudanças pequenas

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

### 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.

<details>

<summary>Genérico — CRUD + permissões (rápido)</summary>

```
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.
```

</details>

<details>

<summary>Genérico — workflow (estados + transições)</summary>

```
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.
```

</details>

<details>

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

```
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.
```

</details>

***

<details>

<summary>Clínica 360</summary>

**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.

</details>

<details>

<summary>CRM 360</summary>

**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.

</details>

<details>

<summary>ERP 360</summary>

**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.

</details>

<details>

<summary>ERP Satélites</summary>

**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.

</details>

<details>

<summary>HelpDesk 360</summary>

**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.

</details>

<details>

<summary>OKR 360</summary>

**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).

</details>

<details>

<summary>ProjectHub 360</summary>

**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).

</details>


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.madrix.dev/br/tutoriais-praticos/4.-templates-de-prompt.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.