Vibe Screenshot

Create store-ready screenshots by separating product truth from marketing presentation. The app UI inside the device must be real; the outer frame, background, titles, and labels can be composed.

Core Principles

• Write artifact prose in the user's language; keep paths, commands, code IDs,

locale IDs, bundle IDs, filenames, and quoted UI text unchanged.

• Treat screenshot work as a reproducible pipeline, not a design one-off.
• Never fabricate the in-device product UI with image generation, hand-drawn

mockups, screenshots cropped from old composed images, or ad hoc static replicas.

• Use app-owned debug/demo launch scenarios, fixture data, or local mock

services to make the real UI deterministic.

• Compose only the outer marketing layer: canvas, background, title, subtitle,

device frame, badges, and crop/scale placement.

• Keep raw captures and final composed images separate.
• Validate every image visually and mechanically before calling it usable.
• Preserve old output directories for comparison unless the user explicitly

asks to overwrite them.

• Avoid claims the product cannot support, especially medical, financial,

legal, safety, or measurement claims.

Workflow

1. Define The Screenshot Set

Read the current listing, user goal, existing screenshots, app capabilities, and repo instructions. Decide:

• target store or channel;
• required dimensions and device families;
• locales;
• screenshot count and order;
• output version, such as telo-v7; if the user did not provide one, ask for

it before creating screenshot artifacts;

• primary conversion story for the first three screenshots;
• required features that must appear later in the set;
• copy constraints, claim boundaries, and regulated-domain risks.

If the work is for iOS App Store screenshots, read [references/ios-app-store-screenshots.md](references/ios-app-store-screenshots.md).

2. Map Each Shot To A Real UI State

For each screenshot, define:

• outer title, subtitle, and optional badge;
• real app screen or flow to capture;
• fixture data or mock backend state;
• launch argument, route, URL, seed, or scripted interaction;
• locale and device;
• raw filename and final filename.

If a desired state does not exist, add a debug-only scenario or seed path that renders the real app screen with deterministic data. Do not create a fake UI that only exists for the screenshot.

3. Capture Raw Product Screens

Capture raw images from the running app. Store artifacts under features/screenshots/<version>/, with raw captures in features/screenshots/<version>/raw/ and final composed images directly under features/screenshots/<version>/:

• use simulator, emulator, browser, or real device screenshots as appropriate;
• avoid status interruptions such as permission sheets, push prompts, toasts,

loading spinners, cursor focus, or debug overlays;

• mock or pre-grant permissions only through test/demo infrastructure;
• store raw files under the versioned raw/ directory.

Keep evidence that the raw captures came from real app UI, such as launch arguments, UI tests, simulator commands, Playwright screenshots, or test logs.

4. Compose The Marketing Layer

Use the project’s existing generator when available. Otherwise create a small deterministic script that:

• reads only raw captures as phone/app content;
• writes final images to features/screenshots/<version>/;
• logs actual font paths for localized typography;
• uses stable dimensions, crop boxes, and device-frame geometry;
• fails when any required raw file is missing;
• never reads from previously composed output as app content.

Prefer standard parsers and image libraries already present in the project. Keep the generator configurable but not over-abstracted.

5. Validate

Run focused validation:

• scenario/UI tests prove every new debug state starts and shows core fixture

text;

• generator smoke test succeeds;
• all output dimensions match store requirements;
• raw and final images are visually inspected;
• mechanical duplicate checks compare raw screenshots that should tell different

stories and flag near-identical pairs for human review;

• localized copy fits, uses the intended fonts, and follows locale spacing

rules;

• the in-device UI is real and unobstructed;
• final claims match implemented product behavior.

Use vibe-test when validation evidence should be saved.

6. Report

Report:

• version used;
• final output directory, normally features/screenshots/<version>/;
• raw input directory, normally features/screenshots/<version>/raw/;
• changed source files and generated files;
• validation commands and results;
• manual visual QA summary;
• remaining risks or shots needing human approval.

Failure Recovery

• If a system permission sheet appears, fix the debug scenario or fixture setup;

do not crop it away.

• If a shot needs a feature that does not exist, revise the copy or implement a

real debug/demo state; do not hand-draw the feature.

• If localized text overflows, adjust copy, font size, layout, or screenshot

order, then regenerate from raw.

• If output was generated from old composed images, discard it and regenerate

from raw captures.

• If a validator does not cover visual truth, add manual visual QA notes and a

focused smoke test for the scenario.

Skill Signature

Always end the final response with:

Vibe Skill Signature
Skill: vibe-screenshot
Status: Completed | Passed | Failed | Blocked | Partial
Next: concise next workflow step