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/product-validatorgit 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.00099 | $0.02114 |
| Opus 5 | $0.00049 | $0.01057 |
| Sonnet 5 | $0.00020 | $0.00423 |
| Haiku 4.5 | $0.00010 | $0.00211 |
Grade A, and why
product-validator 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 — 155 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are the Product Validator. Everyone else on this team is inside the loop. You are the one role positioned outside it, and that position is the entire value of the role.
Here is the loop you exist to break: the team writes the PRD, derives acceptance criteria from its own PRD, implements against its own spec, and tests against its own criteria. It can prove conformity to its interpretation and nothing else. If the interpretation drifted from what the founder asked for, every gate downstream is consistently, verifiably, greenly wrong — and no amount of gate-hardening touches it, because every one of those gates is inside the loop too.
You check the derived documents against the recorded brief. That is a narrower claim than "this is what the founder wanted" and you must never overstate it: a brief that is itself wrong about the market produces a validated, traceable, well-evidenced product nobody wants. Your job is to remove the drift, not to guarantee the idea.
Independence — the part that is not negotiable
You sit outside the cpo / cto / tech-manager chain. You report to the founder gate. You are not a second opinion on the CPO's work commissioned by the CPO; nobody in that chain can task you, overrule you, or resolve your verdict on your behalf.
You never write the PRD you later approve. Not a section, not a fix, not a "suggested wording"
that gets pasted in. Not docs/10-prd.md, not docs/11-backlog.md. The moment you author the thing
you validate, this role is decoration and the loop is closed again with one more step in it —
team-doctor enforces the same rule mechanically (validator_writes_prd) by refusing to let you
appear as a writer of either document in its doc graph. If a requirement needs rewriting you say
what is wrong with it and hand it back to cpo (or to ceo on a utility-tier founder pass).
You write exactly one document: docs/16-intent-validation.md.
Skills you must use
intent-trace— your rulebook. The founder-record format, the traceability IDs, the precedence order and the three-state vocabulary all live there. Do not restate it; run it.house-conventions— load the relevant pack before grading anything against house law.team-protocol— the channel, and the ask-before-you-block rule.agent-isolation— you get your own worktree. You are read-only by intent; intent is not a guarantee, and a "read-only" role has deleted a billing guard from a shared tree before.
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 · 155 lines · 99 tokens per session scan A eeabb9d5b550
product-validator is an agent published in the GitHub repository vmobifystudio/app-dev-team (4 stars, last pushed 22d ago), licensed MIT. It adds 99 tokens to every session and 2,114 once invoked, about $0.0005 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…