Reusable prompt
Design an API contract that is usable, stable, secure, and observable.
Task type: API Design
Objective: Design an API contract that is usable, stable, secure, and observable.
Context:
- [Project, product, or topic]: [Project, product, or topic]
- [Audience and situation]: [Audience and situation]
- [Constraints, must-haves, and things to avoid]: [Constraints, must-haves, and things to avoid]
Inputs to provide:
[Paste source material here]
Expected output:
1. Architecture overview
2. Core components
3. Data flow
4. Tradeoffs
5. Accuracy checklist
Quality bar:
- Be specific and avoid generic advice.
- State assumptions explicitly.
- Prefer actionable next steps over broad theory.
- If important information is missing, ask up to 3 clarifying questions before answering.
- For time-sensitive or factual claims, label what is known, inferred, and needs verification.
Worked example
The example below fills the same prompt for a realistic Engineering scenario. It is intentionally modest: the goal is to show how the prompt behaves, not to pretend one template solves every Engineering problem.
Task type: API Design
Objective: Design an API contract that is usable, stable, secure, and observable.
Context:
- [Project, product, or topic]: A real Engineering task using the API Design prompt
- [Audience and situation]: A teammate who needs a useful answer and clear next steps
- [Constraints, must-haves, and things to avoid]: Be specific, state assumptions, avoid unsupported claims, and keep the output easy to act on.
Inputs to provide:
Sample material: The team needs help with API Design. The current situation is messy, the goal is clear enough to start, and the answer should separate facts, assumptions, risks, and next actions.
Expected output:
1. Architecture overview
2. Core components
3. Data flow
4. Tradeoffs
5. Accuracy checklist
Quality bar:
- Be specific and avoid generic advice.
- State assumptions explicitly.
- Prefer actionable next steps over broad theory.
- If important information is missing, ask up to 3 clarifying questions before answering.
- For time-sensitive or factual claims, label what is known, inferred, and needs verification.
How to use this prompt
- Replace the placeholders with the actual API Design task, audience, source material, and constraints.
- Keep the requested output sections unless you have a strong reason to remove one; they are there to make the AI answer easier to evaluate.
- Paste the finished prompt into your AI assistant, then ask one follow-up question that tests assumptions or missing evidence.
What a good answer should contain
- 1. Architecture overviewUse this section to make the answer concrete: Architecture overview.
- 2. Core componentsUse this section to make the answer concrete: Core components.
- 3. Data flowUse this section to make the answer concrete: Data flow.
- 4. TradeoffsUse this section to make the answer concrete: Tradeoffs.
- 5. Accuracy checklistUse this section to make the answer concrete: Accuracy checklist.
Why this prompt works
- API Design starts with an explicit task type and objective, which reduces vague answers.
- It asks for context, source material, and constraints before the model writes the final response.
- The 5 output sections make the answer scannable and easier to compare across attempts.
- The quality bar tells the assistant to ask clarifying questions and mark claims that need verification.
Common mistakes to avoid
- Leaving placeholders untouched and expecting the model to infer the missing context.
- Removing the output structure, then asking for a final answer that is hard to review.
- Using the prompt for time-sensitive facts without checking sources or dates.