Examples

You're being handed a ZIP file (a ghost in the geometry.zip) — a structured report extracted from a narrated screen recording of Screen Recording 2026-07-05 at 10.39.18 AM.mov.

It contains 8 items grouped into 3 themes, found across 2m 14s of footage. These are NOT all bugs — they're a mix of bugs to fix, feature requests and changes the user wants, UI polish, questions to answer, and plain tasks to do. Every item carries a "category" (bug / feature_request / ui_polish / question / task). Read it and treat each item on its own terms — don't assume everything is a defect.

## ZIP layout

a ghost in the geometry.zip
├── INSTRUCTIONS.md       ← Read this first. Documents the conventions used in every item folder.
├── MASTER.md             ← Index of every item with its category, priority, and theme.
├── bug_001/              ← one item (every folder is named "bug_NNN", whatever its category)
│   ├── README.md         ← Authoritative description of this item + its category. Trust this over everything else.
│   ├── screenshot.png    ← Annotated frame with red box(es) around the affected element(s).
│   ├── screenshot_raw.png ← Same frame, no annotations.
│   ├── clip.mp4          ← Short clip with the user's narration in context.
│   └── omniparser_elements.json ← UI elements detected on the frame (positions / confidences).
├── bug_002/
├── ...
├── captions.srt / captions.vtt ← full narration captions (if available)
└── transcript.txt              ← everything the narrator said, plain text

Act on each item according to its category:
- bug / ui_polish — fix it in the code.
- feature_request — build the feature or make the change the user asked for. It's not a defect; it's something new they want added.
- task — something the user just SAID they want done (often nothing on screen, no screenshot). Treat it as a to-do, not a visual bug.
- question — the user was thinking out loud or weighing a decision. Each has a "recommendation" field with klunk's worked-through answer (options, pros/cons, a pick). Read it, then give YOUR take: agree, disagree, or add what's missing. Don't skip these — the user genuinely wants the decision resolved.

## Your job

1. Read INSTRUCTIONS.md.
2. Read MASTER.md.
3. Open every item folder. Read each README.md in full and note its category.
4. Handle every single item. All of them — don't skip any, don't pick favorites by priority. Fix the bugs, build the features and requested changes, do the tasks, answer the questions. What "handle" means depends on the item's category.
5. For each item, output: the item ID (e.g. bug_003), the file path(s) you're changing, and the concrete change that resolves it — a code diff for bugs and features, a written answer for questions. If several items share a root cause, write one change that covers them and list every item ID it resolves.
6. CRITICAL — DOUBLE-CHECK THE TRANSCRIPT. Now read transcript.txt from start to finish: it is the COMPLETE word-for-word narration. The item folders are only what klunk caught automatically; the transcript is the real source of truth, and klunk CAN miss things. Go through it carefully and confirm that EVERY problem, request, question, complaint, or "it'd be nice if…" the user voiced is handled by one of the items above. If MASTER.md has a "⚠️ Possibly missed" note near the top, start there — klunk already suspects those were dropped. Anything not covered: handle it too. Then tell the user plainly what you did beyond the formal list — label it clearly, e.g. "Extra (from the transcript, not in the numbered items): …". If after a genuine pass you find nothing missing, say so explicitly so they know you actually checked.

## A couple of notes

- The red bounding boxes in screenshots can be off by 1–2 element widths. When the box and the prose in the README disagree, the prose wins.
- If you need clarification on something, ask. And — more importantly — if you spot something in here the user would want to know about (concerns, risks, design decisions where your past experience tells you a question is worth raising), bring it up. The user values your judgment on what's worth flagging.

You're being handed a ZIP file (a study in tiny realism.zip) — a structured report extracted from a narrated screen recording of Screen Recording 2026-07-01 at 10.25.10 PM.mov.

It contains 6 items grouped into 2 themes, found across 1m 58s of footage. These are NOT all bugs — they're a mix of bugs to fix, feature requests and changes the user wants, UI polish, questions to answer, and plain tasks to do. Every item carries a "category" (bug / feature_request / ui_polish / question / task). Read it and treat each item on its own terms — don't assume everything is a defect.

## ZIP layout

a study in tiny realism.zip
├── INSTRUCTIONS.md       ← Read this first. Documents the conventions used in every item folder.
├── MASTER.md             ← Index of every item with its category, priority, and theme.
├── bug_001/              ← one item (every folder is named "bug_NNN", whatever its category)
│   ├── README.md         ← Authoritative description of this item + its category. Trust this over everything else.
│   ├── screenshot.png    ← Annotated frame with red box(es) around the affected element(s).
│   ├── screenshot_raw.png ← Same frame, no annotations.
│   ├── clip.mp4          ← Short clip with the user's narration in context.
│   └── omniparser_elements.json ← UI elements detected on the frame (positions / confidences).
├── bug_002/
├── ...
├── captions.srt / captions.vtt ← full narration captions (if available)
└── transcript.txt              ← everything the narrator said, plain text

Act on each item according to its category:
- bug / ui_polish — fix it in the code.
- feature_request — build the feature or make the change the user asked for. It's not a defect; it's something new they want added.
- task — something the user just SAID they want done (often nothing on screen, no screenshot). Treat it as a to-do, not a visual bug.
- question — the user was thinking out loud or weighing a decision. Each has a "recommendation" field with klunk's worked-through answer (options, pros/cons, a pick). Read it, then give YOUR take: agree, disagree, or add what's missing. Don't skip these — the user genuinely wants the decision resolved.

## Your job

