Files & workspace
Delivery pre-flight
A machine check before you say done: names, sizes, banned words, missing files, zero bytes.
Free Free to read and free to ask for by email.
Background
You cannot see the difference between 900×383 and 901×383 by eye, and you cannot remember whether INDEX was updated. Hand this gate to a script; it does exactly one thing: turn "I thought I had shipped it" into a PASS/FAIL table.
Why it is built this way
900×383 and 901×383 look the same, and nobody remembers whether INDEX.md was updated, so this gate is a script rather than a habit. It produces one table with seven codes: NAME, BANNED, SIZE, NOTE, INDEX, ZERO, DUP. Exit code 1 means at least one FAIL, and a FAIL forbids the word complete. The value is the output line you can quote back after a rework.
SIZE reads the expected dimensions from the purpose keyword in the filename, so a naming mistake silently skips the size check. That is why a NAME failure is handled first and why --kind generic leaves the size row untested. After a fix the command runs again and the Result line gets pasted as evidence, because fixing a name can strip the keyword the check needs and a re-render can leave an empty file.
Where it bites
- The cover that passed at the wrong size SIZE resolves the expected dimensions from the purpose keyword in the filename; one wrong word and the check never runs. A 500×500 slot can be filled by a 400×400 square and still read as a pass. So NAME failures outrank every other code, and --kind generic leaves SIZE untested entirely.
- Fixed it, broke something else Fixing a name can strip the keyword SIZE needs, and a re-render can leave a 0-byte image behind. The skill requires a second run after every fix and the pasted Result line as delivery evidence, so 'fixed' carries an output instead of a sentence in chat.
- INDEX older than the batch Files go out while INDEX.md still has no row for them, so the batch exists and cannot be found from the index. The INDEX check compares mtime against the deliverables, and because copying or unzipping rewrites mtime, the rule adds one manual scan of the index content on top.
- Two copies of one batch The same assets under outputs/ and again in a platform folder make DUP fire, and the batch now has two lives to maintain. Placement rules allow one location per batch; DUP arrives as a WARN, a hint to clear before delivery.
Inside this skill
- When to use
- One command
- What it checks
- Hard rules
- Common mistakes
- Acceptance
The outline is the skill file's own headings, in the order it uses them.
When to use it
Use this before delivering (especially before saying 'done' or 'sending it to you') to run one machine verification pass: non-compliant filenames, size mismatches, banned words, missing delivery notes, INDEX not updated, 0-byte files, duplicate placement. Also use it when the user complains 'why is the size wrong again', 'the naming is a mess', 'you said done but files are missing'.
How to use it
- Ask for the file by email — it is a single
SKILL.md. - Put it in the skills folder your agent reads, in a directory named
delivery-preflight. - Start a message with the trigger from the description, or name the skill directly.
The skill file goes out by email rather than as a download. Signed in, it goes to your account address; otherwise tell us where to send it.