Work a full example

The project is to produce a reproducible dashboard bug report from a sanitized screenshot, evidence inventory, hypotheses, logs, and confirmed root cause. The user is a product analyst preparing a bug report. Definition of done: the intended action is clear, the candidate uses approved evidence, blocking safety checks pass, and another person can reproduce the key result.

Stage 1: prepare

Create the job card and collect cropped screenshot, task goal, UI version, visible labels, expected behavior, sensitive-area redactions, and requested evidence format. Remove or replace prohibited material: crop and redact names, faces, addresses, notifications, account IDs, location clues, EXIF metadata, and confidential browser tabs before upload. Add one ordinary case, one boundary case, and one hostile or misleading case. Record unknowns instead of filling them with plausible guesses.

Stage 2: draft

Inspect this redacted checkout dashboard screenshot. Goal: explain why the conversion total appears inconsistent. First inventory only visible labels and values with locations. Separate observation from inference. Then propose three hypotheses and the next screenshot or log needed to test each. Do not identify people, infer hidden fields, or invent unreadable text.

The first candidate should be An observation table grounded in screen regions, clearly labeled hypotheses, and targeted follow-up evidence instead of a confident visual guess. In this worked run, imagine it also exhibits one realistic defect from this set: hallucinated small text; mixing observation with inference; ignoring chart scale; accidental exposure around the crop; treating an image as current truth. Do not hide the defect. Mark the exact criterion it violates and decide whether the cause belongs to context, instruction, model capability, or the surrounding process.

Stage 3: repair narrowly

Issue a targeted revision:

Revise only the failed criterion identified below.
Preserve all verified content and the original output contract.
Do not add facts or assets.
Return the corrected artifact plus a one-line change note.
Failed criterion: [paste criterion and evidence]

A narrow repair keeps the review surface understandable. If the model cannot repair without new authoritative information, pause and obtain that information.

Stage 4: verify and release

Now zoom and compare source pixels, transcribe critical values manually, reproduce in the product, inspect logs, and reject claims unsupported by visible or supplied evidence. Record pass/fail evidence for each criterion and have the named reviewer make the release decision. Point to regions, labels, frames, or timestamps. When the model cannot read a detail reliably, provide a crop or transcription instead of asking it to guess harder. Save limitations in language the audience can understand.

The durable deliverable is not only the final result. It is a multimodal evidence packet with redaction checklist, annotated image, observation/inference table, follow-up requests, and verification result. Write what surprised you, which check found it, what you changed, and which control should become the default. A clean retrospective distinguishes a prompt improvement from a data, tool, or policy change.