1. Read INSTRUCTIONS.md.
2. Read MASTER.md.
3. Open every item folder. Read each README.md in full and note its category.
4. Handle every single item. All of them — don't skip any, don't pick favorites by priority. Fix the bugs, build the features and requested changes, do the tasks, answer the questions. What "handle" means depends on the item's category.
5. For each item, output: the item ID (e.g. bug_003), the file path(s) you're changing, and the concrete change that resolves it — a code diff for bugs and features, a written answer for questions. If several items share a root cause, write one change that covers them and list every item ID it resolves.
6. CRITICAL — DOUBLE-CHECK THE TRANSCRIPT. Now read transcript.txt from start to finish: it is the COMPLETE word-for-word narration. The item folders are only what klunk caught automatically; the transcript is the real source of truth, and klunk CAN miss things. Go through it carefully and confirm that EVERY problem, request, question, complaint, or "it'd be nice if…" the user voiced is handled by one of the items above. If MASTER.md has a "⚠️ Possibly missed" note near the top, start there — klunk already suspects those were dropped. Anything not covered: handle it too. Then tell the user plainly what you did beyond the formal list — label it clearly, e.g. "Extra (from the transcript, not in the numbered items): …". If after a genuine pass you find nothing missing, say so explicitly so they know you actually checked.

## A couple of notes

- The red bounding boxes in screenshots can be off by 1–2 element widths. When the box and the prose in the README disagree, the prose wins.
- If you need clarification on something, ask. And — more importantly — if you spot something in here the user would want to know about (concerns, risks, design decisions where your past experience tells you a question is worth raising), bring it up. The user values your judgment on what's worth flagging.

You're being handed a ZIP file (our AI has artistic differences.zip) — a structured report extracted from a narrated screen recording of RPReplay_Final1781144539.mp4.

It contains 5 items grouped into 3 themes, found across 5m 49s of footage. These are NOT all bugs — they're a mix of bugs to fix, feature requests and changes the user wants, UI polish, questions to answer, and plain tasks to do. Every item carries a "category" (bug / feature_request / ui_polish / question / task). Read it and treat each item on its own terms — don't assume everything is a defect.

## ZIP layout

our AI has artistic differences.zip
├── INSTRUCTIONS.md       ← Read this first. Documents the conventions used in every item folder.
├── MASTER.md             ← Index of every item with its category, priority, and theme.
├── bug_001/              ← one item (every folder is named "bug_NNN", whatever its category)
│   ├── README.md         ← Authoritative description of this item + its category. Trust this over everything else.
│   ├── screenshot.png    ← Annotated frame with red box(es) around the affected element(s).
│   ├── screenshot_raw.png ← Same frame, no annotations.
│   ├── clip.mp4          ← Short clip with the user's narration in context.
│   └── omniparser_elements.json ← UI elements detected on the frame (positions / confidences).
├── bug_002/
├── ...
├── captions.srt / captions.vtt ← full narration captions (if available)
└── transcript.txt              ← everything the narrator said, plain text

Act on each item according to its category:
- bug / ui_polish — fix it in the code.
- feature_request — build the feature or make the change the user asked for. It's not a defect; it's something new they want added.
- task — something the user just SAID they want done (often nothing on screen, no screenshot). Treat it as a to-do, not a visual bug.
- question — the user was thinking out loud or weighing a decision. Each has a "recommendation" field with klunk's worked-through answer (options, pros/cons, a pick). Read it, then give YOUR take: agree, disagree, or add what's missing. Don't skip these — the user genuinely wants the decision resolved.

## Your job

1. Read INSTRUCTIONS.md.
2. Read MASTER.md.
3. Open every item folder. Read each README.md in full and note its category.
4. Handle every single item. All of them — don't skip any, don't pick favorites by priority. Fix the bugs, build the features and requested changes, do the tasks, answer the questions. What "handle" means depends on the item's category.
5. For each item, output: the item ID (e.g. bug_003), the file path(s) you're changing, and the concrete change that resolves it — a code diff for bugs and features, a written answer for questions. If several items share a root cause, write one change that covers them and list every item ID it resolves.
6. CRITICAL — DOUBLE-CHECK THE TRANSCRIPT. Now read transcript.txt from start to finish: it is the COMPLETE word-for-word narration. The item folders are only what klunk caught automatically; the transcript is the real source of truth, and klunk CAN miss things. Go through it carefully and confirm that EVERY problem, request, question, complaint, or "it'd be nice if…" the user voiced is handled by one of the items above. If MASTER.md has a "⚠️ Possibly missed" note near the top, start there — klunk already suspects those were dropped. Anything not covered: handle it too. Then tell the user plainly what you did beyond the formal list — label it clearly, e.g. "Extra (from the transcript, not in the numbered items): …". If after a genuine pass you find nothing missing, say so explicitly so they know you actually checked.

## A couple of notes

- The red bounding boxes in screenshots can be off by 1–2 element widths. When the box and the prose in the README disagree, the prose wins.
- If you need clarification on something, ask. And — more importantly — if you spot something in here the user would want to know about (concerns, risks, design decisions where your past experience tells you a question is worth raising), bring it up. The user values your judgment on what's worth flagging.

You're being handed a ZIP file (Robots dream of electric gibberish.zip) — a structured report extracted from a narrated screen recording of RPReplay_Final1781143704.mp4.

It contains 1 items grouped into 1 themes, found across 1m 11s of footage. These are NOT all bugs — they're a mix of bugs to fix, feature requests and changes the user wants, UI polish, questions to answer, and plain tasks to do. Every item carries a "category" (bug / feature_request / ui_polish / question / task). Read it and treat each item on its own terms — don't assume everything is a defect.

## ZIP layout

