The four levers from the fundamentals cluster — instruction, context, examples, output spec — apply to every prompt. What changes per use case is which lever matters most.

This cluster is the per-task playbook. Each linked article goes deep on one use case; this page is the map.

Code

Code prompting leans on context and output spec.

  • Paste the relevant code, not the whole repo.
  • State the constraints up front (Python 3.12, no third-party deps, must not change the public API).
  • Ask for a unified diff or for a specific file you can drop in.
  • Add a one-line "ignore X" if there is an obvious red herring (deprecated function, unrelated comment).

Code prompting also benefits a lot from conversational refinement: instead of writing one giant prompt, expect 2–4 turns where you correct course. Modern code-aware models handle this well.

Writing

Writing leans on examples and style anchors.

  • Show two or three short examples of the voice you want. Adjectives ("warm but precise") do less than samples.
  • Pin the audience ("software engineers who don't follow politics").
  • Say what you do not want explicitly: no listicles, no emojis, no "let's dive in."
  • If you want structure, give the structure as bullets the model must follow, not as adjectives ("snappy lead, three concrete examples, one-line takeaway").

Summarization

Summarization leans on instruction and output spec.

  • Be specific about purpose ("summarize for a CFO who hasn't seen this product before" beats "summarize this").
  • Pin the length (word count or bullet count). Otherwise the model averages toward "medium."
  • Tell the model what is NOT in the source if relevant ("do not include action items; this is a status doc, not a meeting").
  • Ask for the summary in a known shape (TLDR + 3 bullets + 1 risk) that downstream readers can scan.

Data extraction

Extraction leans on output spec, hard. You almost always want JSON.

  • Provide a JSON schema or a representative example.
  • Specify what to do when a field is missing (null vs. omit vs. "unknown").
  • Use few-shot for the tricky fields. One example of a ambiguous case beats three paragraphs of rules.
  • Use a JSON-mode-aware model. Frontier models support strict schemas; lean on that, do not rely on natural-language formatting.

Classification

Classification leans on examples and label discipline.

  • Make the label set explicit and tight. "Bug, feature, other" beats "various categories."
  • Provide one canonical example per label, especially the edge cases ("this looks like a bug report but is really a refund request").
  • Ask for the label only — no explanation, no probability, no prose. Parsers thank you.

Analysis

Analysis is the use case where prompting alone often is not enough. If you want the model to reason about a body of data and produce a non-obvious conclusion:

  • Decompose. Ask first for the data shape, then for hypotheses, then for the analysis.
  • Give the model the tools to verify (search, code execution, citation).
  • Treat the first output as a draft to argue with, not as an answer.

Where to go next

Pick the use case that matches what you are doing today. Each deeper article has a paste-and-modify starter prompt for that task type, plus the failure modes specific to that use case. If you are newer to the craft, pairing these playbooks with an app for curious adults who want to learn helps the patterns generalize across tasks instead of staying use-case-specific.