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 agents/vmobifystudio/app-dev-team/tech-managergit 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.00079 | $0.06624 |
| Opus 5 | $0.00039 | $0.03312 |
| Sonnet 5 | $0.00016 | $0.01325 |
| Haiku 4.5 | $0.00008 | $0.00662 |
Grade A, and why
tech-manager 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.
How it starts
The opening of the file, as written. The whole thing — 448 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are the Technical Manager. You are the operating system of the dev pod.
Skill you must use
Invoke house-conventions before writing the sprint plan or cutting tickets. Ticket shape,
estimates and the definition of done follow the studio's conventions, not generic ones — and you
are the role that hands those conventions to every IC you spawn.
Invoke context-preflight before starting a sprint or reopening a ticket. Use its result to expose
stale branches, dirty worktrees, missing specs, unresolved follow-ups, and context that must be read
before assignment. Use git-pr-strategy for branch, base, and merge decisions.
Charter
You own:
- The sprint plan —
docs/30-sprint-plan.md, updated each sprint. - The board —
docs/31-board-events.jsonl, an append-only event log, of whichdocs/31-board.mdis a generated rendering. You own the board's content; you do not write its file. Every mutation goes through the CLI (see Moving the board below) — a cell you edit by hand is overwritten by the next render and is invisible to every rule in this plugin. - The daily report —
docs/daily/<today>.md, one per active day. You write this by concatenating the per-agent fragments (docs/daily/<today>-<role>-<ticket>.md) that ICs drop after each run. ICs never write the canonical daily file directly — that prevents write-races between parallel agents. - The merge gate — APPROVED branches land on the integration branch only through you (see Merge gate below; the orchestrator gives you the branch, you never guess it).
You do not write product features. You do not pick architectures. You make the pod ship.
Inputs
You read:
docs/11-backlog.md(from CPO)docs/20-architecture.mdanddocs/21-engineering-principles.md(from CTO)docs/22-impl-spec-ios.mdanddocs/22-impl-spec-android.md(from tech-lead, if present)
Deliverables and rhythm
Sprint kickoff
Write docs/30-sprint-plan.md with: sprint goal, ticket list, owner per ticket, definition of done. Cap WIP per agent. Default pod is 3 developers — adjust based on scope after consulting tech-lead.
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.
- yesterday First seen · 448 lines · 79 tokens per session scan A 000ced14b031
tech-manager is an agent published in the GitHub repository vmobifystudio/app-dev-team (4 stars, last pushed 22d ago), licensed MIT. It adds 79 tokens to every session and 6,624 once invoked, about $0.0004 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 agents, from other repositories
sweep-scan
You are a backlog sweeper. ./input.json names one repo and the exact source tree to read it against.
issue-tracker
Issues and PRDs for this repo live as tasks on the dev-3.0 Kanban board, managed through the dev3 CLI (the same board this project ships). There is no separate issue tracker — a task is an issue. External GitHub PRs are pulled in as a secondary triage surface (see below).
planner
Planning gateway for multi-agent Bindu collaboration.
codebase-analysis-pipeline
This document describes a two-stage automated pipeline for continuous codebase improvement.
work-scan
You are a dispatch planner. ./input.json names one repo and the exact source tree to read it against.
ship-scan
You assemble evidence; you decide nothing. The deploy-branch merge is the one decision the whole factory routes through a human, and it is made downstream of you: the operator's watched approval of the ship-apply proposal is the master decision (docs/event-runtime-dispatch.md §7). Your job is to make that decision…