What App Store screenshot set should I make? Required:

• Brand spec —

  brand.md

  or equivalent brand notes with name, palette, fonts, voice, and imagery direction; or an App Store URL/app name if you want me to fetch the listing and draft the brand read first
• Raw product screenshots — exported PNGs, a Figma/source file that can export them, a folder of screenshots, or an App Store URL/app name I can fetch with Pika MCP
• Or a fictional app demo brief — only for launch demos/concepts where no real product exists; say

  demo_mode: true

  and provide what the fake app does

Optional: reference App Store screenshot, moodboard, preferred screen count (5 or 6), output folder.

• brand.md

  or an equivalent brand spec with name, palette, fonts, voice, and imagery direction; if the user gives an App Store URL and asks you to "help create it", fetch the listing first and draft an inferred brand spec from the listing/icon/screenshots for approval
• one product source: raw product screenshots, a Figma/source file that can export them, or an App Store URL/app name that can be fetched through Pika MCP
• for fictional launch demos only,

  demo_mode: true

  with

  demo_brief

  is an alternative to real product screenshots; use the Fictional app demo mode path below
• optional reference screenshot or moodboard if they want a specific App Store style

--quick

--config <path>

• --config <path>

  points to a JSON file with pre-baked choices:

  brand_spec

  ,

  product_screenshots

  ,

  app_store_url

  ,

  website_url

  ,

  reference

  ,

  style

  ,

  screen_count

  ,

  narrative_arc

  ,

  demo_mode

  ,

  demo_brief

  , and

  output_folder

  .

• --quick

  means choose the default style unless a reference is supplied, infer the brand read from the provided brand spec or App Store listing, draft the 5-6 screen arc yourself, and proceed.
• For

  --quick

  or

  --config

  , do not stop for confirmation at the style choice, brand-read playback, reference-rule playback, or 5-6 screen strategy pitch. Record assumptions inline and continue to design/render.
• If neither real product screenshots nor explicit

  demo_mode: true

  with

  demo_brief

  is available, stop once with a single compact missing-fields list instead of starting a multi-turn Q&A loop.

demo_mode: true

• Require a

  demo_brief

  or enough user-provided product concept detail to define the app's core job, audience, 3-5 features, and proof/CTA angle.
• Generate UI states that are internally consistent with that brief; do not imply real customers, real reviews, real metrics, or real integrations unless the prompt explicitly provides them.
• Add a demo-only disclosure in the delivery notes and contact sheet label: "Demo UI concept — not production assets and not real product screenshots."
• In non-interactive mode, proceed only if config sets

  demo_mode: true

  and provides

  demo_brief

  ; otherwise stop with a compact missing-fields list.

reference

style

here's how this works:
1. **Read your brand + screenshots** — i absorb the brand voice, palette, type, and figure out what the app actually does
2. **Strategy** — i pitch a 5–6 screen narrative arc (hook → value → features → proof → close) with headlines for each, before any design
3. **Design + generate** — i design each layout, composite at 1290×2796
4. **Preview** — i deliver the PNGs + a contact sheet so you can see the whole campaign at once

quick question before i start — **do you want the default style, or something specific?**

- **Default** — clean, restrained, screens shown untouched. Full-frame device, headline + sub above, solid brand-color backgrounds, brand-voice copy. Codified in `references/default-layout.md`. This is what i deliver well.
- **Something specific** — share a clear reference: a screenshot of an App Store page you love (Notion, Calm, Things, Headspace, anything), a figma file, a moodboard image. I'll study it, extract the compositional rules (device size + position, headline treatment, background, any signature flourishes), pitch back what i read before designing, then build the campaign — **with your brand's palette, fonts, voice, and photography style swapped in**. So if the reference uses an over-the-shoulder photo, i'll generate one in your brand's photo style (`gpt-image-2` accepts the reference as a style input). The reference dictates the composition; your brand dictates the look.

if you don't tell me, i'll go with default.

• Default → follow

  references/default-layout.md

  end-to-end. Same composition skeleton on every screen; variety from color + content. This produces consistent, brand-disciplined work.
