app-ship

A release command for preparing a mobile app for distribution on iOS or Android. It records the exact built app file and checks project readiness before shipping.

In plain words
What is it for?
Use it to bind an iOS or Android release file to a commit, run security and release checks, require quality-assurance approval, and stop when a release condition fails.
Why use it?
Releasing can fail when the app file does not match the reviewed code, quality checks are incomplete, or known bugs remain open. This command makes those checks part of the release process.

Command

Install

Getting it into your agent

One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.

agentmods
npx agentmods add commands/vmobifystudio/app-dev-team/app-ship
Clone the repo
git clone --depth 1 https://github.com/vmobifystudio/app-dev-team
Per session 21 Only the description is in the session, so the agent can decide to use it. The body loads when it is invoked.
When invoked 5,551 The whole file, excluding the scripts and references it only reads on demand.
Security scan A 0 findings. Scan, not verified.
Origin original No closer match found in the catalogue.
Token cost

What it costs to keep this loaded

Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.

ModelPer sessionOnce invoked
Fable 5 $0.00021 $0.05551
Opus 5 $0.00010 $0.02776
Sonnet 5 $0.00004 $0.01110
Haiku 4.5 $0.00002 $0.00555

Measured yesterday against content hash 4113b4dfa623, method: parsed. Prices are Anthropic first-party input rates as of 2026-08-30, from the pricing page.

Security

Grade A, and why

app-ship scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured yesterday.

A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.

Nothing flagged

None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.

commands/app-ship.md · 330 lines

How it starts

The opening of the file, as written. The whole thing — 330 lines — stays where its author put it; the contents beside it link to each section on GitHub.

/app-ship — Cut a release

Version (optional, otherwise release-manager picks): $ARGUMENTS

Steps

  1. Bind the artifact, then run every mechanical precondition as ONE command.

    First bind what you are about to ship to the commit that passed. Everything else here reasons about a COMMIT; until the binary is bound to it, "readiness: PASS" is a true statement about source and silent about the file you hand to a store:

    node "${CLAUDE_PLUGIN_ROOT}/scripts/release-candidate.mjs" record \
      --artifact <path to the built .ipa/.aab> --platform ios|android --variant release \
      --by release-manager
    

    This step stays explicit because only you know the artifact path — guessing it would be inventing the subject of the whole release. A build from a dirty tree records as such and reads STALE forever after; that is not a bug to work around.

    Then:

    node "${CLAUDE_PLUGIN_ROOT}/scripts/orchestrator.mjs" ship
    

    That runs the board doctor, the ONE readiness reducer (which now includes the artifact you just bound) and ship-gate.sh, in order, worst answer wins. They were three separate steps each ending in "read the exit code"; the discipline of running all three, every time, is exactly what a 328-line file erodes.

    • Exit 0 → continue to the runtime gate below.
    • Exit 1do not release. It names which precondition. STALE is not a failure — nothing says the product is broken, it says nobody checked THIS candidate. Re-run the gates it names, or rebuild and re-record.
    • Exit 2CANNOT EVALUATE, also not a pass. A gate has never run, or no artifact was recorded, so what would be uploaded is UNKNOWN.

    Confirm the gate results still describe this candidate rather than last Tuesday's:

    node "${CLAUDE_PLUGIN_ROOT}/scripts/evidence-check.mjs" \
      --result docs/team/journey-result.json --head "$(git rev-parse HEAD)"
    

    Every gate answers at a moment and then stops thinking. journey-gate says PASS, three commits land, and the PASS sits there green describing a candidate that no longer exists. Nobody lied; the verdict outlived its subject. Exit 1 → re-run the gate rather than reasoning about how little changed.

Read the full file on GitHub · 330 lines

Changes

What this file has done since we first saw it

Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.

  1. yesterday First seen · 330 lines · 21 tokens per session scan A 4113b4dfa623

Subscribe to this mod's changes

app-ship is a command published in the GitHub repository vmobifystudio/app-dev-team (4 stars, last pushed 22d ago), licensed MIT. It adds 21 tokens to every session and 5,551 once invoked, about $0.0001 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.