# The four parts of a good instruction
> **What you will learn**
> The [techniques from “New to AI”](/guide/ai-how-to-ask), organised into a system.
> What the four parts are, and exactly how things go wrong when each is missing.
## Why a system is needed
“New to AI” gave you techniques: be specific, give the situation. For personal use
that is enough.
But **when you hand work to an agent, or several people repeat the same task**,
techniques are not enough.
[Agents go just as hard in the wrong direction](/guide/ai-agent-basics), and if
instructions differ by person, so do the results.
So you need **a checklist you can use to confirm nothing is missing.**
## The four parts
| Part | The question it answers | If missing |
|---|---|---|
| **Goal** | what are we making | it makes the wrong thing |
| **Scope** | how far may it reach | it touches what it should not |
| **Done condition** | how do we know it is finished | people disagree on whether it is done |
| **Context** | what already exists | it rebuilds what is already there |
## One at a time
### 1. Goal — what are we making
The most obvious one, and the most often vague.
```
✗ "Improve the login"
→ "improve" is undefined. Speed? Security? The screen?
✓ "Fix the problem where no message appears on failed login"
→ both the problem and the resolution are clear
```
**Tip**: write the goal as **"here is what is currently wrong"** rather than
"here is what I want to do," and it usually becomes clear.
### 2. Scope — how far may it reach
When this is missing, **good intentions cause incidents.** You said improve, so
it touches everything that looks related.
```
✓ "Do not change the authentication logic itself — only the on-screen messages"
```
Scope is most effective written as **what not to do.** Listing everything to do
is hard; the things that must not be touched are few.
### 3. Done condition — how do we know it is finished
The most frequently omitted, and the slowest to reveal itself when omitted.
```
✗ "Make it work properly"
✓ "Done when: wrong password / non-existent account / locked account
each pass their own test"
```
**Without a done condition, a person has to judge "it's done" every time.** That
eats into the gain from automating.
> At organisational scale this part becomes
> [evaluation (evals)](/guide/ai-evaluation) directly. An individual can judge by
> eye; an organisation needs a standard.
### 4. Context — what already exists
Without it, **it reinvents the wheel.**
```
✓ "The coupon model already exists in the Coupon class, and discounts use
PriceCalculator. Use those rather than building new ones."
```
Context also includes **reasons not to do something.** Tell it "we already tried
this and it didn't work" and it deletes that direction.
## All four together
```
[Goal]
Fix the problem where no message appears on failed login.
[Scope]
- Do not change the authentication logic
- Only the messages shown on screen
[Done condition]
- Distinguish wrong password / non-existent account / locked account
- But do not reveal which one was wrong (prevents account-existence leakage)
- Each of the three cases passes its own test
[Context]
- Message strings are managed in messages/en.json
- We were flagged in a security review once for leaking account existence
```
It looks long; it takes **two minutes to write**, and it is faster than giving
it vaguely and asking three times.
## Checklist
Before you send an instruction:
```
□ Goal did you write what is wrong and what would resolve it
□ Scope did you write what must not be touched
□ Done condition is there a way to judge completion
□ Context did you say what exists and what already failed
```
**If all four are filled in and the result is still bad**, it is a different
problem — a limit of the model, or
[context being pushed out](/guide/ai-context-overflow).
## Common misconceptions
### "Am I supposed to write this much every time?"
No. Use it for **repeated work** and **work handed to an agent.** A one-off
question is fine with the “New to AI” techniques.
For repeated work, saving this format as **a template** and reusing it is the
practical move. That is exactly what a
[sub-agent's](/guide/cn-agents-intro) instructions are for.
### "How do I set a done condition in advance?"
If you cannot, **that work is not ready to be handed over.** Hand AI a job whose
completion even a person cannot judge, and judging it stays a human job forever.
---
## Check yourself
**1. Why is it effective to write scope as "what not to do"?**
Answer
**Because listing everything to do is hard, while the things that must not be
touched are few.** Without scope, good intentions reach into everything that
looks related and cause incidents.
**2. Why does a missing done condition eat into the gain from automation?**
Answer
**Because a person has to judge "it's done" every time.** Production is
automatic but judgement is manual, so that much human time remains.
**3. All four parts are filled in and the result is still bad. What do you
suspect?**
Answer
A limit of the model, or **context being pushed out.** It is not the instruction
itself, so look at moving to a new conversation or splitting the work further.
---
Now some practice rewriting → [Rewriting instructions](/guide/ai-rewriting-prompts)