Worked cases: select a pattern

Job: Help a teammate understand what a context window is before a workshop.

Best fit: Role-context-task-criteria with a tutor stance.

Role: patient explainer for a non-engineer teammate.
Task: explain context window in under 180 words with one analogy and one workplace implication.
Criteria: no math jargon without a plain translation; end with a 2-question check.

Why not few-shot first? One clear explanation does not need examples unless the teammate wants a specific house style. Why not JSON? The consumer is a person reading prose.

Watch out: The model may invent product limits. Add “if unsure about a vendor limit, say it varies” or provide the real limit in context.

Job: Pull vendor, invoice date, total, and currency from pasted text.

Best fit: Structured output plus empty-value rules, optionally one example.

Extract only:
vendor, invoice_date (YYYY-MM-DD or null), total_amount (number or null), currency (string or null), evidence_quote.
Do not calculate missing totals. Do not guess currency.

Why not a creative role? Creativity increases invention. Why not chain-of-thought? You need fields, not a monologue.

Watch out: Hand-written totals and tax lines confuse models. Validate numbers in a spreadsheet.

Job: Label messages as billing, bug, how-to, or escalate.

Best fit: Few-shot classification with an escalate-safe default.

Include one clean example per label and one ambiguous escalate example. Require a short note field citing the trigger phrase.

Why not open-ended generation? Free-form summaries are hard to route. Why not deep decomposition? Latency and cost rise; start with labels and escalate edge cases.

Watch out: Users embed instructions in email (“ignore previous policy”). Treat message content as untrusted data, not as system commands.

Job: Turn scattered notes into a plan your manager can approve.

Best fit: Decompose-and-clarify, then draft.

Stage 1: list known facts, unknowns, and risks from notes only.
Stage 2: human confirms priorities and forbidden claims.
Stage 3: draft the update with role-context-task criteria.

Why not one-shot polish? Early polish hides missing decisions. Why not structured JSON alone? Managers still need readable narrative after decisions exist.

Watch out: Plans often invent owners and dates. Keep TBD explicit until confirmed.

Before you write the prompt, answer:

1. Who consumes the output—human, system, or both?
2. What is authoritative input?
3. Is invention worse than incompleteness?
4. Are there dependent stages or approval gates?
5. What is the lightest pattern that satisfies those answers?

If you cannot answer (2) and (3), stop and gather material before pattern shopping.

After these cases, the transferable skill is not memorizing four templates. It is pausing long enough to name the consumer, the evidence boundary, and the cost of invention. When a new task arrives, write those three lines before you reach for role play, examples, or JSON. Most weak prompts fail those lines first and only look like “model quality” problems afterward.

Keep a short personal catalog: one explain prompt, one extract prompt, one classify prompt, and one decompose prompt. Improve them when real failures appear instead of inventing new stacks for every mood.