Prompting Is Not the Skill You Think It Is

A polite lawn sign says: please, always reply in JSON. Footprints cross the grass anyway. A sign isn't a fence: it was asked nicely and never checked. Always, never and you must are just more input, which is not the same as a check outside the prompt that can reject a bad result.

A prompt can express intent, what you are trying to achieve and the part skipped most; constraints, what must not happen; examples, two or three showing the pattern; the requested shape of the output; and priorities, what wins when instructions pull apart. Each narrows the field of likely answers. None of them closes it.

An instruction says ALWAYS RESPOND IN JSON, VERY IMPORTANT. The Model says noted. Most replies are JSON, and occasionally one is plain text, and nothing notices. Emphasis is crossed out in favour of a validator: always and never are more input, and more input is not a check.

A prompt tells the model what you want, like a sticky note asking for JSON. A contract gives software something it can check: fields and types that pass or get rejected. Plain language can be the human-facing interface, with something checkable underneath.

Asked for three slogans, got seven and a poem: the skill is reading that gap. Wrong tone or length: say what you didn't say. Wrong shape now and then: use a schema and a validator. Wrong facts: trace the evidence before the wording. Mostly right but wrong sometimes: stop editing and design for that.

A prompt file with its version history, kept in git, beside a fixed set of test inputs rerun after every edit. If a prompt does real work, keep it in version control, note what a change should do, and rerun the same inputs after each change.