On the morning I meant to fix the store descriptions for my wallpaper apps, I pasted yesterday's notes into the agent as they were: about thirty bullets, in the order they had occurred to me. What came back was polite, long, and a little off from what I wanted in several places at once.
I asked for fixes, got new misses, and only on the third round did it sink in. The agent was not the problem; my request was. The notes said what was happening, but never what I wanted, how far it should reach, or in what form it should come back.
The point I want to start with is simple: folding a request shorter reduces rework more than making it longer. Below is the five-line shape I use, plus a small script that checks it mechanically. It works for non-code tasks too.
Why long notes cause rework
Notes are a record for yourself. They hold the history, the hesitation, even the ideas you dropped, and you can read them because you were there. An agent reading them for the first time cannot tell which lines are the request and which are background.
So it weighs every line equally and tries to answer all of them. A reply to thirty lines ends up long and flat, which is exactly what I got.
There is a quieter gap as well: notes rarely say what not to do. "Leave the Japanese text alone" was obvious in my head and absent on the page.
The five lines
I fold every request into these five lines before handing it over. The order matters.
| Line | What goes in it | What happens if it is empty |
|---|---|---|
| 1. Goal | Why, and for whom | A polite answer aimed at the wrong target |
| 2. Material | The files or text to read | Gaps get filled by guesses |
| 3. Scope | What may be touched, what may not | Parts you never mentioned get edited |
| 4. Finished form | The shape of the result (table, diff, list) | Decoding the answer lands back on you |
| 5. Check | What to show you before finishing | You cannot trace what changed |
Line five needs a word. It is not about the quality of the result; it is the door through which you inspect it. For example: "Show me the list of paragraphs you plan to change first," or "If you are unsure about a phrase, ask instead of deciding."
Before and after: updating store descriptions
Here is part of the notes I pasted that morning.
- the description feels old
- English was fixed earlier
- maybe German and French too
- the number of wallpapers has grown
- a review said "too many ads"
- don't touch Japanese (pretty sure)
...(about twenty more lines)Folded into five lines, it became this.
1. Goal: Make the store description of my wallpaper app easier to read and match the latest update. The reader is someone seeing it for the first time.
2. Material: store/ja.md (source of truth), and the current text in store/de.md and store/fr.md.
3. Scope: The de and fr descriptions only. Do not touch ja. Do not touch the app name or legal wording.
4. Finished form: A table with current text and proposal side by side, one line of reasoning for each change.
5. Check: Before rewriting, show me the list of paragraphs you intend to change. If a phrase is uncertain, ask rather than decide.Same content, very different result. It came back as a table, so I could read each proposal one paragraph at a time, and I could see at a glance that the language I had excluded was unchanged.
A request is the text in which I take on, in advance, the places where the other side might hesitate.
Checking that all five lines are there
Knowing the shape is not enough; on busy days I hand over four lines. The days I skipped "scope" are the days I had the most rework. So I keep a small script that checks the five lines before I send anything.
What it solves: it catches blank or "later" items mechanically, before the request leaves my hands.
#!/usr/bin/env python3
"""brief_check.py — confirm the five items of a request are present.
Usage: python3 brief_check.py brief.txt
Exit code: 0 = complete / 1 = something missing
"""
import re
import sys
LABELS = ["Goal", "Material", "Scope", "Finished form", "Check"]
PLACEHOLDERS = {"", "later", "tbd", "todo", "-", "none"}
def parse(text: str) -> dict:
"""Pick up lines shaped like '1. Goal: body' into {label: body}."""
found = {}
for line in text.splitlines():
m = re.match(r"^\s*\d+[.)]\s*([^:]+):\s*(.*)$", line)
if m:
found[m.group(1).strip()] = m.group(2).strip()
return found
def main(path: str) -> int:
with open(path, encoding="utf-8") as f:
items = parse(f.read())
problems = []
for label in LABELS:
body = items.get(label)
if body is None:
problems.append(f"{label}: line is missing")
elif body.lower() in PLACEHOLDERS:
problems.append(f"{label}: still empty")
elif len(body) < 12:
problems.append(f"{label}: too short ({len(body)} chars); add specifics")
if problems:
print("Review before handing over:")
for p in problems:
print(f" - {p}")
return 1
print("All five items are present.")
return 0
if __name__ == "__main__":
if len(sys.argv) != 2:
print(__doc__)
sys.exit(2)
sys.exit(main(sys.argv[1]))Why a lower limit at all? Some short lines do carry meaning, such as "Scope: de and fr only." Still, most short lines I wrote were "written in spirit only," and a rough threshold is enough of a nudge to make me stop and add detail.
Three ways to write the scope line when you get stuck
Line three is the one most often left empty. When I cannot think what to put, I pick from three shapes.
The first is naming the target: "the de and fr descriptions only," listing what may be touched. The second is naming the exclusion: "leave ja and the app name alone." The third is capping the amount: "at most two sentences per paragraph," a ceiling on the size of the edit.
At first I wrote only exclusions, and the agent edited widely everywhere the list did not mention. These days I put both target and exclusion on one line, and when it gets long, I keep the target.
What five lines do not solve
The shape does not fix everything. When background really matters, folding can drop an important circumstance.
In that case I do not add a sixth line. I hand the background over as a file under line two, Material. Keeping the instruction and the background apart means the agent never has to guess which is which.
One more thing: the shape works best on small tasks. For work that spans days, I first split the job until one request fits in five lines, and that went better than stretching the template.
Try it tomorrow
Before your next request, stop pasting and write only the scope line first. Putting into words what must not be touched changes the outline of what comes back.
The other four lines tend to follow once that one is down. As an indie developer I still skip lines on rushed days — which is exactly why the script sits next to my notes.