Read the before/after chapter.

Prompts are work instructions

Weak prompting asks the model to “do the task.” Strong prompt operations define the job, the inputs, the constraints, the judgment criteria, and the shape of the answer.

The goal is not to make prompts longer. It is to make the work less ambiguous — so the same request produces a useful result every time.

Weak prompt vs operated prompt

The difference is easiest to see before the model writes anything. The weak prompt asks for taste. The operated prompt names the task, audience, output, constraints, and review bar.

This is not about stuffing the model with more words. It is about removing the unknowns that usually cause bland, unusable output.

The operated version

The operated version gives the model a bounded assignment, makes the review criteria part of the work, and can become a template after it survives review.

The operating loop

Every dependable prompt runs the same loop: intent → context → contract → route → output → verification → reuse.

A prompt is not promoted because it sounded clever. It is promoted because it produced a useful output under known constraints, with enough evidence that someone else can reuse it.

The Universal Prompt Contract

Treat the request as a contract with fields: task, context, role/route, output contract, constraints, verification, and a reuse policy.

Filling those fields removes the ambiguity before generation starts — which is where most bad output actually comes from.

Define the output first

Name the exact shape of the answer before the model writes it: format, length, sections, and what “done” looks like.

An output contract turns “make it good” into something you can actually check.

Review gates that stay real

Use a fast audit before promoting any result — context complete, limits explicit, expected shape defined, assumptions visible, review criteria stated, version known.

If you cannot explain why the answer is safe to ship, it is not ready to ship.

Reuse beats cleverness

Good once is not reusable. Save the improved prompt as a versioned template so the next run starts from the last good result, not from scratch.

That is the difference between collecting prompts and building a dependable AI-assisted workflow.

Cathedral case studies

The planned Cathedral Edition should prove the method with controlled runs: DeepSeek barebones first, then the same task with prompts built from the Manual.

Each case study should capture the task, model/version, baseline output, operated output, review notes, revision, and the reusable prompt that survives the test.