TutorialsHow to Use It: Three Hands-On Scenarios
Daily report, project retrospective and post breakdown — three complete prompts, each run through v1, an error hunt, a new rule and v2.
What these notes are
This lesson is the hands-on core. Three scenarios, three complete prompts, all ready to copy.
In class, each learner picks one scenario, fills in their own business material, and completes a first test run.
Suggested way to read this: copy the prompt and run it on your own material first, then come back to the error to hunt for — you will almost certainly see it.
Scenario A · Daily report: from scattered notes to a fixed briefing
Demo material
Finished the course homepage requirements review; login page copy awaiting operations confirmation; discussed two card versions with design; need to give developers an acceptance checklist tomorrow; launch date not yet confirmed.
This material hides three traps: the copy is still unconfirmed, the two card versions were only discussed, and there is no launch date. Will AI write them as done, as final, as having a launch date? That is what to watch.
The complete prompt
You are a product manager's reporting assistant. Turn my work log into a daily report for my manager.
Goal: report real progress, blockers and next steps clearly; do not overstate results.
Input: date [fill in]; today's work log [paste]; extra context [optional].
Steps:
1. Extract completed items and outputs that have evidence;
2. Separate done, in progress and to be confirmed;
3. Extract risks and items needing confirmation;
4. Write the deliverables that can be handed over tomorrow;
5. Check back against the original log.
Rules: do not invent progress, metrics, owners or launch dates; discussed does not mean final; mark missing information as [to be confirmed].
Format:
1. Today's progress (at most 3 items, action + result);
2. Risks / blockers;
3. Tomorrow's plan (at most 3 items, state the expected deliverable);
4. Requirement summary;
End with a list of items I need to confirm.Six-element mapping
| Element | Where it appears in the prompt |
|---|---|
| Role | A product manager's reporting assistant |
| Goal and boundaries | Report real progress clearly; do not overstate |
| Input spec | Date, work log, extra context (optional) |
| Steps | Extract facts → classify status → find risks → set next steps → check back |
| Decision constraints | Do not invent; discussed is not final; mark gaps |
| Output and acceptance | Four sections, ending with items to confirm |
The error to hunt for
- Was the copy wrongly written as done?
- Was a launch date invented?
- Was discussed two card versions written as final?
Learner task: add one rule targeting this specific error.
Deliverable: a reusable daily-report SOP v2.
Scenario B · Project retrospective: from experience to next-round action
Demo material
The goals, timeline, actual results, feedback, problems and available data of a finished project. Leave blanks where data is missing.
The complete prompt
You are a product manager's retrospective partner. Using the project materials provided, produce a retrospective that can guide the next round of work.
Input: project goals [fill in]; planned vs actual milestones [fill in]; results and metrics [fill in]; key events, feedback and problems [fill in].
Steps:
1. Compare goals against actual results;
2. Reconstruct the key events;
3. Separate facts from hypotheses about causes;
4. Extract what worked and what needs adjusting;
5. For each improvement, propose a concrete next step, a suggested owner and a check date;
6. List the evidence still missing.
Output: goal vs result table → key events → what worked / problems / cause hypotheses → next-round action table (action, deliverable, owner to be confirmed, timing to be confirmed) → missing data. Keep it under 900 words.
Constraints: without a baseline, do not claim a magnitude of improvement; do not present correlation as causation; do not assign responsibility or commit to dates on the team's behalf; all numbers come from the input.The error to hunt for
Take one cause AI wrote and ask for its evidence. If the evidence is thin, change it to a hypothesis to be validated.
This move matters: AI is very good at producing a plausible-sounding attribution, but it is often just a guess. The most expensive mistake in a retrospective is writing that guess into the next round of actions as a conclusion.
Look at the next-round action table — note the owner to be confirmed and timing to be confirmed columns. AI cannot commit to a schedule on anyone's behalf, so these must be left for a human to fill in.
Learner task: produce at least one task that genuinely enters the next-round action list.
Scenario C · Social post breakdown: from observation to an original test
Demo material
A post you are authorized to use, including title, cover description, body, visible metrics and comments.
When given only a link, do not assume AI can read the page. How the material is obtained must be stated separately — provided by a human, or through an interface that is actually available.
The complete prompt
You are a content analyst. Break down a Xiaohongshu post, extract the methods worth borrowing, and design an original plan for my account.
Input: my account positioning [fill in]; target readers [fill in]; the post's title, cover, body, image descriptions, engagement data and comments [paste].
Steps:
1. Record the known data and the gaps;
2. Analyze the topic and the readers;
3. Break down the title, opening, middle, ending and engagement prompts;
4. Analyze image style and information density;
5. Extract the structure worth borrowing;
6. Design one original topic based on my real experience;
7. Propose a test that changes only one variable, plus review metrics.
Output: a table covering the seven parts — data results, account planning, single post, images, original adaptation, testing, iteration — plus one original topic.
Constraints: mark every judgment as [verifiable from material] or [inference]; mark missing data as [not provided]; do not invent the author's motives, do not copy the wording or cover, and do not promise a guaranteed hit.The error to hunt for
- Did any inference get written as fact? (check the verifiable / inference tags)
- Were missing data points honestly marked not provided?
- Did any guaranteed hit promise appear?
Seven modules ↔ seven SOP steps
The seven output parts are not arbitrary — the seven page modules map one-to-one onto the seven SOP steps:
1 data results → 2 account planning → 3 single post → 4 images → 5 original adaptation → 6 testing → 7 iterationThe one-to-one mapping is why this kind of breakdown tool works well: you can see which step you are on.
One-click AI analysis requires a model interface that is configured and tested in advance. Without one, the manual route of pasting the body text works just as well.
Learner task: produce one breakdown table and one original test plan.
What all three scenarios share
They look different, but the skeleton is the same:
| Shared trait | How it shows up |
|---|---|
| All six elements present | Every prompt covers role, goal and boundaries, input, steps, constraints and output |
| Blanks left in the input | [fill in] and [paste] mark what a human must supply |
| Constraints stop invention | Every scenario has rules like do not invent, mark gaps, do not promise |
| Output has acceptance | All three specify format, item caps or word limits |
| v1 to v2 | All three improve by catching one specific error, adding one rule, and verifying on a second set of material |
In class, each learner picks one scenario, fills in their own business material, and completes a first test run.
Lesson recap
| Scenario | Most likely error | Rule to add |
|---|---|---|
| Daily report | Writing unconfirmed items as done; inventing a launch date | Discussed is not final; mark gaps as to be confirmed |
| Project retrospective | Treating a guess as a conclusion; committing to dates for the team | No baseline means no improvement claim; owner and timing stay with humans |
| Post breakdown | Writing inference as fact; promising a guaranteed hit | Tag every judgment as verifiable or inference; never promise a hit |
The next lesson tackles the next problem: the SOP is written, but the day's work is still scattered — time for a workbench.
What It Is + Why: An SOP for AI
Write down the goal, inputs, steps, decision rules, output format and checking method for a repeated task — the six-element formula, taught through a daily-report example.
Workbench: From SOP to a Daily Workflow
Why a finished SOP still needs a workbench — the six-stage loop, the five-step build method, the copy-paste prompt, and the cross-role reuse formula.