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.

Quality

When a prompt needs empirical evaluation, especially for reusable or consequential use, define what a correct result means and use representative normal, edge, and adversarial scenarios that match the real task. Compare old and new versions on the same scenarios. Treat a metaprompt or model self-critique as a source of hypotheses, not as proof that a revision is better.

After creating or changing a prompt, run one review stage with a fresh prompt-reviewer. Supply the prompt location, required result and output contract, input sources, trust boundaries, model capabilities, callers, validation evidence, and a short explanation of what changed, how the prompt works, why this approach was chosen, deliberate limits, and assumptions. The reviewer verifies that explanation and may challenge the chosen approach or propose a more useful alternative within prompt quality and safety. Include reviewers required by other active skills in the same stage.

After the review, apply no finding and do not repeat it automatically. Explain what you changed and how the prompt works, then what the reviewer found, what it can cause, whether you agree and why, and what you recommend. Wait for the user's approval before editing.