The basic convention
Write a component name in uppercase, followed by a colon. Put the component's contents below it. Separate blocks with a blank line. Labels are signposts, not commands: the material below CONTEXT remains context even when it contains sentences that look like instructions.
- Labels: use uppercase names such as INTENT:, CONTEXT:, INSTRUCTION:, CONSTRAINTS:, RESULT: and VALIDATION:.
- One block: keep one component's material together so a reader can see its scope.
- Blank lines: leave a blank line between blocks for scanning and for reliable section boundaries.
- Material: paste documents, data and examples under CONTEXT or KNOWLEDGE rather than hiding them in a vague instruction.
Canonical skeleton
INTENT: [what you are trying to accomplish and who will use the result] CONTEXT: [paste source material and describe the situation] INSTRUCTION: [the primary action the model should take] CONSTRAINTS: [limits, requirements, tone, exclusions and treatment of uncertainty] RESULT: [the artefact, sections, fields or format you expect] VALIDATION: [checks, citations, assumptions and missing information to report]
Framework labels
The six canonical labels above map directly to the Gaiish method. BASIC uses GOAL:, CONTEXT:, ACTION: and OUTPUT:. PRO uses ROLE:, INTENT:, CONTEXT:, KNOWLEDGE:, CONSTRAINTS:, PROCESS:, OUTPUT: and VALIDATION:. Use the labels belonging to the framework you chose; do not add empty ceremony to a small request.
Labels are case-insensitive in meaning, but uppercase is the written convention because it makes the structure immediately visible. A model may interpret equivalent wording differently, so keep names consistent within a team or document.
Optional modifiers
Modifiers add a useful instruction without pretending to be new components. Put them inside the block they qualify, and explain an unfamiliar modifier the first time it appears. Examples include a tone or audience modifier under CONSTRAINTS, a source priority under KNOWLEDGE, or a numbered process under PROCESS.
CONSTRAINTS: TONE: direct and calm. AUDIENCE: a non-specialist manager. LENGTH: no more than 500 words. EXCLUDE: unsupported claims and unexplained jargon.
What not to do
- Do not hide the goal in a vague verb. “Do something with this” does not tell the model what success means.
- Do not paste instructions into CONTEXT without marking them. Separate source material from what you want the model to do.
- Do not make every sentence a new label. Components are blocks, not a decorative line-by-line format.
- Do not use contradictory constraints. Resolve “be exhaustive” and “use 50 words” before sending the prompt.
- Do not treat validation as a guarantee. A model's self-check is a useful pass, not independent proof.
- Do not assume labels erase ambiguity. Supply the facts, audience and boundaries the answer depends on.
Syntax in practice
Start with the smallest framework that fits. Write the blocks in a stable order, then read only the labels: can another person reconstruct the task from them? Read the contents next: is each claim in the right block, and does validation check the actual constraints? This two-pass habit catches missing structure before a model does.