Goal
What outcome are you actually trying to achieve? Give the reason, not only the immediate action.
Introduction 2
Good prompting is mostly good specification.
You do not need magic words. You need to make the job legible: what you want, what the AI needs to know, what it must do, what it must not assume, what the output should look like, and how success will be checked.
The six-part request
Context
Supply private facts, project rules, source material, audience, prior decisions and terminology the AI cannot safely infer.
Task
State the concrete work: analyze, compare, rewrite, design, debug, research, extract, plan or review.
Constraints
Define boundaries: scope, length, authority, technologies, files allowed, time horizon, style or things it must not change.
Output
Say what a useful answer looks like: decision table, brief, draft, step sequence, test plan, code review or prioritized list.
Verification
Tell the AI how to treat uncertainty and what proof you require: sources, tests, file inspection, calculations or a real run.
A weak request
Make my website better.
The AI has to guess the audience, problem, technology, scope, tone and definition of “better”.
A useful request
Goal: make this small personal AI guide easier for beginners to navigate. Context: it is a static website hosted on WAMP. It must remain portable and require no build system. Task: review the page structure and navigation, then propose the smallest changes that improve comprehension. Constraints: preserve the existing dark visual style; no framework; no analytics; do not rewrite valid content unnecessarily. Output: list issues by severity, then give a patch plan. Verification: distinguish observed issues from preferences. Do not claim a fix is complete until the rendered pages have been checked.
Context is not the same as a long prompt
More words do not automatically mean more clarity. Good context is the minimum information required to avoid the wrong assumptions.
Useful context
“The customer is a retired engineer, already understands networking, and wants a local solution because the documents cannot leave the office.”
That changes the right explanation and likely architecture.
Noise
Pages of irrelevant history, duplicated instructions and contradictory requirements make it harder to identify what is authoritative.
Structure the context and make authority explicit when several sources disagree.
A powerful pattern: “Before proposing a solution, tell me which important facts are missing and which assumptions you would otherwise need to make.”
Use authority order when it matters
In real projects, AI may see requirements, old documentation, configuration and existing code that disagree. Tell it which source wins. A typical order might be: current instruction → locked decisions → design documentation → configuration/schema → existing implementation. This prevents the AI from treating an accidental implementation as the intended design.
AdventureWorld uses exactly this principle. Existing code is deliberately the lowest authority; design and locked decisions govern it. This is one reason the project can use AI for substantial review without allowing the current implementation to redefine the specification.