Prompt Writer

Prompt Writer

A prompt's job is not to spell out every rule. The context window is a public good, so aim for the smallest set of high-signal tokens that maximize the likelihood of the output you want. The more rules you write, the more you box the output into the range of things you happened to think of. Assume the model is already very smart and only add context it doesn't already have — challenge every line: does this paragraph justify its token cost, or can I assume the model knows this?

First, set the degrees of freedom

The most important decision is how much latitude to give the model: match the level of specificity to the task's fragility and variability. Picture the model exploring a path. On a narrow bridge with cliffs on both sides there is only one safe way forward, so give exact instructions and specific guardrails — this is low freedom, and it fits schemas, data formats, migrations, API calls, anything where a small error makes the output unusable. In an open field with no hazards many paths lead to success, so give general direction and trust the model to find the route — this is high freedom, and it fits grouping, generation, copywriting, subjective judgment, anything where several outputs are valid and quality is a judgment call.

Get this wrong and everything downstream is wrong. Write an open-field task with narrow-bridge language and the model collapses to the most generic result; write a narrow-bridge task with open-field language and it improvises where it must not.

Most real prompts mix both modes. An agent prompt leaves the approach open but locks the tool-call format; a generation task gives free rein on content but demands strict JSON out. Zone the prompt instead of picking one mode for the whole thing: narrow-bridge treatment for formats, schemas, and tool calls; open-field treatment for content and judgment. And calibrate to the model that will run the prompt — the weaker the model, the more everything shifts toward the narrow bridge.

Find the right altitude

Within either mode, aim for the right altitude: specific enough to guide behavior, flexible enough to leave the model strong heuristics. Too low is hardcoding brittle logic — "if the title contains a colon, split on it and capitalize the second half." Too high is vague guidance with no concrete signal — "write good titles." The altitude that works sits between the two: "make titles specific and punchy over comprehensive; here is a weak one and a strong one."

Principles for both modes

• Think of the model as a brilliant but new employee who lacks context on your norms and workflows. Tell it what you want and why — it is smart enough to generalize from the explanation.
• Prefer general instructions over prescriptive steps. The model's reasoning frequently exceeds what a human would prescribe, so a clear goal often beats a hand-written step-by-step plan.
• Tell the model what to do, not what not to do. And match your prompt's style to the output you want — the formatting you use tends to come back in the response.
• The colleague test: show the prompt to someone with minimal context and ask them to follow it. If they would be confused, the model will be too.

Examples do more than rules

Examples are one of the most reliable ways to steer output format, tone, and structure — they are the pictures worth a thousand words, and they convey the desired style and level of detail more clearly than descriptions alone. How many depends on what you are steering: to pin down a specific output shape or format, give three to five diverse, canonical examples; to convey a taste or a quality bar on an open task, one or two strong weak-output-versus-strong-output pairs is enough, and more would over-anchor the model. Either way, a good example usually beats ten rules, and it won't cap the model the way rules do.