vybekiit 0.7.23 → 0.7.24

package/dist/global-skills/launch-agent-access/SKILL.md

@@ -0,0 +1,26 @@
+---
+name: launch-agent-access
+description: Use when the developer wants to drive Launch from AI tooling - wire the MCP server into an AI client, serve the read-only local dashboard, or scaffold the agent skills/rules into the repo. All local-only. Covers `launch mcp install`, `launch dashboard`, and `launch agents init`.
+---
+
+# Expose Launch to AI agents & a local dashboard
+
+<!-- generated by launch v0.32.12 - `npx launch agents init` - do not hand-edit -->
+
+## Use this when
+
+- let Claude / Cursor drive Launch (set up MCP)
+- open the local Launch dashboard
+- scaffold the Launch agent skills / rules into this repo
+- give an AI agent access to Launch
+
+## Steps
+
+1. `npx launch mcp install` - wire `launch mcp` into an AI client's config (auto-detects Claude Code / Cursor)
+2. `npx launch dashboard` - serve a local, read-only web UI over apps, builds, accounts, and secrets
+3. `npx launch agents init` - write Claude skills, Cursor rules, and the AGENTS.md Launch section into this repo
+
+These are the on-ramps for agent-driven and at-a-glance use, all strictly local: `mcp install` exposes Launch's commands to an AI client, `dashboard` opens a read-only web view of your state, and `agents init` drops these very skills into the repo.
+
+- `dashboard` is read-only and `mcp install` only edits a local client config - neither touches the store.
+- `agents check` keeps the scaffolded skills in sync after Launch upgrades.

package/dist/global-skills/launch-ai-listing/SKILL.md

