The problem with a one-liner is that it states only what to do, not the other three things: where input comes from, what output looks like, and what counts as done. Add those and results become reproducible.
Before
Help me turn these PDFs into an index.
After
Scan every PDF under [directory: pdfs/] and generate a Markdown index at index.md. [Input] - Only PDFs directly in pdfs/, no recursion - Files with no extractable text go in their own section marked 'read failed' [Output] A table with four columns: filename | one-line description | three keywords | modified time - The description must come from the body, never inferred from the filename - Group by topic, newest first within a group [Acceptance] - index.md exists and no original PDF was modified - Every description can be located in the source text - Unreadable files are listed separately, not skipped - total = successes + failures Do only the first 5 for now so I can check the format, then continue.
What each section fixes
| Section | Fixes | Without it |
|---|---|---|
| Input | Boundaries and preconditions: what to process, what not to, what to do with bad data | It decides scope itself, differently each time |
| Output | Shape and criteria: how many columns, what format, which fields must not be guessed | Output varies; nothing can be checked mechanically |
| Acceptance | What done means, checkably | It says it finished; you cannot say whether it did |
Two details most often missed
- Say 'do not guess' explicitly. Without 'the description must come from the body', it invents a plausible line from the filename.
- Put 'first five only' in the instruction. That one clause turns a gamble into two confirmations at almost no cost.
Every acceptance line must be mechanically checkable. 'Good quality' is not an acceptance item; 'total = successes + failures' is.