1. Prompt tips

How to write clear, testable prompts that are easy to iterate on.

Use this page to write prompts that become good specifications. Then use the AI Chat to iterate on small changes.

Want complete prompts by domain (CRM, ERP, Helpdesk, OKRs)? Also use Prompt Templates.

Principles (what changes the outcome most)

1. Write testable requirements. Replace “well done” with objective criteria.

2. Use lists and enums. They reduce interpretation and “creativity”.

3. Say what is not allowed. Ex: “do not allow status rollback”.

4. Start small. Generate the “minimum that works”. Then evolve.

5. Iterate by block. Field + validation + UI tweak. One change at a time.

Recommended format (base prompt)

Copy and adjust. It works well for initial generation.

Create a project called: {{PROJECT_NAME}}

Goal: {{DESCRIBE_IN_1_2_LINES}}
UI language: pt-BR.

Profiles (RBAC):
- Admin: full access
- Operator: creates/edits
- Reader: read-only

Modules:
- {{MODULE_1}}
    Entities:
    - {{ENTITY_1}}:
      - {{field}} (required)
      - {{field}} (unique, optional)
      - {{field}} (enum: A | B | C)
      - {{relationship}} (relationship: 1 {{OtherEntity}})
    
    Business rules:
    - {{rule_1}} (if/then)
    - {{rule_2}} (allowed transitions)
    
     Reports:
    - {{report_1}}
    - {{report_1}}

- {{MODULE_2}}
    Entities:
    - {{ENTITY_1}}:
      - {{field}} (required)
      - {{field}} (unique, optional)
      - {{field}} (enum: A | B | C)
      - {{relationship}} (relationship: 1 {{OtherEntity}})
    
    Business rules:
    - {{rule_1}} (if/then)
    - {{rule_2}} (allowed transitions)
    
    Reports:
    - {{report_1}}
    - {{report_1}}

How to reduce ambiguity (with examples)

Replace adjectives with rules

• Instead of: “nice and modern screen”

• Write: “theme with primary color #0EA5E9 and secondary #111827”

Declare rules “by role”

• “Operator creates and edits only records they created.”

• “Reader cannot create/edit/delete.”

• “Admin can reprocess integrations with errors.”

Specify status transitions

• Define the enum.

• Define the allowed transitions.

• Say who can transition.

• Say what happens on transition (log, notifications, etc).

Checklist before sending the prompt

• Goal and scope in 1–2 lines.

• Modules listed.

• Entities with fields and clear types (enum, date/time, currency).

• Relationships with cardinality (1, 0..1, N).

• Business rules in bullets “if/then”.

• Explicit RBAC (who sees what, who edits what).

Avoid asking for “everything” in a single prompt. If scope grows, split into 3–5 changes.