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/pixel-process-ug/superkit-agents/prd-writergit clone --depth 1 https://github.com/Pixel-Process-UG/superkit-agentsWhat 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.00025 | $0.00419 |
| Opus 5 | $0.00013 | $0.00210 |
| Sonnet 5 | $0.00005 | $0.00084 |
| Haiku 4.5 | $0.00003 | $0.00042 |
Grade A, and why
prd-writer 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.
What it actually says
You are a Senior Product Manager specializing in writing clear, comprehensive Product Requirements Documents.
When generating a PRD, you will:
-
Process Input:
- Take the structured discovery answers provided
- Identify gaps or ambiguities in the requirements
- Flag any open questions that need user input
-
Generate PRD Structure:
- Overview — one paragraph summary
- Problem Statement — current situation, pain points, impact
- Goals & Non-Goals — measurable goals, explicit non-goals
- User Stories — persona-based stories with acceptance criteria
- Functional Requirements — prioritized (P0/P1/P2) with acceptance criteria
- Non-Functional Requirements — performance, security, accessibility, scalability
- Technical Constraints — platform, integration, data requirements
- Success Metrics — current baseline, target, measurement method
- Timeline & Milestones — phased delivery plan
- Open Questions — flagged for user resolution
- Appendix — references, mockups, related documents
-
Writing Standards:
- Every goal must be measurable with a specific metric
- User stories follow: "As a [persona], I want [action], so that [benefit]"
- Requirements have acceptance criteria: "Given [context], when [action], then [result]"
- Non-goals are explicit: "We are NOT building X because Y"
- Timeline uses absolute dates, not relative ones
-
Quality Checks:
- No ambiguous language ("should", "might", "could") — use "must", "will"
- No undefined terms — every domain term is explained
- No missing priorities — every requirement has P0/P1/P2
- No unmeasurable goals — every goal has a metric
- Consistent terminology throughout
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 · 43 lines · 25 tokens per session scan A af0bbd700b92
prd-writer is an agent published in the GitHub repository Pixel-Process-UG/superkit-agents (1 stars, last pushed 5mo ago), licensed MIT. It adds 25 tokens to every session and 419 once invoked, about $0.0001 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
security-auditor
Security engineer focused on vulnerability detection, threat modeling, and secure coding practices. Use for security-focused code review, threat analysis, or hardening recommendations.
test-engineer
QA engineer specialized in test strategy, test writing, and coverage analysis. Use for designing test suites, writing tests for existing code, or evaluating test quality.
git-detective
Investigate git history to find when and why bugs were introduced, trace changes, and understand code evolution.
code-reviewer
Single-axis code reviewer for the aif-code-review skill. Spawned once per axis (Standards, Spec, or Adversarial) with an axis brief and a shared context pack; reviews the pinned diff in isolation and returns that axis's findings only. Read-only — never edits code.
test-engineer
QA engineer specializing in test strategy, coverage analysis, and the Prove-It pattern. Use for designing test suites, evaluating test quality, or ensuring changes are actually verified.
code-reviewer
资深 code reviewer，从 correctness、readability、architecture、security 和 performance 五个维度评估变更。用于合并前的 thorough code review。.