accessibility-gate
Use as a pass/fail gate on any diff with a user-facing surface — by code-reviewer during review, by qa-engineer during the test pass, and by any IC before…
Use before advancing a ticket past QA and before any release — builds the app and launches it, then drives the P0 journey where UI automation exists. Triggers from /app-build's QA wave, /app-ship, qa-engineer and verification-engineer, and any moment someone is about to certify
$ npx -y skills add vmobifystudio/app-dev-team --skill runtime-gate --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
/runtime-gateContext preview
The summary Claude sees to decide when to auto-load this skill.
Use before advancing a ticket past QA and before any release — builds the app and launches it, then drives the P0 journey where UI automation exists. Triggers from /app-build's QA wave, /app-ship, qa-engineer and verification-engineer, and any moment someone is about to certify
name: runtime-gate description: Use before advancing a ticket past QA and before any release — builds the app and launches it, then drives the P0 journey where UI automation exists. Triggers from /app-build's QA wave, /app-ship, qa-engineer and verification-engineer, and any moment someone is about to certify that an app works without having run it.
Every other gate in this plugin verifies that the **process** was followed. `verify-done.sh` checks the branch exists and the test command exited zero. `board-doctor` checks the board is coherent. `ship-gate.sh` checks nothing is in flight and no S1/S2 is open. `code-reviewer` checks the diff reads correctly. A sprint can run green through all four on an app that does not compile in Xcode, does not launch, or launches to a blank screen — because nothing ever ran it.
This is `defect-hunting` §2 — *never certify by reading, execute it* — pointed at the app itself.
sh "${CLAUDE_PLUGIN_ROOT}/scripts/runtime-gate.sh" [--platform ios|android|auto] [--project-root .]| Exit | Meaning | What to do | |---|---|---| | `0` | PASS — built **and** launched | Record the evidence path. Continue. | | `1` | FAIL — does not build, or does not launch | **Blocks the row.** Re-spawn the developer with the compiler output the gate printed, verbatim. | | `2` | CANNOT EVALUATE — the toolchain is not on this machine | **Not a pass.** Report it as CANNOT EVALUATE in the standup and in the verdict block. |
**Exit 2 is the point of the script.** A machine without Xcode is a normal state — a CI runner, a Linux box, an Android-only project. It is not an error and it is not a pass. The gate prints what was missing and what would make it evaluable; surface those lines rather than paraphrasing them.
Two traps it already closes, so do not re-open them by hand: `command -v xcodebuild` succeeds on a Command-Line-Tools-only Mac where every invocation fails, and a build that compiles is **not** a pass — "BUILDS, but launch UNKNOWN" is exit 2. Timeouts are stated and enforced; a hung simulator produces CANNOT EVALUATE, never an infinite wait.
The script is the floor — it proves the app starts. On iOS the Axiom toolchain, when installed, gives far more, and you should route to it:
crashes and errors. This is what turns "it launched" into "the journey works".
All three are **external and optional** — separate plugins, not this one's `skills/`. Their absence is normal; it is never a defect to file.
Absent toolchain → **degrade to the plain script and say so**. Never silently skip a step: an unavailable capability produces a stated CANNOT EVALUATE for that step, never a quiet pass. An unstated gap reads as a cleared one.
Building and launching is the floor. Where UI automation is available, exercise the **primary user journey** and capture evidence at each step.
Pick the flow this way:
1. `docs/10-prd.md` — take the P0 features in priority order. The first P0 journey is the one that, if broken, makes the release pointless. 2. The ticket's acceptance criteria — the `Given / When / Then` rows are already the script. Drive them literally: the `When` is the interaction, the `Then` is what the screenshot must show. 3. `docs/50-test-plan.md` — qa-engineer's rows for those tickets, if the plan exists.
A journey that cannot be driven is stated as not driven, with the reason.
The script writes `docs/evidence/runtime-<date>-<platform>.png` on a successful launch. Anything you drive beyond that writes its own artifact to `docs/evidence/` too — a screenshot, or a log excerpt for a step with nothing visual to show.
**Reference the artifact by path in the DONE report, the QA verdict, or the ship summary.** A claim with no artifact behind it is exactly the class of self-report this whole system exists to distrust — and per `defect-hunting` §4, a finding with no evidence and no owner is one that gets silently skipped.
Describe your app idea in one line. Get a shipped iOS & Android app. AI App Studio is a team of 30 AI specialists — a CEO, product manager, designers, iOS/Android engineers, a code reviewer, QA, and a release manager — that works like a real software studio.
Repo: vmobifystudio/app-dev-team
Use as a pass/fail gate on any diff with a user-facing surface — by code-reviewer during review, by qa-engineer during the test pass, and by any IC before…
Use before spawning any agent that writes files, and by every developer/fixer agent as its first and last action. Gives each agent its own git worktree,…
Use to produce the technical architecture doc and engineering principles for a mobile app. Used primarily by the CTO agent. Triggers on "design the…
Use to validate docs/31-board.md before spawning any agent, and to verify a developer's "DONE" claim before moving a row to review. Triggers as step 0 of…
Use when pointing the team at an EXISTING, already-built app instead of a blank project — detects the stack, reverse-engineers the as-built architecture, and…
Use when deciding or revisiting how the product makes money — pricing, tiers, trial shape, ad load, unit economics — by ceo when setting the model, by cpo when…