# 4. Prompt Templates

Copy a template. Adjust the placeholders. Generate the app. Then iterate on the specification.

{% hint style="info" %}
Want to see the full flow (prompt → deploy)? Combine with [Demonstrations](https://app.gitbook.com/s/XnYvLewhXbdSQIvAlbqN/demonstracoes).
{% endhint %}

### How to use (30s)

{% stepper %}
{% step %}

### Choose a template and define the scope

Decide modules and the “minimum that needs to work”. Avoid asking for everything on the first generation.
{% endstep %}

{% step %}

### Replace the placeholders and paste into Madrix

Replace `{{NOME_DO_PROJETO}}`, `{{IDIOMA_UI}}` and `{{PERFIS}}`. Paste the prompt and click **Generate**.
{% endstep %}

{% step %}

### Approve the specification and validate in the Preview

Validate entities, rules and permissions. Then validate the basics in the Preview with test data.
{% endstep %}

{% step %}

### Iterate with small changes

Request adjustments by block. Example: “add field X + validation + adjust form”.
{% endstep %}
{% endstepper %}

### Placeholders (default)

Use these markers to customize quickly.

* `{{NOME_DO_PROJETO}}`: project name.
* `{{IDIOMA_UI}}`: `pt-BR` or `en-US`.
* `{{PERFIS}}`: system roles. Ex: `Admin`, `Manager`, `Operator`.
* `{{REGRAS_DE_NEGOCIO}}`: “if/then” rules and transitions.
* `{{INTEGRACOES}}`: webhooks, import, external APIs.

### Generic examples (copy and paste)

Use when you don’t yet have a domain template. These are neutral blocks to compose your app.

<details>

<summary>Generic — CRUD + permissions (quick)</summary>

```
Create a project called: {{NOME_DO_PROJETO}}

Goal: simple CRUD app, with profile-based permissions and basic validations.
UI language: {{IDIOMA_UI}}.

Profiles (RBAC):
- Admin: full access
- Operator: create/edit records
- Reader: read-only

Entities:
- Record:
  - title (required)
  - description
  - status (Active | Inactive)
  - createdAt (date/time)
  - createdBy (1 User)

Business rules:
- Operator can only edit records they created.
- Reader cannot create/edit/delete.

Minimum screens:
- Record list (filters by status + search by title)
- Create/edit record (validations)
- Record detail

Acceptance criteria:
- Admin sees everything.
- Operator creates and edits only what they created.
- Reader can list and open detail, without editing.
```

</details>

<details>

<summary>Generic — workflow (states + transitions)</summary>

```
Create a project called: {{NOME_DO_PROJETO}}

Goal: app with workflow and a simple approval trail.
UI language: {{IDIOMA_UI}}.

Profiles (RBAC):
- Admin
- Requester
- Approver

Entities:
- Request:
  - title (required)
  - description
  - amount (currency, optional)
  - status (Draft | Submitted | Approved | Rejected | Cancelled)
  - requester (1 User)
  - approvedBy (0..1 User)
  - createdAt (date/time)

- StatusHistory:
  - request (1 Request)
  - fromStatus
  - toStatus
  - author (1 User)
  - comment
  - createdAt (date/time)

Business rules:
- Allowed transitions:
  - Draft -> Submitted
  - Submitted -> Approved | Rejected
  - Draft -> Cancelled
  - Submitted -> Cancelled (Admin only)
- Only Approver can approve/reject.
- Always record StatusHistory on any transition.

Minimum screens:
- My requests (requester)
- Approval queue (approver)
- Request detail + status history

Acceptance criteria:
- Requester submits and cannot edit after Submitted.
- Approver approves/rejects with a comment.
- History lists all status changes.
```

</details>

<details>

<summary>Generic — integrations (webhook/API + log + reprocess)</summary>

```
Create a project called: {{NOME_DO_PROJETO}}

Goal: app with external integration via webhook/API, with logging and reprocessing.
UI language: {{IDIOMA_UI}}.

Profiles (RBAC):
- Admin
- Operator

Entities:
- IntegrationEvent:
  - type (Outbound | Inbound)
  - system (required)
  - event (required)
  - payload (text/json)
  - status (Pending | Success | Error)
  - attempts (number)
  - lastError
  - createdAt (date/time)
  - processedAt (date/time, optional)

Integration flow:
- When creating/updating a Record, trigger an Outbound event.
- Send payload to a configurable endpoint (per environment).
- Record success/error in IntegrationEvent.
- Allow “Reprocess” for events with Error status.

Business rules:
- Maximum of 5 attempts per event.
- Only Admin can manually reprocess.

Minimum screens:
- Settings: endpoints per environment (Dev/Staging/Prod)
- Integrations log (filter by status + system + period)
- Event detail (payload + errors + reprocess button)

Acceptance criteria:
- A failure creates an Error event with a message.
- Admin can reprocess and see status become Success.
```

</details>

***

<details>

<summary>Clinic 360</summary>

**When to use**

* Clinic or practice.
* Schedule + care + simple billing.
* Control by profile and basic auditing.

**Base prompt (copy and paste)**

```
Create a project called: {{NOME_DO_PROJETO}}

Goal: clinic system with scheduling, care and simple billing.
UI language: {{IDIOMA_UI}}.

Profiles (RBAC):
- Admin: full access
- Reception: schedule and patient registration
- HealthProfessional: medical record and appointments
- Finance: billing and payments

Modules:
- Schedule
- Patients
- Appointments (medical record)
- Billing

Entities:
- Patient:
  - fullName (required)
  - cpf (unique, required)
  - birthDate (date)
  - phone
  - email
  - notes

- Professional:
  - fullName (required)
  - specialty
  - councilRegistration

- Appointment:
  - patient (relationship: 1 Patient)
  - professional (relationship: 1 Professional)
  - start (date/time)
  - end (date/time)
  - status (Scheduled | Confirmed | InService | Completed | Cancelled)
  - cancellationReason

- Service:
  - patient (1 Patient)
  - professional (1 Professional)
  - dateTime (date/time)
  - mainComplaint
  - progressNotes
  - prescription
  - attachments (optional)

- Invoice:
  - patient (1 Patient)
  - service (0..1 Service)
  - amount (currency)
  - status (Open | Paid | Cancelled)
  - dueDate (date)
  - paymentMethod (Pix | Card | Cash | Boleto)

Business rules:
- Prevent double booking of the same professional at the same time.
- Reception cannot see clinical fields of the Service.
- Finance cannot edit Services.

Minimum screens:
- Schedule calendar (day/week) with quick creation
- Patient list + create/edit
- Check-in: convert Appointment to Service
- Patient medical record (timeline of services)
- Billing: invoice list + mark as paid

Acceptance criteria:
- User with Reception profile can schedule and confirm.
- HealthProfessional can record service and complete it.
- Finance can record payment and list pending items.
```

**Common extensions**

* Reminders (WhatsApp/email) for appointments.
* Terms and consents with acceptance.
* Multi-unit (branch) and schedule per unit.

</details>

<details>

<summary>CRM 360</summary>

**When to use**

* B2B sales.
* Pipeline with activities.
* Goals dashboard.

**Base prompt (copy and paste)**

```
Create a project called: {{NOME_DO_PROJETO}}

Goal: sales CRM with pipeline, activities and reports.
UI language: {{IDIOMA_UI}}.

Profiles (RBAC):
- Admin: full access
- SalesManager: manages pipeline and goals
- Seller: manages their leads and opportunities
- SDR: qualifies leads and schedules meetings

Modules:
- Records
- Pipeline
- Activities
- Reports

Entities:
- Company:
  - name (required)
  - cnpj (unique, optional)
  - segment
  - size (Small | Medium | Large)

- Contact:
  - company (1 Company)
  - name (required)
  - email
  - phone
  - position

- Lead:
  - name (required)
  - origin (Inbound | Outbound | Referral | Event)
  - status (New | Qualified | Discarded | Converted)
  - owner (relationship: 1 User)
  - company (0..1 Company)
  - contact (0..1 Contact)

- Opportunity:
  - title (required)
  - company (1 Company)
  - estimatedValue (currency)
  - probability (0..100)
  - stage (Prospecting | Diagnosis | Proposal | Negotiation | ClosedWon | ClosedLost)
  - owner (1 User)
  - lossReason
  - expectedCloseDate (date)

- Activity:
  - type (Call | Email | Meeting | Task)
  - relatedTo (Lead or Opportunity)
  - owner (1 User)
  - dateTime (date/time)
  - status (Pending | Completed | Cancelled)
  - notes

Business rules:
- Seller only sees and edits records where they are the owner.
- SalesManager sees the whole team’s data.
- Stage can only advance. Do not allow moving back.

Minimum screens:
- Opportunities Kanban by stage
- Lead list + qualify/discard/convert to Opportunity
- Activities schedule (my activities)
- Dashboard: pipeline by stage + forecasted revenue per month

Acceptance criteria:
- SDR can qualify lead and convert.
- Seller can move opportunity in the Kanban.
- SalesManager can see the team’s consolidated pipeline.
```

**Common extensions**

* Lead import (CSV).
* WhatsApp integration.
* Commissions per seller.

</details>

<details>

<summary>ERP 360</summary>

**When to use**

* Operations with sales, purchases and inventory.
* Basic finance (accounts payable/receivable).

**Base prompt (copy and paste)**

```
Create a project called: {{NOME_DO_PROJETO}}

Goal: simple ERP with catalog, purchasing, sales, inventory and basic finance.
UI language: {{IDIOMA_UI}}.

Profiles (RBAC):
- Admin: full access
- Purchasing: purchase orders and suppliers
- Sales: sales orders and customers
- Inventory: movements and inventory
- Finance: accounts payable/receivable

Modules:
- Records
- Purchasing
- Sales
- Inventory
- Finance

Entities:
- Product:
  - sku (unique, required)
  - name (required)
  - unit (UN | BX | KG | LT)
  - salePrice (currency)
  - standardCost (currency)
  - active (boolean)

- Customer:
  - name (required)
  - document (cpf/cnpj)
  - email
  - phone

- Supplier:
  - name (required)
  - document (cpf/cnpj)
  - email
  - phone

- SalesOrder:
  - customer (1 Customer)
  - status (Draft | Approved | Invoiced | Cancelled)
  - orderDate (date)
  - total (currency)

- SalesOrderItem:
  - salesOrder (1 SalesOrder)
  - product (1 Product)
  - quantity (number)
  - unitPrice (currency)

- PurchaseOrder:
  - supplier (1 Supplier)
  - status (Draft | Approved | Received | Cancelled)
  - orderDate (date)
  - total (currency)

- PurchaseOrderItem:
  - purchaseOrder (1 PurchaseOrder)
  - product (1 Product)
  - quantity (number)
  - unitCost (currency)

- InventoryMovement:
  - product (1 Product)
  - type (In | Out | Adjustment)
  - quantity (number)
  - dateTime (date/time)
  - reference (PurchaseOrder or SalesOrder, optional)

- FinancialEntry:
  - type (Payable | Receivable)
  - status (Open | Paid | Cancelled)
  - amount (currency)
  - dueDate (date)
  - paymentDate (date, optional)
  - origin (PurchaseOrder or SalesOrder, optional)

Business rules:
- When receiving a PurchaseOrder: generate Stock In.
- When invoicing a SalesOrder: generate Stock Out and an Accounts Receivable entry.
- Prevent negative stock.

Minimum screens:
- Product/customer/supplier registration
- Purchase order (with items) + receiving
- Sales order (with items) + invoicing
- Inventory: position by product + movement list
- Finance: open entries (payable/receivable)

Acceptance criteria:
- Purchasing can approve and receive an order.
- Sales can invoice and deduct stock.
- Finance can list open entries and mark as paid.
```

**Common extensions**

* Multiple warehouses.
* Lots and expiration dates.
* Cost center and chart of accounts.

</details>

<details>

<summary>Satellite ERPs</summary>

**When to use**

* You already have an ERP.
* You need quick satellite apps.
* You want to avoid “touching the core”.

**Base prompt (copy and paste)**

```
Create a project called: {{NOME_DO_PROJETO}}

Goal: satellite app integrated with the current ERP, focused on a specific process.
UI language: {{IDIOMA_UI}}.

Target process (describe clearly):
- Example: purchase requisition and approval by authority levels.

Profiles (RBAC):
- Admin
- Requester
- Approver
- Purchasing

Entities:
- PurchaseRequisition:
  - requester (1 User)
  - costCenter
  - status (Draft | Submitted | Approved | Rejected | SentToERP)
  - estimatedValue (currency)
  - justification
  - createdAt (date/time)

- PurchaseRequisitionItem:
  - requisition (1 PurchaseRequisition)
  - description (required)
  - quantity (number)
  - unit (UN | BX | KG | LT)
  - estimatedPrice (currency)

Integrations:
- {{INTEGRACOES}}
- Example: on approval, call the ERP API to create an official request.

Business rules:
- Approval by authority levels:
  - amount <= 5,000: 1 approver
  - amount > 5,000: 2 levels
- Do not allow editing after Submitted.

Minimum screens:
- Create/edit requisition with items
- Approval screen (approver queue)
- History and trail (who approved, when, comment)
- Integrations: log of calls to the ERP (success/error)

Acceptance criteria:
- Requester creates and submits.
- Approver approves/rejects with a comment.
- After approval, the requisition is sent to the ERP and the status is recorded.
```

**Common extensions**

* Upload attachments (3 quotes).
* SLA and notifications.
* Reprocessing of failed integrations.

</details>

<details>

<summary>HelpDesk 360</summary>

**When to use**

* Internal or customer support.
* SLAs and queues.
* Simple knowledge base.

**Base prompt (copy and paste)**

```
Create a project called: {{NOME_DO_PROJETO}}

Goal: helpdesk with tickets, queues, SLAs and macros.
UI language: {{IDIOMA_UI}}.

Profiles (RBAC):
- Admin
- Agent: handles tickets
- Supervisor: manages queues and reports
- Requester: opens and follows up tickets

Modules:
- Tickets
- SLAs
- Knowledge base
- Reports

Entities:
- Ticket:
  - number (unique)
  - subject (required)
  - description
  - priority (Low | Medium | High | Critical)
  - status (Open | InService | WaitingCustomer | Resolved | Closed)
  - requester (1 User)
  - agent (0..1 User)
  - queue (1 Queue)
  - category
  - tags
  - createdAt (date/time)
  - updatedAt (date/time)

- TicketComment:
  - ticket (1 Ticket)
  - author (1 User)
  - visibility (Internal | Public)
  - text (required)
  - createdAt (date/time)

- Queue:
  - name (required)
  - slaFirstResponseHours (number)
  - slaResolutionHours (number)

- Macro:
  - name (required)
  - defaultText
  - changeStatusTo (optional)

Business rules:
- Requester only sees their own tickets.
- Agent sees tickets from their queue.
- Status only advances. Do not allow reverting from Closed.

Minimum screens:
- Open ticket (requester)
- My requests (requester)
- Ticket queue (agent)
- Ticket screen with internal vs public comments
- Dashboard: backlog by queue, SLA violations, average resolution time

Acceptance criteria:
- Requester opens a ticket and follows the status.
- Agent responds using Macro.
- Supervisor sees SLA reports by queue.
```

**Common extensions**

* Dynamic form by category.
* Routing rules for queues.
* Search and articles in the knowledge base.

</details>

<details>

<summary>OKR 360</summary>

**When to use**

* Goals management by cycles.
* Follow-up with check-ins.
* View by team and company.

**Base prompt (copy and paste)**

```
Create a project called: {{NOME_DO_PROJETO}}

Goal: OKR system with cycles, objectives, key results and check-ins.
UI language: {{IDIOMA_UI}}.

Profiles (RBAC):
- Admin
- Leader: creates and follows the team’s OKRs
- Member: updates their KRs and check-ins

Modules:
- Cycles
- OKRs
- Check-ins
- Reports

Entities:
- Cycle:
  - name (required)
  - start (date)
  - end (date)
  - status (Planning | InProgress | Closed)

- Objective:
  - cycle (1 Cycle)
  - title (required)
  - description
  - team
  - owner (1 User)
  - status (Active | Paused | Completed)

- KeyResult:
  - objective (1 Objective)
  - title (required)
  - type (Number | Percentage | Currency)
  - baseline (number)
  - target (number)
  - current (number)
  - status (OnTrack | AtRisk | OffTrack | Completed)

- CheckIn:
  - keyResult (1 KeyResult)
  - author (1 User)
  - date (date)
  - comment
  - currentValue (number)

Business rules:
- Closing a cycle blocks editing Objectives/KRs.
- Current KR value must be updated via CheckIn.

Minimum screens:
- Cycle planning (list of objectives + KRs)
- OKR view by team
- Weekly check-in (simple form)
- Cycle dashboard (aggregate progress, KRs at risk)

Acceptance criteria:
- Leader creates objectives and KRs for the cycle.
- Member does check-in and updates the KR value.
- Dashboard shows KRs at risk and progress.
```

**Common extensions**

* Weights by KR and objective score.
* Integration with Jira/Linear for evidence.
* Comments and alignment (parent/child OKR).

</details>

<details>

<summary>ProjectHub 360</summary>

**When to use**

* Projects with tasks, sprints and roadmap.
* An internal "simple Jira."

**Base prompt (copy and paste)**

```
Create a project called: {{NOME_DO_PROJETO}}

Objective: project management with backlog, sprints and roadmap.
UI language: {{IDIOMA_UI}}.

Profiles (RBAC):
- Admin
- PM: manages roadmap and sprints
- Dev: executes tasks and updates status
- Stakeholder: read-only and comments

Modules:
- Backlog
- Sprints
- Roadmap
- Reports

Entities:
- Project:
  - name (required)
  - description
  - status (Active | Paused | Closed)

- Sprint:
  - project (1 Project)
  - name (required)
  - start (date)
  - end (date)
  - status (Planned | InProgress | Closed)

- BacklogItem:
  - project (1 Project)
  - type (Epic | Story | Bug | Task)
  - title (required)
  - description
  - priority (Low | Medium | High)
  - status (Backlog | InProgress | InReview | Done)
  - assignee (0..1 User)
  - sprint (0..1 Sprint)
  - estimatePoints (number, optional)

- Comment:
  - item (1 BacklogItem)
  - author (1 User)
  - text (required)
  - createdAt (date/time)

Business rules:
- Status can only advance: Backlog -> InProgress -> InReview -> Done.
- Stakeholder cannot edit items. Only comment.

Minimum screens:
- Backlog with filters and quick creation
- Board (kanban) per sprint
- Item detail with comments
- Simple roadmap (epics by period)
- Report: throughput per sprint + items in WIP

Acceptance criteria:
- PM creates sprint and pulls items from the backlog.
- Dev moves items on the board respecting transitions.
- Stakeholder can follow and comment.
```

**Common extensions**

* Dependencies between items.
* SLAs for bugs.
* Integration with GitHub (PR/commit link).

</details>