@@ -0,0 +1,30 @@
+---
+name: launch-ai-listing
+description: Use when the developer wants AI to draft App Store / Google Play listing copy (name, subtitle, description, keywords, what's-new) into `store.config.json`, then review and ship it. Covers `launch ai listing`, previewing with `launch plan`, and `launch metadata push`.
+---
+
+# AI-drafted store listing copy
+
+<!-- generated by launch v0.32.12 - `npx launch agents init` - do not hand-edit -->
+
+## Use this when
+
+- draft / write the App Store or Play listing copy with AI
+- generate store description and keywords
+- improve the listing metadata
+- fill in store.config.json copy automatically
+
+## Steps
+
+1. `npx launch ai listing` - draft App Store / Play listing copy with AI into store.config.json
+2. `npx launch plan` - review the drafted listing as a read-only diff against the live store
+3. `npx launch metadata push` - upload store.config.json to the live listing (metadata only; no binary)
+
+`ai listing` writes drafted copy into `store.config.json` only - it changes nothing live. Treat the draft as a starting point: read it, edit it, then preview before pushing.
+
+- Preview with `launch plan` (see the launch-plan skill) so you see exactly what the listing change would do before it goes out.
+- `metadata push` is what actually updates the live listing - gate it behind a human review of the AI copy.
+
+## Cautions
+
+- AI-drafted copy is a draft - review it for accuracy and brand voice before shipping. `metadata push` changes the LIVE store listing, so preview with `launch plan` and get confirmation first.

package/dist/global-skills/launch-ai-screenshots/SKILL.md

@@ -0,0 +1,33 @@
+---
+name: launch-ai-screenshots
+description: Use when the developer wants polished App Store or Google Play screenshots generated from real app screens. Covers installing and authenticating the Genshot companion, `launch ai screenshots`, store-dimension validation, `launch plan screenshots`, and the guarded upload through `launch sync`.
+---
+
+# AI-generated store screenshots with Genshot
+
+<!-- generated by launch v0.32.12 - `npx launch agents init` - do not hand-edit -->
+
+## Use this when
+
+- generate polished App Store or Google Play screenshots
+- turn real app screens into store marketing creatives
+- create localized screenshots with captions
+- prepare screenshots before syncing a store listing
+
+## Steps
+
+1. `npx launch ai screenshots` - generate and validate store-ready screenshots from real screens; use --platform ios|android and --brief to steer the design
+2. `npx launch plan screenshots` - review the generated screenshot diff against the live store without writing
+3. `npx launch sync` - upload the reviewed screenshots with the rest of the declared listing
+
+Before generation, make sure the companion is available: `npm install --save-dev @genshot/cli`, then `npx genshot login`. Browser OAuth stores the Genshot credential in the user account config; never put an API key in `launch.config.ts`.
+
+- Put real source images under `<app>/screenshots/<locale>/<DISPLAY_TYPE>/`. Launch enhances those screens; it does not fabricate product UI.
+- `launch ai screenshots` delegates to Genshot, identifies Launch as the client source, validates every returned image against the selected store, and promotes approved files into the listing tree.
+- Use `--captions` for ordered marketing captions, `--locale` for localization, and `--device-types` only when overriding the supported default (`APP_IPHONE_67` for iOS or `phone` for Android).
+- Review with `launch plan screenshots`. Uploading remains the separate `launch sync` action and requires human confirmation.
+
+## Cautions
+
+- Genshot generation spends Credits. If the developer did not directly request generation, show the selected sources, platform, count, and brief and get approval before running it.
+- `launch sync` changes the LIVE store listing. Show the read-only screenshot plan and get explicit human confirmation before uploading.

package/dist/global-skills/launch-ci/SKILL.md

@@ -0,0 +1,31 @@
+---
+name: launch-ci
+description: Use when the developer wants to build and ship this app from CI - scaffold a GitHub Actions workflow on a hosted macOS / Linux runner, or run Launch unattended and headless. Covers `launch ci init` and the non-interactive, env-var-driven command flow.
+---
+
+# CI on a hosted runner
+
+<!-- generated by launch v0.32.12 - `npx launch agents init` - do not hand-edit -->
+
+## Use this when
+
+- set up CI / GitHub Actions to build and ship the app
+- build and ship from a hosted runner without a local Mac
+- run Launch unattended / headless
+- wire up the release pipeline secrets
+
+## Steps
+
+1. `npx launch ci init` - write .github/workflows/launch.yml for a hosted runner (--android adds an Android job)
+2. `npx launch doctor --yes` - non-interactive preflight inside the workflow
+3. `npx launch build ios --yes` - unattended build + upload to the testing track
+
+`ci init` writes a transparent, editable workflow (not a black-box action) wired to the same unattended commands Launch already supports.
+
+- It installs `launch-store` globally on the runner, triggers on `workflow_dispatch` and pushed `v*` tags, and reads credentials from repository secrets decoded at runtime: `ASC_KEY_ID`, `ASC_ISSUER_ID`, `ASC_API_KEY_BASE64` (Android adds `PLAY_SERVICE_ACCOUNT_BASE64`, `ANDROID_KEYSTORE_BASE64`, and the key alias/passwords).
+- Pass `--yes` on the safe commands; Launch also auto-detects CI and degrades to non-interactive on its own.
+
+## Cautions
+
+- Keep `launch release` (public production) OUT of an automatic CI trigger - put it behind a manual approval / protected environment so a push can't publish to the store unattended. CI should target the TESTING track by default.
+- Supply credentials only via repository secrets decoded at runtime; never commit a `.p8`, keystore, or service-account JSON.

package/dist/global-skills/launch-doctor/SKILL.md

@@ -0,0 +1,31 @@
+---
+name: launch-doctor
+description: Use when a Launch build is failing, the toolchain looks broken, signing or credentials won't resolve, or the developer asks to fix their build environment. Covers `launch doctor --fix` (toolchain) and `launch diagnose` (native build-log analysis).
+---
+
+# Diagnose toolchain & build failures
+
+<!-- generated by launch v0.32.12 - `npx launch agents init` - do not hand-edit -->
+
+## Use this when
+
+- the build is failing or broken - fix it
+- fix the toolchain / install missing build tools
+- diagnose a native build error
+- signing or credentials won't resolve
+
+## Steps
+
+1. `npx launch doctor` - detect the iOS/Android toolchain and store-side blockers; --fix installs missing brew tools (--yes for CI)
+2. `npx launch diagnose` - analyze the most recent build log (or a given logfile) and explain the native failure
+3. `npx launch creds status` - show which Apple account and signing assets are active when signing fails
+
+Start with `doctor` to separate environment problems from build problems, then `diagnose` to read the actual native failure.
+
+- `doctor --fix` asks for consent, then installs missing iOS tools via Homebrew (`--yes` skips the prompt for CI/agents). `doctor --platform android` checks the Android toolchain.
+- `diagnose` reads the newest log under `~/.launch/logs` (or a path you pass) and explains the failure in plain English. A config footgun check also runs at the head of every `build`.
+- When signing is the problem, `creds status` shows the active account; `creds set-key` / `creds setup` fix a missing key or profile.
+
+## Cautions
+
+- `doctor --fix` installs build tools via Homebrew. It's safe to run, but review what it proposes; pass `--yes` only in CI where unattended installs are intended.

package/dist/global-skills/launch-insights/SKILL.md

@@ -0,0 +1,26 @@
+---
+name: launch-insights
+description: Use when the developer wants to read store performance - aggregated rating & review trends, individual customer reviews, or Sales & Trends / finance / analytics reports. All read-only, over the same API key. Covers `launch insights`, `launch reports`, and `launch reviews list`.
+---
+
+# Ratings, reviews, sales & analytics insights
+
+<!-- generated by launch v0.32.12 - `npx launch agents init` - do not hand-edit -->
+
+## Use this when
+
+- how is the app rated / how are reviews trending?
+- read the latest customer reviews
+- download a sales or finance report
+- pull App Store analytics
+
+## Steps
+
+1. `npx launch insights` - aggregate rating & review trends across the App Store and Play (read-only)
+2. `npx launch reports sales` - download a Sales & Trends report (gzipped TSV, or --json)
+3. `npx launch reviews list` - list an app's customer reviews, newest first (filter by rating/territory)
+
+`insights` is the aggregated cross-store view (ratings and review trends); drop to `reviews list` for the individual reviews and `reports` for the raw Sales & Trends / finance / analytics data.
+
+- Everything here only reads - safe to run unattended.
+- Reply to reviews with `launch reviews reply` (App Store) or `launch play-reviews reply` (Play) once you've read them.

package/dist/global-skills/launch-migrate/SKILL.md

@@ -0,0 +1,27 @@
+---
+name: launch-migrate
+description: Use when the developer is moving an existing project onto Launch - importing an EAS or fastlane setup into a `launch.config.ts`, onboarding an app that already ships, or validating the resulting config. Covers `launch migrate eas`/`fastlane`, `launch adopt`, and `launch config validate`.
+---
+
+# Migrate from EAS / fastlane, or adopt a live app
+
+<!-- generated by launch v0.32.12 - `npx launch agents init` - do not hand-edit -->
+
+## Use this when
+
+- migrate from Expo EAS / eas.json to Launch
+- import an existing fastlane setup
+- onboard an app that already ships on the store
+- validate my launch.config.ts against the schema
+
+## Steps
+
+1. `npx launch migrate eas` - read eas.json/app.json and emit launch.config.ts, .env.example, store.config.json + a report
+2. `npx launch migrate fastlane` - read fastlane config (Appfile/Fastfile/Matchfile...) and emit the same Launch config set + a report
+3. `npx launch adopt` - onboard an already-shipping app: import its live App Store Connect setup into config
+4. `npx launch config validate` - validate the config against the schema, reporting each problem by field path
+
+Pick the migrator that matches the current setup: `migrate eas` for an Expo EAS project, `migrate fastlane` for a fastlane one, or `adopt` to pull a live App Store Connect setup into config. Each writes a `launch.config.ts` (plus `.env.example` and `store.config.json`) and a report of what it found.
+
+- Migration only writes local config files - it touches no store and provisions nothing.
+- Always finish with `config validate` to confirm the emitted config is schema-clean, then `launch plan` (see the launch-plan skill) to see how it compares to live state.

package/dist/global-skills/launch-ota/SKILL.md

@@ -0,0 +1,31 @@
+---
+name: launch-ota
+description: Use when the developer wants to publish an over-the-air JS / asset update to already-installed builds (Expo Updates protocol), inspect published updates, or roll back a bad update. Covers `launch update` and `launch updates`.
+---
+
+# Over-the-air updates & rollback
+
+<!-- generated by launch v0.32.12 - `npx launch agents init` - do not hand-edit -->
+
+## Use this when
+
+- publish an OTA update / push a JS-only change without a rebuild
+- ship a hotfix over the air
+- list or inspect published updates
+- roll back a bad update
+
+## Steps
+
+1. `npx launch update` - publish a code-signed OTA update to the channel (--channel, --platform; --dry-run rehearses)
+2. `npx launch updates list` - list published updates for a channel
+3. `npx launch updates view latest` - inspect an update by id (or 'latest')
+4. `npx launch updates rollback` - reverse a bad update - promote a known-good one or drop clients to the embedded bundle
+
+OTA updates ship only JS and asset changes the installed runtime can accept (same runtime version), code-signed and hosted on the user's own bucket. **Native** changes (new dependencies, config plugins, permissions) need a full `build` + `release`, not an update.
+
+- `update --channel <name> --platform ios|android|all` publishes; `--dry-run` prints the layout without uploading. Avoid `--no-sign` (it lets anyone who can write the bucket push JS).
+- `updates rollback` is the escape hatch - it promotes a known-good update or drops clients back to the embedded bundle.
+
+## Cautions
+
+- An OTA update reaches real users immediately. Rehearse with `--dry-run`, and confirm the channel and runtime version before publishing to a production channel.

package/dist/global-skills/launch-plan/SKILL.md

@@ -0,0 +1,25 @@
+---
+name: launch-plan
+description: Use when the developer wants to preview how `launch.config.ts` differs from the live App Store Connect / Google Play state, or fail CI when the store has drifted from config - the read-only half of store-config-as-code. Covers `launch plan [surface]` and `launch drift`.
+---
+
+# Store config as code: plan & drift
+
+<!-- generated by launch v0.32.12 - `npx launch agents init` - do not hand-edit -->
+
+## Use this when
+
+- preview the store config diff before syncing
+- what would `launch sync` change?
+- detect or gate configuration drift in CI
+- check that the live store still matches launch.config.ts
+
+## Steps
+
+1. `npx launch plan` - diff launch.config against live store state across every config-as-code surface (read-only)
+2. `npx launch drift` - fail when live state has drifted from config - `plan --check` for CI
+
+`plan` is the read-only preview behind `sync` / `metadata` / the Play reconcilers: it diffs config against live state across capabilities, IAPs, subscriptions, pricing, listing, and the rest of the config-as-code surfaces. `drift` is the same diff as a CI gate (exit non-zero on any difference).
+
+- `plan [surface]` narrows the diff to one surface; bare `plan` covers them all.
+- Use `drift` in CI to keep the store and `launch.config.ts` from silently diverging; apply changes with the launch-store-config skill once the plan looks right.

package/dist/global-skills/launch-release/SKILL.md

@@ -0,0 +1,34 @@
+---
+name: launch-release
+description: Use when the developer wants to submit an already-built version to the PUBLIC App Store or Google Play production track, check review status, or steer a phased rollout (pause / resume / complete). Covers `launch release`, `launch status`, and `launch rollout`. This is the irreversible, outward-facing step - confirm with a human before submitting.
+---
+
+# Public release & phased rollout
+
+<!-- generated by launch v0.32.12 - `npx launch agents init` - do not hand-edit -->
+
+## Use this when
+
+- release the app to the App Store / production / make it public
+- submit for review or go live
+- check review or rollout status
+- pause, resume, or complete a phased rollout
+
+## Steps
+
+1. `npx launch status` - show each app's store version, review state, and phased-rollout state (--json for CI)
+2. `npx launch release ios` - submit the latest build to the PUBLIC production track - preview with --dry-run first
+3. `npx launch rollout pause` - steer an iOS phased release: pause | resume | complete
+4. `npx launch release-train start` - coordinate iOS + Android + OTA as one resumable release record (start | status | release | abort)
+
+`release` is the deliberate public step, distinct from `build` (which only reaches the testing track). Always preview first.
+
+- `release <platform> --dry-run` prints the release plan and touches nothing - run it, show the plan, then let a human trigger the real submit.
+- iOS options: `--phased` opts into Apple's 7-day phased rollout, `--build latest|<n>` promotes an existing build instead of uploading, `--manual` holds the approved build for manual release, `--scheduled <iso>` schedules go-live.
+- `status --watch` polls until review reaches a terminal verdict; `rollout pause|resume|complete` steers an in-progress phased release.
+- Shipping iOS + Android (and an OTA leg) together? `release-train start` records the whole release as one resumable unit - `--hold` gates every leg until all are approved and releases them together, `--platform`/`--no-ota` scope it, and `status`/`release`/`abort` drive or unwind it.
+
+## Cautions
+
+- `launch release` makes the app PUBLIC and is hard to reverse. Run `launch release <platform> --dry-run`, show the plan, and get explicit human confirmation before the real submit.
+- `rollout complete` accelerates a public rollout to 100% - confirm before running it.

package/dist/global-skills/launch-ship/SKILL.md

@@ -0,0 +1,35 @@
+---
+name: launch-ship
+description: Use when the developer wants to build, sign, and ship this Expo / React Native app to TestFlight or Google Play with Launch - first-time setup, provisioning signing credentials, producing a signed build, or uploading to the internal testing track. Covers `launch init`, `launch creds`, `launch doctor`, and `launch build`.
+---
+
+# Set up and ship to TestFlight / Play
+
+<!-- generated by launch v0.32.12 - `npx launch agents init` - do not hand-edit -->
+
+## Use this when
+
+- ship the app to TestFlight or Play internal testing
+- build and upload a test build
+- set up code signing / credentials for the app
+- onboard an existing (already-shipping) app to Launch
+
+## Steps
+
+1. `npx launch init` - scaffold launch.config.ts (+ .env.example); skip if it already exists
+2. `npx launch adopt` - OPTIONAL - app already on the store? import its live App Store Connect setup into config
+3. `npx launch creds set-key` - store the App Store Connect API key (.p8) in the OS keychain
+4. `npx launch creds setup` - register the app id and create or reuse the cert + provisioning profile
+5. `npx launch doctor` - verify the iOS/Android toolchain and config; add --fix to install missing tools
+6. `npx launch build ios` - run the full pipeline and upload to TestFlight (use 'android' for Play; --no-submit builds only)
+
+Run the steps in order. `init` writes the config, `creds` puts the signing material in the keychain, `doctor` catches toolchain and store-side blockers, and `build` produces a signed binary and uploads it to the **testing** track.
+
+- `build` flags worth knowing: `--profile <name>` selects a build profile, `--no-submit` builds without uploading, `--dry-run` rehearses every step, `--explain` teaches as it runs, and `--remote [aws|user@host]` builds iOS without a local Mac.
+- Manage testers after the upload with `launch testflight` (groups, add/remove testers, `testflight release` to push a build to a group). `launch builds` lists build history; `launch build:resign` re-signs a stored artifact without rebuilding.
+- Android: `build android` signs with the upload keystore and uploads to the Play track (`--track internal|closed|open|production`).
+
+## Cautions
+
+- `build` uploads to the TESTING track only - that's safe. Putting the app in front of the PUBLIC is `launch release` (see the launch-release skill), which needs human confirmation.
+- First-time `creds setup` provisions real signing assets in the Apple Developer account - expected during onboarding. Switching or removing an account later (`creds use|remove`) needs human confirmation.

package/dist/global-skills/launch-snapshot/SKILL.md

@@ -0,0 +1,31 @@
+---
+name: launch-snapshot
+description: Use when the developer wants to capture the live App Store Connect / Google Play state as a named baseline, compare baselines or live state, restore a listing back to a saved snapshot, or prune old snapshots. Covers `launch snapshot create`/`diff`/`restore`/`prune`.
+---
+
+# Snapshot & restore live store state
+
+<!-- generated by launch v0.32.12 - `npx launch agents init` - do not hand-edit -->
+
+## Use this when
+
+- snapshot the current store state before a risky change
+- what changed in the store since the last snapshot?
+- restore / roll back the store listing to a saved snapshot
+- clean up old snapshots
+
+## Steps
+
+1. `npx launch snapshot create` - capture live App Store + Play state into a named snapshot
+2. `npx launch snapshot diff <name>` - compare a saved snapshot against another snapshot or live state (default: live)
+3. `npx launch snapshot restore <name>` - restore a snapshot's App Store listing back to live - additive; previews unless --yes
+4. `npx launch snapshot prune` - delete old user snapshots by --keep <n> and/or --older-than <days> (auto baselines untouched)
+
+Take a `snapshot create` before any risky reconcile so you have a labelled baseline, then `snapshot diff` to see exactly what moved. `restore` writes the saved App Store listing back to live (other surfaces are preview-only for now).
+
+- `snapshot diff <name>` defaults to comparing against live state; pass a second name to compare two saved snapshots.
+- `snapshot prune` requires at least one of `--keep`/`--older-than` and never touches the automatic pre-sync baselines.
+
+## Cautions
+
+- `snapshot restore` changes a LIVE listing (additive, never destructive). It previews the plan by default - show that plan and get human confirmation before re-running with `--yes`.

package/dist/global-skills/launch-store-config/SKILL.md

@@ -0,0 +1,37 @@
+---
+name: launch-store-config
+description: Use when the developer wants to manage App Store Connect or Google Play configuration as code from launch.config.ts - in-app purchases, subscriptions, pricing, capabilities, listing metadata, promo offers, in-app events, A/B experiments, availability / territories, or custom product pages. Covers `launch sync`, `launch metadata`, `launch offers`, `launch play-products`, `launch play-subscriptions`, and more.
+---
+
+# Store configuration as code
+
+<!-- generated by launch v0.32.12 - `npx launch agents init` - do not hand-edit -->
+
+## Use this when
+
+- add or change an in-app purchase or subscription
+- sync store config / capabilities to App Store Connect
+- push or pull the store listing metadata
+- set up Google Play products, subscriptions, or tracks
+- generate promo offer codes, an in-app event, or an A/B experiment
+
+## Steps
+
+1. `npx launch sync` - reconcile ASC IAPs, subscriptions, pricing, and capabilities from config - run with --dry-run first
+2. `npx launch metadata pull` - pull the current listing into store.config.json to edit (--platform android for Play)
+3. `npx launch metadata push` - push edited listing copy / screenshots back to the store - --dry-run rehearses
+4. `npx launch play-products` - reconcile Google Play in-app products from config
+5. `npx launch play-subscriptions` - reconcile Google Play subscriptions (base plans + offers)
+
+Store config lives in `launch.config.ts` (catalog) and `store.config.json` (listing). One catalog drives BOTH stores. Every reconcile runs plan -> confirm -> apply.
+
+The safe loop: preview with `--dry-run` (or `metadata pull`), review the plan, then apply. See the bundled command reference for the full surface across both stores.
+
+Preview the full cross-surface diff with `launch plan` and gate drift in CI with `launch drift` (see the launch-plan skill); draft listing copy with `launch ai listing` before pushing it (see the launch-ai-listing skill).
+
+See [`reference.md`](./reference.md) for the full command surface across both stores.
+
+## Cautions
+
+- These commands change a LIVE store. Always preview with `--dry-run` (or `metadata pull`), show the plan, and get human confirmation before applying.
+- `sync --allow-destructive` can remove a capability or product - treat it as requiring explicit human sign-off.

package/dist/global-skills/launch-store-config/reference.md

@@ -0,0 +1,26 @@
+# Store configuration as code - command reference
+
+<!-- generated by launch v0.32.12 - `npx launch agents init` - do not hand-edit -->
+
+The full store-config surface, both stores. Each runs a read-only plan -> confirm -> apply; preview with `--dry-run` and never apply to a live or in-review listing without human confirmation.
+
+| Command | What it does |
+| --- | --- |
+| `npx launch sync` | App Store Connect: reconcile IAPs, subscriptions, pricing, capabilities (--dry-run, --allow-destructive, --yes) |
+| `npx launch metadata pull` | pull the store listing (copy, screenshots, previews) into store.config.json |
+| `npx launch metadata push` | push the edited listing back to the store |
+| `npx launch offers list` | list promotional offers for a subscription product |
+| `npx launch offers generate-codes` | generate one-time promo / offer codes for a product |
+| `npx launch offers deactivate` | deactivate an offer |
+| `npx launch play-products` | Google Play: reconcile in-app products |
+| `npx launch play-subscriptions` | Google Play: reconcile subscriptions (base plans + offers) |
+| `npx launch play-tracks status` | show Google Play track state |
+| `npx launch play-tracks promote` | promote a build between Play tracks |
+| `npx launch availability` | manage territory / country availability |
+| `npx launch custom-pages` | manage custom product pages |
+| `npx launch experiments` | manage product-page A/B experiments |
+| `npx launch events list` | list in-app events |
+| `npx launch events create` | create an in-app event |
+| `npx launch app-clips` | configure App Clips |
+| `npx launch game-center` | configure Game Center leaderboards / achievements |
+| `npx launch accessibility` | set the accessibility declarations on the listing |

package/dist/global-skills/launch-verify/SKILL.md

@@ -0,0 +1,27 @@
+---
+name: launch-verify
+description: Use when the developer wants to know whether the app would pass review right now - a pre-submit sweep, store-account readiness, in-app-purchase readiness, or a privacy / permissions reconcile. All read-only. Covers `launch audit`, `launch store doctor`, `launch iap doctor`, and `launch privacy scan`.
+---
+
+# Pre-submit readiness & verification
+
+<!-- generated by launch v0.32.12 - `npx launch agents init` - do not hand-edit -->
+
+## Use this when
+
+- is the app ready to submit / would it get rejected?
+- run a pre-submit readiness check
+- verify the App Store / Play account and in-app purchases are set up
+- check the privacy declarations against the app's permissions
+
+## Steps
+
+1. `npx launch audit` - one-shot pre-submit sweep - would a submission be rejected right now? (read-only)
+2. `npx launch store doctor` - store-account readiness: the Apple app record, Play onboarding & access (read-only)
+3. `npx launch iap doctor` - in-app-purchase readiness: products & subscriptions exist and are submittable (read-only)
+4. `npx launch privacy scan` - reconcile permissions / manifests against the privacy declarations; flags undeclared collection
+
+Run these before a `release` to catch rejections on your machine instead of in App Review. Every command here only reads - none of them changes the store.
+
+- `audit` is the headline sweep; the focused doctors (`store doctor`, `iap doctor`) and `privacy scan` drill into the specific area that fails.
+- Pair this with `launch plan` (see the launch-plan skill) to also diff your config-as-code against live state before submitting.

package/dist/global-skills/manifest.json

@@ -78,6 +78,20 @@
     "harden",
     "instrument-feature-flags",
     "instrument-product-analytics",
+    "launch-agent-access",
+    "launch-ai-listing",
+    "launch-ai-screenshots",
+    "launch-ci",
+    "launch-doctor",
+    "launch-insights",
+    "launch-migrate",
+    "launch-ota",
+    "launch-plan",
+    "launch-release",
+    "launch-ship",
+    "launch-snapshot",
+    "launch-store-config",
+    "launch-verify",
     "mongodb-atlas-stream-processing",
     "mongodb-connection",
     "mongodb-mcp-setup",
@@ -128,5 +142,5 @@
     "wrangler",
     "xcode-project-setup"
   ],
