#Instruction Clarity, Delimiters & Decomposition¶

Ambiguity is the #1 cause of bad outputs. This lesson is about removing it.

1. Separate Instructions From Data¶

Always fence user/input data with delimiters. This prevents the model from interpreting data as instructions and is a real security boundary (prompt injection — Module 5).

1Summarise the text between the triple quotes in one sentence.
2
3"""
4{user_text}
5"""

Good delimiters: triple quotes """, XML-style tags <doc>...</doc>, or Markdown fences. XML tags are especially robust because the model rarely confuses them with content.

1<article>
2{article}
3</article>
4
5<task>Extract every named person as a JSON array.</task>

2. Be Specific and Measurable¶

3. Prefer Positive Instructions¶

Models follow "do X" better than "don't do Y".

• ❌ "Don't be verbose."
• ✅ "Respond in at most 3 sentences."

4. Decompose Complex Tasks¶

If a task has multiple steps, enumerate them. The model is far more reliable following an explicit procedure than inferring one.

1Do the following, in order:
21. Identify the programming language of the snippet.
32. List any bugs you find.
43. Provide a corrected version.
54. Output as JSON with keys: language, bugs, fixed_code.

For very complex workflows, split into multiple prompts/chained calls — one job per call is more reliable than one mega-prompt (you'll formalise this as prompt chaining in Module 4).

5. Tell It What To Do When Unsure¶

1If the answer is not present in the provided text,
2respond exactly with: "NOT_FOUND". Do not guess.

This single line dramatically reduces hallucination in extraction tasks.

Checklist: Is the task one sentence? Is data fenced? Are constraints measurable? Is there a fallback for "unknown"? If yes to all — ship it.