Help us improve
Share bugs, ideas, or general feedback.
From pika
Generates 5–6 App Store screenshots from a brand spec, product screenshots, or a live App Store listing via Pika MCP. Outputs story-driven 1290×2796 PNGs ready for App Store Connect.
npx claudepluginhub pika-labs/pika-plugins --plugin pikaHow this skill is triggered — by the user, by Claude, or both
Slash command
/pika:app-store-screens <brand-md-or-brand-spec-or-app-store-url> [product-screenshots-or-figma-url] [reference=<url-or-path>] [count=5|6] [--quick] [--config <path>]<brand-md-or-brand-spec-or-app-store-url> [product-screenshots-or-figma-url] [reference=<url-or-path>] [count=5|6] [--quick] [--config <path>]The summary Claude sees in its skill listing — used to decide when to auto-load this skill
Take a brand plus real product screens and produce a 5–6 screen App Store campaign at iPhone 6.9" size (1290×2796). The product screens can come from raw exports, Figma/source files, or a public App Store listing fetched through Pika MCP. Story-driven, splashy, strict to the brand.
Creates, revises, translates, crops, validates, and prepares App Store marketing screenshots via a workspace workflow. Useful for building `.appstore-screenshots` assets from app inspection and install-promise copy.
Generates cinematic 1080p iOS app teaser videos from App Store screenshots, enhanced with GPT-image-2. Sources screens from App Store, websites, or user files, and outputs a beat-driven teaser with brand logo and COMING SOON overlay.
Generates App Store/Google Play promotional screenshots in Pencil (.pen) format using 5-agent team for strategy, Pencil design, copywriting, spec validation, and quality review. Use for app promo images.
Share bugs, ideas, or general feedback.
Take a brand plus real product screens and produce a 5–6 screen App Store campaign at iPhone 6.9" size (1290×2796). The product screens can come from raw exports, Figma/source files, or a public App Store listing fetched through Pika MCP. Story-driven, splashy, strict to the brand.
This is a sister skill to build-a-brand — it consumes that skill's brand.md spec, but works equally well with any brand spec the user supplies.
5 or 6 PNGs, numbered, saved to ~/Desktop/[app-name]-app-store-screens/ (or wherever the user prefers):
01_hook.png ← biggest claim, works as a search-result thumbnail
02_value.png ← the one thing the app does best
03_feature_a.png ← specific capability
04_feature_b.png ← another specific capability
05_proof.png ← social proof, awards, "loved by", differentiator
06_close.png ← optional 6th — closer / CTA / brand flourish
Plus a contact sheet (_preview.png) showing all 6 at a glance.
If invoked with empty args and no usable brand/screenshot/demo context, print this menu verbatim and stop. Do not generate imagery or render HTML until the required inputs are present.
What App Store screenshot set should I make? Required:
- Brand spec —
brand.mdor 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: trueand provide what the fake app doesOptional: reference App Store screenshot, moodboard, preferred screen count (5 or 6), output folder.
In interactive mode, if the user has supplied partial input, ask only for the missing required items and stop. If the non-interactive fast lane applies, use Step 0.5 instead. Required inputs:
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 approvaldemo_mode: true with demo_brief is an alternative to real product screenshots; use the Fictional app demo mode path belowUse this path when the caller passes --quick or --config <path>, or when the
caller states they are running from CI, a subagent, a batch job, or any other
non-interactive harness.
This section has precedence over the interactive ask/wait instructions below. When it applies, use this fast lane and do not fall through to the multi-turn intake unless the required brand and either product screenshots or explicit demo mode inputs are truly unavailable.
--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.--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.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.Use this only when the caller explicitly says this is a fictional app, fake app,
launch demo, concept demo, or passes demo_mode: true in config. Do not use demo mode for real products.
Demo mode is allowed to create representative UI mocks in the brand voice when no real product screenshots exist, but the output must be labeled as demo-only concept work, not production assets. Treat the invented screens as a storyboarded QRT/demo artifact, not App Store Connect-ready evidence of a real product.
demo_brief or enough user-provided product concept detail to define
the app's core job, audience, 3-5 features, and proof/CTA angle.demo_mode: true and
provides demo_brief; otherwise stop with a compact missing-fields list.In interactive mode, when the required inputs are present, open with a brief agenda and ask one upfront style question. This is the cheapest moment to learn whether the user wants the default or a specific reference. In the non-interactive fast lane, choose the default style unless reference or style is supplied, record that assumption inline, and continue.
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.
Why no "jazzed up" auto-mode. Doing rich/varied/dramatic compositions well requires visual-judgment calls (perspective, layering, typography hierarchy, color balance) that don't have a programmatic answer. When users want richness without a reference, my approximations tend to look amateur. Asking for a concrete reference lets me extract specific rules to replicate instead of inventing freely — and the user has a way to verify i'm aiming at the right thing.
Two downstream paths based on the answer:
references/default-layout.md end-to-end. Same composition skeleton on every screen; variety from color + content. This produces consistent, brand-disciplined work.If the user can't or won't supply a reference but still wants more than default, push back gently — explain that without a reference you'll deliver default plus their brand color, and that's better than a guessing-game iteration loop. Don't invent a "jazzed" style on the fly.
If the user supplies an apps.apple.com URL, numeric App Store app ID, or app-name search term as the product source, try Pika MCP mcp__pika__fetch_appstore_screens first because it is faster, more stable, and returns hosted screenshot/icon assets ready for later render steps:
fetch_appstore_screens(
query: <app_store_url | numeric_app_id | search_term>,
country: "us",
max_screens: 10,
include_icon: true
)
Use the returned metadata, icon, and screenshots as the product source. The returned screenshot url values are already Pika-hosted HTTPS assets and can be used directly in later mcp__pika__html_to_png stages.
If the user provided a country-specific App Store URL, preserve that storefront country when calling the tool when possible. If the country is unclear, default to "us" unless the user asked for another storefront.
If the MCP tool is unavailable, unauthenticated, or returns no screenshots, say what happened and then use the least fragile fallback available: other read/fetch tools, official App Store/iTunes metadata endpoints, or user-provided screenshots. Keep the fallback grounded in real listing assets; do not invent product UI.
Expected result shape:
{
"app_url": "https://apps.apple.com/...",
"metadata": { "name": "...", "subtitle": "...", "description": "...", "category": "...", "icon_url": "https://..." },
"icon": { "url": "https://cdn.pika.art/...", "source_url": "https://is...mzstatic.com/...", "filename": "appstore-icon.png", "mime_type": "image/png", "width": 1024, "height": 1024 },
"screenshots": [
{ "url": "https://cdn.pika.art/...", "source_url": "https://is...mzstatic.com/.../1290x2796bb.png", "filename": "appstore-screen-01.png", "mime_type": "image/png", "width": 1290, "height": 2796 }
],
"count": 1
}
After mcp__pika__fetch_appstore_screens, count usable screenshots that show real
product UI. If the listing returns fewer than 3 real product screenshots, treat it
as a thin App Store listing.
mcp__pika__capture_website or supplied
website/onboarding URLs to capture real product surfaces, then continue with
those captures as product screenshots.demo_mode: true with demo_brief.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.After fetching, infer only a draft brand read from the listing and visuals: app name, category, visible palette, likely type direction, voice from subtitle/description, and notable UI moments. In interactive mode, read it back as a provisional brand spec and ask the user to correct it before pitching the 5-6 screen arc. In the non-interactive fast lane, record it as the provisional brand spec and continue.
The reference describes WHAT THE LAYOUT/STYLE LOOKS LIKE. The brand describes WHAT COLORS/FONTS/VOICE/PHOTOGRAPHY TO USE. The skill's job is to combine them: replicate the reference's visual structure, but render it with the user's brand. Two things to extract from the reference, two from the brand:
From the reference, extract structural rules:
From the brand, apply specifics:
For generated hero imagery: pass the reference as reference_images to gpt-image-2. The tool supports up to 16 reference images. Use this when the reference uses a distinctive photo composition (hand-holding-phone, over-the-shoulder, person breaking out of screen, 3D character emerging). Combine with the brand's photography rules in the prompt:
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."
This is how you get the reference's STYLE without copying its CONTENT. The hand+phone composition transfers; the lighting/cast/setting comes from the brand.
Pitch the extracted rules back before designing in interactive mode. Write them out as a short bullet list ("device 75% canvas tilted -8°, headline-on-yellow-pill above device, over-the-shoulder hero, ink callouts with curved arrows") and confirm with the user that you read the reference correctly. In the non-interactive fast lane, record the extracted rules inline and continue. Then build all 6 screens applying those rules consistently. Don't deviate mid-campaign.
Then actually read:
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.mcp__pika__analyze_media to inspect screenshots without loading them as images, do — it's faster for a quick scan.Then read back what you found (3-5 lines, conversational):
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.
Interactive mode: wait for confirmation before pitching strategy. Catches misreads cheaply. In the non-interactive fast lane, treat the brand read as provisional, record the assumption inline, and continue to the strategy.
Before designing anything, write out the narrative arc as plain text. Each screen needs:
Present it like:
**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."
...
Interactive mode: ask the user to sign off on the arc before you generate or composite anything. Iterate on copy here — it's the cheapest moment to fix it. In the non-interactive fast lane, generate from the configured or inferred arc without stopping for signoff.
For any screen that calls for splashy background/hero imagery, generate it with mcp__pika__generate_image.
Defaults that work for App Store splash:
provider: gpt-image-2quality: medium for finished screenshots; low only when the user explicitly wants fast iterationaspect_ratio: 9:16 for full-bleed backgrounds (matches the iPhone canvas)gpt-image-2 to its 2K/4K tier (9:16 backgrounds support both) or escalate to seedream — surface the tradeoff and ask firstPrompt structure for brand-world imagery:
Reserve upper third for the headline. Tell the image model where the type will go so it leaves room.
Keep generated image URLs as HTTPS/CDN URLs for server-side rendering. If the user provides local product screenshots or background images, upload them with mcp__pika__upload_asset first and use the returned public_url; mcp__pika__html_to_png cannot read local file:// paths.
Write one HTML stage per screen, then render to PNG via Pika MCP mcp__pika__html_to_png. See references/render-pipeline.md for:
mcp__pika__html_to_png request shapeEach HTML stage should be exactly 1290×2796px. Use @font-face with HTTPS raw font URLs or inline data:font/... sources. Local brand-kit font files must be exposed through a public HTTPS URL or inlined; mcp__pika__upload_asset does not accept font mime types.
After each render, run a pre-delivery QA pass before accepting the PNG. Use
mcp__pika__analyze_media on the rendered image and inspect the authored HTML
positions when available. Reject and rerender any screen whose text block
bounding boxes put load-bearing headline, eyebrow, subhead, CTA, or product UI
outside the safe content area documented in references/render-pipeline.md.
Once all 6 PNGs render cleanly:
_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.file_url. If you also saved local copies, include those local paths separately.Do not report the screenshot set complete until _preview.png exists and is
included in the delivery. If the contact sheet render fails, fix the sheet HTML
or rerender the missing PNGs first; do not deliver only the individual PNGs and
call the campaign finished.
Use one per screen. Don't stack devices. One bold idea per screen.
See references/layout-archetypes.md for full CSS skeletons and visual examples. Quick reference:
App Store headlines are tested in a tiny window. They must:
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.Banned (these are the App Store equivalent of "crafted with love"):
If the headline could appear on 500 other apps without anyone noticing — rewrite.
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.The raw screens can come from anywhere — an App Store listing fetched through Pika MCP, a Figma frame, a Sketch export, a simulator screenshot, or local files. If the source is an App Store URL/app ID/app name, use the App Store listing path above. If the source is Figma and you have Figma MCP access:
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.Before delivering, do the squint test:
These anchors keep the generated campaign legible and on-brand:
| Phrase | Where | Why load-bearing |
|---|---|---|
vertical composition with negative space in upper third for headline | Brand-world image prompts | Leaves usable space for real App Store headline type instead of forcing text over busy imagery. |
The device is the hero — type is the caption | Visual standards | Prevents poster-like screens where copy overwhelms the product UI. |
Apple safe zones | Visual standards / render QA | Keeps critical claims clear of status-bar and App Store overlay areas. |
no text, no logos | Generated background prompts | Avoids unusable generated typography; real copy is added in HTML. |
Pick one: bleed OR full-frame | Device layout rule | Prevents the half-cut rounded-corner crop that looks like a rendering bug. |
The final screenshots should be deterministic HTML/CSS composites rendered through mcp__pika__html_to_png, because App Store copy, device masks, safe zones, and brand typography need exact control. Use gpt-image-2 only for splash/background/brand-world imagery where generation adds visual richness; keep real product UI as screenshots. Bump gpt-image-2 to its 2K/4K tier (or escalate to seedream) only when a specific generated background genuinely needs higher resolution than 1K.
Typical run time is 10-25 minutes, depending on how much user confirmation is needed:
| Step | Wall clock | Notes |
|---|---|---|
| Intake + style choice | 1-5 min | User-paced if a reference is needed |
| Brand/screenshot read | 2-5 min | Includes visual inspection and feature mapping |
| Strategy pitch | 2-5 min | Best place to iterate copy cheaply |
| Image generation | 2-8 min | Only for backgrounds or reference-driven hero imagery |
| HTML composite + render | 5-10 min | Six 1290x2796 PNGs plus contact sheet |
| QA revisions | variable | Copy tweaks are cheap; new imagery is slower |
| Symptom | Cause | Fix |
|---|---|---|
| Screens look like six variants of the same layout | Default skeleton was repeated without enough content contrast | Reassign layout archetypes and rotate focal weight, color, and screenshot choice |
| Headlines are illegible in contact sheet | Type is too small for App Store thumbnail use | Increase headline size, shorten copy to 5-8 words, and rerender |
| Generated background contains text or fake UI | Prompt over-described brand/product specifics | Regenerate with a no-text/no-logo guardrail and reserve the real UI for screenshots |
| App Store listing has fewer than 3 usable screenshots | Thin App Store listing, often a companion app or early listing | Use the website-capture path, ask for real screenshots, or stop. For fictional launch-demo concepts only, use Fictional app demo mode with demo_mode: true, demo_brief, and the demo-only disclosure |
| Fictional app has no real product screenshots | Launch-demo concept needs representative UI, but production rules forbid hallucinated UI | Use Fictional app demo mode only with demo_mode: true, a concrete demo_brief, representative UI mocks, and a demo-only disclosure |
| Load-bearing text appears too close to the top or bottom edge | Safe-zone QA was skipped or checked only the rendered look, not text block bounding boxes | Reject and rerender with text block bounding boxes inside the strict safe-zone margin |
| Device corners look uneven | Source screenshot already contains background in the rounded corner area, or CSS radius does not match the source | Ask for transparent/high-res source exports, use a real mockup cutout, or apply one consistent CSS mask and visually QA. A server-side uniform corner cleaner is still a tool gap. |
| Brand feels generic after hiding the screenshots | Surrounding design ignores brand.md voice, palette, or imagery rules | Rebuild the screen shell from the brand spec before rerendering |
| Render is blurry or scaled | Stage dimensions or raster options are wrong | Verify 1290x2796 stage size and mcp__pika__html_to_png viewport_px:1290x2796, device_scale:1 |
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).demo_mode: true with a concrete demo_brief.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.