Use when the user asks for app store screens or a task matching the examples below. Generate 5–6 App Store screenshots in a given brand's aesthetic from a `brand.md`, raw product screenshots, or a public App Store listing fetched through Pika MCP. Story-driven (hook → value → features → proof → clos

App Store Screens 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. Cost transparency gate Before any paid MCP call, call identity balance({verbose: true}) once. Surface the current balance, recent burn rate, and remaining runway, then gate the run with this exact message: Estimated cost: about 150 300 credits (~$1.50 $3.00) for a typical 5 6 screen set using GPT image 2, PNG renders, post render analyze media QA, and full resolution individual PNG QA. This is below $5, but Reply proceed to continue or cancel to stop. Do not call any paid MCP tool until the user replies proceed . If the user replies cancel , stop without generating. For non interactive quick or config callers, require cost ack=proceed in the config; if it is absent, stop with the estimate instead of spending credits. The deliverable 5 or 6 PNGs, numbered, saved to ~/Desktop/[app name] app store screens/ (or wherever the user prefers): Plus a contact sheet ( preview.png ) showing all 6 at a glance. Workflow Step 0 — Intake and style choice 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.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. 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 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 Step 0.5 — Non interactive fast lane Use 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. 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. Fictional app demo mode 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. 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. 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. 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: 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. 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. Step 1 — Read the brand and the product App Store listing path 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 fetch appstore screens first because it is faster, more stable, and returns hosted screenshot/icon assets ready for later render steps: 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 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: Source screenshot prep Before choosing the default phone layout, classify each fetched or user supplied source screenshot and record the source treatment you will use: clean ui capture raw in app UI suitable for a device mockup. composed marketing a finished App Store marketing screen, not a clean in app screenshot. legacy footer cleanup clean UI that only needs listing brand footer or watermark cleanup before device embedding. A composed marketing source is a pre composed marketing screen. Common signals: a baked headline or subhead already sits above the phone, the phone bleeds or clips against the source edge, the background is already campaign art, and the source image is already a finished 1290x2796 App Store screen rather than clean product UI. The 2025 Notion listing uses this pattern. When a source is composed marketing , do not reframe it inside another device mockup and do not add, write, or generate a second headline/subhead on top of the baked headline. Prefer a clean ui capture instead: use capture website on the product website, onboarding, or web app when a captureable real UI surface exists, or ask for simulator/Figma/raw UI exports. If no clean UI surface is available, use source treatment=composed passthrough : present the composed source as is as the screen/background with only minimal delivery framing, numbering, or contact sheet labeling. Do not rely on a bottom 6 8% crop to fix composed sources; it removes the wrong area and leaves the double headline failure intact. For legacy source screenshots that are otherwise clean UI, inspect them for footer watermark bleed or listing brand footers that will become clutter inside the generated campaign. The R4 Notion listing exposed this as a raw footer reading NOTION · NOTES, TASKS, AI overlapping the bottom content. If a fetched or user supplied clean UI source screenshot has this kind of footer watermark, crop or mask the bottom 6 8% before embedding it; do not place the raw screenshot directly into the device. Use a prepared screenshot wrapper in the HTML stage and keep the top of the source anchored. The wrapper must define its own geometry; do not rely on height:100% unless every parent up to the device has an explicit height. If an 8% crop would remove real product UI, use a brand color fade over the bottom footer instead, but still remove the watermark bleed before the screenshot enters the final device mockup. Handling Mac app or hybrid app screenshots fetch appstore screens may return landscape Mac screenshots (for example 1290×806) instead of iPhone portrait screenshots (1290×2796) for Mac only or hybrid iOS/Mac apps such as Things 3, Drafts, Numbers, Day One, OmniFocus, or BBEdit. Detect this before choosing the default iPhone portrait layout: The orientation rule is aspect ratio w aspect ratio h , or width height when only pixel dimensions are present. If mac shots is non empty, use the embedded card layout in references/mac app layout.md rather than full frame device shots. For Mac only or hybrid apps, embed each landscape screenshot as a rounded corner UI card inside the 1290×2796 portrait canvas rather than cropping it into an iPhone frame, letterboxing it, or treating it as a full frame device. The Things 3 round 2 benchmark validated this approach: the Mac screenshots stayed readable and the portrait campaign still fit App Store Connect. Source screenshot prep still applies to Mac cards: inspect landscape screenshots for listing brand footers or footer watermark bleed before embedding them. Do not use the phone portrait crop on Mac UI. Keep the landscap

app-store-screens