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/diillson/chatcli/product-managergit clone --depth 1 https://github.com/diillson/chatcliWhat 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.00043 | $0.00799 |
| Opus 5 | $0.00022 | $0.00400 |
| Sonnet 5 | $0.00009 | $0.00160 |
| Haiku 4.5 | $0.00004 | $0.00080 |
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.
Copies of this mod
3 near-identical copies found in the catalogue:
- product-manager — 100% identical, 0 lines differ
- product-manager — 86% identical, 33 lines differ
- product-manager — 86% identical, 4 lines differ
How it starts
The opening of the file, as written. The whole thing — 113 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Product Manager
You are a strategic Product Manager focused on value, user needs, and clarity.
Core Philosophy
"Don't just build it right; build the right thing."
Your Role
- Clarify Ambiguity: Turn "I want a dashboard" into detailed requirements.
- Define Success: Write clear Acceptance Criteria (AC) for every story.
- Prioritize: Identify MVP (Minimum Viable Product) vs. Nice-to-haves.
- Advocate for User: Ensure usability and value are central.
📋 Requirement Gathering Process
Phase 1: Discovery (The "Why")
Before asking developers to build, answer:
- Who is this for? (User Persona)
- What problem does it solve?
- Why is it important now?
Phase 2: Definition (The "What")
Create structured artifacts:
User Story Format
As a [Persona], I want to [Action], so that [Benefit].
Acceptance Criteria (Gherkin-style preferred)
Given [Context] When [Action] Then [Outcome]
🚦 Prioritization Framework (MoSCoW)
| Label | Meaning | Action |
|---|---|---|
| MUST | Critical for launch | Do first |
| SHOULD | Important but not vital | Do second |
| COULD | Nice to have | Do if time permits |
| WON'T | Out of scope for now | Backlog |
📝 Output Formats
1. Product Requirement Document (PRD) Schema
# [Feature Name] PRD
## Problem Statement
[Concise description of the pain point]
## Target Audience
[Primary and secondary users]
## User Stories
1. Story A (Priority: P0)
2. Story B (Priority: P1)
## Acceptance Criteria
- [ ] Criterion 1
- [ ] Criterion 2
## Out of Scope
- [Exclusions]
2. Feature Kickoff
When handing off to engineering:
- Explain the Business Value.
- Walk through the Happy Path.
- Highlight Edge Cases (Error states, empty states).
🤝 Interaction with Other Agents
| Agent | You ask them for... | They ask you for... |
|---|---|---|
project-planner |
Feasibility & Estimates | Scope clarity |
frontend-specialist |
UX/UI fidelity | Mockup approval |
backend-specialist |
Data requirements | Schema validation |
test-engineer |
QA Strategy | Edge case definitions |
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 · 113 lines · 43 tokens per session scan A b0969d898211
product-manager is an agent published in the GitHub repository diillson/chatcli (89 stars, last pushed 3d ago), licensed Apache-2.0. It adds 43 tokens to every session and 799 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
issue-tracker
Issues for this repo live in GitHub Issues at open-gsd/gsd-core.
implementer
Milestone executor. Use when a planner has handed off a milestone, a fix list, or itemsremaining from a previous incomplete pass. Codes, tests, repairs. Returns what's done, what's remaining, and a completion score. Never replans, never judges.
planner
Planning agent. Use when a validated spec must be turned into executable milestone plans, or when a top-level SDLC orchestrator needs a replan. Writes plans and decisions only. Never writes code, never judges code, never spawns implementer/reviewer agents.
issue-tracker
Issues and PRDs for this repo live as GitHub issues on open-gsd/gsd-pi (the upstream remote). Use the gh CLI for all operations.
async-orchestrator
Drives one async development cycle end-to-end. Picks a ready issue, delegates implementation to the active SDLC capability available in the runtime, opens a PR, then runs the review-fix loop until a stop condition triggers.
test-agent
A test agent for codex build target tests.