-  "count": 127
+  "count": 141
 }

package/dist/global-skills/publish-app/SKILL.md

@@ -33,22 +33,28 @@ account steps the stores legally require, one at a time.
    review contact). Decide sensible defaults; confirm the name with the builder.
    **Verify:** the app's identity is set and no `publish-app` markers remain (re-grep `TODO(vybekiit)`).
 
-3. **The one-time store accounts (they cost money — say so plainly).** Tell them, in plain words,
+3. **Prepare the store pictures.** Ask which real screens best explain the app, then run
+   `launch ai screenshots` with a short description of the product. The official picture tool is
+   already installed. If it opens a browser, ask the builder to approve that one sign-in. Show the
+   finished pictures before spending more credits or sending anything to a store.
+   **Verify:** `launch plan screenshots` shows the approved pictures and makes no live change.
+
+4. **The one-time store accounts (they cost money — say so plainly).** Tell them, in plain words,
    that each store needs a paid developer account (Apple's is a yearly fee; Google's is a one-time
    fee) and walk them through creating each — **one step at a time**, where to tap. Then guide the
    one sign-in the build tool needs (a browser opens; they approve).
    **Verify:** both accounts exist and the tools report they're signed in (run `vybekiit doctor`).
 
-4. **Build the installable version.** Run the build yourself. Explain in one line: *"I'm packaging
+5. **Build the installable version.** Run the build yourself. Explain in one line: *"I'm packaging
    your app for the stores now — this runs in the cloud and can take a little while."*
    **Verify:** the build finishes green and an installable file is produced. If it fails, run `doctor`
    and read the one real cause — never paste the red log.
 
