Moving from one-off prompts to maintainable, programmatic prompt systems.
Never concatenate strings ad hoc. Use named placeholders:
1SYSTEM: You are a {role}. Always answer in {language}.
2
3USER:
4Summarise the document for a {audience} in {max_words} words.
5
6<document>
7{document}
8</document>Benefits: versionable, testable, reviewable in code review, and safe (you control where untrusted input is injected — never inside the instruction region).
Split a complex job into a pipeline where each step's output feeds the next. More reliable than one mega-prompt (Module 2: decomposition).
Raw transcript
│ Prompt A: extract action items (JSON)
▼
Action items JSON
│ Prompt B: assign owner + due date per item
▼
Enriched items
│ Prompt C: draft a polite follow-up email
▼
Final email
Each prompt is single-purpose, independently testable, and can use the right model size for its difficulty (cheap model for extraction, stronger for drafting — cost optimisation, Module 5).
A cheap classifier prompt routes the request to a specialised prompt:
1Classify the request into exactly one of:
2[billing, technical, sales, other]
3Respond with one word only.→ then dispatch to a handler prompt tuned for that category.
Treat prompts like code:
prompts/ module), not scattered in strings| Pitfall | Fix |
|---|---|
| Untrusted input inside the instruction block | Inject only inside fenced data region |
| One giant 2-page prompt doing 5 jobs | Chain into single-purpose steps |
| Hard-coded prompts copy-pasted everywhere | Centralised, versioned templates |
| No logging of prompt+version+output | Log them — you can't debug what you can't see |
Takeaway: Production prompting is software engineering. Templates, chaining, versioning, and tests are not optional.