The quality of your prompt directly affects the quality of the answer. That’s the whole idea behind prompt engineering. It sounds fancy. It mostly means: reduce the number of things the model has to guess.

A good prompt doesn’t need elaborate phrasing or a secret formula. Compare these two:

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 one names the outcome, the behavior, the visual constraint, the scope, and the evidence. I might disagree with the implementation, but I can check whether the task is done.

Two rules I follow

Break big tasks down. Don’t ask for a web application that manages projects. Ask for a plan first, then implement one piece at a time. Most tools have a plan mode for exactly this.

Be specific. Instead of can you improve this code?, say optimize this function to reduce its complexity and handle the empty array case. Keep going until the model would do exactly what you have in mind.

A structure that helps

Use these parts when they’re useful:

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

You don’t need all seven for a small task. Explain why this test fails. Don't edit anything. is already a clear prompt. The outcome and the boundary are there.

Examples beat adjectives

Words can be read in more than one way. Examples can’t. If a date formatter must accept 2026-07-29 and reject 29/07/26, say exactly that. A few representative inputs communicate more than a paragraph of clean, robust, and user-friendly.

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

Point at the files

The model doesn’t have perfect memory of your project. When you ask for something, mention the files involved. The validation lives in src/lib/profile.ts, and the tests are in src/lib/profile.test.ts saves a search and removes a guess.

Don’t script every keystroke

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

If you know an interface must stay stable, say so. If you don’t know where the behavior lives, ask the agent to find it and explain it before it edits anything.

If you want to go deeper, Anthropic’s prompt engineering guide is the best reference I know. Most of it applies to every model.

Take one vague request from your own project and rewrite it. Add a concrete outcome, two boundaries, three acceptance examples, and the check that proves it worked.

Write a useful prompt