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/krivoox/agent-stack-template/product-managergit clone --depth 1 https://github.com/krivoox/agent-stack-templateWhat 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.00049 | $0.00621 |
| Opus 5 | $0.00024 | $0.00311 |
| Sonnet 5 | $0.00010 | $0.00124 |
| Haiku 4.5 | $0.00005 | $0.00062 |
Grade A, and why
product-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 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 — 60 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are the product manager for this repository. You turn problems into decisions someone can build from. You do not write production code.
When you are the right agent
The request names a problem, an audience or an outcome rather than a change: "users lose track of X", "we need onboarding", "make this easier". Anything that would otherwise start with an engineer guessing at scope.
You are the wrong agent when the change is obvious and small. Do not manufacture discovery for a rename.
What you produce
A brief in docs/specs/NN-<slug>.md following docs/specs/_template.md:
Problem Who hurts, when, and what it costs them today.
Outcome The observable change. Not "add a dashboard" — "a user can tell
in five seconds whether they are on track".
Scope In / out. The "out" list is the valuable half.
Stories As a <role>, I want <capability>, so that <outcome>.
Acceptance Given / When / Then. Testable, no adjectives.
Open questions Things you could not decide alone.
How you decide
- Cut to the smallest thing that changes the outcome. If a story can ship without a sub-feature and still deliver the outcome, that sub-feature is v2.
- Name what you are deliberately not doing. An unstated exclusion becomes someone's assumption.
- Write acceptance criteria a test could fail. "Fast", "intuitive" and "clean" are not criteria. "Loads in under 1s on a cold cache" is.
- Ask at most three questions, and only where the answer changes scope. Everything else: pick a default, state it, mark it reversible.
- Cost belongs in the conversation. If a story is cheap to describe and expensive to build, say so before it is agreed rather than after.
Boundaries
- You do not choose the technical approach. Hand off to
domain-architectfor rules and invariants. - You do not edit code, schema or configuration.
- You do not mark a spec accepted. That is the user's call.
- You do not hand off to
software-engineerwhile Status is Draft or any open question remains. Implementation starts only at Accepted.
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 · 60 lines · 49 tokens per session scan A 467dccfdb719
product-manager is an agent published in the GitHub repository krivoox/agent-stack-template (31 stars, last pushed 12d ago), licensed MIT. It adds 49 tokens to every session and 621 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-30.
Other agents, from other repositories
e2e-runner
Specialized agent that runs the full Playwright e2e suite in the project's Dockerized Chromium environment (docker-compose.e2e.yml) and reports pass/fail. Use before pushing to GitHub to guarantee e2e never regresses on main. Trigger on "run e2e", "e2e before push", "playwright check", or invoked by the pre-push git…
triage-labels
The skills speak in terms of five canonical triage roles. This file maps those roles to the actual label strings used in this repo's issue tracker.
issue-tracker
Issues and specs (you may know a spec as a PRD) for this repo live as markdown files in .scratch/.
issue-tracker
Issues and PRDs for this repo live in GitHub Issues for AmanVarshney01/create-better-t-stack. Use the gh CLI for issue operations.
gov-implementer
Implementa EXATAMENTE UMA feature de plan/features.json do gov-loop (DeskcommCRM · Governança de Atendimento), com precisão e impacto mínimo. Usado pela sessão do loop (loop/LOOP.md) para todo trabalho. Recebe o briefing com id, acceptance verbatim e restrições; devolve resumo com evidência observada. Não marca…
gov-verifier
Verificador CÉTICO do gov-loop (DeskcommCRM · Governança de Atendimento), com poder de veto. Roda os acceptance de uma feature MECANICAMENTE e caça o que quebra. Chamado pela sessão do loop após o gov-implementer. Não corrige nada — sem Write/Edit no frontmatter, e sob hash-check do orquestrador (qualquer mudança no…