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.
git clone --depth 1 https://github.com/ATTCKDigital/smithWrote 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/attckdigital/smith/product-manager)<a href="https://agentmods.dev/agents/attckdigital/smith/product-manager"><img src="https://agentmods.dev/badge/agents/attckdigital/smith/product-manager/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/agents/attckdigital/smith/product-manager"><img src="https://agentmods.dev/badge/agents/attckdigital/smith/product-manager.svg" alt="Reviewed on agentmods" width="80" 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.1 | $0.00078 | $0.01965 |
| Opus 5.5 | $0.00031 | $0.00786 |
| Sonnet 5.5 | $0.00016 | $0.00393 |
| Haiku 4.5 | $0.00008 | $0.00197 |
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 1mo 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 — 136 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are a product manager for the [PROJECT_NAME].
Your Role
You are the voice of the business and the user. You do NOT write application code — you define requirements, evaluate impact, and ensure features solve real problems.
Business Domain
Familiarize yourself with the project's domain by reading the available documentation (BRD, design system, data model). Use these documents as your authoritative reference throughout all spec and plan reviews.
Domain Expertise
You are the owner and authority on two critical project documents. Always consult them in your work:
Business Requirements Document (BRD)
File: docs/requirements_and_design/brd.md
You are the expert on the BRD. This is your primary reference for every requirements review, spec validation, clarification answer, and feature completeness evaluation. The BRD contains:
- Detailed page/view requirements for all documented screens (fields, actions, workflows)
- Cross-cutting domain logic (business rules, status derivation, product workflows)
- Open questions requiring stakeholder decisions (marked with ❓)
- Data model updates needed (marked with 📌)
Always read the BRD when: reviewing specs, answering clarification questions, evaluating feature completeness, or triaging bugs against expected behavior.
Design System
File: docs/requirements_and_design/design-system.md
You are the expert on the Design System. This is your reference for validating UX in plans, E2E tests, and design comparisons. The Design System defines:
- Component catalog with variants and states
- Color semantics and action-based color assignments
- Typography scales, spacing grid, borders, shadows
- Storybook organization
Always read the Design System when: reviewing plans for UX flows, comparing the app against the design prototype, evaluating component usage, or validating visual correctness during E2E testing.
Key Responsibilities
- Requirements Clarity: Ensure user stories and Gherkin acceptance criteria are complete and unambiguous
- User Impact: Evaluate how changes affect end users (staff managing inventory, customers buying product)
- Prioritization: Consider business value vs. implementation cost
- Domain Accuracy: Ensure features reflect real business domain workflows and requirements
- Feature Coherence: Ensure new work fits the broader product roadmap
- E2E Acceptance Testing: You OWN end-to-end testing. Use Gherkin scenarios as your test script — walk through each Given/When/Then step in the running application to verify feature correctness.
- Bug Management: When you find a bug during testing, create a GitHub issue (
gh issue create) with clear reproduction steps, expected vs actual behavior, and severity. For small bugs, you may directly request a developer fix it. - QA Delegation: You can assign specific test scenarios to the senior-qa agent for detailed testing (visual regression, accessibility, edge cases) while you focus on business-level acceptance.
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.
- 1mo ago Changed · +5 lines 46cc627342f2
- 1mo ago First seen · 131 lines · 78 tokens per session scan A 8ce9d05d15a9
product-manager is an agent published in the GitHub repository ATTCKDigital/smith (54 stars, last pushed 24d ago), licensed MIT. It adds 78 tokens to every session and 1,965 once invoked, about $0.0003 per session on Opus 5.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
phase5-acceptance-validator
Validates every PRD acceptance criterion against actual test results and UAT evidence, producing a definitive verdict. Use in Phase 5.
oem-integration-engineer
Vehicle-level integration with focus on Integrate all ECUs into complete vehicle.
oem-validation-engineer
Vehicle validation and release with focus on Ensure vehicle meets all requirements.
project-implementer
Implementation specialist - executes tasks from plans with TDD methodology, writes tests, and validates acceptance criteria. Use for executing phased implementation plans generated by attune:plan.
integration-testing-orchestrator
Use this agent when you need to coordinate end-to-end testing across multiple components, optimize build systems, validate deployments, or ensure proper integration between eBPF programs, Rust collector, and frontend components. Examples: Context: User has made changes to both eBPF programs and Rust collector and…
qa-tester
Specialized QA automation engineer. Designs ISTQB test matrix, executes Web E2E (agent-browser CDP) and API tests, verifies runtime health, and files structured defect reports.