App-store presence, in your repo.
A free, open-source, cross-AI skill that walks any mobile-app repository,
learns how to run it, captures store-compliant screenshots, and assembles the
full App Store + Google Play listing — copy, metadata, and
graphics — stored in the repo as the source of truth.
-orange){kind=icon}
Shipping a mobile app means hand-producing a pile of store assets: correctly sized screenshots for several device classes, marketing copy under strict character limits, URLs, copyright, platform graphics. It's tedious, error-prone, and repeated on every release — and it's scattered across simulators, cropping tools, spreadsheets, and the store consoles. There's no single source of truth that lives with the code.
listing-kit makes the repo that source of truth. Store copy gets reviewed like code (PRs, diffs, history). Screenshots become regenerable, not hand-curated one-offs. And because everything is written in the fastlane convention, existing publishing tooling can pick it up with zero translation.
If a repo already has fastlane/ metadata, listing-kit uses it as the baseline.
Reruns should make focused edits for new features, missing fields, screenshots,
or validation failures, not rewrite good store copy just because the model can.
In git repos, listing-kit installs a pre-commit rule so any commit that stages
fastlane/** changes also refreshes and stages listing-review.html.
This is not "a screenshot tool." Screenshots are one artifact among several. The unit of value is a complete, version-controlled listing that stays in sync with the running app.
Point your agent at a mobile repo and listing-kit will:
- Detect the stack — native iOS, native Android, Flutter, or React Native / Expo.
- Doctor the environment — verify SDKs/toolchains before any build, fail fast with fixes.
- Discover & curate — enumerate your screens from static signals, then you pick, order, name, and describe the desired state of each.
- Run the app on the right simulator/emulator, with sanitized status bars (9:41, full battery/signal) and pre-granted permissions.
- Drive to each curated state via Maestro (one driver for every stack/platform), with a manual-assist fallback.
- Capture screenshots at every store-required dimension using clean SDK tooling (
simctl/adb). - Assemble copy, keywords, URLs, copyright, and a generated Play feature graphic into the fastlane layout — then scan to guarantee no secret was committed.
- Validate & report every asset/field against current store rules.
Out of scope (v1): actually publishing to the stores, writing your marketing copy content for you, app preview videos, A/B testing, non-mobile targets.
| Stacks | Stores | AI platforms |
|---|---|---|
| Native iOS, Native Android, Flutter, React Native / Expo | Apple App Store, Google Play | Claude Code, Codex, Copilot CLI, Gemini CLI, Kiro* |
*Kiro support is best-effort (steering-doc wrapper).
/plugin marketplace add bilal-/listing-kit
/plugin install listing-kit@listing-kitThen just ask: "Use listing-kit to prepare App Store and Play screenshots for this app."
A single canonical SKILL.md is the source of truth; per-platform manifests are
generated from it so they never drift (gemini-extension.json, AGENTS.md).
| Platform | How |
|---|---|
| Codex / Copilot CLI | Clone the repo; the agent reads AGENTS.md → skills/listing-kit/SKILL.md. |
| Gemini CLI | gemini extensions install https://github.com/bilal-/listing-kit (uses gemini-extension.json). |
| Any | Load skills/listing-kit/SKILL.md as context. All work is plain shell-outs — see tool-mapping.md. |
Regenerate the non-Claude manifests after editing the skill:
bash skills/listing-kit/scripts/package/generate-manifests.shlisting-kit gates heavy dependencies so you only install what a given run needs:
| Tool | When needed | If missing |
|---|---|---|
| Stack SDK (Xcode+CocoaPods / JDK+Android SDK / Flutter / Node) | Build & run | Doctor fails fast with fix instructions |
xcrun simctl / adb |
Run, sanitize, capture | required for that platform |
| Maestro + JDK | Drive step only | falls back to manual-assist |
| ImageMagick | Feature-graphic generation only | falls back to prompting you for one |
detect → doctor → discover → plan → configure → run → drive → capture → validate → assemble
The skill is a shared orchestration core plus pluggable modules: the core
never holds stack- or store-specific commands; those live in
references/ modules the core dispatches to.
Driving is shared — Maestro is the only UI driver that's both cross-stack and
cross-platform, which collapses four per-stack automation implementations into
one. New stacks or stores are added by writing a module, not editing the core.
Full walkthrough: docs/GUIDE.md. Design rationale: docs/superpowers/specs/2026-05-25-listing-kit-design.md.
examples/expo-recipe-box is a complete, automation-friendly
Expo app you can run listing-kit against. See examples/ for the full set
(native iOS, Android, and Flutter examples are planned).
The committed tree is the source of truth for non-secrets only. Listing copy,
screenshots, and graphics get committed; credentials and seed secrets never
do — they live in a git-ignored .listing-kit/ or environment variables, and
the Assemble step runs a secret scan that fails the run if anything leaked.
After a run, open listing-review.html at the app root to review all copy (with copy buttons), screenshots, and validation in one page.
Contributions are very welcome — especially deepening a stack module or keeping a store's specs current. See CONTRIBUTING.md and our Code of Conduct. Good first issues: add detection signals for a framework, fix a drifted store size, or improve a Maestro flow recipe.
listing-kit is free and MIT-licensed. If it saved you a tedious afternoon, you can say thanks: buymeacoffee.com/bilaldev ☕
MIT © Bilal Ahmad and listing-kit contributors.