vmobifystudio
UserAutonomous 17-role mobile-app development team for Claude Code — idea to shipped iOS/Android app, parallel agents, self-reviewing, wired to Axiom/Material3/ASO skills, with a living House Knowledge Base.
Categories
Indexed Skills (30)
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 claiming a UI ticket done. This is the gate the plan called for instead of an accessibility specialist role. Triggers whenever a screen, component or state changes.
agent-isolation
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, forbids blanket staging, and requires confirming a mutation actually landed. Triggers from /app-build, /app-audit, parallel-orchestrator, and any parallel agent launch. Prevents parallel agents corrupting each other's work.
architecture-builder
Use to produce the technical architecture doc and engineering principles for a mobile app. Used primarily by the CTO agent. Triggers on "design the architecture", "pick the stack", or as part of /app-plan.
board-doctor
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 /app-build and /app-run, from /app-status, and any time the board looks inconsistent. Catches tickets the sprint loop cannot see.
brownfield-onboarding
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 classifies remediation work as safe-to-auto-fix vs risky-needs-approval. Triggered by /app-onboard, /app-audit, and by /app-run when it detects a non-empty app directory.
business-model
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 a scope decision turns on revenue, and by product-researcher when investigating willingness to pay. A pricing analysis is a document, not a standing role.
content-design
Use when writing or reviewing any string a user reads — labels, buttons, empty states, errors, permission prompts, onboarding, notifications. Invoked by ux-architect and product-designer while specifying screens, and by product-manager when a clarification turns out to be a copy decision. Triggers the moment a placeholder string would ship.
database-migration
Use before changing any persisted schema — by backend-developer on a server store, by web-developer on a client or server store, and by reliability-engineer when reviewing a change that migrates data. Triggers on the first column, field, index or model change, not on the deploy.
defect-hunting
Use when reviewing code, auditing an app, writing a guard rule or test, or certifying any threshold/constant/formula. Finds the defects a diff review structurally cannot see — the second write path, the mis-calibrated constant, the rule that cannot fail. Triggers from code-reviewer, /app-audit, qa-engineer, verification-engineer, and any task that adds a lint rule, architecture test, or CI grep.
design-system
Use when defining or extending design tokens and the shared component library — by product-designer when writing docs/13-design-tokens.md and docs/14-components.md, and by any IC about to add a component. Triggers the moment a value would be hardcoded instead of named, or a one-off component would be created instead of composed.
growth-analysis
Use post-launch when analysing acquisition, activation, retention, referral or revenue movement — by data-analyst for the KPI report, and by product-researcher when the question is about an existing product's funnel. Same data, same tools as the analytics schema; this is the reading of it.
house-conventions
Use before writing any code, spec, or store asset on a Mobify Studio app — loads the relevant House Knowledge Base pack(s) so output matches the studio's established conventions instead of generic defaults. Every IC invokes this first; execs invoke it when their document names a platform, version, library, or store surface.
intent-trace
Use whenever an artifact derives from another one — writing the PRD from the founder brief, criteria from a requirement, tickets from criteria, tests from criteria, analytics from a feature, or a release from all of it. Defines the founder-intent record, the traceability IDs every node carries, the precedence order that resolves a conflict, and the three-state vocabulary that stops an artifact being silently "fine". Triggered before scope-lock, at every hand-off, and by anything that runs scripts/trace.mjs.
interaction-motion
Use when specifying or reviewing motion and interaction feel — transitions, gestures, feedback timing, loading and progress. Invoked by product-designer while composing screens and by any IC implementing an animated surface. Triggers whenever something moves, and whenever something takes long enough that the user must be told.
localisation
Use when the product ships in more than one locale, or when a string, date, number, currency or layout could differ by region — by ux-architect when the locale set changes navigation, by privacy-reviewer when region determines obligation, and by any IC writing a user-visible string. Triggers on the first string, not on the first translation.
mutation-testing
Use when adding or reviewing a gate, guard rule, CI grep, or test assertion in this plugin's own scripts — and whenever a suite is green and you need to know whether that means anything. Runs scripts/mutate.sh, which breaks the code on purpose and reports which assertions failed to notice. Triggers from code-reviewer, verification-engineer, and any change under scripts/ or hooks/.
parallel-orchestrator
Use to actually launch multiple developer agents in parallel via the subagent tool (Task/Agent), given a sprint plan and board. Triggers from /app-build or when the tech-manager says "spawn the pod". Encapsulates the rules for safe concurrent agent execution.
performance-review
Use as a review dimension on any diff that could cost startup time, frames, memory, battery, bandwidth or bundle size — by code-reviewer during review and by web-developer and test-automation-engineer before claiming a UI or harness ticket done. The studio's position is that this is a dimension with existing auditors behind it, not a standing role.
requirements-intake
Use at the very start of a new app project to convert a one-line idea or rough brief into a structured requirements document the CEO/CPO/CTO agents can act on. Triggers when the user says "build an app", "I have an idea for an app", or kicks off /app-init with a fuzzy prompt.
role-activation
Use at project start — /app-init, /app-onboard, or /app-run's first step — to decide which of the roles this product actually needs, and to write the durable roster the rest of the flow reads. Triggers whenever a command is about to fan out to a team, or a gate is about to run for a role that may not be on this project.
runtime-gate
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.
spec-critic
Use after the impl specs and the board exist but before any developer is spawned, to find every question a developer would otherwise be forced to guess at — error types, empty/failure states, cancel paths, source of truth, units, offline, atomicity. Produces `question` rows in the team ledger for tech-lead to answer in one batch. Triggers from /app-plan and from tech-lead whenever a sprint is about to start.
sprint-planner
Use to convert the backlog into a runnable sprint with parallel ticket assignment and dependency tracking. Used primarily by the tech-manager. Triggers on "plan the sprint", "what does the pod do next", or as part of /app-build.
support-mining
Use when turning store reviews, support threads, crash clusters or feedback into ranked product findings — by data-analyst post-launch, and by product-researcher when existing user evidence is the question. A review-mining pass, not a standing role.
team-protocol
Use whenever one role needs something from another role — a blocker, a spec question, a cross-platform divergence, a handoff, or an escalation. Defines the durable team message ledger, who may talk to whom, the anti-ping-pong guard, and when to escalate to the user instead. Triggers from every agent that would otherwise say "I need X from Y" and stop.
context-preflight
Run before changing a repository to verify branch, worktree, ticket, dependencies, source-of-truth documents, and unresolved obligations are understood.
dependency-policy
Audit declared dependencies, lockfiles, tool versions, compatibility, licenses, and upgrade evidence before implementation or release.
git-pr-strategy
Apply safe branching, commits, conflict resolution, review ownership, merge, rollback, and release-tag rules.
policy-checker
Validate project privacy, security, licensing, accessibility, release, and waiver policies with explicit evidence.
prd-builder
Use to construct a complete Product Requirements Document for a mobile app from a vision file. Used primarily by the CPO agent. Triggers on requests to "write the PRD", "spec out the product", or as part of /app-plan.
Bio shown is the top-scored skill's repo description as a fallback — real GitHub bios land in a future update.