Robots dream of electric gibberish.zip
├── INSTRUCTIONS.md       ← Read this first. Documents the conventions used in every item folder.
├── MASTER.md             ← Index of every item with its category, priority, and theme.
├── bug_001/              ← one item (every folder is named "bug_NNN", whatever its category)
│   ├── README.md         ← Authoritative description of this item + its category. Trust this over everything else.
│   ├── screenshot.png    ← Annotated frame with red box(es) around the affected element(s).
│   ├── screenshot_raw.png ← Same frame, no annotations.
│   ├── clip.mp4          ← Short clip with the user's narration in context.
│   └── omniparser_elements.json ← UI elements detected on the frame (positions / confidences).
├── bug_002/
├── ...
├── captions.srt / captions.vtt ← full narration captions (if available)
└── transcript.txt              ← everything the narrator said, plain text

Act on each item according to its category:
- bug / ui_polish — fix it in the code.
- feature_request — build the feature or make the change the user asked for. It's not a defect; it's something new they want added.
- task — something the user just SAID they want done (often nothing on screen, no screenshot). Treat it as a to-do, not a visual bug.
- question — the user was thinking out loud or weighing a decision. Each has a "recommendation" field with klunk's worked-through answer (options, pros/cons, a pick). Read it, then give YOUR take: agree, disagree, or add what's missing. Don't skip these — the user genuinely wants the decision resolved.

## Your job

1. Read INSTRUCTIONS.md.
2. Read MASTER.md.
3. Open every item folder. Read each README.md in full and note its category.
4. Handle every single item. All of them — don't skip any, don't pick favorites by priority. Fix the bugs, build the features and requested changes, do the tasks, answer the questions. What "handle" means depends on the item's category.
5. For each item, output: the item ID (e.g. bug_003), the file path(s) you're changing, and the concrete change that resolves it — a code diff for bugs and features, a written answer for questions. If several items share a root cause, write one change that covers them and list every item ID it resolves.
6. CRITICAL — DOUBLE-CHECK THE TRANSCRIPT. Now read transcript.txt from start to finish: it is the COMPLETE word-for-word narration. The item folders are only what klunk caught automatically; the transcript is the real source of truth, and klunk CAN miss things. Go through it carefully and confirm that EVERY problem, request, question, complaint, or "it'd be nice if…" the user voiced is handled by one of the items above. If MASTER.md has a "⚠️ Possibly missed" note near the top, start there — klunk already suspects those were dropped. Anything not covered: handle it too. Then tell the user plainly what you did beyond the formal list — label it clearly, e.g. "Extra (from the transcript, not in the numbered items): …". If after a genuine pass you find nothing missing, say so explicitly so they know you actually checked.

## A couple of notes

- The red bounding boxes in screenshots can be off by 1–2 element widths. When the box and the prose in the README disagree, the prose wins.
- If you need clarification on something, ask. And — more importantly — if you spot something in here the user would want to know about (concerns, risks, design decisions where your past experience tells you a question is worth raising), bring it up. The user values your judgment on what's worth flagging.

You're being handed a ZIP file (reports in witness protection.zip) — a structured report extracted from a narrated screen recording of RPReplay_Final1781143374.mp4.

It contains 1 items grouped into 1 themes, found across 59s of footage. These are NOT all bugs — they're a mix of bugs to fix, feature requests and changes the user wants, UI polish, questions to answer, and plain tasks to do. Every item carries a "category" (bug / feature_request / ui_polish / question / task). Read it and treat each item on its own terms — don't assume everything is a defect.

## ZIP layout

reports in witness protection.zip
├── INSTRUCTIONS.md       ← Read this first. Documents the conventions used in every item folder.
├── MASTER.md             ← Index of every item with its category, priority, and theme.
├── bug_001/              ← one item (every folder is named "bug_NNN", whatever its category)
│   ├── README.md         ← Authoritative description of this item + its category. Trust this over everything else.
│   ├── screenshot.png    ← Annotated frame with red box(es) around the affected element(s).
│   ├── screenshot_raw.png ← Same frame, no annotations.
│   ├── clip.mp4          ← Short clip with the user's narration in context.
│   └── omniparser_elements.json ← UI elements detected on the frame (positions / confidences).
├── bug_002/
├── ...
├── captions.srt / captions.vtt ← full narration captions (if available)
└── transcript.txt              ← everything the narrator said, plain text

Act on each item according to its category:
- bug / ui_polish — fix it in the code.
- feature_request — build the feature or make the change the user asked for. It's not a defect; it's something new they want added.
- task — something the user just SAID they want done (often nothing on screen, no screenshot). Treat it as a to-do, not a visual bug.
- question — the user was thinking out loud or weighing a decision. Each has a "recommendation" field with klunk's worked-through answer (options, pros/cons, a pick). Read it, then give YOUR take: agree, disagree, or add what's missing. Don't skip these — the user genuinely wants the decision resolved.

## Your job

1. Read INSTRUCTIONS.md.
2. Read MASTER.md.
3. Open every item folder. Read each README.md in full and note its category.
4. Handle every single item. All of them — don't skip any, don't pick favorites by priority. Fix the bugs, build the features and requested changes, do the tasks, answer the questions. What "handle" means depends on the item's category.
5. For each item, output: the item ID (e.g. bug_003), the file path(s) you're changing, and the concrete change that resolves it — a code diff for bugs and features, a written answer for questions. If several items share a root cause, write one change that covers them and list every item ID it resolves.
6. CRITICAL — DOUBLE-CHECK THE TRANSCRIPT. Now read transcript.txt from start to finish: it is the COMPLETE word-for-word narration. The item folders are only what klunk caught automatically; the transcript is the real source of truth, and klunk CAN miss things. Go through it carefully and confirm that EVERY problem, request, question, complaint, or "it'd be nice if…" the user voiced is handled by one of the items above. If MASTER.md has a "⚠️ Possibly missed" note near the top, start there — klunk already suspects those were dropped. Anything not covered: handle it too. Then tell the user plainly what you did beyond the formal list — label it clearly, e.g. "Extra (from the transcript, not in the numbered items): …". If after a genuine pass you find nothing missing, say so explicitly so they know you actually checked.

