Write Prompts Around the Finished Work

Write an AI prompt by defining the finished work before describing how the model should behave. The most reliable structure we found moves through the intended outcome, operating context, controlling sources, limits, required shape, and definition of done. Use only the parts that close a real decision.

That method produced more accepted target outputs in our 12-case prompt run, but detail was not automatically helpful. Five noncoding cases tied, and one revised launch prompt regressed. The goal is not a long prompt. It is work that arrives with the right facts, shape, and review boundary.

Start with the definition of done

“Write a report” asks for a category. “Write a six-row incident table from the supplied logs, keep unknown root causes unknown, and flag any row missing an owner” asks for work a reviewer can inspect.

The second prompt does three jobs before the model writes a word. It names the artifact, protects the evidence boundary, and exposes missing fields. Tone and persona can come later if they change the result.

Our prompt-outcome run held 12 synthetic tasks and their inputs constant. Across the 10 noncoding cases, rough prompts fully passed 20 of 30 runs and revised prompts passed 28 of 30. The largest gains came from missing citations, table fields, action-item uncertainty, and protected executive-summary facts. The complete before-and-after article keeps the five ties and one regression beside those wins.

These parts can live in one paragraph, a structured form, or a repository instruction file. The labels are scaffolding. The closed decisions are the product.

Change one running example

Suppose the task is to compare two AI provider privacy policies. The rough version is:

Compare these AI provider privacy policies and recommend one.

The model can produce fluent prose from that request, but it must invent the comparison frame. Does retention matter more than regional processing? Should it cite a paragraph, link, or nothing? Which workload controls the recommendation? What happens when one policy is silent?

The revised assignment closes those decisions:

Outcome
Compare Provider A and Provider B for a regulated API workload, then recommend
one under the stated assumption.

Sources
Use only the two supplied policy documents.

Criteria
- Data retention
- Training use
- Regional processing
- Enterprise controls

Constraints
Cite the source ID and section heading for every policy claim. Keep anything
the policies do not state as unknown.

Output
Return a four-row comparison table followed by a recommendation of at most
120 words.

Acceptance check
Every criterion appears, every policy statement has a citation, unknowns stay
unknown, and the recommendation names the workload assumption.

In the frozen run, the rough prompt produced 0/3 fully accepted outputs. The revised version produced 3/3. The improvement did not come from phrases such as “be comprehensive.” It came from supplying the missing decision and a citation receipt.

Use one copyable contract

Start with this template:

Outcome
[Name the finished work and the decision it should support.]

Context
[Name the audience, operating situation, and relevant prior state.]

Source material
[Provide or identify the facts, files, data, examples, or policies that
control the answer.]

Constraints
[State what must not change, what may not be inferred, and what remains
unknown.]

Output contract
[Define the sections, fields, schema, length, tone, and completion receipt.]

Acceptance check
[List the observable conditions that make the result usable.]

Do not fill every field with generic advice. “Be accurate” does not define accuracy. “Use a professional tone” does not identify the audience. “Act as a world-class expert” has never supplied a missing fact.

A short prompt is enough when the environment already closes the decisions. In our invoice extraction case, the source input listed the exact JSON keys and the rule for missing values. Both variants passed 3/3. Repeating the schema in more elaborate prose would not improve the observed outcome.

Three jobs need different evidence

Marketing prompts need a source ledger. The model should see approved facts, prohibited claim categories, unresolved details, the audience, and the format. In the factual-marketing run, source-ledger prompts met 11 of 12 fact-and-format contracts; rough prompts met 3 of 12. The stricter drafts were safer raw material, not finished campaign copy. The marketing lab shows the flat prose and remaining human-review boundary.

Coding prompts need repository evidence. Name the behavior, relevant files, invariants, allowed paths, and commands. Both prompt variants passed all 12 repository runs in our coding lab because the harness supplied strong tests and scope controls to both. The revised prompts mainly reduced unrelated code under an unblinded review. The coding lab explains why passing tests did not settle the merge decision.

Structured extraction needs a schema and an uncertainty rule. For invoice JSON, define every key, value type, and missing-value behavior. For meeting notes, define how to represent an absent owner or due date. A model should not turn an empty source field into an educated guess merely because the output table expects a value.

The prompt format changes because the acceptance evidence changes.

More detail can damage the result

The launch-announcement test began with a source containing four approved facts and three prohibited claim categories. The revised prompt repeated those categories and told the model to mark unsupported claims unknown. Two of three outputs responded by printing the prohibited categories as disclaimers.

The prompt became more explicit and the work became less publishable.

That regression provides a practical editing rule: phrase constraints as output behavior. “Do not mention savings percentages, including to deny them” is safer than “Savings percentages are unknown.” The first controls the artifact. The second gives the model language it can copy.

Long contexts can fail in a similar way. A repository dump may contain an old interface beside the new one. Three research papers may measure incompatible outcomes. More input helps only when the prompt labels which evidence controls the decision and which material must stay separate.

Test the prompt as a small experiment

Use the AI Prompt Generator when the task begins as a brief. Use the AI Prompt Optimizer when an existing instruction produced a recognizable failure. Then run a controlled loop:

1. Choose a representative input.
2. Freeze the acceptance conditions before revising.
3. Run the original prompt more than once.
4. Record full, partial, and failed work.
5. Change one instruction attached to a failure.
6. Rerun under the same model settings.
7. Keep ties and regressions.

Do not infer accepted work from a copied prompt or a positive prompt vote. The target-model output still needs its own check. For code, that means repository commands and diff review. For marketing, it means factual and editorial review. For data, it means recalculating the result from the source.

Model and token choices belong to the experiment too. The Token Counter can expose how much source material the assignment carries, and current API pricing can help select routes for repeated runs. Neither number says whether the output is usable.

Stop adding words when the work survives. The finished prompt is not the longest version or the one with the most headings. It is the smallest instruction and evidence bundle that repeatedly produces accepted work on representative inputs.

If a rule does not protect a fact, decision, interface, shape, or check, remove it and rerun.