Prompt Lab

Hands-on AI skills

Prompt WritingLab

Design, test, and improve prompts for technical work

Start the lab See the syllabus
1 h 10 mintotal time
3modules
6lessons
3self-checks

Syllabus

3 modules. One clear path.

Built for Technical practitioners who want more reliable results from generative AI tools

  1. 001 / Module

    Make the task explicit

    Turn vague requests into prompts with a clear job, relevant context, and useful constraints.

    2 lessons · 22 min
    • 1. Diagnose a vague prompt
    • 2. Build a prompt specification
  2. 002 / Module

    Control the shape of the answer

    Use examples and format instructions to make outputs consistent and usable.

    2 lessons · 24 min
    • 1. Show the pattern you want
    • 2. Request structured output
  3. 003 / Module

    Test and improve

    Evaluate responses with realistic cases and revise prompts based on evidence.

    2 lessons · 24 min
    • 1. Run a prompt test
    • 2. Choose the next revision

The lab

Learn by doing.

Pick any lesson from the tree. Flip the cards, answer the checks and mark each lesson complete to fill your progress receipt.

lesson.mdLesson 1/6
Try itModule 112 min

Diagnose a vague prompt

Find what an AI tool would need to know before it can produce a useful response.

  • Identify missing information in a prompt
  • Rewrite a prompt with a specific task and audience

A prompt is an instruction and the context needed to carry it out. A request such as “explain caching” leaves the tool to guess the audience, depth, and purpose.

For a technical task, specify what to do, what the tool should assume, and what a useful result looks like. Keep sensitive data out of prompts unless your organization has approved the tool and workflow.

Rewrite a vague request

  1. 1
    Choose a task

    Start with: “Explain caching.” Use this or a small, non-sensitive task of your own.

  2. 2
    Name the audience

    Specify who will use the answer, such as a new backend engineer.

  3. 3
    Add relevant context

    State the system or situation. For example, the service reads frequently requested product records.

  4. 4
    Set boundaries and a result

    Ask for two trade-offs and one recommendation in plain language. Add any real constraints that matter.

Saved in this browser only. Nothing is sent anywhere.

Try itModule 110 min

Build a prompt specification

Use a repeatable structure to make technical requests easier to test.

  • Draft a prompt with role, task, context, constraints, and output format

A reusable prompt specification can include a role, task, context, constraints, and output format. Include only details that help the task; a long role description does not compensate for missing requirements.

Example: “Act as a technical editor. Rewrite the release note below for application developers. Preserve all version numbers and behavior changes. Use a heading and three concise bullets. If a detail is unclear, mark it as a question rather than inventing it.”

Draft and inspect

  1. 1
    State the task

    Use a precise verb such as classify, compare, extract, or rewrite.

  2. 2
    Provide context

    Add only the background needed to complete the task.

  3. 3
    Set constraints

    Name required facts, exclusions, length, or uncertainty handling.

  4. 4
    Specify the output

    Describe the format and fields you need, then check that every instruction is testable.

Knowledge checkWhich instruction best helps prevent an AI tool from inventing missing technical details?

Try itModule 212 min

Show the pattern you want

Test when a compact example can clarify a classification or transformation task.

  • Decide when examples are useful
  • Write an example that demonstrates the requested pattern

Examples can show a model how to apply an instruction, especially when categories are subtle or the desired style is hard to describe. These examples are often called few-shot examples.

Use examples that match the real task. If your examples cover only easy cases, the tool may perform poorly on edge cases. Keep examples synthetic or approved for the tool; do not paste confidential tickets or customer records.

Create a small example set

  1. 1
    Define categories

    For triaging bug reports, use “reproducible,” “needs information,” and “not a bug.”

  2. 2
    Write one clear example

    Input: “The app closes after I tap Save.” Output: “needs information,” because device and app version are missing.

  3. 3
    Add a boundary case

    Try an example that could fit two categories and explain the deciding rule.

  4. 4
    Test without examples

    Compare the output on a new synthetic report, then add or revise examples only if they address a specific failure.

Saved in this browser only. Nothing is sent anywhere.

