Anatomy of a useful prompt

The difference between a prompt that works and one that doesn't is almost never politeness or length. It's whether the prompt contains the things Claude has no way to infer: who the answer is for, what situation it has to survive, and what shape it needs to be in before you can use it.

A working prompt has three parts. The request — what you want done, stated with a verb: explain, draft, compare, list, rewrite. The context — what Claude cannot guess: your audience, your constraints, what you already tried. The shape — what a good answer looks like: its format, its length, the level it's pitched at.

Weak:
  Explain database indexes.

Strong:
  Explain database indexes to a junior developer on my team who
  writes SQL daily but has never tuned a slow query. We're on
  Postgres. Six bullets, no code samples — I want them to
  understand when an index helps before they start adding any.

Notice what the strong version did not do: it didn't say "please", it didn't say "you are an expert", and it isn't longer for the sake of being longer. Every clause it added removes a guess Claude would otherwise have had to make — about the reader's level, the database, and whether code would help or distract.

Format is not decoration. Asking for a checklist, a table or three bullets changes what you can do with the answer, not just how it looks. A table invites comparison, so ask for one when you're choosing between options. A checklist invites action, so ask for one when the next step matters more than the reasoning. Prose is right when the reasoning is the point.

Constraints work when they remove work. "No code samples", "assume I know SQL", "under 200 words" each cut something out, so each one changes the answer. Constraints that only sound demanding — "be concise but thorough and highly detailed" — pull in opposite directions and cancel, leaving Claude to pick for you.

Loading your workspace…