A prompt is an engineered interface for a model task, not merely a message. It specifies the work, supplies context and inputs, constrains behavior, and defines a usable result. Treat it like an API contract: make its expectations explicit so outputs can be reviewed and tested. section 1.4 section 1.3
Separate the parts that do different jobs:
- Instructions state the task and intended audience. section 1.4
- A labeled input section holds the material to process; a placeholder marks what changes between runs. section 1.4
- Output requirements name the required sections or format, making results easier to compare and reuse. section 1.4
Incident-summary prompt
Instructions: Read the incident report and write a concise post-incident summary for engineers. Identify what failed, the main timeline, and follow-up actions. Output: One-sentence summary; short timeline; action items. Incident report: {{incident_report_text}}. Keeping the report in its own labeled section distinguishes changing input from the task specification. section 1.4
Clear labels help organize a prompt, but they do not enforce a security boundary: user messages and retrieved documents can influence the output alongside trusted instructions. Check for conflicting requirements. For example, an HR assistant told both to be maximally helpful and not to disclose employee records may treat an urgent request as an exception; a narrower policy-only scope removes that ambiguity. section 10.1 section 10.3.2
Test a prompt against representative inputs, review and version changes, and document failures. Avoid accumulating every use case in one instruction block; focused prompts are easier to change and debug. When a prompt is replaced, deprecate it before archiving its history rather than deleting the audit trail. section 1.3 section 11.6.10 section 11.3.9
