Capstone — Rebuild Your Top 5 Prompts

Audit and rebuild your most-used prompts using everything from this course

This lesson is a project, not new material

You’ve covered eleven lessons of advanced technique: reasoning scaffolds and negative examples, chaining, long-context management, templating, chain-of-thought calibration, self-critique loops, schemas, constraint reinforcement, analytical rigor, voice systems, and systematic testing. The capstone is putting all of it to work on the prompts you actually use — because technique you haven’t applied to your own work isn’t really learned yet.

Step 1 — Identify your top 5

Pick the five prompts you run most often, or the five where quality matters most. These are probably not your most complicated prompts — they’re the ones embedded in your regular workflow: a status report, a client email type, a code review pass, a research summary format, a piece of recurring content.

Step 2 — Audit each one against a checklist

For each prompt, run it against the techniques from this course. Most existing prompts are missing several of these — that’s normal, and finding the gaps is the point.

AUDIT CHECKLIST

Structure (Lesson 1)
[ ] Does it include a positive example of the output you want?
[ ] Does it include a negative example from a real rejected output?
[ ] Are stable instructions early, task specifics late?

Process (Lessons 2, 3, 6)
[ ] Would this benefit from being split into a chain?
[ ] If it uses long reference material, is it labeled and does
    the question come after the material?
[ ] Would a critique-and-revise pass measurably improve it?

Reasoning (Lesson 5)
[ ] If it involves multi-step logic, does it use a structured
    reasoning scaffold, not just "think step by step"?
[ ] If it's a judgment/creative task, have you confirmed CoT
    isn't making it worse?

Output (Lessons 7, 8)
[ ] If output feeds another system, is there an explicit schema
    with edge cases defined?
[ ] Are hard constraints (length, format) restated right before
    the generation point?

Voice & rigor (Lessons 9, 10)
[ ] For analysis: are claims tied to evidence, with a counter-case?
[ ] For voice-dependent content: concrete do/don'ts, not adjectives?

Validation (Lesson 11)
[ ] Have you tested this prompt against more than one input?
[ ] Do you know what "better" means for this prompt, in writing?

Step 3 — Rebuild, one prompt at a time

Don’t try to apply every technique to every prompt — that’s over-engineering. Apply the two or three techniques that address the actual failure modes you’ve observed in that specific prompt. A status-report template mostly needs constraint reinforcement and a good example; an analytical prompt mostly needs evidence-tagging and a counter-case section; a classification prompt mostly needs a tight schema.

Key principle: The goal isn’t a maximally sophisticated prompt. It’s a prompt that reliably solves the actual problem you have with it today. Match the technique to the failure mode you’ve actually observed, not to whichever technique feels most advanced.

Step 4 — Version it into your library

Once a rebuilt prompt is working, don’t let it evaporate back into a chat thread. Add it to the prompt library you started in Lesson 4, with a version note describing what changed and why — this capstone is, in effect, generating five new entries (or five new versions of existing entries) for that library.

Step 5 — Test before you trust

Before retiring the old version of a prompt, run the rebuilt version against a small test set (Lesson 11) covering your typical case and at least one edge case. A rebuild that looks better on the first try you happen to glance at is exactly the trap that lesson warned about.

Do it now: Pick your single most-used prompt. Run it through the audit checklist above, identify the two techniques most likely to fix its actual weak points, rebuild it, test it against 3 inputs including one edge case, and save the versioned result to your library.

Tip: Come back to this capstone checklist any time a prompt in regular use starts underperforming — it’s a diagnostic tool, not a one-time exercise.