Stats

Actions

Available In

Tags

photography-workflow

A five-step intake pipeline for commercial-photography catalogs, expressed as five self-activating skills. Built for a working photographer running a sales platform: every photo that ends up on a "buy this print" page has been through metadata enrichment, a quality gate, a property/trademark/copyright audit, a model-release audit, and a publish step — in that order, with no step skipped.

The pipeline

Skill

Question it answers

Output

photo-metadata-helper

What is this photo of, where, and who?

IPTC title / description / keywords / PersonInImage embedded; file renamed from a hyphenated title

quality-review

Is it good enough — technically, editorially, and at print scale?

PASS / CONDITIONAL PASS / FAIL with one-line reasons; size restrictions if any

property-release-review

Is anything in the scene a rights concern (building, sculpture, mural, branded venue, trademark)?

Bucket 1 / Bucket 2 / SOFT-FLAG / OK / EXEMPT per image, with FOP analysis where relevant

model-release-review

Does anyone in the frame need a signed model release?

HARD-FLAG / SOFT-FLAG / OK / EXEMPT keyed to identifiability-to-the-public, with stricter bars for children and workers-at-workplace

reviewed-photo-publish

Catalog entry, sales-platform listing, intake-queue cleanup — only acts on photos that cleared every upstream step

Stripe product + child prices per supported size; file moved to published location; original archived; intake queue cleaned

Each skill's SKILL.md declares its position in the pipeline. Order matters: quality runs before legal so rights-clearance effort isn't spent on photos that won't make it; property runs before model because property/trademark concerns are usually dispositive regardless of model status. A FAIL or Bucket-1 at any upstream step short-circuits the rest of the pipeline for that photo.

For audit-only sweeps of an already-published catalog, any single skill can be invoked standalone.

Diagram

flowchart TD SRC([Admin panel upload queue — or — input directory]):::source SRC --> S1[1. photo-metadata-helper IPTC · rename · PersonInImage]:::step S1 --> S2{2. quality-review} S2 -- FAIL --> H1[/Hold for re-edit or drop user decides/]:::halt S2 -- PASS / CONDITIONAL PASS --> S3{3. property-release-review} S3 -- Bucket 1 --> H2[/Remove + archive property concern dispositive/]:::halt S3 -- Bucket 2 --> P[Mark portfolio-only no Stripe at step 5]:::mark S3 -- OK / EXEMPT --> S4{4. model-release-review} P --> S4 S4 -- HARD-FLAG · no release --> H3[/Hold for release or drop/]:::halt S4 -- OK / EXEMPT / release on file --> S5[5. reviewed-photo-publish dry-run preview]:::step S5 --> SO{Per-photo sign-off in current turn?}:::gate SO -- No --> H4[/Halt; surface partial state/]:::halt SO -- Yes --> LIVE[Stripe product + sized prices file moves · archive · queue removal]:::live LIVE --> RPT([Final report: verdicts · dispositions · what shipped]):::report GATE[[1024-gate · every image read load-bearing safety rule]]:::rule GATE -.-> S1 GATE -.-> S2 GATE -.-> S3 GATE -.-> S4 GATE -.-> S5 classDef source fill:#eef,stroke:#446,stroke-width:1px; classDef step fill:#efe,stroke:#363,stroke-width:1px; classDef gate fill:#fee,stroke:#933,stroke-width:2px; classDef halt fill:#fdd,stroke:#933,stroke-width:1px; classDef mark fill:#ffe,stroke:#663,stroke-width:1px; classDef live fill:#dfd,stroke:#363,stroke-width:2px; classDef report fill:#eef,stroke:#446,stroke-width:1px; classDef rule fill:#fef,stroke:#636,stroke-width:1px,stroke-dasharray: 4 2;

The two red-bordered nodes — the 1024-gate and the per-photo sign-off — are load-bearing safety rules. Everything else can be tuned; those two stay.

Two rules that show up in every skill

1. The 1024-gate. Before reading or classifying any image, downscale to 1024px on the long edge and view the downscaled copy. If the resize fails, HALT and ask — never fall back to the full-resolution original. This block is duplicated in every skill on purpose: it once prevented a session from burning ~137M tokens reading full-res photos, and inlining it is the only way to be sure it survives partial loads, refactors, and skill-level edits. Treat it as load-bearing safety code, not boilerplate.