## A couple of notes

- The red bounding boxes in screenshots can be off by 1–2 element widths. When the box and the prose in the README disagree, the prose wins.
- If you need clarification on something, ask. And — more importantly — if you spot something in here the user would want to know about (concerns, risks, design decisions where your past experience tells you a question is worth raising), bring it up. The user values your judgment on what's worth flagging.

You're being handed a ZIP file (whispers from the community void.zip) — a structured report extracted from a narrated screen recording of Screen Recording 2026-06-10 at 11.34.16 AM.mov.

It contains 11 items grouped into 3 themes, found across 5m 38s of footage. These are NOT all bugs — they're a mix of bugs to fix, feature requests and changes the user wants, UI polish, questions to answer, and plain tasks to do. Every item carries a "category" (bug / feature_request / ui_polish / question / task). Read it and treat each item on its own terms — don't assume everything is a defect.

## ZIP layout

whispers from the community void.zip
├── INSTRUCTIONS.md       ← Read this first. Documents the conventions used in every item folder.
├── MASTER.md             ← Index of every item with its category, priority, and theme.
├── bug_001/              ← one item (every folder is named "bug_NNN", whatever its category)
│   ├── README.md         ← Authoritative description of this item + its category. Trust this over everything else.
│   ├── screenshot.png    ← Annotated frame with red box(es) around the affected element(s).
│   ├── screenshot_raw.png ← Same frame, no annotations.
│   ├── clip.mp4          ← Short clip with the user's narration in context.
│   └── omniparser_elements.json ← UI elements detected on the frame (positions / confidences).
├── bug_002/
├── ...
├── captions.srt / captions.vtt ← full narration captions (if available)
└── transcript.txt              ← everything the narrator said, plain text

Act on each item according to its category:
- bug / ui_polish — fix it in the code.
- feature_request — build the feature or make the change the user asked for. It's not a defect; it's something new they want added.
- task — something the user just SAID they want done (often nothing on screen, no screenshot). Treat it as a to-do, not a visual bug.
- question — the user was thinking out loud or weighing a decision. Each has a "recommendation" field with klunk's worked-through answer (options, pros/cons, a pick). Read it, then give YOUR take: agree, disagree, or add what's missing. Don't skip these — the user genuinely wants the decision resolved.

## Your job

1. Read INSTRUCTIONS.md.
2. Read MASTER.md.
3. Open every item folder. Read each README.md in full and note its category.
4. Handle every single item. All of them — don't skip any, don't pick favorites by priority. Fix the bugs, build the features and requested changes, do the tasks, answer the questions. What "handle" means depends on the item's category.
5. For each item, output: the item ID (e.g. bug_003), the file path(s) you're changing, and the concrete change that resolves it — a code diff for bugs and features, a written answer for questions. If several items share a root cause, write one change that covers them and list every item ID it resolves.
6. CRITICAL — DOUBLE-CHECK THE TRANSCRIPT. Now read transcript.txt from start to finish: it is the COMPLETE word-for-word narration. The item folders are only what klunk caught automatically; the transcript is the real source of truth, and klunk CAN miss things. Go through it carefully and confirm that EVERY problem, request, question, complaint, or "it'd be nice if…" the user voiced is handled by one of the items above. If MASTER.md has a "⚠️ Possibly missed" note near the top, start there — klunk already suspects those were dropped. Anything not covered: handle it too. Then tell the user plainly what you did beyond the formal list — label it clearly, e.g. "Extra (from the transcript, not in the numbered items): …". If after a genuine pass you find nothing missing, say so explicitly so they know you actually checked.

## A couple of notes

- The red bounding boxes in screenshots can be off by 1–2 element widths. When the box and the prose in the README disagree, the prose wins.
- If you need clarification on something, ask. And — more importantly — if you spot something in here the user would want to know about (concerns, risks, design decisions where your past experience tells you a question is worth raising), bring it up. The user values your judgment on what's worth flagging.

You're being handed a ZIP file (ai summary had one job.zip) — a structured report extracted from a narrated screen recording of copy_FB2D7AFA-695D-45F7-91A4-A663BBC968E2.mov.

It contains 1 items grouped into 1 themes, found across 23s of footage. These are NOT all bugs — they're a mix of bugs to fix, feature requests and changes the user wants, UI polish, questions to answer, and plain tasks to do. Every item carries a "category" (bug / feature_request / ui_polish / question / task). Read it and treat each item on its own terms — don't assume everything is a defect.

## ZIP layout

ai summary had one job.zip
├── INSTRUCTIONS.md       ← Read this first. Documents the conventions used in every item folder.
├── MASTER.md             ← Index of every item with its category, priority, and theme.
├── bug_001/              ← one item (every folder is named "bug_NNN", whatever its category)
│   ├── README.md         ← Authoritative description of this item + its category. Trust this over everything else.
│   ├── screenshot.png    ← Annotated frame with red box(es) around the affected element(s).
│   ├── screenshot_raw.png ← Same frame, no annotations.
│   ├── clip.mp4          ← Short clip with the user's narration in context.
│   └── omniparser_elements.json ← UI elements detected on the frame (positions / confidences).
├── bug_002/
├── ...
├── captions.srt / captions.vtt ← full narration captions (if available)
└── transcript.txt              ← everything the narrator said, plain text

Act on each item according to its category:
- bug / ui_polish — fix it in the code.
- feature_request — build the feature or make the change the user asked for. It's not a defect; it's something new they want added.
- task — something the user just SAID they want done (often nothing on screen, no screenshot). Treat it as a to-do, not a visual bug.
- question — the user was thinking out loud or weighing a decision. Each has a "recommendation" field with klunk's worked-through answer (options, pros/cons, a pick). Read it, then give YOUR take: agree, disagree, or add what's missing. Don't skip these — the user genuinely wants the decision resolved.

