4. Prompt Templates

Copyable templates to generate complete apps (CRM, ERP, Helpdesk, OKRs and more).

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

Want to see the full flow (prompt → deploy)? Combine with Demonstrations.

How to use (30s)

1

Choose a template and define the scope

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

2

Replace the placeholders and paste into Madrix

Replace {{NOME_DO_PROJETO}}, {{IDIOMA_UI}} and {{PERFIS}}. Paste the prompt and click Generate.

3

Approve the specification and validate in the Preview

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

4

Iterate with small changes

Request adjustments by block. Example: “add field X + validation + adjust form”.

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.

Generic — CRUD + permissions (quick)

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.

Generic — workflow (states + transitions)

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.

Generic — integrations (webhook/API + log + reprocess)

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.

---

Clinic 360

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.

CRM 360

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.

ERP 360

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.

Satellite ERPs

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.

HelpDesk 360

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.

OKR 360

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

ProjectHub 360

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