Prompt Engineering Workshop: An Agenda and Practice Tasks

A prompt engineering workshop gives a team shared language and a set of tested prompts they agree to use. The result is not just skills: it is a library of instructions that anyone on the team can rely on and a set of lessons about what works for your specific tasks. Tools like fenbs keep those prompts and lessons in one place after the workshop ends.

A good workshop runs three to four hours with a small group of four to eight people. Larger groups work when you split into pairs for the exercises and bring results back together. The goal is prompts that solve real problems your team faces, reviewed and agreed on together.

Before the workshop: choose your tasks

The exercises will be more useful if they use real tasks from your work rather than generic examples. Before the workshop, ask each participant to bring one task they regularly use AI for and one they tried but gave up on. These become the raw material for the exercises.

Also choose the AI model you will all use during the workshop. Using the same model removes one variable and makes it easier to compare results. If your team uses multiple models, run the exercises on the one most people use daily, and note which results might differ on another model.

For written resources to share with participants beforehand, prompt engineering books covers the main introductory texts worth reading beforehand.

A half-day agenda

1. 0:00 - 0:20 Introduction (20 min). What the workshop will produce: a shared prompt library and a set of team lessons. Brief on the technique vocabulary: instruction, context, format, examples, constraints.
2. 0:20 - 1:00 Exercise 1: Rewrite a vague prompt (40 min). Pairs work on a real task, compare outputs, revise.
3. 1:00 - 1:10 Break (10 min).
4. 1:10 - 1:50 Exercise 2: Build a chain-of-thought instruction (40 min). Pairs add reasoning steps to a decision-making or analysis task.
5. 1:50 - 2:30 Exercise 3: Debug a broken prompt (40 min). Pairs diagnose why a prompt gives inconsistent outputs and fix it.
6. 2:30 - 2:40 Break (10 min).
7. 2:40 - 3:20 Review and decide (40 min). Share results, score prompts against the review criteria, agree on which prompts to keep.
8. 3:20 - 3:30 Wrap-up (10 min). Record agreed prompts and lessons; assign who maintains the library.

Exercise 1: Rewrite a vague prompt

Start with a prompt that everyone recognizes as too vague to be reliable. Something like "summarize this document" or "write a response to this email." Each pair runs the prompt as written, reads the output, and identifies the three most common problems with it.

Then they rewrite it with three additions: an output format ("two bullet points per section"), a constraint ("do not include recommendations, only findings"), and a context sentence ("this document is a contract summary for a client who has not read the original"). Run it again on the same input and compare.

Summarize this document.

Summarize the following contract summary.

Format: two bullet points per section heading.
Constraint: do not include recommendations or action items, only findings.
Audience: a client who has not read the original document.

[paste document here]

The debrief question is: what did adding the format, constraint, and context change? Ask each pair to explain one improvement and one thing the revised prompt still does not handle well. That honest limit is part of the record.

Exercise 2: Build a chain-of-thought instruction

Chain-of-thought prompting asks the model to explain its reasoning before giving an answer. It improves outputs on tasks that involve analysis, trade-offs, or decisions with multiple considerations. The exercise applies it to a real analysis task from your team.

Each pair picks an analysis task, such as evaluating a vendor proposal, prioritizing a list of feature requests, or assessing a risk. First they run a direct prompt asking for the answer. Then they add a reasoning step: "Before giving your answer, list the three factors that matter most for this decision and explain how each one applies." Run both versions and compare.

The debrief question is: did the reasoning step improve the answer, or did it produce a longer answer that is not better? Chain-of-thought helps most when the task genuinely involves weighing multiple factors. It adds noise on simple lookup tasks.

Exercise 3: Debug a broken prompt

This exercise uses prompts that give inconsistent outputs: sometimes they work, sometimes they do not. Ask participants to bring one from their own experience, or use this version: a prompt that asks for a JSON object and sometimes returns correctly formatted JSON, sometimes does not.

Pairs run the broken prompt ten times on different inputs and note the failure pattern. Common failure modes include: the model ignoring the format instruction when the input is long, the output changing when the model has to make an inferred decision, or the format breaking when the content includes special characters.

The fix usually involves making the instruction more specific about the failure mode: "Always return valid JSON. If the input does not have enough information to fill a field, use null rather than omitting the field." The debrief discusses what the diagnostic process found and how to test a fix before trusting it.

How to review and decide which prompts to keep

During the review session, each pair presents their best revised prompt. The group evaluates it against four criteria: does it give a consistent output on different inputs, does it handle the most common edge case your team encounters, is it short enough that someone new can understand it quickly, and does it include an honest note about what it does not do well.

• Consistent: run it on three different inputs; the output format and quality are similar each time.
• Handles the common edge case: the input that used to cause problems now produces a useful output.
• Readable: someone who did not write it can tell what it does in thirty seconds.
• Honest limit: the prompt includes a note or the team records what it does not handle well.

A prompt that fails two or more criteria is a draft to continue working on, not one to add to the shared library yet. Keep it in progress and return to it in the next session.

How to do this with fenbs

1. Create a free account before the workshop. Set up a project for the work these prompts belong to.
2. During the review session, add each agreed prompt to Skills and prompts. Include the task it solves, the model it was tested on, and the known limitation.
3. Add a Lesson for each exercise: what the team learned, what surprised them, and what to check before using the technique on a new task.
4. Assign one person to maintain the library after the workshop. Their job is to update prompts when they stop working and add new ones when the team tests something.
5. Connect your AI apps from Integrations so assistants read the shared library before working on tasks it covers.