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.