Prompts API Depot: Make Every Instruction Clearer

Blueprint one: classify with a defined label set

Classification works best when the available choices and the treatment of uncertainty are explicit. Start with a compact category list that reflects the decisions your application actually makes. Include a review path so the prompt does not have to force every message into an unsuitable label.

Task: Classify the supplied support message.
Context: Use only the approved category list.
Output: Return one category and a short reason.
Evaluation: Choose “needs review” when no category fits.

Evaluate ambiguous messages and messages covering several topics. Check that the label vocabulary stays consistent and that the short explanation supports the selected category without inventing customer details.

Blueprint two: summarize from supplied evidence

A grounded summary should preserve the distinction between what the source says and what the reader might infer. Specify the audience and the amount of detail needed, then ask for a compact structure that can be checked against the original material.

Task: Summarize the supplied release notes for a support team.
Context: Use only the provided release notes.
Output: Give three change bullets and any unresolved questions.
Evaluation: Every change must be supported by the source.

Test notes containing uncertainty, removed features, and exceptions. A useful summary keeps those qualifications visible. If the source does not answer a question, the output should preserve that gap rather than supply a plausible answer.

Blueprint three: extract fields without guessing

Structured extraction needs an explicit field list and a clear rule for missing information. Decide how the consuming application distinguishes absent values from empty ones before writing the prompt. Preserve identifiers and units exactly where the task requires them.

Task: Extract order details from the supplied message.
Context: Required fields are product, quantity, and requested date.
Output: Return a field-and-value list; mark missing values “unavailable.”
Evaluation: Preserve stated units and never invent a value.

Use examples with incomplete orders, corrections, and conflicting dates. Check each extracted field separately. A neatly formatted response still needs validation before it becomes a stored record or triggers an action.

Treat a prompt as a versioned part of the workflow

Keep the prompt, relevant settings, and evaluation examples together. Change one important element at a time and compare the results against the current version. Record which cases improved and which became worse. This creates a useful history of decisions instead of a collection of prompts that happen to sound persuasive.

Separate formatting checks from checks of factual support and task success. Revisit examples when real inputs reveal a new failure pattern, while keeping a held-out set for comparison. The goal is a prompt that behaves usefully within a defined application, supported by validation and appropriate review. Consistency comes from the whole workflow, not wording alone.