terrylica photo-gallery-delivery
Self-Evolving Skill: This skill improves through use. If instructions are wrong, parameters drifted, or a workaround was needed — fix this file immediately, don't defer. Only update for real, reproducible issues.
The full playbook for delivering a photo set to a real recipient when "just share the album" isn't working — because the files are HEIC, the share app forces a login, or the recipient's software can't ingest what you sent. It stitches three focused skills into one flow and adds the gist-gateway + password delivery model.
When to use
- A recipient says they can't open / can't download / can't convert your photos (classic: iPhone HEIC vs. Windows appraisal/CRM software).
- You want to hand over a clean, unlisted JPEG gallery (viewable in any browser, no app, no login) plus a bulk ZIP — to a dealer, insurance adjuster, client, or contractor.
- You're already sharing a gist / landing page with people and want it to lead to JPEGs instead of a format they can't use.
The pipeline
cloud album ──▶ download originals ──▶ HEIC→JPEG + gallery + ZIP ──▶ unlisted host ──▶ gist gateway
(share link) amazon-photos- heic-to-jpeg-bundle cloudflare- (link + password)
album-download workers-publish
Each stage is its own skill; this skill is the glue + the decisions between stages.
1. Pull the originals — productivity-tools/amazon-photos-album-download
Get a verified local copy of every original from the public Amazon Photos share link. Store them outside any git repo (originals carry GPS/plate/VIN EXIF).
ALBUM_URL="https://www.amazon.ca/photos/share/<id>" ALBUM_OUT="$HOME/.cache/album/originals" \
bun "$(find ~/.claude ~/eon -path '*/amazon-photos-album-download/scripts/download-album.ts' | head -1)"
2. Convert + bundle — media-tools/heic-to-jpeg-bundle
Make a gallery (2048px view tier + thumbnails) and a password-protected ZIP sized to fit the host's per-file cap.
bash "$(find ~/.claude ~/eon -path '*/heic-to-jpeg-bundle/scripts/make-bundle.sh' | head -1)" \
--src "$HOME/.cache/album/originals" \
--title "2023 Corolla Cross — trade-in photos" \
--zip --password "<PICK-A-PASSWORD>" --zip-cap-mib 25
3. Host it unlisted — devops-tools/cloudflare-workers-publish
Deploy the _bundle/site/ directory (gallery + per-photo JPEGs + the ≤25 MiB ZIP). You get
an unlisted https://<name>.<slug>.workers.dev/ URL. Mind the 25 MiB/file cap (CFW-16):
the gallery and a downscaled ZIP fit; a full-resolution ZIP does not — host that on R2 / a
GitHub Release / your own server and link it from the gallery. See
large files & ZIP delivery.
4. Share through the gist gateway
If you already share a gist (or any landing page) with recipients, make it the gateway:
- Add a "📸 Photos (JPEG)" section: the gallery URL, the ZIP URL, and the ZIP password.
- Keep the password only on the gist, never on the Workers page (password-on-the-gateway, see the cloudflare skill). The gist becomes the one place that has both link and password.
- If a short link (tinyurl) already points at the gist, every previously-sent link upgrades for free.
gh gist edit <gist-id> -f <file.md> /tmp/updated-gist.md
Decisions to surface (use AskUserQuestion)
- Resolution / tiers: web-res gallery only, or also a full-resolution ZIP for the recipient's own analysis? Full-res can't sit on Workers (size) — confirm a large-file host.
- Hosting: unlisted Workers (recommended) vs. public GitHub Release (world-readable — avoid for PII) vs. own server.
- Gating: password-protected ZIP with the password on the gist, vs. open download.
- Privacy: these photos often show plate / VIN / home — keep originals out of git, prefer unlisted hosting, and don't index publicly.
Worked example (June 2026)
A used-car buyer's Amazon Photos album of 125 HEIC trade-in photos was unusable to dealers
whose appraisal software couldn't open HEIC (the documented #1 blocker in their outreach).
Flow: pulled all 125 originals (byte-verified) → converted to a 2048px JPEG gallery + a
24 MiB ZipCrypto ZIP (--zip-cap-mib 25 downscaled it to fit) → deployed gallery + ZIP to
vehicle-appraisal.example-account.workers.dev (the 109 MiB full-res ZIP hit the 25 MiB cap, so
it was kept off Workers) → updated the dealer-facing gist with the gallery link, ZIP link, and
the password. Because a tinyurl already pointed at the gist, ~22 already-sent dealer links
upgraded to JPEGs with nothing re-sent.
Post-Execution Reflection
After a delivery, before closing:
- Did the recipient succeed? If they still struggled, note the exact tool/format and fix the relevant stage skill (not this one, unless the orchestration itself was wrong).
- Did a stage's external dependency drift? (Amazon API, Workers cap, gist tooling.) Log it in that stage skill's own notes/evolution-log.
- Only update this SKILL.md for real, reproduced changes to the end-to-end flow.