## Your job

1. Read INSTRUCTIONS.md.
2. Read MASTER.md.
3. Open every item folder. Read each README.md in full and note its category.
4. Handle every single item. All of them — don't skip any, don't pick favorites by priority. Fix the bugs, build the features and requested changes, do the tasks, answer the questions. What "handle" means depends on the item's category.
5. For each item, output: the item ID (e.g. bug_003), the file path(s) you're changing, and the concrete change that resolves it — a code diff for bugs and features, a written answer for questions. If several items share a root cause, write one change that covers them and list every item ID it resolves.
6. CRITICAL — DOUBLE-CHECK THE TRANSCRIPT. Now read transcript.txt from start to finish: it is the COMPLETE word-for-word narration. The item folders are only what klunk caught automatically; the transcript is the real source of truth, and klunk CAN miss things. Go through it carefully and confirm that EVERY problem, request, question, complaint, or "it'd be nice if…" the user voiced is handled by one of the items above. If MASTER.md has a "⚠️ Possibly missed" note near the top, start there — klunk already suspects those were dropped. Anything not covered: handle it too. Then tell the user plainly what you did beyond the formal list — label it clearly, e.g. "Extra (from the transcript, not in the numbered items): …". If after a genuine pass you find nothing missing, say so explicitly so they know you actually checked.

## A couple of notes

- The red bounding boxes in screenshots can be off by 1–2 element widths. When the box and the prose in the README disagree, the prose wins.
- If you need clarification on something, ask. And — more importantly — if you spot something in here the user would want to know about (concerns, risks, design decisions where your past experience tells you a question is worth raising), bring it up. The user values your judgment on what's worth flagging.

You're being handed a ZIP file (the UI needs a pep talk.zip) — a structured report extracted from a narrated screen recording of Screen Recording 2026-06-06 at 8.48.56 AM.mov.

It contains 2 items grouped into 2 themes, found across 3m 38s of footage. These are NOT all bugs — they're a mix of bugs to fix, feature requests and changes the user wants, UI polish, questions to answer, and plain tasks to do. Every item carries a "category" (bug / feature_request / ui_polish / question / task). Read it and treat each item on its own terms — don't assume everything is a defect.

## ZIP layout

the UI needs a pep talk.zip
├── INSTRUCTIONS.md       ← Read this first. Documents the conventions used in every item folder.
├── MASTER.md             ← Index of every item with its category, priority, and theme.
├── bug_001/              ← one item (every folder is named "bug_NNN", whatever its category)
│   ├── README.md         ← Authoritative description of this item + its category. Trust this over everything else.
│   ├── screenshot.png    ← Annotated frame with red box(es) around the affected element(s).
│   ├── screenshot_raw.png ← Same frame, no annotations.
│   ├── clip.mp4          ← Short clip with the user's narration in context.
│   └── omniparser_elements.json ← UI elements detected on the frame (positions / confidences).
├── bug_002/
├── ...
├── captions.srt / captions.vtt ← full narration captions (if available)
└── transcript.txt              ← everything the narrator said, plain text

Act on each item according to its category:
- bug / ui_polish — fix it in the code.
- feature_request — build the feature or make the change the user asked for. It's not a defect; it's something new they want added.
- task — something the user just SAID they want done (often nothing on screen, no screenshot). Treat it as a to-do, not a visual bug.
- question — the user was thinking out loud or weighing a decision. Each has a "recommendation" field with klunk's worked-through answer (options, pros/cons, a pick). Read it, then give YOUR take: agree, disagree, or add what's missing. Don't skip these — the user genuinely wants the decision resolved.

## Your job

1. Read INSTRUCTIONS.md.
2. Read MASTER.md.
3. Open every item folder. Read each README.md in full and note its category.
4. Handle every single item. All of them — don't skip any, don't pick favorites by priority. Fix the bugs, build the features and requested changes, do the tasks, answer the questions. What "handle" means depends on the item's category.
5. For each item, output: the item ID (e.g. bug_003), the file path(s) you're changing, and the concrete change that resolves it — a code diff for bugs and features, a written answer for questions. If several items share a root cause, write one change that covers them and list every item ID it resolves.
6. CRITICAL — DOUBLE-CHECK THE TRANSCRIPT. Now read transcript.txt from start to finish: it is the COMPLETE word-for-word narration. The item folders are only what klunk caught automatically; the transcript is the real source of truth, and klunk CAN miss things. Go through it carefully and confirm that EVERY problem, request, question, complaint, or "it'd be nice if…" the user voiced is handled by one of the items above. If MASTER.md has a "⚠️ Possibly missed" note near the top, start there — klunk already suspects those were dropped. Anything not covered: handle it too. Then tell the user plainly what you did beyond the formal list — label it clearly, e.g. "Extra (from the transcript, not in the numbered items): …". If after a genuine pass you find nothing missing, say so explicitly so they know you actually checked.

## A couple of notes

- The red bounding boxes in screenshots can be off by 1–2 element widths. When the box and the prose in the README disagree, the prose wins.
- If you need clarification on something, ask. And — more importantly — if you spot something in here the user would want to know about (concerns, risks, design decisions where your past experience tells you a question is worth raising), bring it up. The user values your judgment on what's worth flagging.

You're being handed a ZIP file (pixels doing their own thing.zip) — a structured report extracted from a narrated screen recording of Screen Recording 2026-06-06 at 8.45.05 AM.mov.

It contains 7 items grouped into 3 themes, found across 3m 32s of footage. These are NOT all bugs — they're a mix of bugs to fix, feature requests and changes the user wants, UI polish, questions to answer, and plain tasks to do. Every item carries a "category" (bug / feature_request / ui_polish / question / task). Read it and treat each item on its own terms — don't assume everything is a defect.

