pika-labs/pika-plugins6 files

App Store Screens

>

Specification
Skill ID
pika-labs/pika-plugins/app-store-screens
Publisher
pika-labs
Repository
pika-plugins
Installs
0
Files
6
Synced
Sep 23, 2026
How to use it

Open any RiverX project, open the Skills panel in the chat, and search for this identifier. The files are fetched from the source repository at install time.

pika-labs/pika-plugins/app-store-screensInstalls these files
  • SKILL.md
  • references/default-layout.md
  • references/fonts.md
  • references/layout-archetypes.md
  • references/mac-app-layout.md
  • references/render-pipeline.md

What this skill tells the agent

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):

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.

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.

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.

Use this skill in a project

Open any RiverX project, search the Skills panel for pika-labs/pika-plugins/app-store-screens, and install it in one click.

Use this skill