agentleFS
Sign inStart free
agshinrajabovagshinrajabov/store-ready-kit/skills/store-assets/SKILL.md

store-assets

Skill1 starsChanged 41 days agoMITView on GitHub

Plans the App Store product page assets that decide whether people tap — the first three screenshots, the full screenshot narrative, caption copy, the icon brief and a 15–30 second app preview script — and checks the exported files against Apple's sizes and rules. Use when making or redoing App Store screenshots, captions, an app icon or a preview video, when conversion from search is low, or after store-audit / a 4.3 rejection says the store page looks like everyone else's. Plans in words first, lints the plan, then hands the visual pass to no-slop-design.

1 other project uses a version of this.

Adopted by

Most recently taken up by

  • Other versions1 project uses a version of this.

    Word for word · 0

    None found.

    Edited · 0

    None found.

    Wrote their own version · 1

    1. raaaf/claude-skills★ 0same name

    How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.

  • In this repository3 other files it gives its agents.

The file

We split this skill into the rules it gives an agent

5 rules. About 0 are common, 1 is distinctive, and 4 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈1

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 4

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Keep everything in assets/<date>/ at the project root (or a scratch folder with no project).

    line 26
  2. Very specific:

    Visual pass: write the hand-over to no-slop-design (plan, niche pattern, icon brief).

    line 45
  3. Very specific:

    File check: after export. In a planning turn, write "not run, no exports yet" and the command: python3 scripts/asset_check.py <screens…> …

    line 48
  4. Very specific:

    If the differentiator cannot be seen in a frame, the problem is the product or the UI, not the screenshots.

    line 69
  5. Distinctive:

    Prefer a caption-free frame 1 when the image is distinctive.

    line 71

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

store-assets

Decide what the product page has to say before anyone designs it, make the first three frames do the work, and make sure the files will upload.

Rules. Frame 1 is the app in use, never title art. Captions describe outcomes the frame can prove. No prices, rankings, "free", other platforms or other apps' names anywhere in the assets (2.3.7, 2.3.10). This skill plans and checks. It does not do the visual design. For the visual pass, run no-slop-design with this skill's plan and briefs.

Inputs

  1. What the app does and for whom. Its differentiator (from store-audit if it ran).
  2. The current screenshots, icon and any preview, if they exist.
  3. The competitor snapshot from store-audit (competitors.json), or run its competitor_scan.py.
  4. Words users use, from aso-research's review mining, if available.
  5. Supported devices (iPhone / iPad) and languages.

Workflow

Keep everything in assets/<date>/ at the project root (or a scratch folder with no project). Languages: if the user has not said, ask. If there is no answer, plan for the primary market's language and say so.

  1. Current assets (if any): describe the current frames as a plan, run plan_lint.py on it, and list what fails. That is the before picture.
  2. Three sentences: core outcome, differentiator, the user's doubt (references/screenshot-narrative.md, step 1).
  3. Niche pattern: take the 10 apps that rank highest on the app's most relevant search terms (not by rating count). Leave out apps from other categories. Describe their first three frames and icons as concepts, not pixels, and write down what they share. You need image URLs: firstScreenshots and artworkUrl512 in a snapshot from the current competitor_scan.py. If the snapshot is older and lacks them, re-run the scan, or ask the user for screenshots. If neither is possible, infer from descriptions, label every visual claim not observed, and have the user confirm the pattern by eye before the visual pass.
  4. Narrative plan: the moment map → frame order → captions (references/caption-copy.md). Write it as plan.json and run: python3 scripts/plan_lint.py --plan plan.json Fix every BLOCK. Rewrite captions that get a stock-phrase or feature-list warning.
  5. Icon brief: references/icon-brief.md. Include the niche pattern and how this icon departs from it.
  6. Preview script (optional, only if the first 3 seconds can be strong): references/preview-video.md.
  7. Visual pass: write the hand-over to no-slop-design (plan, niche pattern, icon brief). Run it only once real captures from the build exist. Otherwise the hand-over is the output. Say so plainly if it is not installed.
  8. File check after export. In a planning turn, write "not run, no exports yet" and the command: python3 scripts/asset_check.py <screens…> --icon icon-1024.png --platform iphone [--platform ipad]

Output: store-assets.md

  1. The three sentences.
  2. Niche pattern table (what competitors' first frames and icons share) and the one-line "how we differ".
  3. Screenshot plan: one row per frame with job, what it shows, real UI yes/no, caption, and word count. Then the plan_lint result line.
  4. Caption alternatives for frames 1–3 (two each), all passing the caption tests.
  5. Icon brief.
  6. Preview script, or the reason to skip a preview for now.
  7. Hand-over to the visual pass, and after export the asset_check result.
  8. Footer: Guidance based on public App Review Guidelines; Apple's decisions are their own.

Judgement

  • Frames that depend on UI you have not seen (a highlight, a locked state) are conditions the user must confirm in the build. List them. Never plan a frame showing UI the build does not have (2.3.1).
  • Caption test 4 (the user's words) needs review mining from aso-research. Without it, mark that test "not run".
  • If the differentiator cannot be seen in a frame, the problem is the product or the UI, not the screenshots. Say so, and send it back to store-audit.
  • Prefer a caption-free frame 1 when the image is distinctive. Use a caption when the outcome needs words.
  • Converge on what the market needs to see (readable outcome, real UI). Diverge in how it looks.
  • Localise captions per supported language in the user's words. Never add a language the app does not support.

References

  • references/first-three-screenshots.md: why three, what fails, formats and sizes
  • references/screenshot-narrative.md: the planner, step by step, and the plan format
  • references/caption-copy.md: outcome over feature, tests, voice
  • references/icon-brief.md: brief fields, niche comparison, review test
  • references/preview-video.md: Apple's rules, a 24-second structure, script template

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free