Appstore Assets

App Store Assets

Turn an app's codebase or landing page into an upload-ready App Store asset set: screenshots for each required display class plus optional creative assets, rendered from HTML by headless Chrome and verified against Apple's specs. Prime directive: show only what the shipped app does. Never invent UI, features or claims (App Review Guideline 2.3).

Terms used throughout:

• asset set: <out>/ holding src/, one folder per display class, creative/, sheets/ and PLAN.md.
• display class: iphone-6.9, iphone-6.3, ipad-13 or mac.
• grounded screen: a recreated screen whose elements trace to a cited view (path:line) or a landing-page image.
• clean capture: a real screenshot that passes the checklist in references/input-discovery.md.
• overclaim: anything a frame shows that the shipped build cannot do.
• pre-authorized run: the request fixes the direction, frames and UI source, or delegates them ("just build it", "pick whatever looks good", "don't ask").

When to Use

Use when someone needs App Store screenshots or header/search creative assets for an iPhone, iPad or Mac app, from its code or landing page, or wants an existing asset set edited and re-rendered. Not for listing copy, review audits, app icons, preview videos, or Google Play assets.

Workflow overview

Step 0 branch → 1 discover → 2 refresh specs → 3 plan and approve → 4 build → 5 render and verify → 6 review → 7 hand off. After each step, print a Step Completion Report: √/× rows tied to commands, files or counts, then Result: PASS | FAIL | PARTIAL.

Step 0 — Select the branch

Prerequisites: run python3 <skill>/scripts/render.py --preflight. It requires Pillow and Chrome or Chromium and prints the fix for a missing one (use the project's venv when it has one). If it fails, report BLOCKED. Without the Agent tool, run Steps 1 and 6 inline and say so. For a landing page, confirm the user publishes the app before building; never make assets for someone else's app.

Repo Sync Before Edits (mandatory)

Before the first write of Step 4 (the backup included), sync the repo that will hold <out>. Skip it, and record why, when that folder is not in a git repo or the repo has no origin.

repo="$(git -C "<existing parent of out>" rev-parse --show-toplevel)"; branch="$(git -C "$repo" rev-parse --abbrev-ref HEAD)"
[ -n "$(git -C "$repo" status --porcelain)" ] && git -C "$repo" stash push -u -m appstore-assets-presync && stashed=1
if git -C "$repo" fetch origin && git -C "$repo" pull --rebase origin "$branch"; then sync=ok
elif [ -d "$repo/.git/rebase-merge" ] || [ -d "$repo/.git/rebase-apply" ]; then git -C "$repo" rebase --abort; sync=conflict
else sync=failed; fi
[ "${stashed:-0}" = 1 ] && git -C "$repo" stash pop

sync=failed (network, auth, missing branch): record it and continue. sync=conflict: write nothing and ask the user how to continue. This skill never commits, pushes or uploads.

Dependency Preflight (mandatory)

This skill optionally invokes frontend-design (Step 3), emil-design-eng (Step 6) and browse (landing-page fetch), declared in frontmatter dependencies. Before Step 1:

command -v asm >/dev/null || echo "asm not installed: npm install -g agent-skill-manager"
asm deps discover "<this skill's directory>" --json
printf 'aa_session=%s\n' "appstore-assets-$(date +%s)-$$"   # record it; reuse it verbatim

At a dependency's first use, run asm deps acquire <reference> --session <aa_session> --json with its frontmatter reference, and read the returned skillMdPath. Without asm, look for ~/.claude/skills/<name>/SKILL.md or ~/.agents/skills/<name>/SKILL.md. Never acquire a dependency whose step is not reached. At the end, including an early stop, run asm deps release --session <aa_session> --json. All three are fail-soft: without frontend-design or emil-design-eng, use references/design-direction.md and note it under Uncertainty; without browse, use the host's web-fetch tool.

Step 1 — Discover (explorer subagent)

Spawn the explorer. Input: agents/app-explorer.md, references/input-discovery.md, the input path or URL, and whether browse is available. Output: the app brief JSON. Do not read the source tree yourself in this step; the explorer keeps it out of your context budget.

Bar: every platform carries evidence and every screen has a source. If stop_reason is set, take the Stop branch.

Step 2 — Refresh Apple's specs

Fetch the three source URLs in references/apple-specs.md and compare the required classes and sizes. The kit's sizes are fixed in render.py and check_assets.py, so if a class changed, render only the unchanged classes, report PARTIAL, and list each difference. If the fetch fails, use the snapshot and record its date under Uncertainty.

Bar: each platform's required display class and pixel size are named.

Step 3 — Plan and approve

Read references/apple-guidelines.md and references/design-direction.md. Acquire frontend-design and apply its Design Thinking to the marketing canvas only, with the app's brand as the explicit brief.

1. Choose 3–10 frames. The first three carry the core promise.
2. Give each frame a two-line headline, an optional supporting line, and one screen.
3. Choose each screen's UI source: a clean capture first, then a grounded screen. If neither exists, drop the frame.
4. Remove every overclaim. For sensitive features, reuse the brief's approved_wording.
5. Ask one combined question: direction (2–3 options), frame list, UI source, extras (creatives, preview page).
6. If the run is pre-authorized, state the plan in one line and continue. Extras stay off unless requested.
7. If the brief has no screens (no readable views and no page UI), ask for simulator captures instead.

Bar: the plan is approved or pre-authorized, and nothing was written before that. If the run ends unanswered, report BLOCKED with the pending question as the Decision.