screenshot-loop — read, act, delete
The user drops screenshots in one folder. You read them, act, then delete the
ones you read. The folder is a mailbox, not an archive.
The directory
Read .screenshot-dir at the repo root — one line, an absolute path.
If it does not exist, ask the user for the path once, then write their answer
to .screenshot-dir — not a placeholder, the path they actually gave you:
<absolute path the user gave you>
If the user gives a path in their message, that wins for this cycle, and write
it to .screenshot-dir if the file is missing or points somewhere else (ask
before overwriting an existing different path).
No one to ask, and no .screenshot-dir? Say so in one line and stop — never guess
a folder. Step 6 deletes everything it read, and a guessed folder is someone else's
files. Same if the file points somewhere other than a path you were given: use the
given path for this cycle and leave .screenshot-dir as it is.
The cycle
- List — glob the directory for
*.png *.jpg *.jpeg *.webp *.gif, sorted
oldest first. Empty? Say so in one line and stop. Do not go looking elsewhere.
- Read every one with the Read tool. Every one, not a sample. Screenshot 4
is usually the one that explains screenshots 1–3.
- Understand before acting. State in 1–3 lines what the set shows: the
screen, what is wrong or being asked for, and which files that maps to. If
the screenshots are ambiguous — you cannot tell what the user wants changed —
ask, and do not delete anything.
- Act. Make the fix or the change. This is normal work: find the code,
edit it, run the check. Screenshots are the bug report, not the task list —
if two of them show the same defect, that is one fix.
- Verify the way the project normally verifies (tests, build, run). If the
change cannot be verified, say so plainly.
- Delete — and only now — exactly the files listed in step 1, by name.
Files that appeared mid-cycle are next cycle's input; leave them.
- Report: what the screenshots showed, what changed, what was deleted.
Deletion rules
- Delete files, never the directory itself.
- Delete only after the work is done and reported. Work blocked, question
pending, or user interrupted → screenshots stay.
- Never delete anything outside the screenshot directory.
- If the user says "keep them" or "don't delete", skip step 6 and say so.
Repeat rounds
The user will drop a new batch and say "again" / "recheck" / "still broken".
Run the cycle again from step 1. Carry what you learned last round — a second
round of the same screen means the first fix missed, so investigate rather than
re-applying the same edit.
1---2name: screenshot-loop3description: Use when the user says "screenshots", "check the screenshots", "I dropped new screenshots", "test screenshots", "look at the latest run", or gives a screenshot directory path — test screenshots dropped in a project's screenshot folder that need acting on and then clearing. NOT for taking screenshots (use a browser/app skill for that) and NOT for permanent design assets — everything in that folder is treated as disposable.4---56# screenshot-loop — read, act, delete78The user drops screenshots in one folder. You read them, act, then delete the9ones you read. The folder is a mailbox, not an archive.1011## The directory1213Read `.screenshot-dir` at the repo root — one line, an absolute path.1415If it does not exist, ask the user for the path once, then write their answer16to `.screenshot-dir` — not a placeholder, the path they actually gave you:1718```19<absolute path the user gave you>20```2122If the user gives a path in their message, that wins for this cycle, and write23it to `.screenshot-dir` if the file is missing or points somewhere else (ask24before overwriting an existing different path).2526No one to ask, and no `.screenshot-dir`? Say so in one line and stop — never guess27a folder. Step 6 deletes everything it read, and a guessed folder is someone else's28files. Same if the file points somewhere other than a path you were given: use the29given path for this cycle and leave `.screenshot-dir` as it is.3031## The cycle32331. **List** — glob the directory for `*.png *.jpg *.jpeg *.webp *.gif`, sorted34 oldest first. Empty? Say so in one line and stop. Do not go looking elsewhere.352. **Read every one** with the Read tool. Every one, not a sample. Screenshot 436 is usually the one that explains screenshots 1–3.373. **Understand before acting.** State in 1–3 lines what the set shows: the38 screen, what is wrong or being asked for, and which files that maps to. If39 the screenshots are ambiguous — you cannot tell what the user wants changed —40 ask, and do not delete anything.414. **Act.** Make the fix or the change. This is normal work: find the code,42 edit it, run the check. Screenshots are the bug report, not the task list —43 if two of them show the same defect, that is one fix.445. **Verify** the way the project normally verifies (tests, build, run). If the45 change cannot be verified, say so plainly.466. **Delete** — and only now — exactly the files listed in step 1, by name.47 Files that appeared mid-cycle are next cycle's input; leave them.487. **Report**: what the screenshots showed, what changed, what was deleted.4950## Deletion rules5152- Delete files, never the directory itself.53- Delete only after the work is done and reported. Work blocked, question54 pending, or user interrupted → screenshots stay.55- Never delete anything outside the screenshot directory.56- If the user says "keep them" or "don't delete", skip step 6 and say so.5758## Repeat rounds5960The user will drop a new batch and say "again" / "recheck" / "still broken".61Run the cycle again from step 1. Carry what you learned last round — a second62round of the same screen means the first fix missed, so investigate rather than63re-applying the same edit.
bodish-coder