loom-prompt-engineering

Prompt Engineering

Overview

Craft prompts for LLMs and orchestrated agents (system prompts, agent signals, few-shot). Optimize for output quality, consistency, and injection-resistance. Bias toward measurable iteration over intuition.

Prompt anatomy

Use named sections to make the contract inspectable. The best order and amount of context are model- and task-dependent; evaluate them for the target system. A structured prompt has:

1. Role — who the model is ("You are a Rust reviewer"). Sets vocabulary and priors; keep it short.
2. Instructions — the task as explicit, ordered directives. Positive imperatives ("Return X") beat prohibitions.
3. Context — data, code, conventions the task needs, clearly delimited (below).
4. Examples — few-shot demonstrations when format/behavior must be consistent.
5. Output contract — exact format, schema, length, and what to do on failure.

Tell the model what TO do, not just what to avoid. Replace vague verbs ("analyze") with the concrete deliverable ("list each bug as file:line — description").

Delimiters & structure

Separate instructions from data with unambiguous delimiters. XML-like tags or clear headings both work; choose the convention the target model and application already use. Delimiters improve inspection, but are not a security boundary and do not make hostile text safe by themselves.

<instructions>
Summarize the article for engineers in 2-3 sentences.
</instructions>

<article>
{article_text}
</article>

Prefer tags/headings over prose for multi-part prompts. Keep untrusted content visibly distinct from the task, but do not treat a delimiter as isolation or authorization; enforce authority and tool permissions outside the prompt.

Few-shot: selection over quantity

Use examples when the required behavior or output shape remains ambiguous after clear instructions. Start with the smallest representative set, then add or remove examples only when the eval shows a material effect.