• Replicate a reference → study the reference, extract the rules, swap in the user's brand. See "Reference-driven path" below for the full process.

mcp__pika__fetch_appstore_screens

• Do not create a 5-6 screen campaign by hallucinating UI. Real product UI is the default requirement for device frames.
• Interactive mode: stop before strategy and offer two choices:
  1. Website-capture path — use

     mcp__pika__capture_website

     or supplied website/onboarding URLs to capture real product surfaces, then continue with those captures as product screenshots.
  2. Real screenshot path — ask for simulator exports, Figma frames, or other product UI captures before continuing. Do not offer synthesized device UI for real products. If the user explicitly pivots to a fictional launch/concept demo, route to Fictional app demo mode and require

     demo_mode: true

     with

     demo_brief

     .
• Non-interactive fast lane: prefer the website-capture path when

  website_url

  or an obvious product website is available. If there is no captureable product surface, stop once with a compact missing-fields list unless config explicitly sets

  demo_mode: true

  and provides

  demo_brief

  .

• Device size (as % of canvas) and tilt angle
• Headline treatment (size, position, color logic — accent on key word? tinted bg pill?)
• Background treatment (solid color, photo, gradient, abstract elements)
• Hero imagery pattern (hand holding phone, over-the-shoulder, real subject breaking out of phone, 3D objects floating, etc.)
• Callout / pull-out pattern (speech bubbles with arrows, floating cards, polaroid frames, etc.)
• Repetition rules: same layout every screen, or varied per slot?

• Palette (substitute brand colors wherever the reference uses solid color blocks)
• Fonts (substitute brand display + body fonts everywhere the reference uses type)
• Voice (rewrite all headlines/subs in brand voice — don't copy the reference's words)
• Photography direction (any generated imagery follows the brand's photo rules — for DeltaStream that's documentary 35mm, golden hour, real apartments, butter accent in every frame, real cast diversity)
• Mood (warm vs. clinical, playful vs. expert, etc.)

reference_images

gpt-image-2

Reference: [user's reference photo — e.g., insect app's hand-holding-phone with butterfly]

Prompt: "In the EXACT composition and lighting style of the reference image — hand
holding a phone at the same angle and scale — but render the subject and scene
per [BRAND] photography rules: documentary 35mm, golden hour window light, real
apartment, butter-yellow ceramic mug visible, mid-30s mixed-race cast, 35mm film
grain. Vertical 9:16 portrait."

• brand.md

  — extract: brand name, tagline, palette (with hex), display font + body font, voice adjectives, voice examples, forbidden words, photography/illustration direction, mood words. If the file is a different format (PDF, plain notes), parse what's there and ask about gaps in interactive mode. In the non-interactive fast lane, record reasonable assumptions for non-critical gaps — don't invent a brand.
• Product screenshots — open each one and form an honest mental model: what does this app actually do? Note the core UI patterns (feed, chat, canvas, list, map, etc.), the primary action surface, and any "wow moment" screens (a generative result, a beautiful state, a unique interaction).
• If you can use

  mcp__pika__analyze_media

  to inspect screenshots without loading them as images, do — it's faster for a quick scan.

ok — reading [brand name]: [tagline]. palette: [colors]. voice: [adjectives]. the app looks like
it does [X] — i see [specific UI cue 1] and [specific UI cue 2]. the standout screen is [screen
N] because [reason]. correct me where i'm wrong, otherwise i'll pitch the 6-screen arc.

