Lesson 6: Prompt Strategies for Different Tasks

Learning goals:

• Master the prompt best practices for code-generation tasks
• Learn effective strategies for writing and summarizing documents
• Understand prompt techniques for data analysis and extraction

Prerequisites: << 05 Debugging and Improving Prompts

Different tasks need different prompt strategies

You've learned the basic structure of a prompt, few-shot, CoT, and how to debug — those are general skills. But different kinds of tasks have their own quirks and traps, and they call for targeted strategies.

Code generation needs clear inputs, outputs, and edge cases; document writing needs a defined audience and tone; data extraction needs to handle missing values and keep the format consistent. This lesson walks through concrete techniques for three common task types.¹

Task type 1: Code generation

Code generation is one of the most common ways people use AI. The key is simple: spell out the requirements clearly, and the AI can write code you can actually use.¹

The six elements of a code-generation prompt

A good code-generation prompt should include:¹

1. Language and version: Python 3.10, TypeScript 5.0
2. Function signature: input parameter types, return type
3. Core logic: what the function should do
4. Edge cases: how to handle empty input and error conditions — this is defensive programming: assume the input might be invalid and decide up front how to respond
5. Code style: comments, type hints, error handling
6. Dependency limits: standard library only, or which third-party libraries are allowed

Comparison: vague vs clear code prompts

❌ Fuzzy prompt:

Write a Python function to process user data

The AI can only guess: what data? Process it how?

✅ Clear prompt:

Write a Python 3.10 function with these requirements:
Behavior:- Input: a list of dicts, each with name (str), age (int), email (str)- Output: drop users with age < 18, return the remaining users' emails (deduplicated)
Requirements:- Include type hints- Handle missing fields (if a dict is missing age or email, skip that user)- Use the Python standard library only- Include a docstring describing usage
Example:Input: [{"name": "Alice", "age": 20, "email": "a@example.com"},        {"name": "Bob", "age": 15, "email": "b@example.com"},        {"name": "Charlie", "age": 25, "email": "a@example.com"}]Output: ["a@example.com"]

This prompt nails down the input, output, edge cases, and code style, so the AI can write usable code on the first try.

There's research behind this: "prompts with explicit specifications reduced the need for back-and-forth refinements by 68%"¹ — spell out the details and you're far more likely to get code you can use straight away.

Code-generation best practices

Practice 1: Spell out the input and output data structures

Don't say "process the data." Say "input is List[Dict[str, Any]], output is Dict[str, int]."

Practice 2: Use examples to clarify edge cases

Handle these special cases:- Empty list input → return an empty list- None value → skip it- Duplicate value → keep the first occurrence

Practice 3: Specify the code style

Code style requirements:- Use type hints- Include a docstring (Google style)- Don't over-comment (don't explain obvious code)- Favor readability first, performance second

Practice 4: Say what you don't want

Don't:- Don't use global variables- Don't pull in external dependencies (standard library only)- Don't write test code (main function only)

Code-review prompts

When you ask the AI to review code, name the review dimensions explicitly:

Review the Python code below, focusing on:
1. Correctness: logic errors, edge-case handling2. Performance: time-complexity analysis, possible bottlenecks3. Security: SQL injection, XSS, input validation
Don't comment on code style or naming (those already pass lint checks).
For each issue you find, state:- Location (line number or code snippet)- Issue type (bug / performance / security)- Concrete impact (under what conditions it breaks)- Suggested fix
Code:[paste code]

Name the review dimensions, and the AI won't waste time on details that don't matter.

Task type 2: Writing and summarizing documents

Document work covers a lot: technical docs, meeting notes, article summaries, report generation.

The key elements of document writing

1. Target audience: technical vs non-technical readers
2. Purpose: explaining how to use something vs persuading a decision-maker
3. Tone and style: formal vs casual, detailed vs concise
4. Structure template: which sections organize the content

Comparison: document-summary prompts

❌ Fuzzy prompt:

Summarize this technical document

✅ Clear prompt:

You're a technical writer, good at turning complex technical docs intosummaries anyone can follow.
Task: summarize the API doc below as a quick-start guide for frontenddevelopers.
Audience: frontend engineers who know JavaScript but have never used this API.
Output format:1. One sentence on what this API does2. The three most-used features (for each: purpose + code example)3. One complete usage-scenario example4. Common mistakes and fixes (2-3)
Tone: direct and practical, no marketing speak.
Length: 800 words or fewer.
Original document:[paste document]

This prompt nails the audience (frontend engineers), the purpose (quick start), the structure (four parts), and the tone (practical).

Document-writing best practices

Practice 1: Spell out the audience's background

Audience:- Role: product manager- Technical level: doesn't code, but understands basic software-architecture concepts- Reading goal: decide whether to adopt this approach

Practice 2: Provide a structure template

Organize it like this:
## BackgroundWhy this approach is needed (1 paragraph)
## Options compared| Option | Pros | Cons | Cost ||--------|------|------|------|| ...    | ...  | ...  | ...  |
## RecommendationWhich option to pick, and why (2-3 paragraphs)
## RisksThe main risks of this approach and how to handle them (list)

