Write a useful prompt

A good prompt reduces the decisions the model must guess. It does not need elaborate phrases or a special formula.

Compare these two requests:

Improve the saved articles page.

Add an empty state to the saved articles list.

Show it only after loading finishes and the list is empty. Reuse the existing list typography. Do not change the API. Add tests for empty, loading, and populated states. Inspect the current component first and keep the change inside this feature.

The second prompt names the outcome, behavior, visual constraint, scope, and evidence. We can disagree with the implementation, but we can check whether the task is complete.

A practical prompt structure

Use these parts when they help:

• Outcome: what should be true when the work is done
• Current state: the bug, limitation, or starting point
• Scope: where the agent may work
• Constraints: interfaces, styles, dependencies, and decisions to preserve
• Acceptance criteria: observable examples that must pass
• Verification: tests, builds, visual checks, or sources to use
• Deliverable: code, explanation, plan, review, or another format

You do not need all seven parts for a small task. Explain why this test fails. Do not edit anything. is already clear because the outcome and boundary are explicit.

Give examples at the boundary

Examples are especially useful when words can be interpreted differently. If a formatter must accept 2026-07-29 and reject 29/07/26, say so. A few representative inputs often communicate more than a paragraph of adjectives.

Include negative examples too. Never follow redirects outside our domain exposes a boundary that a happy-path example would miss.

Do not prescribe every keystroke

Describe the result and important constraints, then let the agent inspect the system. A prompt that guesses every file and implementation step can force the wrong solution.

If you already know a specific interface must remain stable, say that. If you do not know where the behavior lives, ask the agent to find and explain it before editing.

Split large work

A large feature combines discovery, decisions, implementation, and verification. Ask for a plan when architecture or scope is uncertain. Then implement one coherent behavior at a time.

Small prompts create review points. You can correct a misunderstanding before it spreads through a large diff.

Try this

Rewrite one vague request from your project. Add a concrete outcome, two boundaries, three acceptance examples, and the check that will prove the result.