> For the complete documentation index, see [llms.txt](https://docs.madrix.dev/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.madrix.dev/hands-on-tutorials/4.-prompt-templates.md). # 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](/demonstrations.md). {% 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.
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).
--- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## 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, and the optional `goal` query parameter: ``` GET https://docs.madrix.dev/hands-on-tutorials/4.-prompt-templates.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. 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.