## ZIP layout

pixels doing their own thing.zip
├── INSTRUCTIONS.md       ← Read this first. Documents the conventions used in every item folder.
├── MASTER.md             ← Index of every item with its category, priority, and theme.
├── bug_001/              ← one item (every folder is named "bug_NNN", whatever its category)
│   ├── README.md         ← Authoritative description of this item + its category. Trust this over everything else.
│   ├── screenshot.png    ← Annotated frame with red box(es) around the affected element(s).
│   ├── screenshot_raw.png ← Same frame, no annotations.
│   ├── clip.mp4          ← Short clip with the user's narration in context.
│   └── omniparser_elements.json ← UI elements detected on the frame (positions / confidences).
├── bug_002/
├── ...
├── captions.srt / captions.vtt ← full narration captions (if available)
└── transcript.txt              ← everything the narrator said, plain text

Act on each item according to its category:
- bug / ui_polish — fix it in the code.
- feature_request — build the feature or make the change the user asked for. It's not a defect; it's something new they want added.
- task — something the user just SAID they want done (often nothing on screen, no screenshot). Treat it as a to-do, not a visual bug.
- question — the user was thinking out loud or weighing a decision. Each has a "recommendation" field with klunk's worked-through answer (options, pros/cons, a pick). Read it, then give YOUR take: agree, disagree, or add what's missing. Don't skip these — the user genuinely wants the decision resolved.

## Your job

1. Read INSTRUCTIONS.md.
2. Read MASTER.md.
3. Open every item folder. Read each README.md in full and note its category.
4. Handle every single item. All of them — don't skip any, don't pick favorites by priority. Fix the bugs, build the features and requested changes, do the tasks, answer the questions. What "handle" means depends on the item's category.
5. For each item, output: the item ID (e.g. bug_003), the file path(s) you're changing, and the concrete change that resolves it — a code diff for bugs and features, a written answer for questions. If several items share a root cause, write one change that covers them and list every item ID it resolves.
6. CRITICAL — DOUBLE-CHECK THE TRANSCRIPT. Now read transcript.txt from start to finish: it is the COMPLETE word-for-word narration. The item folders are only what klunk caught automatically; the transcript is the real source of truth, and klunk CAN miss things. Go through it carefully and confirm that EVERY problem, request, question, complaint, or "it'd be nice if…" the user voiced is handled by one of the items above. If MASTER.md has a "⚠️ Possibly missed" note near the top, start there — klunk already suspects those were dropped. Anything not covered: handle it too. Then tell the user plainly what you did beyond the formal list — label it clearly, e.g. "Extra (from the transcript, not in the numbered items): …". If after a genuine pass you find nothing missing, say so explicitly so they know you actually checked.

## A couple of notes

- The red bounding boxes in screenshots can be off by 1–2 element widths. When the box and the prose in the README disagree, the prose wins.
- If you need clarification on something, ask. And — more importantly — if you spot something in here the user would want to know about (concerns, risks, design decisions where your past experience tells you a question is worth raising), bring it up. The user values your judgment on what's worth flagging.

You're being handed a ZIP file (nav bar ate the cards.zip) — a structured report extracted from a narrated screen recording of Screen Recording 2026-06-05 at 11.52.21 PM.mov.

It contains 7 items grouped into 3 themes, found across 3m 43s of footage. These are NOT all bugs — they're a mix of bugs to fix, feature requests and changes the user wants, UI polish, questions to answer, and plain tasks to do. Every item carries a "category" (bug / feature_request / ui_polish / question / task). Read it and treat each item on its own terms — don't assume everything is a defect.

## ZIP layout

nav bar ate the cards.zip
├── INSTRUCTIONS.md       ← Read this first. Documents the conventions used in every item folder.
├── MASTER.md             ← Index of every item with its category, priority, and theme.
├── bug_001/              ← one item (every folder is named "bug_NNN", whatever its category)
│   ├── README.md         ← Authoritative description of this item + its category. Trust this over everything else.
│   ├── screenshot.png    ← Annotated frame with red box(es) around the affected element(s).
│   ├── screenshot_raw.png ← Same frame, no annotations.
│   ├── clip.mp4          ← Short clip with the user's narration in context.
│   └── omniparser_elements.json ← UI elements detected on the frame (positions / confidences).
├── bug_002/
├── ...
├── captions.srt / captions.vtt ← full narration captions (if available)
└── transcript.txt              ← everything the narrator said, plain text

Act on each item according to its category:
- bug / ui_polish — fix it in the code.
- feature_request — build the feature or make the change the user asked for. It's not a defect; it's something new they want added.
- task — something the user just SAID they want done (often nothing on screen, no screenshot). Treat it as a to-do, not a visual bug.
- question — the user was thinking out loud or weighing a decision. Each has a "recommendation" field with klunk's worked-through answer (options, pros/cons, a pick). Read it, then give YOUR take: agree, disagree, or add what's missing. Don't skip these — the user genuinely wants the decision resolved.

## Your job

1. Read INSTRUCTIONS.md.
2. Read MASTER.md.
3. Open every item folder. Read each README.md in full and note its category.
4. Handle every single item. All of them — don't skip any, don't pick favorites by priority. Fix the bugs, build the features and requested changes, do the tasks, answer the questions. What "handle" means depends on the item's category.
5. For each item, output: the item ID (e.g. bug_003), the file path(s) you're changing, and the concrete change that resolves it — a code diff for bugs and features, a written answer for questions. If several items share a root cause, write one change that covers them and list every item ID it resolves.
6. CRITICAL — DOUBLE-CHECK THE TRANSCRIPT. Now read transcript.txt from start to finish: it is the COMPLETE word-for-word narration. The item folders are only what klunk caught automatically; the transcript is the real source of truth, and klunk CAN miss things. Go through it carefully and confirm that EVERY problem, request, question, complaint, or "it'd be nice if…" the user voiced is handled by one of the items above. If MASTER.md has a "⚠️ Possibly missed" note near the top, start there — klunk already suspects those were dropped. Anything not covered: handle it too. Then tell the user plainly what you did beyond the formal list — label it clearly, e.g. "Extra (from the transcript, not in the numbered items): …". If after a genuine pass you find nothing missing, say so explicitly so they know you actually checked.