Try itModule 212 min

Request structured output

Specify fields and validation expectations for outputs that feed into technical workflows.

  • Define fields that match a downstream use
  • Check whether generated output follows the requested structure

A format instruction should describe both the shape and meaning of each field. For example, ask for a short summary, severity, and evidence from the supplied report. If a downstream system requires valid JSON, use a tool or API feature that supports constrained output when available; a text instruction alone does not guarantee valid syntax.

Design an output contract

  1. 1
    Choose the consumer

    Decide whether a person, spreadsheet, script, or API will use the result.

  2. 2
    Name the fields

    For an issue summary, define fields such as “summary,” “severity,” and “evidence.”

  3. 3
    Define allowed values

    If severity must be low, medium, or high, say so and explain the criteria.

  4. 4
    Try a missing-data case

    Provide a report with no version number and check that the tool marks it unknown rather than filling one in.

Knowledge checkA generated result will be consumed by a script. Which prompt instruction is the most useful?

Try itModule 314 min

Run a prompt test

Use a small test set to reveal where a prompt succeeds or fails.

  • Create test cases that include ordinary and boundary inputs
  • Record response quality against explicit criteria

A single successful response does not show that a prompt is reliable. Try ordinary inputs, incomplete inputs, and boundary cases. Keep the prompt and test inputs fixed when comparing revisions so you can tell what changed.

Score outputs against criteria such as factual support, correct classification, required fields, and clarity. A score is a signal for review, not proof that the model is correct.

Build a quick evaluation sheet

  1. 1
    Write the criteria

    Choose three observable checks, such as correct category, evidence cited, and missing details flagged.

  2. 2
    Prepare varied inputs

    Use a typical case, an incomplete case, and a borderline case with synthetic details.

  3. 3
    Run the same prompt

    Save each response and note which criteria it meets. Do not change the prompt between test inputs.

  4. 4
    Revise one thing

    Fix the most common failure with one targeted instruction, then repeat the same tests.

Saved in this browser only. Nothing is sent anywhere.

Try itModule 310 min

Choose the next revision

Distinguish prompt problems from missing information and tool limitations.

  • Select a revision that addresses an observed failure
  • Decide when a prompt change is not enough

Match each revision to an observed failure. If the output misses a required field, state the field and its expected meaning. If it guesses when evidence is absent, add an explicit uncertainty rule and test it. If the task depends on current or private system data, a prompt cannot provide access the tool does not have.

For consequential technical decisions, verify claims against authoritative documentation, tests, or a qualified reviewer. Keep a record of the prompt version, test inputs, and results when repeatability matters.

Sort it

Sort each failure by the most useful first response.

  1. The answer omits a required summary field.
  2. The tool invents a value when the input is blank.
  3. The tool needs access to current internal service metrics.
  4. The output must be guaranteed to match a strict machine-readable schema.

Saved in this browser only. Nothing is sent anywhere.

Progress

Your receipt.

0/6

Lessons completed. Everything is tracked in this browser only. Nothing is sent anywhere.

Prompt LabProgress

1 · Make the task explicit0/2
2 · Control the shape of the answer0/2
3 · Test and improve0/2
Time completed0 min
Checks answered0/3
Reflections saved0/4
Total0%

A demo receipt for a fictional course. It is not a credential.

Your guide

Mira Chen

Prompt Design Instructor at Northstar Learning Studio (fictional)

Mira teaches practical methods for designing and evaluating prompts for technical workflows.

Fictional guide and course, generated for this demo.

FAQ

Does a longer prompt always produce a better answer?

No. Add information that changes the task or evaluation. Remove repetition and irrelevant background. Test changes against the same cases.

Should I put confidential information into a prompt?

Only when your organization has approved the specific tool and use. Otherwise, use synthetic examples or remove identifying and sensitive details.

Can a prompt guarantee factual or correctly formatted output?

No. Clear instructions can improve consistency, but you still need checks. Use constrained-output features where available and validate important claims and structure.

Enrol

Ready to start?

1 h 10 min of self-paced learning across 3 modules. Free, and your progress stays on your device.

enrol --course PLDemo