-5. **Submit to the stores.** Send the build in for review.
+6. **Submit to the stores.** Send the build in for review.
    **Verify:** each store confirms the submission was received. 🎉 *Celebrate this milestone* — it's
    submitted.
 
-6. **Set expectations on review.** Tell them plainly: the stores read every app before it goes
+7. **Set expectations on review.** Tell them plainly: the stores read every app before it goes
    public, which can take anywhere from a few hours to a few days — nothing is broken while they
    wait. Check the review state with `launch status` and report it in plain words; don't claim it's
    live until the store says so.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "vybekiit",
-  "version": "0.7.23",
+  "version": "0.7.24",
   "description": "Choose your services, sign in, create a VybeKiit app, and open its verified local welcome page.",
   "license": "MIT",
   "publishConfig": {
@@ -32,13 +32,13 @@
     "tsup": "8.5.1",
     "typescript": "5.7.2",
     "vitest": "3.2.6",
-    "@vybekiit/agent-kit": "0.7.23",
-    "@vybekiit/core": "0.7.23",
-    "@vybekiit/agent-mcp": "0.7.23",
-    "@vybekiit/db": "0.7.23",
-    "@vybekiit/report-mode": "0.7.23",
-    "@vybekiit/deploy": "0.7.23",
-    "@vybekiit/payments": "0.7.23"
+    "@vybekiit/agent-mcp": "0.7.24",
+    "@vybekiit/db": "0.7.24",
+    "@vybekiit/core": "0.7.24",
+    "@vybekiit/deploy": "0.7.24",
+    "@vybekiit/agent-kit": "0.7.24",
+    "@vybekiit/report-mode": "0.7.24",
+    "@vybekiit/payments": "0.7.24"
   },
   "scripts": {
     "build": "tsup && node scripts/bundleGlobalSkills.mjs",