## A couple of notes

- The red bounding boxes in screenshots can be off by 1–2 element widths. When the box and the prose in the README disagree, the prose wins.
- If you need clarification on something, ask. And — more importantly — if you spot something in here the user would want to know about (concerns, risks, design decisions where your past experience tells you a question is worth raising), bring it up. The user values your judgment on what's worth flagging.

You're being handed a ZIP file (our ai is trying its best.zip) — a structured report extracted from a narrated screen recording of klunkchanges.mov.

It contains 9 items grouped into 4 themes, found across 5m 18s of footage. These are NOT all bugs — they're a mix of bugs to fix, feature requests and changes the user wants, UI polish, questions to answer, and plain tasks to do. Every item carries a "category" (bug / feature_request / ui_polish / question / task). Read it and treat each item on its own terms — don't assume everything is a defect.

## ZIP layout

our ai is trying its best.zip
├── INSTRUCTIONS.md       ← Read this first. Documents the conventions used in every item folder.
├── MASTER.md             ← Index of every item with its category, priority, and theme.
├── bug_001/              ← one item (every folder is named "bug_NNN", whatever its category)
│   ├── README.md         ← Authoritative description of this item + its category. Trust this over everything else.
│   ├── screenshot.png    ← Annotated frame with red box(es) around the affected element(s).
│   ├── screenshot_raw.png ← Same frame, no annotations.
│   ├── clip.mp4          ← Short clip with the user's narration in context.
│   └── omniparser_elements.json ← UI elements detected on the frame (positions / confidences).
├── bug_002/
├── ...
├── captions.srt / captions.vtt ← full narration captions (if available)
└── transcript.txt              ← everything the narrator said, plain text

Act on each item according to its category:
- bug / ui_polish — fix it in the code.
- feature_request — build the feature or make the change the user asked for. It's not a defect; it's something new they want added.
- task — something the user just SAID they want done (often nothing on screen, no screenshot). Treat it as a to-do, not a visual bug.
- question — the user was thinking out loud or weighing a decision. Each has a "recommendation" field with klunk's worked-through answer (options, pros/cons, a pick). Read it, then give YOUR take: agree, disagree, or add what's missing. Don't skip these — the user genuinely wants the decision resolved.

## Your job

1. Read INSTRUCTIONS.md.
2. Read MASTER.md.
3. Open every item folder. Read each README.md in full and note its category.
4. Handle every single item. All of them — don't skip any, don't pick favorites by priority. Fix the bugs, build the features and requested changes, do the tasks, answer the questions. What "handle" means depends on the item's category.
5. For each item, output: the item ID (e.g. bug_003), the file path(s) you're changing, and the concrete change that resolves it — a code diff for bugs and features, a written answer for questions. If several items share a root cause, write one change that covers them and list every item ID it resolves.
6. CRITICAL — DOUBLE-CHECK THE TRANSCRIPT. Now read transcript.txt from start to finish: it is the COMPLETE word-for-word narration. The item folders are only what klunk caught automatically; the transcript is the real source of truth, and klunk CAN miss things. Go through it carefully and confirm that EVERY problem, request, question, complaint, or "it'd be nice if…" the user voiced is handled by one of the items above. If MASTER.md has a "⚠️ Possibly missed" note near the top, start there — klunk already suspects those were dropped. Anything not covered: handle it too. Then tell the user plainly what you did beyond the formal list — label it clearly, e.g. "Extra (from the transcript, not in the numbered items): …". If after a genuine pass you find nothing missing, say so explicitly so they know you actually checked.

## A couple of notes

- The red bounding boxes in screenshots can be off by 1–2 element widths. When the box and the prose in the README disagree, the prose wins.
- If you need clarification on something, ask. And — more importantly — if you spot something in here the user would want to know about (concerns, risks, design decisions where your past experience tells you a question is worth raising), bring it up. The user values your judgment on what's worth flagging.

You're being handed a ZIP file (Design intent on vacation.zip) — a structured report extracted from a narrated screen recording of Is this right.mov.

It contains 1 items grouped into 1 themes, found across 19s of footage. These are NOT all bugs — they're a mix of bugs to fix, feature requests and changes the user wants, UI polish, questions to answer, and plain tasks to do. Every item carries a "category" (bug / feature_request / ui_polish / question / task). Read it and treat each item on its own terms — don't assume everything is a defect.

## ZIP layout

Design intent on vacation.zip
├── INSTRUCTIONS.md       ← Read this first. Documents the conventions used in every item folder.
├── MASTER.md             ← Index of every item with its category, priority, and theme.
├── bug_001/              ← one item (every folder is named "bug_NNN", whatever its category)
│   ├── README.md         ← Authoritative description of this item + its category. Trust this over everything else.
│   ├── screenshot.png    ← Annotated frame with red box(es) around the affected element(s).
│   ├── screenshot_raw.png ← Same frame, no annotations.
│   ├── clip.mp4          ← Short clip with the user's narration in context.
│   └── omniparser_elements.json ← UI elements detected on the frame (positions / confidences).
├── bug_002/
├── ...
├── captions.srt / captions.vtt ← full narration captions (if available)
└── transcript.txt              ← everything the narrator said, plain text

