agentsclimarketplace

Appstore release planner

Skill Xopoko/plug-n-skills/plugins/build-swift-apps/skills/appstore-release-planner

Ready-to-install skills and plugins for Codex, Claude Code, and AI coding agents: practical workflows for app delivery, architecture, research, design, and agent tooling.

Install
npx -y skills add Xopoko/plug-n-skills --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

  • 9 stars9 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

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.

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,099 of the 1,860 authors here whose files we hold, read 2026-08-07

  • Ask one question at a timein 51 of 1099
  • Break plans into vertical slicesin 29 of 1099, across 11 files
  • Publish issues in dependency orderin 27 of 1099, across 9 files
  • Iterate until user approves the breakdownin 25 of 1099, across 7 files
  • Explore the repository to understand the codebase statein 24 of 1099, across 7 files
  • Use domain glossary vocabularyin 23 of 1099, across 5 files
  • Apply correct triage labels to published issuesin 23 of 1099, across 5 files
  • Prefer AFK slices over HITLin 22 of 1099, across 7 files
  • Write a specification before writing any codein 22 of 1099, across 14 files
  • Write failing tests before implementation codein 22 of 1099, across 20 files
  • Ask clarifying questions until requirements are concretein 21 of 1099, across 13 files
  • Respect existing architecture decision recordsin 20 of 1099, across 5 files

Said here and by no other author read

  • report ready or not-ready first
  • list blocking issues
  • recommend next focused skill
  • resolve app version and build identifiers
  • establish release target and submission state
  • call out web-session 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 326,984. 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.