Lint, then measure: Prompt anatomy

Cheap automatic checks, and an ablation that shows what each part of a prompt is worth.

lint(SPEC, render(SPEC))        # [] means none of the cheap checks fired
lint(PromptSpec(task="Do {{thing}}"), "Do {{thing}}")
# ['missing section: output_format', 'unfilled variable: thing']

The linter catches a missing task or format, leftover {{variables}}, vague rules without numbers, duplicate rules and a size over budget. A clean lint is not proof that the prompt is good. It only removes errors that never need a model to find. Run it on the template, not on a prompt that already contains user text, because a ticket that happens to contain {{x}} would be reported as an unfilled variable.

Ablation: what is each part worth?

Ablation

Removing one part of a system to see what it was contributing. For prompts: run the same test inputs with the full prompt, then with each part taken out in turn, and compare the scores.

for name, spec in ablations(SPEC).items():
    print(name, evaluate(spec, TICKETS, complete))

Real output of the example. Removing the output format or the labels breaks things; removing role or task changes nothing for this imitation model.

Variant	Parseable	Correct	Mean reason words
full prompt	100%	90%	8.0
without role	100%	90%	8.0
without task	100%	90%	8.0
without context (labels)	100%	0%	8.0
without constraints	100%	90%	8.4
without output format	0%	0%	0.0

Two lessons. First, the parts that carry information the code depends on (the labels and the format) matter enormously. Second, one of the ten tickets stays wrong even with the full prompt. "Checkout is broken and my payment fails" is labelled bug, but the imitation's keyword rule sees payment first. Finding such cases in bulk is what module 7 (debugging) is for.

With only ten tickets, one ticket is 10 percentage points. Differences that small are noise. For a real decision, use more cases (Level 9).

What you will use daily at work

Practice	What it looks like
Prompts as files	Prompts live in version control as templates, not as strings buried in code.
Shared building blocks	One reviewed output-format block is reused by every prompt that needs it.
A fixed test set	Each prompt change is scored on the same inputs before it ships.
Template checks in CI	A script like the linter fails the build on a missing variable.

Draft: confirm how your provider and libraries apply chat templates and handle system prompts before relying on this.

Interview angle

"How do you improve a prompt?" A weak answer is "try different wording". A strong one: hold the test inputs fixed, change one part at a time, score the outputs, and keep what helps. Mention that you would store the prompt in version control (module 5), and that results from a different model need re-checking. A follow-up: "what is the difference between a prompt template and a chat template?"