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-recovergit 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.00025 | $0.01421 |
| Opus 5 | $0.00013 | $0.00711 |
| Sonnet 5 | $0.00005 | $0.00284 |
| Haiku 4.5 | $0.00003 | $0.00142 |
Grade A, and why
app-recover 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 — 126 lines — stays where its author put it; the contents beside it link to each section on GitHub.
/app-recover — recover an interrupted run
Run / attempt: $ARGUMENTS
This is the highest-stress command in the studio and it used to be eleven lines of prose invoking
nothing. A run dies mid-flight with worktrees leased, tickets claimed, a wave half-merged and a
lease nobody released — and the instruction was to go and look. Every one of those states already has
a script that can answer it definitively; none of them was called. Meanwhile /app-run-status calls
run-doctor, orchestrator round calls four checks, and the command for the worst moment called
zero.
Work the four questions in order. Each is a command, and each has a three-way answer. Do not skip to step 5 because an earlier step "looked fine" — a run that died is precisely the state in which looking fine is cheap.
1. What was running, and is anything still holding a lease?
node "${CLAUDE_PLUGIN_ROOT}/scripts/run-doctor.mjs" --root .
node "${CLAUDE_PLUGIN_ROOT}/scripts/run-ledger.mjs" list --root .
-
Exit
0→ no attempt is live. Continue. -
A live lease → do not start a replacement. Either the attempt is still running somewhere, or it died holding the lease. Establish which before writing anything:
node "${CLAUDE_PLUGIN_ROOT}/scripts/run-ledger.mjs" abandon --run <id> --attempt <n> \ --detail "<what actually happened — an interruption is a fact, not an inference>"abandonis a terminal record and the ledger is append-only. Never edit or re-anchor it by hand: a broken chain is evidence, and repairing it destroys the only account of what happened.
2. Does the board still describe reality?
node "${CLAUDE_PLUGIN_ROOT}/scripts/board-doctor.mjs" docs/31-board.md
node "${CLAUDE_PLUGIN_ROOT}/scripts/merge-reconcile.mjs" --root .
merge-reconcile is the one that matters here, and read its wording carefully — it now
distinguishes two states that look identical from the outside:
AWAITING INTEGRATION→ merge-gated, carryingverified_static, wave not yet run. Nothing is wrong. Go to step 4 and land the wave.BLOCKED — claims integrated code that is NOT in <base>→ a ticket says its code shipped and git disagrees. That is a real inconsistency and the likeliest thing a crash leaves behind. Correct the record by appending, never by editing:
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 · 126 lines · 25 tokens per session scan A f904c644183d
app-recover is a command published in the GitHub repository vmobifystudio/app-dev-team (4 stars, last pushed 23d ago), licensed MIT. It adds 25 tokens to every session and 1,421 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.
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.