Turn a vague request into a usable task
Write and evaluate a Context, Task, Standards and Evidence prompt.
Reviewed: 2026-10-03
Illustrated teaching example • Fictional data
Narration: Microsoft Mark · locally synthesized

00:00:00.000 — Make the task checkable.

A useful prompt tells the system what to produce and what would count as success. Our framework is Context, Task, Standards, and Evidence. These four parts make a request easier to evaluate. They do not guarantee correctness or require a long prompt.

Visual description:
Context · Task · Standards · Evidence

00:00:20.375 — Start with the missing information.

Help me write a brief leaves important questions unanswered. Who is the audience? Which facts may be used? What artifact is needed? What should happen when evidence is missing? Resolve those questions before adding elaborate role instructions or more words.

Visual description:
Vague: Help me write a brief.
Bounded: Draft a 70-word pilot proposal from the supplied facts.
Specify the result before polishing the wording.

00:00:40.583 — Context supplies the relevant facts.

Use the fictional Riley source: six people, forty requests weekly, eighteen minutes per request, and a proposed two week pilot. Savings are unknown. Relevant context includes the source and intended audience. Extra irrelevant documents or old versions can make the task harder to check.

Visual description:
Audience: Operations manager
Current work: 6 people · 40 requests weekly
Baseline: 18 minutes per request
Trial status: Proposed · savings unknown (warning)

00:01:03.292 — Name the artifact and standards.

The task is a seventy word proposal. The standards require a clear distinction between current facts and proposed work. The evidence requirement forbids invented savings or completed results. Ask the output to list unknowns that prevent a savings claim. Now a reviewer has observable acceptance checks.

Visual description:
Context: Riley’s fictional source facts.
Task: draft a 70-word proposal.
Standards: distinguish facts from proposed work.
Evidence: no invented savings; list unknowns.

00:01:26.333 — Inspect the result against the criteria.

Suppose the constructed output says the team already saves forty percent. That fails the evidence requirement even if the paragraph is concise and well written. Mark the unsupported claim. Keep the valid parts. Repair the specific failure instead of regenerating endlessly without a diagnosis.

Visual description:
The team already saves 40%.
Length: Can be checked separately
Savings claim: Unsupported by supplied source (fail)
Repair: Remove claimed savings; propose measurement (pass)

00:01:48.792 — Change one variable.

For a meaningful comparison, keep the source and task fixed, change one instruction, and inspect the outputs using the same criteria. Record the model and relevant settings if you use a real tool. A single example illustrates behavior; it does not establish a universal performance improvement.

Visual description:
Fixed source + task
One changed instruction
Same acceptance checks
Record the setup. Do not claim a benchmark.

00:02:10.500 — Write your own bounded request.

Use a different supplied fictional task in the lesson. Write the four prompt parts, define two observable checks, and inspect the result or supplied draft. Explain one revision. Stop when the checks pass, or when missing evidence prevents a defensible answer.

Visual description:
What would make your output acceptable?
A named artifact.
Two observable checks.
A rule for missing evidence.
Your evidence: prompt, checked draft and explained revision.