Your first prompt is a draft

Treat prompting like writing, not like casting a spell. Nobody nails a tricky prompt on the first try, and expecting to is exactly what makes people give up on a tool that would have worked two edits later. The real skill isn't writing the perfect prompt — it's debugging a decent one quickly.

Diagnose before you change

When a result is off, resist the urge to rewrite everything. First name what kind of wrong it is:

• Ambiguous instruction — it did something reasonable but not what you meant. Tighten the wording.
• Missing context — it didn't know something only you know. Add it.
• Wrong format — the content's fine, the shape's wrong. Specify the format or show an example.
• Ignored a constraint — you said it, it skipped it. Move that constraint to the end and make it emphatic.

Change one thing at a time

This is the rule people break most. If you alter the role, the format, and the examples all at once and it improves, you've learned nothing about why. Change one variable, observe, keep or discard. It's slower for a single prompt and far faster across the hundred you'll write this year.

Build a prompt library

The payoff of all this iteration is reuse. When a prompt works, save it — with a note on what it's for and any gotchas. Over time you accumulate a personal toolkit: the email-rewriter, the meeting-summarizer, the code-explainer. One-off luck becomes a repeatable skill you carry between tools and projects.

Don't hunt for magic words. Start with a reasonable prompt, diagnose the specific failure, change one thing, and save what works. That loop is prompt engineering.

Try this: Find a prompt you abandoned because the output was bad. Diagnose it with the four failure types above, change only the one that applies, and rerun. Then paste the working version into a notes file — the first entry in your prompt library.