agentleFS
mocchaleramocchalera/mockup-to-code-skill/skills/photo-art-direction/SKILL.md

photo-art-direction

Skill0 starsChanged 4 months agoISCView on GitHub

Preserve source-specific photographic storytelling when planning, generating, reviewing, or implementing images for websites and mockups. Use with mockup-to-code or image generation when source subject relationships, gaze, environment, copy space, focal geometry, responsive crops, tone, or distinct semantic photo stories must survive instead of becoming generic substitutes.

The file

Show its rules and text

We split this skill into the rules it gives an agent

13 rules. About 0 are common, 9 are distinctive, and 4 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈9

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 4

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  • could be automatic: a setting could enforce it
  1. Distinctive:

    Treat each source photo as a spatial story, not a bag of visual keywords.

    line 8
  2. Very specific:

    Read the source and implementation constraints.

    line 12
  3. Very specific:

    Write each exact prompt to a UTF-8 file.

    line 15
  4. Distinctive:

    Run the validator again before handing assets to mockup-to-code.

    line 20
  5. Distinctive:

    Keep declared copy spaces empty at every target viewport.

    line 26
  6. Distinctive:

    Keep responsive focal points attached to the named subject zone.

    line 27
  7. Distinctive:

    Keep tone concrete: lighting direction, palette, contrast, texture, era, and forbidden drift.

    line 28
  8. Distinctive:

    Keep each prompt receipt story-local.

    line 29
  9. Distinctive:

    Never mark a placeholder, missing file, unevidenced score, or all-rejected set as adopted.

    line 30
  10. Distinctive:

    Do not let aesthetic preference override a failed semantic or geometric check.

    line 31
  11. Very specific:

    Read references/photo-art-direction-v1.schema.json when creating or changing a plan.

    line 35
  12. Very specific:

    After exit 0, emit the parent manifest receipt from the mockup work root:

    line 52
  13. Distinctive:

    Do not weaken the schema or validator to make a candidate pass.

    line 64

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Photo Art Direction

Treat each source photo as a spatial story, not a bag of visual keywords. Freeze the story contract before generation, bind every candidate to the exact prompt receipt, and adopt only evidence-backed candidates.

Workflow

  1. Read the source and implementation constraints. Create one stories[] entry per semantically distinct source photo or photo field. Never merge stories to save generation calls or reuse one candidate for different stories.
  2. Record the source path and a verbatim source quote that explains why the photo exists. If no quote exists, keep the plan blocked; do not invent client intent.
  3. Map every subject as a normalized [0,1] zone. Record gaze, relationships, environment, copy spaces, tone, semantic cause-and-effect, and one focal point per responsive frame.
  4. Write each exact prompt to a UTF-8 file. Issue a pre-generation prompt-generation-receipt/v1 receipt. When mockup-to-code is available, prefer its scripts/prompt_receipt.py; otherwise emit the same receipt contract. Never cite a prompt that was merely consulted.
  5. Validate the plan before generation. Do not generate while the validator reports malformed data or unresolved placeholders. A valid pre-generation plan still remains incomplete until candidates are reviewed.
  6. Generate candidates only when the user authorizes image generation. Preserve identities only when permitted; otherwise preserve roles, relative geometry, gaze logic, and semantic relationships without claiming identity fidelity.
  7. Review every candidate against all seven axes: subject relationships, gaze, environment, copy space, focal geometry, tone, and semantic story. Record real candidate, comparison, review, and responsive evidence paths.
  8. Reject explicitly. A rejection needs at least one failed axis and concrete reasons. Adoption needs every axis passing, every responsive frame checked, copy-space intersections within limits, and exactly one adopted candidate per story.
  9. Run the validator again before handing assets to mockup-to-code. Keep originals and evidence; implementation derivatives do not replace review evidence.

Hard rules

  • Preserve relationships before isolated appearance: who looks at whom, distance, ordering, scale, gesture, and shared activity.
  • Preserve environment as story evidence. Do not replace a meaningful workplace, home, street, landscape, or object system with a generic backdrop.
  • Keep declared copy spaces empty at every target viewport. Do not solve collisions by shrinking the subject until the source hierarchy disappears.
  • Keep responsive focal points attached to the named subject zone; do not use one desktop crop as proof for mobile.
  • Keep tone concrete: lighting direction, palette, contrast, texture, era, and forbidden drift.
  • Keep each prompt receipt story-local. A candidate may reference exactly one receipt and one story.
  • Never mark a placeholder, missing file, unevidenced score, or all-rejected set as adopted.
  • Do not let aesthetic preference override a failed semantic or geometric check.

Contract and templates

  • Read references/photo-art-direction-v1.schema.json when creating or changing a plan.
  • Copy assets/photo-art-direction.blocked-starter.json to start. Its blocked state and placeholders are intentional.
  • Copy assets/candidate-review-decision.template.md for the human review record, then mirror the decision into the JSON plan.

Resolve relative paths from the plan file's directory. Use normalized geometry: x, y, width, height, and focal x, y all range from 0 to 1.

Validate

SKILL_ROOT="${SKILL_ROOT:-${CODEX_HOME:-$HOME/.codex}/skills}"
"$SKILL_ROOT/mockup-to-code/scripts/skill-pack-python" \
  "$SKILL_ROOT/photo-art-direction/scripts/validate_photo_art_direction.py" \
  path/to/photo-art-direction.json

The validator uses only the Python standard library and emits deterministic JSON. Exit 0 means a fully adopted plan. Exit 1 means malformed contract data. Exit 2 means structurally readable but honestly incomplete or blocked. Use --base-dir only when evidence paths intentionally resolve somewhere other than the plan directory.

After exit 0, emit the parent manifest receipt from the mockup work root:

SKILL_ROOT="${SKILL_ROOT:-${CODEX_HOME:-$HOME/.codex}/skills}"
"$SKILL_ROOT/mockup-to-code/scripts/skill-pack-python" \
  "$SKILL_ROOT/photo-art-direction/scripts/validate_photo_art_direction.py" \
  reports/photo-art-direction.json \
  --receipt --receipt-root .

Store the emitted {contract,path,sha256} at specialistReports.photoArtDirection. Blocked or invalid plans never emit a receipt.

Do not weaken the schema or validator to make a candidate pass. Fix the plan, prompt provenance, candidate, or evidence.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.