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.
npx agentmods add commands/vmobifystudio/app-dev-team/app-onboardgit clone --depth 1 https://github.com/vmobifystudio/app-dev-teamWhat 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.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00041 | $0.01329 |
| Opus 5 | $0.00020 | $0.00665 |
| Sonnet 5 | $0.00008 | $0.00266 |
| Haiku 4.5 | $0.00004 | $0.00133 |
Grade A, and why
app-onboard 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.
How it starts
The opening of the file, as written. The whole thing — 84 lines — stays where its author put it; the contents beside it link to each section on GitHub.
/app-onboard — Bring an existing app into the team
Target app path (optional, default = current directory): $ARGUMENTS
Use this when the project already has code. It produces the same baseline the greenfield flow
assumes, but reverse-engineered from what's actually there — so /app-audit and /app-build have
something to work against.
Steps
-
Invoke the
brownfield-onboardingskill and follow it. Run its Step 1 detection first: scan the target for iOS/Android markers, versions, libraries, and module layout. Print a short "what I found" block (platforms, stack, module count, whether CLAUDE.md / CI / Firebase exist). If the directory has no app in it, stop and suggest/app-init(greenfield) instead. -
Invoke
house-conventionsso the reverse-engineering is framed against the studio's standards (and the right Flagship/Utility tier).
2a. Activate the roster. Invoke the role-activation skill. Both axes come from step 1's
detection, not from a guess: the product type from its detection table (a tree that is
neither iOS nor Android is a normal answer — read the package manifests), the tier from the
app's size and shape, naming the signal that decided it. Ambiguous → ask one question.
Write docs/02-team-roster.md (copy ${CLAUDE_PLUGIN_ROOT}/docs/02-team-roster.md and fill it
in) — every role in the activation matrix, active / conditional / off with trigger or
reason — before spawning anyone below. If detection lands on an unstaffed product type
(cli), print the skill's ACTIVATION REFUSED block and stop: onboarding a codebase no IC on
this team can work on produces a baseline nobody can act on. Otherwise print the
tier, the product type, and the off-list. A brownfield backend service that spawns an
aso-specialist and gets store-listing homework is the failure this closes.
- Spawn the
activeroles in parallel (single message), each reading the codebase and writing an as-built snapshot — describe what exists, mark guesses(inferred), change no code:cto+tech-lead→docs/20-architecture.md(actual stack, layering, state/persistence/DI/ navigation, backend, CI, signing) and per-platformdocs/22-impl-spec-<platform>.mdsnapshots.cpo→docs/10-prd.mdfeature inventory derived from the navigation graph and screen files, and from that same inventorydocs/11-backlog.mdand a minimaldocs/00-vision.md. Ask the user only for product intent that cannot be read from code.
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.
- 2d ago First seen · 84 lines · 41 tokens per session scan A 98cbf8b2cdad
app-onboard is a command published in the GitHub repository vmobifystudio/app-dev-team (4 stars, last pushed 23d ago), licensed MIT. It adds 41 tokens to every session and 1,329 once invoked, about $0.0002 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.
Other commands, from other repositories
release
Prepare, cut, and verify a warren release — tracker audits, version bump, CHANGELOG curation, ROADMAP update, push, then watch the pipeline through to published artifacts.
factory-merge
Review open PRs thoroughly, fix what's fixable, merge what's good.
factory-retro
Find what is repeatedly wasting the factory's time and fix the harness, not the symptom.
factory-ticket
Implement exactly one already-claimed Linear ticket in the current worktree.
factory-friction
File harness friction observed in an interactive session — capture only, never implement.
factory-next
Recommend and optionally run the next factory stage for this repo.