Templates & debugging

The problem of perpetually starting over

Let's do the math with Sofia. Every week, she writes: three LinkedIn posts, two newsletters, a dozen replies to customer reviews, email rewrites. For each of these tasks, she reinvents her prompt every time — from memory, with unintended variations, and up-and-down results. The good prompts she wrote last month? Lost in the conversation history.

This is the final level of this course, and the most profitable one: moving from craftsmanship (rewriting every time) to tooling (capitalizing on what works). The previous four chapters taught you to write a good prompt; this one teaches you to never rewrite it again.

Identifying your winning prompts

When a prompt gives an excellent result, the reflex to install immediately: save it. Not mentally — in a dedicated note. Then identify what in this prompt is permanent (the role, the tone, the constraints, the structure) and what is variable (the topic of the day, the text to process, the target length). Replace the variable parts with {{ }} fields: you've just created a template.

[TEMPLATE — Email rewrite]
You are {{role}}.
Rewrite this email so it is {{goal: shorter / warmer / firmer}}:
{{email}}
Constraints: max {{n}} words, {{tone}} tone.

Notice the writing convention: the {{goal}} field lists its usual values right in the template. In three weeks, you'll have forgotten what you used to put in that field — the template reminds you. A good template is self-sufficient: any colleague should be able to fill it in without asking you a question.

Anatomy of a robust template

Everything you've learned in this course converges here. A robust template contains: a role with an audience (chapter 4), a permanent context block about your company and your target (chapter 1), the task with its variable fields, few-shot examples if the format is specific (chapter 2), the constraints and the output format (chapters 1 and 4), and if the task is analytical, the reasoning guidance with an "Answer:" line (chapter 3).

[TEMPLATE — Product LinkedIn post]
You are a B2B communications manager writing for rushed, not very tech-savvy restaurant owners. Tone: direct, concrete, never corporate.

Examples of our style:
{{2 existing posts you're proud of}}

Task: write a LinkedIn post about {{topic}}, angle {{angle: time saved / testimonial / key figure}}.

Constraints: 80-120 words, opening hook as a question, 1 quantified benefit, final call to action, no exclamation marks, no hashtags.

This template encapsulates hours of past iterations. That's the capitalization effect: every improvement found once benefits all future uses. After three months, your templates encode an expertise that neither you nor your colleagues need to retrieve from memory anymore.

Building your library (and keeping it alive)

Three or four templates require no organization. But at fifteen, you need a library: a note or document per project, with for each template a clear, task-oriented name ("Email rewrite — soften", not "prompt 7"), the template itself, an example of a successful output below it (to check at a glance that it's the right one), and the date of last update.

Where to store it? Where you already work: a Notion or Obsidian note, a shared doc, even a plain text file. The tool matters little; the routine matters: every Friday, two minutes to carry the week's good prompts into the library. Sofia also turned her three most-used templates into custom "GPTs" — the template becomes the system prompt (chapter 1), and all that's left day-to-day is filling in the fields.

Team bonus: a shared library aligns everyone. When Sofia's intern writes a post with the in-house template, he produces the brand tone from his very first day — Sofia's prompting expertise has become a team asset, not knowledge in her head.

Debugging a bad result: the method

Even with good tooling, a prompt will regularly disappoint you. The amateur reflex: rewriting everything at random, or worse, rerunning the same prompt hoping for a miracle. The pro reflex: diagnose before modifying, by reviewing the ingredients in order:

• Missing context? → add who you are and the situation.
• Ambiguous task? → specify the expected action.
• Unspecified format? → impose length and structure.
• No example? → add 1-2 examples (few-shot).

80% of bad prompts are missing just one of these elements. Add the missing ingredient instead of starting from scratch — and change only one thing at a time. If you modify three elements at once and it improves, you don't know which one did the work, and your library learns nothing. Prompt debugging follows the same hygiene as code debugging: one hypothesis, one change, one test.

flowchart TD
  B["Bad result"] --> Q1{"Missing context?"}
  Q1 -->|"Yes"| F1["Add who you are + the situation"]
  Q1 -->|"No"| Q2{"Ambiguous task?"}
  Q2 -->|"Yes"| F2["Specify the expected action"]
  Q2 -->|"No"| Q3{"Missing format?"}
  Q3 -->|"Yes"| F3["Impose length + structure"]
  Q3 -->|"No"| F4["Add 1-2 few-shot examples"]

An underused diagnostic technique: ask the model itself. "Here is my prompt and the output I got. The output is too generic: what in my prompt is missing or confusing?" The model is surprisingly good at spotting the ambiguities in your instructions — it's your first prompt reviewer, free and always available.

The pitfalls of the over-corrected prompt

Debugging has its opposite excess: the obese prompt. By adding an instruction after every disappointment, some prompts become walls of fifteen constraints — several of which contradict each other ("be exhaustive" + "maximum 100 words"; "warm tone" + "strictly factual"). Faced with contradictory instructions, the model arbitrates silently, and you lose control over what is actually applied.

Hygiene rule: with every added constraint, ask yourself whether an existing constraint becomes obsolete or contradictory. And periodically, do a clean pass: start again from the bare template (role + task + format) and only reintroduce the constraints whose absence visibly degrades the result. You'll be surprised how many accumulated instructions no longer served any purpose.

The final word: a skill that compounds

Let's recap Sofia's journey. Chapter 1: her prompts gained a skeleton (context, task, format). Chapter 2: her examples replaced her adjectives. Chapter 3: her calculations and analyses became verifiable. Chapter 4: her outputs respect a register and usable formats. Chapter 5: all of this is capitalized in a library that improves every week. Same model as on day one — results beyond comparison.

That's the true nature of prompt engineering: not a collection of magic tricks, but a skill of structured communication that compounds over time. Models will change; the ability to phrase a precise need, to show by example, to demand the verifiable and to capitalize on what works will remain your advantage. Your move.