• Role (hook / value / feature / proof / close)
• Headline (5–8 words, in brand voice — see "Copy" below)
• Optional subhead (one short line)
• Layout archetype (see below — name it, don't draw it yet)
• Which raw screenshot it features (filename) — or "none, full-bleed typography"

**Screen 1 — HOOK**
Headline: "Sleep like you mean it."
Sub: (none — let the headline carry)
Layout: full-bleed UI with bold typography overlay
Featured screenshot: home_screen.png

**Screen 2 — VALUE**
Headline: "One tap. Then quiet."
...

mcp__pika__generate_image

• provider: gpt-image-2

• quality: medium

  for finished screenshots;

  low

  only when the user explicitly wants fast iteration

• aspect_ratio: 9:16

  for full-bleed backgrounds (matches the iPhone canvas)
• 1K is the default. If a screen genuinely needs higher res (e.g. a hyper-detailed background that gets blown up), bump

  gpt-image-2

  to its 2K/4K tier (9:16 backgrounds support both) or escalate to

  seedream

  — surface the tradeoff and ask first

1. Subject + composition ("a wide cinematic shot of a single ceramic mug on weathered oak…")
2. Brand palette as named colors ("limited to ink black #0E0E10, oat #F5F0E6, and a single accent of rust #C84B2F")
3. Light + mood ("soft overcast window light, slight film grain, documentary feel")
4. Negative cues ("no text, no logos, no people unless specified, no stock-photo gloss")
5. Aspect for 9:16 backgrounds: "vertical composition with negative space in upper third for headline"

mcp__pika__upload_asset

public_url

mcp__pika__html_to_png

file://

mcp__pika__html_to_png

references/render-pipeline.md

• The exact

  mcp__pika__html_to_png

  request shape
• Server-side asset/font rules
• Safe-zone guides
• Common gotchas (font loading, retina text sharpness, mid-curve crop)

@font-face

data:font/...

mcp__pika__upload_asset

mcp__pika__analyze_media

references/render-pipeline.md

1. Build a

   _preview.png

   contact sheet with

   mcp__pika__html_to_png

   — 6 thumbnails in a 3×2 grid at ~25% size, on a neutral background, labeled by role.
2. Present the contact sheet URL plus each individual screenshot

   file_url

   . If you also saved local copies, include those local paths separately.
3. Ask: anything to revise? Common revisions are copy tweaks (cheap) or layout swaps (medium) or new imagery (most expensive).

_preview.png

references/layout-archetypes.md

1. Floating device — tilted phone on a splash background. The workhorse. Best for value/feature screens.
2. Full-bleed UI — phone canvas fills the frame; typography overlays at top or bottom. Best for the hook.
3. Side-by-side — device on one side, generated lifestyle imagery on the other. Best for emotional features.
4. Parallax stack — phone in front, branded shape/imagery floating behind. Best for "wow moment" feature screens.
5. Quote card — big pulled quote with a small device tucked in a corner. Best for the proof screen.

• Be 5–8 words. Anything longer dies on a 6.1" phone in search results.
• Echo the brand voice exactly. If

  brand.md

  says voice is "dry, deadpan, never exclamatory," the headlines never end in

  !

  . If voice is "warm and a little teasing," the headlines have rhythm.
• Make a claim, not a description. "Sleep like you mean it" > "Track your sleep". "Built for one quiet hour a day" > "Productivity app".
• First two screens work as standalone thumbnails. Bigger type, clearest hook. App Store search shows the first 2-3 expanded; the rest only render if a user taps through.

• "Stay organized."
• "Your daily companion."
• "All-in-one [category]."
• "Designed to help you [verb]."
• "Track. Plan. Achieve."
• Anything with "seamlessly", "effortlessly", "powerful", "smart", "intelligent".

• The device is the hero — type is the caption. On a 1290×2796 canvas, the device should be 1050–1150px wide (≈ 81–89% of canvas). Anything smaller looks timid. Headlines support the screen content; they don't compete with it.
• Typography hierarchy. One thing dominates per screen — usually the device. Headline 100–140px Funnel-Display-class; subhead 36–44px; visible difference in weight and size. (Past 150px the headline starts fighting the device for the eye.)
• Skip SVG-stroke iPhone frames — they don't align with screenshot corners. Stroke-based SVG bezels sit half-inside/half-outside their path, and the radius/Dynamic Island proportions never quite match a real iPhone. Prefer transparent screenshot exports from Figma/simulator or a real iPhone mockup PNG with a transparent cutout. If only rectangular source screenshots are available, use a consistent CSS

  border-radius

  +

  overflow:hidden

  wrapper and visually QA the corners. The old local

  clean_phone_uniform()

  PIL recipe is now a documented MCP gap, not a default dependency.
• Pick one: bleed OR full-frame. Never mid-crop the bottom curve. Default is full-frame (device top at y=580 with width=1000, so the rounded bottom corners sit fully inside the canvas with ~48px breathing room below). Bleed variant (device top ≥ 819) pushes the rounded bottom corners entirely past y=2796 — useful for hook screens that want drama. Anything in between produces a visible half-cut curve where the canvas slices through the rounded corner mid-arc; this is the failure mode the rule prevents.
• Apple safe zones. Strict safe-zone rule: load-bearing text and product UI must stay inside y=180..2616. The top and bottom 100px bands are never for critical content, and the extra 80px buffer keeps App Store chrome, search-result cropping, and text ascenders from crowding the edge. Decoration is fine; critical claim and readable app UI are not.
• One bold device per screen. Massive type or generated imagery or a quote — not all three. Splashy ≠ chaotic.
• Color from the brand palette only. No new colors invented for the screenshots. If the palette feels too restrictive, that's the brand's problem to solve, not yours.

• get_screenshot(fileKey, nodeId)

  returns the rendered PNG of a node. This works without needing the user to select anything in the Figma desktop app.
• For a strip-of-phones layout, prefer asking for individual phone exports. If only a strip is available, crop manually from the design source or use a future server-side crop/clean tool when exposed; don't make local PIL cropping a default dependency of this skill.
• The natural render is usually at logical-pixel size (e.g. 393×852 per iPhone 15 Pro phone). When you scale this to the default 1000px device width on the App Store canvas, the upscale is acceptable for non-pixel-critical content. For tighter fidelity, ask if there's a higher-resolution export.

1. Squint at the contact sheet. Can you tell the 6 screens apart at a glance? (Different headlines, different layouts, different focal weight.) If they look like 6 versions of the same screen — redesign.
2. First-2-screens thumbnail test. Crop screens 1 and 2 to 25% size. Is the headline still legible? Is the hook still clear? If you have to lean in, the type is too small.
3. Brand-test. Cover the device on each screen. Does the surrounding design still feel like the brand? (Color, type, mood, voice in headlines.) If not, the screenshot is generic.
4. Anti-generic test (same as build-a-brand): could these screens belong to literally any other app in this category? If yes — rewrite the copy and rework the focal hierarchy.
5. Safe-zone audit. Check every rendered PNG and reject and rerender any screen with load-bearing text or product UI outside the safe content area.

• If they want a "jazzed up" version without supplying a reference → push back. Ask for a screenshot of an App Store page they love, a figma file, or a moodboard. Explain that without a reference, you'll deliver default plus their brand color, and that's better than guessing at "exciting." (This rule comes from real campaign work — auto-jazzing produced amateur output every time.)
• If they want a 10-screen campaign → push back. 5-6 is the sweet spot; more is fatigue.
• If the brand voice in

  brand.md

  is generic ("modern, friendly, intuitive") → flag it. You can still produce screens, but tell them the headlines will only be as distinctive as the voice spec. Offer to sharpen the voice first (it lives in

  brand.md

  's Voice & Tone section).
• If they have no real product screenshots and did not explicitly request fictional app demo mode → don't invent UI. Ask for screenshots, website/onboarding capture targets, or explicit

  demo_mode: true

  with a concrete

  demo_brief

  .
• If they don't have a brand at all → don't proceed on vibes. Route them to

  build-a-brand

  first, or have them write at minimum: name, palette hexes, display font, body font, one-line voice description.

• references/default-layout.md

  — the visual system the skill produces when the user supplies no reference. Read this first for any run. Codifies the headline-top + device-dominant + full-frame composition, color rotation, and squint-test checklist. This is what the skill delivers well.

• references/layout-archetypes.md

  — vocabulary list of layout patterns found in real App Store campaigns. Use only to analyze a user-supplied reference. Not a free-choice menu.

• references/render-pipeline.md

  —

  mcp__pika__html_to_png

  render request, server-side asset/font rules, safe-zone overlay, font-loading checklist, pre-delivery checklist.