agentsclimarketplace
Sign in

Appstore release planner

Skill Xopoko/build-swift-apps/skills/appstore-release-planner

Answer App Store release go/no-go questions and choose the next focused release skill. Use for readiness planning, first-submission blockers, release sequencing, or deciding whether to stage or submit; use appstore-review-readiness for concrete validate, submit, monitor, cancel, and repair commands.From its SKILL.md

Install
npx -y skills add Xopoko/build-swift-apps --skill appstore-release-planner

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • reads credentialsReads from 1 credential source: `ASC_*`.

SKILL.md

3.8 KB, 718 tokens by cl100k_base, as published. Nobody here has run it

App Store Release Planner

Use this as the decision front door for App Store release readiness. Do not duplicate the execution workflow here; after the decision, read the focused skill that owns the next action.

Routing

  • Use appstore-release-director when the user wants an end-to-end release from local repo through upload, TestFlight, review, and evidence.
  • Use appstore-review-readiness for concrete validation, staging/submission, status monitoring, cancellation, and blocker repair commands.
  • Use appstore-archive-uploader when the next unresolved step is version/build numbering, archive, export, upload, or processed build selection.
  • Use appstore-metadata-sync, appstore-screenshot-validator, appstore-signing-setup, appstore-pricing-planner, appstore-subscription-localizer, or appstore-testflight-coordinator when the blocker is clearly in that narrower surface.

Answer Order

  1. Ready now or not.
  2. Blocking issues.
  3. Public API fixes vs experimental web-session/manual fixes.
  4. Next exact command.

Resolve APP_ID, version, VERSION_ID, and BUILD_ID; ensure asc auth login or ASC_*; use canonical ./metadata when staging.

Decision Path

  1. Establish release target: app, platform, version, build, submission state, and whether this is a first submission.
  2. Check whether the next missing evidence belongs to metadata, screenshots, signing, pricing/availability, subscriptions/IAP, App Privacy, review details, Game Center, build processing, or review status.
  3. If the version looks action-ready or needs command proof, switch to appstore-review-readiness and follow its current asc command workflow.
  4. If the user only needs an executive answer, report ready/not-ready, blockers, public-API fixes versus experimental web-session/manual fixes, and the next focused skill/command owner.

First-Submission Blockers

  • Availability missing: public edit commands may work after initial availability exists; bootstrap can require an experimental web-session or manual ASC action.
  • Subscriptions ready but not attached to first review: later reviews can use public subscription review paths; first review attachment can require an experimental web-session or manual ASC action.
  • IAP review readiness: public IAP validation/submission paths cover most cases; selecting IAPs with the first app version can require an experimental web-session or manual ASC action.
  • Game Center: create app-version records and add component versions through explicit review submission items before submit.
  • App Privacy: public API cannot fully prove publish state; use asc web privacy pull/plan/apply/publish or manual App Store Connect confirmation.
  • Review details: only set demo account fields when review truly needs them.

Call out all asc web ... commands as experimental web-session escape hatches.

Ready Checklist

Ready means validation has no blockers; stage/submit dry-run is correct; build is VALID and attached; metadata, screenshots, app info, content rights, encryption, age rating, and review details are complete; availability exists; digital goods and Game Center review items are handled; App Privacy is confirmed/published.

Guardrails

  • Do not use legacy submit-preflight, submit-create, or release-run shortcuts.
  • Do not claim ready without concrete validation evidence or a clear manual-confirmation boundary.
  • Do not submit, cancel, or mutate review state from this planner; hand off to appstore-review-readiness.

What ships with it

Read from the repository

Just SKILL.md. No reference files, no scripts.

Gives 0 of the 12 instructions most plan spec skills give in 718 tokens

Counted across 1,360 of the 2,617 authors here whose files we hold, read 2026-09-06

  • Ask one question at a timein 73 of 1360
  • Write the spec using the templatein 22 of 1360
  • Ask clarifying questions if neededin 19 of 1360, across 18 files
  • Wait for user confirmation before proceedingin 19 of 1360
  • Save plans to the plans directoryin 17 of 1360, across 13 files
  • Check for product marketing context firstin 16 of 1360, across 5 files
  • Read the plan file completelyin 16 of 1360
  • Order tasks by dependencyin 16 of 1360
  • Gather context from the conversationin 15 of 1360, across 9 files
  • Explore the codebase instead of askingin 15 of 1360, across 13 files
  • Wait for explicit user approvalin 14 of 1360, across 13 files
  • Quiz the user on the breakdownin 13 of 1360, across 7 files

Said here and by no other author read

  • Establish the release target
  • Check for missing release evidence
  • Switch to appstore-review-readiness for action-ready versions
  • Report ready status and blockers
  • Call out asc web commands as experimental

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.

Keep looking

Skills are one crate of 325,949. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.