Prompt Master

Prompt Master

Treat a prompt as a clear task contract. Add information that changes the result; do not add a technique merely because it is common in prompt-engineering guides.

Prompt Essentials

A prompt should communicate the applicable parts of:

• the task and required result;
• context the model cannot infer but needs to perform the task correctly;
• real constraints and the reasons behind non-obvious requirements;
• criteria that distinguish an acceptable result;
• the response format when it matters to the user or a downstream system.

Use a role only when it changes the required expertise, tone, or behavior. Decorative claims such as "you are the best expert" do not replace relevant context or concrete requirements.

State each instruction once. Prefer direct positive guidance when it fully expresses the rule, and keep explicit prohibitions for genuine boundaries or common failures that positive wording would leave ambiguous. Explain why a non-obvious rule matters instead of relying on capitalization or repeated emphasis.

Conditional Techniques

• Examples: Start with a clear task description. Add examples when the required format, tone, or decision boundary is difficult to specify in words, or when observed outputs reveal a concrete failure that an example can correct. Use realistic examples without a fixed count.
• Structure: Use headings, XML, or other delimiters when they help distinguish instructions, context, examples, and input data. They improve readability and parsing; they do not create a security boundary by themselves.
• Chaining: Split work across model calls when an intermediate result must be inspected, evaluated, or kept separate by the application. A coherent task may remain in one prompt.
• Structured output: When software consumes the response, define the exact schema and use a structured-output feature when available rather than relying only on a request to return JSON.

Agents and Tools

For an agent that can take actions, define the autonomy and approval boundary: what it may do on its own and what requires confirmation. Distinguish privileged instructions from user-controlled or external data.

Tool descriptions should tell the model when and why to use the tool, what relevant result it returns, and how failures are represented when this is not already evident from the tool contract. Expose only the tools and permissions needed for the task.

Do not place untrusted data in privileged instructions. Assess prompt-injection risk from the agent's capabilities, the trust boundary, and the consequence of manipulated behavior. Delimiters can help the model recognize data, but access control, least privilege, structured data flow, and confirmations must be enforced by the surrounding system. These measures reduce prompt-injection risk; prompt wording does not eliminate it.