Clear instructions / repeatable outputs
Prompt engineering that turns rough intent into useful AI work
Good prompt engineering is not about adding more words. It is the work of identifying the outcome, preserving the user's real intent, supplying the context that changes the answer, and making the finished result easy to evaluate.
- Use this when
- A request has a real goal but leaves the model guessing about the deliverable, reader, constraints, source standard, or success condition.
- You leave with
- A task-specific instruction that preserves the ask and gives the model enough context to produce a result the user can judge.
First action
Reviewed 26 Jul 2026
Start the work before reading further.
Write one sentence that names the finished artifact and the decision, action, or use it must support.
Start with the outcome, not a template
A weak request often contains a useful goal but leaves the model to guess the audience, deliverable, constraints, or evidence standard. The first job is to recover those missing decisions without replacing the user's objective with a generic framework.
The strongest prompt states what must be produced and why it will be used. It then adds only the context that materially changes the result. A coding request may need the runtime and failure behavior; a strategy request may need the decision, stakeholders, and tradeoffs; a writing request may need the reader, voice, and publication format.
- 01Name the finished artifact: implementation, memo, analysis, lesson, plan, or decision brief.
- 02Preserve supplied names, facts, constraints, and non-negotiable language.
- 03Keep unknowns visible when inventing a default would change the result.
- 04Request checks that let the user recognize whether the answer succeeded.
Match the instruction to the kind of work
Different tasks need different prompt anatomy. Code benefits from environment details, interfaces, tests, and failure modes. Research benefits from source standards, uncertainty, and a distinction between evidence and inference. Creative work benefits from a clear emotional or narrative target without over-constraining every sentence.
A universal prompt system should therefore route by the work being requested, not simply insert the request into a fixed shell. Structure is useful only when it reflects the task's real dependencies.
Evaluate the output before adding more instructions
A prompt is ready when another model can act on it without guessing the central objective, and when the user can tell whether the response is complete. More requirements are not automatically better; redundant instructions can bury the actual ask.
Use a short quality pass: check intent fidelity, task specificity, factual boundaries, usable formatting, and completion criteria. Revise the weak dimension instead of rebuilding everything from scratch.
Close the brief
Check the work before you move on.
- 01Preserve the user's objective before improving the wording.
- 02Add domain-specific context only when it changes the answer.
- 03Define a usable deliverable and a visible success condition.
- 04Remove boilerplate that could appear in any unrelated prompt.
Evidence to keep
The response can be checked against a named outcome, supplied facts, required boundaries, and a visible completion standard.
Next route