Practice 3: Control the level of detail

Level of detail:- Explain each point in 1-2 sentences, don't expand- Skip implementation details, cover business impact only- Don't cite specific code or technical jargon

Meeting-notes prompts

You're a project assistant, good at pulling the key points out of meetingrecordings or transcripts.
Task: write meeting notes from the transcript below.
Output structure:1. Meeting info   - Date: YYYY-MM-DD   - Attendees: [list]   - Topic: [one sentence]
2. Discussion (ordered by priority)   For each item:   - Problem statement (1 sentence)   - Discussion points (2-3)   - Decision (a clear conclusion; if none was reached, write "pending")
3. Action items   For each:   - Task description (start with a verb, actionable)   - Owner   - Due date
Constraints:- Record only discussions with a clear conclusion, skip the chit-chat- Every action item must be checkable (has a clear deliverable)- Total length 500 words or fewer
Transcript:[paste transcript]

Task type 3: Data analysis and extraction

Data analysis covers pulling structured information out of text, classifying, filtering, and counting.

The key elements of data extraction

A reliable data-extraction prompt spells out four things up front:

1. Field definitions: what each field means and its allowed range of values
2. Missing-value handling: what to do when a field can't be found
3. Output format: JSON, CSV, table
4. Data validation: whether the extracted data needs checking

Comparison: data-extraction prompts

❌ Fuzzy prompt:

Extract the key information from this job posting

✅ Clear prompt:

Extract the following fields from the job posting and output JSON.
Field definitions:- position (string): job title- location (string): work location (city + district, if present)- experience (string): experience required (keep the original wording, e.g. "3-5 years", "any")- salary (string): salary range (keep the units, e.g. "20-30k/month", "negotiable")- company (string): company name
Missing-value handling:- If a field isn't in the source text, output null- Don't guess or infer missing information
Example 1:Input: Urgently hiring a Java engineer, Nanshan Shenzhen, 3+ years experience, 25-35k/month, XX TechOutput:{  "position": "Java engineer",  "location": "Nanshan, Shenzhen",  "experience": "3+ years",  "salary": "25-35k/month",  "company": "XX Tech"}
Example 2:Input: Frontend developer, remote, salary negotiableOutput:{  "position": "Frontend developer",  "location": "remote",  "experience": null,  "salary": "negotiable",  "company": null}
Now process:[paste job posting]

The examples cover both the complete case and the missing case, so the AI knows to output null when it can't find something rather than making it up — that habit of confidently fabricating facts is called hallucination.

Data-extraction best practices

Practice 1: Spell out the allowed values for each field

Field: sentimentAllowed values: exactly one of "positive" / "negative" / "neutral"Don't output: things like good, upbeat, favorable, or any other word

Practice 2: Use few-shot to standardize the format

When extracting structured data, 2-3 examples work better than a written description (the few-shot technique from Lesson 3).

Practice 3: Say how to handle edge cases

Special cases:- If a passage carries mixed sentiment ("good product, but too expensive") → classify as "neutral"- If it's a pure question ("how does this work?") → classify as "neutral"- If the text is too short (fewer than 3 words) → output null

Practice 4: Add data validation

Validation rules:- The salary field must contain a number- If experience isn't null, it must contain "year" or "any"- location can't be an empty string — either a value or null
If the extracted data fails a validation rule, return an error messageinstead of the invalid data.

Applying the general principles

Whatever the task, the general principles from earlier lessons still hold:

• The four elements (Lesson 2): role, task, format, constraints
• Few-shot (Lesson 3): give 2-3 examples for complex tasks
• CoT (Lesson 4): add "let's think step by step" for tasks that need reasoning
• Debugging (Lesson 5): change one thing at a time, verify with test cases

The task-specific strategies in this lesson are targeted optimizations layered on top of those general principles:

• Code generation → emphasize input/output types, edge cases, what not to do
• Document writing → emphasize the audience's background, structure templates, tone
• Data extraction → emphasize field definitions, missing-value handling, few-shot examples

Recap

Different tasks need different prompt strategies:

• Code generation: nail down input/output types, edge cases, code style, dependency limits; use examples to clarify special cases
• Document writing: define the audience's background and technical level, provide a structure template, control the level of detail and the tone
• Data extraction: define the allowed values for each field, say how to handle missing values, use few-shot to standardize the format, add data validation

These strategies build on the general skills from earlier lessons (the four elements, few-shot, CoT, debugging) — they're optimizations for specific task types. In practice, pick the combination that fits the task in front of you.

Course wrap-up

You've finished all six lessons of Prompt Engineering Basics:

1. Understood what a prompt really is and why it matters
2. Mastered the four core elements of a prompt
3. Learned to guide the AI with examples using few-shot
4. Applied chain-of-thought to make the AI show its reasoning
5. Built a systematic routine for debugging and improving prompts
6. Learned the specific strategies for different task types

Now you have the full toolbox. The next step is practice: pick a real task from your own work, apply these techniques, watch what happens, and keep refining. Prompt engineering is a skill you sharpen by doing — the coursework ends here, but the real learning starts when you put it to use.