app-team

A command that prints the roster of an app development team and explains each agent's role.

In plain words
What is it for?
Use it to see responsibilities across roles such as company direction, product planning, research, architecture, and engineering management.
Why use it?
It shows which agent handles a particular kind of product or engineering work, so you can choose the right one.

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-team
Clone the repo
git clone --depth 1 https://github.com/vmobifystudio/app-dev-team
Per session 13 Only the description is in the session, so the agent can decide to use it. The body loads when it is invoked.
When invoked 906 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.00013 $0.00906
Opus 5 $0.00006 $0.00453
Sonnet 5 $0.00003 $0.00181
Haiku 4.5 $0.00001 $0.00091

Measured 2d ago against content hash 43094cbbb784, method: parsed. Prices are Anthropic first-party input rates as of 2026-08-30, from the pricing page.

Security

Grade A, and why

app-team 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 2d ago.

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-team.md · 70 lines

What it actually says

/app-team — Roster

Print the team in this order, each line as <role> — <one-line charter>:

Exec

  • ceo — vision, success metrics, scope
  • cpo — PRD, user stories, backlog
  • cto — architecture, stack, engineering principles (starts from the House KB defaults)
  • chief-of-staff — the single founder interface: decision briefs, unresolved commitments, founder inbox (flagship, and only when it removes more decisions than it creates)

Product

  • product-manager — day-to-day product execution below the CPO: ticket clarification, backlog grooming, in-sprint scope calls

  • product-researcher — independent evidence gathering, with fact / user evidence / competitor observation / hypothesis / agent inference labelled separately (conditional)

  • product-validator — compares the founder's recorded brief to the PRD and flags omitted intent, invented requirements and silent scope change. Sits outside the cpo/cto/tech-manager chain, reports to the scope-lock gate, and never writes the PRD it checks

Management

  • tech-lead — per-platform impl specs, patterns, hands-on senior
  • tech-manager — sprint plan, board, daily report, merge gate, standups, pod coordination

Build

  • ios-developer — Swift/SwiftUI implementation, routes through Axiom skills (multiple in parallel)
  • android-developer — Kotlin/Compose implementation, Material 3 skills (multiple in parallel)
  • web-developer — TypeScript/browser implementation; the IC that makes web-app a staffed product type
  • backend-developer — API + persistence (if backend in scope); activates as the ai-engineer, data-engineer or integration-engineer variant when the architecture calls for one
  • monetization-engineer — StoreKit/Play Billing IAP, paywall gateway, AdMob + consent
  • code-reviewer — gate on every PR-equivalent; runs Axiom auditors on iOS branches
  • qa-engineer — test plans, bug filing, ship sign-off
  • test-automation-engineer — test infrastructure, the device and state matrix, evidence bundles, flake detection (flagship, conditional)
  • verification-engineer — executes what everyone else asserts: sweeps constants against outside reference data, grades every guard rule, and must watch a rule fail before trusting it

Design & Growth

  • ux-architect — information architecture, navigation, flows, the screen-and-state inventory
  • product-designer — screen composition, hierarchy, interaction, visual quality, tokens, components
  • aso-specialist — store listing, keywords, screenshots, store-readiness gate
  • data-analyst — analytics schema, instrumentation check, post-launch KPI report

Platform & Release

  • devops-engineer — git strategy, CI, signing, flavors, secrets hygiene
  • security-reviewer — pre-ship MASVS pass, severity-classified findings (and the privacy checklist as its privacy mode on utility projects)
  • privacy-reviewer — data inventory, consent, retention, regional compliance (flagship)
  • reliability-engineer — offline, retries, idempotency, sync conflict, state restoration, recovery (flagship, conditional)
  • red-team-agent — attacks the product and the studio's own assumptions (flagship, conditional)
  • release-manager — version, signing, store upload, release notes
  • release-auditor — independently reviews the evidence bundle and the gate record, and can block the release. release-manager cannot satisfy it — separation of duties
  • incident-commander — owns coordination, containment, and resolution for an open sev1/sev2 incident (conditional, activates only while one is open)

End by reminding the user that not every role runs on every project: role-activation decides the roster from the product type and tier, records every deactivation with its reason in docs/02-team-roster.md, and refuses outright on a product type no IC can build. Also that team size can be tuned per project via the tech-manager agent, and that all build agents read the Mobify Studio House Knowledge Base (knowledge/) before working.

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. 2d ago First seen · 70 lines · 13 tokens per session scan A 43094cbbb784

Subscribe to this mod's changes

app-team is a command published in the GitHub repository vmobifystudio/app-dev-team (4 stars, last pushed 22d ago), licensed MIT. It adds 13 tokens to every session and 906 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.