prompt-master

name	prompt-master
description	Creates, improves, and reviews LLM prompts using concise, task-aware guidance. Use when: "напиши промпт", "улучши промпт", "prompt engineering", "проверь промпт"

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.

Run no more than two review waves. After creating or changing a prompt, run wave 1 with a fresh prompt-reviewer. Supply the prompt location, required result and output contract, input sources, trust boundaries, model capabilities, and callers. Review findings are diagnoses, not a work queue. Check the evidence and exact correction; apply only an authorized local correction to agreed normal behavior. If the scenario is rare or unagreed, or the correction adds behavior, state, entities, contracts, dependencies, architecture, or material complexity, reject it with a short reason or ask the user before editing. user_decision_required: false does not replace this check. Include reviewers required by other active skills in these same waves instead of starting a separate wave sequence.

If an authorized fix changes the prompt, run wave 2 with a fresh reviewer against the revised version. Stop after a clean wave or when no authorized correction changes the prompt. After wave 2, do not launch another reviewer automatically; make only remaining local corrections within the agreed prompt, perform applicable direct evaluation, and report any remaining findings or required user decisions.