Eleven Agent Skills that wrap the asc CLI
Skills to automate app store deployed and everything related to it using the asc cli
At a glance
- What is it?
- rorkai/app-store-connect-cli-skills is a set of instruction documents that teach a coding agent the verbs of the asc CLI. Coverage is wide, but two skills lean on commands the README calls experimental and most examples are prompts rather than runnable lines.
- Who is it for?
- This is a well-scoped instruction pack for teams that already run asc and want a coding agent to drive signing, screenshots and submission without hand-writing flags. Teams shipping to the App Store today gain the most, because every skill assumes a real app record and a working login.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 4 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 23, 2026, and from our analysis. They are not legal advice.
Editorial analysis
What the pack contains and who writes it
The repository bundles Agent Skills for the asc cli, the App Store Connect client hosted at github.com/rorkai/App-Store-Connect-CLI. Each skill is a document an agent reads at run time, not a package you import, and the eleven that receive their own entry cover command syntax, Apple Ads, repo-local workflows, app creation, Xcode builds, ad hoc distribution, screenshots, submission, signing and identifier lookup. A twelfth, asc-submission-health, is named once as where to go for readiness failures, blocker diagnosis, monitoring, cancellation and retry decisions, yet it gets no section and no example. The top level is mostly plumbing: .claude-plugin/ and .codex-plugin/ carry 2 plugin manifests, .github/ and .gitignore sit beside README.md, and scripts/, skills/ and tests/ hold the rest. Oddly, the language statistics give Python as the primary language, and no Python packaging file appears anywhere in that listing.
The project calls itself community-maintained and unofficial, and states it is not affiliated with Apple. The last push landed on 2026-09-14, the licence is MIT, and the repository publishes no GitHub releases, so there is no release history to read beyond the commit log. Its homepage is asccli.sh, a name that belongs to the client rather than to these skills.
Installing through asc, npx skills, and the Claude Code plugin
Three documented paths exist. When asc is already on the machine, a single command registers the pack with the agent runtime:
asc install-skillsThe same directory can be pulled straight from GitHub without the client at all:
npx skills add rorkai/app-store-connect-cli-skillsA third route treats the repository as a Claude Code marketplace, added once and then installed as a plugin:
claude plugin marketplace add rorkai/app-store-connect-cli-skills
claude plugin install asc@rorkaiCodex is handled separately, because a manifest under .codex-plugin/ is not enough on its own:
npx skills add rorkai/app-store-connect-cli-skills --agent codexWhat none of these paths shows is how to install the asc binary. The client lives in its own repository, and the pack simply assumes it exists, so work out which of the two pieces you already have before anything else, since a skill asked for the right verb and flag combination has nothing to call without it.
Repo-local graphs in workflow.json, validated before they run
asc-workflow comes closest to conventional automation. It defines graphs held in .asc/workflow.json inside your repository, run through `asc workflow`, and checked with `asc workflow validate`, which the documentation describes as running cycle and reference checks before execution. 3 named hooks (`before_all`, `after_all`, `error`) wrap a graph, conditionals branch inside it, and private helper sub-workflows can be called from it. Output is JSON first, which is what makes a graph legible to CI and to an agent that cannot scrape a terminal. The migration target is explicit as well: lane-based automation is the older arrangement being replaced.
Even here the graph is not a script. No lockfile and no pinned schema version appear at the top level, so a workflow edited in one branch and validated in another stays the reader's problem. The example the skill gives is a prompt rather than a command:
Create an asc workflow that stages a release, validates it, and only submits when CONFIRM_RELEASE=true.The confirmation flag does the safety work that a shell script would otherwise do with a here-document prompt.
English prompts fenced as bash, and a truncated final example
Several skill examples sit inside bash fences while containing no commands at all. The asc-cli-usage entry closes by asking the agent to find the right asc command, list every build for app 123456789 as JSON and paginate through the results. The asc-apple-ads entry asks for account discovery, campaign queries through Platform API v1 and a paused test plan before anything is created. Under asc-workflow comes the workflow prompt quoted above. Only asc-release-flow breaks the pattern, stating its request as a blockquote that opens with "Stage version 2.4.0 with the selected build" and no fence language at all.
The truncation goes further. The last documented example, filed under asc-id-resolver, stops mid-sentence after "Resolve the App Store Connect app ID, latest", so the identifier skill ships an entry with an unfinished illustration. A fence label is the fastest signal available to anyone skimming the file, and in three places here it points at the wrong thing.
Two skills stand on commands the documentation calls experimental
asc-ad-hoc-distribution is built on the experimental `asc distribute` workflow for verified private installs on registered devices. Its stated jobs include resuming or live-verifying a private S3-compatible run, which means storage you operate yourself, and it asks for a read-only plan with approval of a plan hash before any additive signing or storage mutation happens. asc-shots-pipeline carries the same warning in a different place: capture through xcodebuild and simctl, AXe driving the interface beforehand, then `asc screenshots upload` and the experimental `asc screenshots frame`, with supported devices listed by `asc screenshots list-frame-devices`. The single hard version anchor in the whole document is the pin koubou==0.18.1 for deterministic framing.
A pack that labels 2 of its commands experimental is telling you the floor moves. A single pin among a dozen skill entries also tells you which part was thought to be unstable enough to name.
Where a skill meets a browser login and a live ad account
asc-app-create-ui fills a gap the documentation names outright: the app record is created through browser automation because no API exists for it. That means a real App Store Connect login in a browser, with name, bundle ID, SKU and primary language entered before any record exists to point at. A creation step driven by typing is the one part of this pack that does not go through asc, and it is the part a layout change would break.
Apple Ads carries a different friction. The skill asks for OAuth, profile and ad-account context under ASC_ADS_* guidance, and describes guarded mutations plus a read-first plan, which moves risk onto the approval step rather than removing it. 2 silences matter here: the README gives no procedure for undoing a submission already sent, and it never says where the client keeps its token.
A CI script versus instructions a model reads at run time
The obvious alternative is a shell script in CI calling asc with fixed flags, and the real difference is where each one decides. A script settles the verb, the flags and the order at commit time, fails the same way every night, and hands a human a log when a build number moves. A skill defers those choices to the moment the agent runs, which is what lets asc-cli-usage answer a question you never phrased in advance. asc-id-resolver covers the same gap on identifiers, turning names into the app, build, app version, digital-goods version, group and tester IDs a command demands, including the API 4.4.1 identifiers for in-app purchases, subscriptions and subscription groups.
asc-workflow sits between the two designs, keeping the JSON output and the validate step a bare script lacks while leaving the prompt that starts the graph to the caller. Teams needing identical behaviour on every run should read that split before picking.
What breaks when asc renames a flag
Skills in this pack are text, so a renamed flag on the client side turns into a wrong instruction rather than an import error, and nothing announces it. No dependency file pins asc at the top level, and entries name commands such as `asc review submit` and `asc publish appstore` with no version attached to either. One surface is already dated: asc-apple-ads describes migrating deprecated asc ads v5 automation to Platform API v1, so an install can point straight at a path its own documentation calls obsolete.
Upgrade cost then lands as reading, not as a merge conflict. The tests/ and scripts/ directories sit in the listing and go unexplained, with no statement about what they check or when they run. Anyone adopting this should budget to re-read the skills after a client upgrade rather than once at install.
Editorial conclusion
This is a well-scoped instruction pack for teams that already run asc and want a coding agent to drive signing, screenshots and submission without hand-writing flags. Teams shipping to the App Store today gain the most, because every skill assumes a real app record and a working login. Teams that need identical behaviour on every CI run will not find it here, since the pack is prose rather than a pipeline. Before adopting, run asc workflow validate against your own graphs and confirm the experimental commands your build depends on still exist.
Frequently asked questions
What does rorkai/app-store-connect-cli-skills actually install?
Instruction documents in the Agent Skills format, eleven of which get their own README entry, covering asc usage, Apple Ads, workflows, app creation, Xcode builds, ad hoc distribution, screenshots, submission, signing and identifier lookup. A twelfth, asc-submission-health, is referenced but never given an entry or an example. The listing does not name the files inside skills/, so the mapping from skill names to directories is left unstated.
Do I need the asc CLI installed before these skills work?
For the first install path, yes, since asc install-skills is the client doing the work. The README documents no install step for the binary itself, which lives in the rorkai/App-Store-Connect-CLI repository, and the npx path installs the skills without it, leaving you to add the client before any skill can call a command.
Can Codex install this pack as a plugin?
Not yet, according to the README. A Codex plugin manifest is present in the repository, but Codex installs plugins only from configured marketplaces, so the documented route for Codex is npx skills add rorkai/app-store-connect-cli-skills --agent codex until asc has a public listing.
Are the commands in the README examples copy-pasteable?
Most are not. Three examples are fenced as bash but hold English requests instead of commands, one asks the agent to find the right asc command and page through builds for app 123456789 as JSON, and only the submission skill states its request as a blockquote with no fence language at all.
How does asc-workflow differ from a CI script I write myself?
A script fixes the command and flags when it is committed, while a workflow keeps them as instructions the agent resolves when it runs. What the workflow adds over a plain script is structure and checking: JSON output, the before_all, after_all and error hooks, and asc workflow validate, which runs cycle and reference checks before execution.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/rorkai-app-store-connect-cli-skills)Was this useful?