Act on each item according to its category:
- bug / ui_polish — fix it in the code.
- feature_request — build the feature or make the change the user asked for. It's not a defect; it's something new they want added.
- task — something the user just SAID they want done (often nothing on screen, no screenshot). Treat it as a to-do, not a visual bug.
- question — the user was thinking out loud or weighing a decision. Each has a "recommendation" field with klunk's worked-through answer (options, pros/cons, a pick). Read it, then give YOUR take: agree, disagree, or add what's missing. Don't skip these — the user genuinely wants the decision resolved.

## Your job

1. Read INSTRUCTIONS.md.
2. Read MASTER.md.
3. Open every item folder. Read each README.md in full and note its category.
4. Handle every single item. All of them — don't skip any, don't pick favorites by priority. Fix the bugs, build the features and requested changes, do the tasks, answer the questions. What "handle" means depends on the item's category.
5. For each item, output: the item ID (e.g. bug_003), the file path(s) you're changing, and the concrete change that resolves it — a code diff for bugs and features, a written answer for questions. If several items share a root cause, write one change that covers them and list every item ID it resolves.
6. CRITICAL — DOUBLE-CHECK THE TRANSCRIPT. Now read transcript.txt from start to finish: it is the COMPLETE word-for-word narration. The item folders are only what klunk caught automatically; the transcript is the real source of truth, and klunk CAN miss things. Go through it carefully and confirm that EVERY problem, request, question, complaint, or "it'd be nice if…" the user voiced is handled by one of the items above. If MASTER.md has a "⚠️ Possibly missed" note near the top, start there — klunk already suspects those were dropped. Anything not covered: handle it too. Then tell the user plainly what you did beyond the formal list — label it clearly, e.g. "Extra (from the transcript, not in the numbered items): …". If after a genuine pass you find nothing missing, say so explicitly so they know you actually checked.

## A couple of notes

- The red bounding boxes in screenshots can be off by 1–2 element widths. When the box and the prose in the README disagree, the prose wins.
- If you need clarification on something, ask. And — more importantly — if you spot something in here the user would want to know about (concerns, risks, design decisions where your past experience tells you a question is worth raising), bring it up. The user values your judgment on what's worth flagging.

You're being handed a ZIP file (UI forgot its manners.zip) — a structured report extracted from a narrated screen recording of KlunkBigBugs.mov.

It contains 35 items grouped into 5 themes, found across 28m 36s of footage. These are NOT all bugs — they're a mix of bugs to fix, feature requests and changes the user wants, UI polish, questions to answer, and plain tasks to do. Every item carries a "category" (bug / feature_request / ui_polish / question / task). Read it and treat each item on its own terms — don't assume everything is a defect.

## ZIP layout

UI forgot its manners.zip
├── INSTRUCTIONS.md       ← Read this first. Documents the conventions used in every item folder.
├── MASTER.md             ← Index of every item with its category, priority, and theme.
├── bug_001/              ← one item (every folder is named "bug_NNN", whatever its category)
│   ├── README.md         ← Authoritative description of this item + its category. Trust this over everything else.
│   ├── screenshot.png    ← Annotated frame with red box(es) around the affected element(s).
│   ├── screenshot_raw.png ← Same frame, no annotations.
│   ├── clip.mp4          ← Short clip with the user's narration in context.
│   └── omniparser_elements.json ← UI elements detected on the frame (positions / confidences).
├── bug_002/
├── ...
├── captions.srt / captions.vtt ← full narration captions (if available)
└── transcript.txt              ← everything the narrator said, plain text

Act on each item according to its category:
- bug / ui_polish — fix it in the code.
- feature_request — build the feature or make the change the user asked for. It's not a defect; it's something new they want added.
- task — something the user just SAID they want done (often nothing on screen, no screenshot). Treat it as a to-do, not a visual bug.
- question — the user was thinking out loud or weighing a decision. Each has a "recommendation" field with klunk's worked-through answer (options, pros/cons, a pick). Read it, then give YOUR take: agree, disagree, or add what's missing. Don't skip these — the user genuinely wants the decision resolved.

## Your job

1. Read INSTRUCTIONS.md.
2. Read MASTER.md.
3. Open every item folder. Read each README.md in full and note its category.
4. Handle every single item. All of them — don't skip any, don't pick favorites by priority. Fix the bugs, build the features and requested changes, do the tasks, answer the questions. What "handle" means depends on the item's category.
5. For each item, output: the item ID (e.g. bug_003), the file path(s) you're changing, and the concrete change that resolves it — a code diff for bugs and features, a written answer for questions. If several items share a root cause, write one change that covers them and list every item ID it resolves.
6. CRITICAL — DOUBLE-CHECK THE TRANSCRIPT. Now read transcript.txt from start to finish: it is the COMPLETE word-for-word narration. The item folders are only what klunk caught automatically; the transcript is the real source of truth, and klunk CAN miss things. Go through it carefully and confirm that EVERY problem, request, question, complaint, or "it'd be nice if…" the user voiced is handled by one of the items above. If MASTER.md has a "⚠️ Possibly missed" note near the top, start there — klunk already suspects those were dropped. Anything not covered: handle it too. Then tell the user plainly what you did beyond the formal list — label it clearly, e.g. "Extra (from the transcript, not in the numbered items): …". If after a genuine pass you find nothing missing, say so explicitly so they know you actually checked.

## A couple of notes

- The red bounding boxes in screenshots can be off by 1–2 element widths. When the box and the prose in the README disagree, the prose wins.
- If you need clarification on something, ask. And — more importantly — if you spot something in here the user would want to know about (concerns, risks, design decisions where your past experience tells you a question is worth raising), bring it up. The user values your judgment on what's worth flagging.