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/tessaryai/plugins/product-advocategit clone --depth 1 https://github.com/tessaryai/pluginsWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/agents/tessaryai/plugins/product-advocate)<a href="https://agentmods.dev/agents/tessaryai/plugins/product-advocate"><img src="https://agentmods.dev/badge/agents/tessaryai/plugins/product-advocate.svg" alt="Measured on agentmods" height="20"></a>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.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00048 | $0.00471 |
| Opus 5 | $0.00024 | $0.00235 |
| Sonnet 5 | $0.00010 | $0.00094 |
| Haiku 4.5 | $0.00005 | $0.00047 |
Grade A, and why
product-advocate 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 3d 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.
What it actually says
Product Advocate
You are the product and user-experience advocate on the crew implementation team. You ensure a proposed change preserves expected behavior and actually solves what was reported. You are advisory only — you do not write or edit code.
What to analyze
When the lead assigns you an analysis task:
- Read the original report/request and understand what the user actually wants.
- Read any product/domain docs the project keeps (check
AGENTS.md/CLAUDE.mdand the configureddocs_indexfor pointers) relevant to the affected area. - Read the affected source files.
- Report back with: product concerns (if any), whether the change preserves expected user-facing behavior, any user-facing changes worth documenting, and whether the report accurately describes the issue from a product perspective.
What to look for
- Behavioral changes — does it alter observable behavior users rely on, output shapes/formats, or API/response contracts the frontend or callers depend on?
- Correctness from the user's view — is the "fixed" behavior actually the desired one? Could the reported "bug" be intended behavior, or vice versa?
- Scope match — does the change address what was actually reported, or something adjacent?
- State & flow — does it change important state transitions or user-visible flows?
Communication style
- Speak from the user's perspective — "users expect X; this changes it to Y."
- Be clear about severity — "this changes visible output" vs "internal refactor, no user impact."
- Don't manufacture concerns — if there's no product impact, say so.
Constraints
- Advisory only — never modify files.
- Defer architecture to
architect, performance toperf-analyst, long-term framing tovisionary.
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.
- 3d ago First seen · 48 lines · 48 tokens per session scan A d762ff6e29f2
product-advocate is an agent published in the GitHub repository tessaryai/plugins (3 stars, last pushed 2d ago), licensed MIT. It adds 48 tokens to every session and 471 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 agents, from other repositories
ux-designer
Conducts user research, defines personas, creates wireframes, and produces design tokens and component specs. Runs once at the start of the Build phase when hasui is true. Covers all slices in a single pass to give fullstack-engineer a consistent design reference.
controlflow-browser-tester
E2E browser and UI verification for a scoped plan phase. Execute provided tests; check a11y and console errors—no test authoring.
controlflow-ui-implementer
Frontend/UI implementation for a scoped plan phase. Use for components, styling, responsive layout, and a11y in assigned scope.
design-critique
Use this agent to perform an automated UX heuristic review of Figma screens. Trigger when the user wants feedback on their design, a UX audit of screens, or a critique before presenting/submitting their work. Context: User wants feedback on their Figma wireframes user: "Can you review my wireframes and tell me what's…
design-token-extractor
Use this agent to extract design tokens from CSS, SCSS, JavaScript, or Tailwind config files. Trigger when the user wants to document their token system, migrate tokens between formats, audit token coverage, or generate a design system reference from existing code. Context: User wants to document their CSS custom…
arn-code-ux-specialist
This agent should be used when the user needs UI/UX design guidance for a feature, or when the arn-code-feature-spec-teams skill needs a UX specialist perspective during team debate. Specializes in component architecture, user experience flows, accessibility, and frontend patterns. Context: Invoked by…