app-build

A sprint command that coordinates developer agents, reviews their changes, and moves completed work toward testing. A sprint is a planned batch of development work.

In plain words
What is it for?
It launches agents for ready tickets, runs dispatch checks, records status changes in the board’s event log, reviews pull-request equivalents, and sends bugs back through the development loop.
Why use it?
It adds checks before agents can start, so work uses fresh context, approved capabilities, scheduled tickets, and the right risk controls. It also keeps the project board aligned with the work.

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-build
Clone the repo
git clone --depth 1 https://github.com/vmobifystudio/app-dev-team
Per session 24 Only the description is in the session, so the agent can decide to use it. The body loads when it is invoked.
When invoked 12,250 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.00024 $0.12250
Opus 5 $0.00012 $0.06125
Sonnet 5 $0.00005 $0.02450
Haiku 4.5 $0.00002 $0.01225

Measured yesterday against content hash 7d5cd9951fc0, method: parsed. Prices are Anthropic first-party input rates as of 2026-08-30, from the pricing page.

Security

Grade A, and why

app-build 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 yesterday.

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-build.md · 759 lines

How it starts

The opening of the file, as written. The whole thing — 759 lines — stays where its author put it; the contents beside it link to each section on GitHub.

/app-build — Execute the sprint

Tickets (optional, default = all ready): $ARGUMENTS

Before spawning any ticket owner, run the unified dispatch gate:

node "${CLAUDE_PLUGIN_ROOT}/scripts/dispatch-preflight.mjs" \
  --root <project> --ticket <ID> --context "$CONTEXT_MANIFEST" --schedule "$SCHEDULE_PLAN" \
  --capability "$CAPABILITY_MANIFEST" --risk "$RISK_POLICY" \
  --role <role> --operation write --path <changed-path> --file <changed-file> --change <summary>

This composes context freshness, scheduler admission, capability allowlisting, and blast-radius routing. --ticket is checked against the scheduler's own ready set — a ticket the scheduler has not marked ready fails preflight even if every other check would have passed, so a caller cannot launch on its own belief that a ticket is ready. A failed or unavailable check stops the spawn and is reported to the manager.

How this loop writes the board

Every status change below is an append to docs/31-board-events.jsonl through one command:

node "${CLAUDE_PLUGIN_ROOT}/scripts/board.mjs" move <ID> <event> --by <role> [--detail "..."]

docs/31-board.md is regenerated from that log on every append. Never edit a cell — the next render erases it and no rule in this plugin ever saw it. The loop's steps map to events exactly:

Step Situation Event
2 a developer picks the ticket up claimed
3 developer returns DONE: APP-NNN done_reported
3 verify-done.sh VERIFIED / REJECTED verified / rejected
3 routed to review review_requested (--detail "-> code-reviewer")
3 reviewer begins started
4 APPROVED / REQUEST CHANGES approved / changes
4 merge gate clears merged
5 QA verdict qa_passed / qa_failed, then closed
any stopped, for any reason blocked, later unblocked

Exit 1 is a refusal, and a refusal is a finding. The CLI rejects the transition and prints why and what is legal from here. Do not retry it, do not work around it, and do not touch the Markdown: surface the refusal verbatim in the standup and fix the thing it names. Each refusal corresponds to a state this board could previously be written into and the doctor could only report afterwards — a review requested on an unverified DONE, an owner approving their own work, a merge with no non-owner approval, a claim on a dependency that never merged. Exit 2 means the log is missing or unreadable: that is CANNOT EVALUATE, not an empty board. Stop the round.

Read the full file on GitHub · 759 lines

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. yesterday First seen · 759 lines · 24 tokens per session scan A 7d5cd9951fc0

Subscribe to this mod's changes

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