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 skills/kv0906/pm-kit/reportnpx skills add kv0906/pm-kit --skill reportgit clone --depth 1 https://github.com/kv0906/pm-kitWhat 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.00075 | $0.01654 |
| Opus 5 | $0.00037 | $0.00827 |
| Sonnet 5 | $0.00015 | $0.00331 |
| Haiku 4.5 | $0.00007 | $0.00165 |
Grade A, and why
report 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 — 214 lines — stays where its author put it; the contents beside it link to each section on GitHub.
/report — Report to Me
Brief the user as if they are the CEO or product owner. Plain language. Outcomes over output. No technical jargon unless translated into business or user impact.
Context
Today's date: !date +%Y-%m-%d
Config: @_core/config.yaml
Processing logic: @_core/PROCESSING.md
Preview rules: @.claude/rules/preview-formats.md (when --preview)
Usage
/report
/report project-a
/report all
/report project-a --week
/report all --preview
/report project-a --save --preview
Flags
| Flag | Effect |
|---|---|
--week |
Last 7 days (default) |
--since {date} |
Custom start date |
--save |
Write to reports/{date}-executive-brief-{project}.md |
--preview |
Also render HTML via shell-executive.html |
--risks-only |
Skip shipped/WIP — focus on blockers and decisions needed |
Session Task Progress
TaskCreate: "Gather vault signals"
activeForm: "Reading vault for executive signals..."
TaskCreate: "Translate to impact"
activeForm: "Translating to business and user impact..."
TaskCreate: "Deliver brief"
activeForm: "Preparing your briefing..."
Voice & Rules
You are briefing a decision-maker, not an engineer.
Always
- Lead with what matters most to the business
- Explain what changed for users (faster, safer, clearer, unblocked)
- Explain what changed for the business (revenue, risk, speed, cost, trust)
- Use short sentences. No acronyms without plain-English translation
- Quantify when data exists ("3 items shipped", "1 blocker overdue")
- End with what needs their decision or attention
Never
- Stack traces, API names, framework choices, sprint mechanics
- "We merged PR #412" → say what capability that unlocks for users
- "Blocked on Redis" → say "users may see slower checkout until caching is fixed"
- Jira ticket IDs, branch names, implementation details
- Passive voice that hides ownership
Translation examples
| Vault says | Report says |
|---|---|
| Merged auth migration PR | Users can now sign in with their company account — fewer password resets |
| Blocked on API rate limits | Checkout may fail during peak traffic until we secure higher API limits |
| Decided PostgreSQL over MongoDB | We chose a database that handles financial transactions more reliably — reduces data-loss risk |
| WIP on notifications | Users will soon get alerts when their order ships — not live yet |
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 · 214 lines · 75 tokens per session scan A 6af53feaffb2
report is a skill published in the GitHub repository kv0906/pm-kit (133 stars, last pushed 2mo ago), licensed MIT. It adds 75 tokens to every session and 1,654 once invoked, about $0.0004 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 skills, from other repositories
critique-agent
Pressure-test an existing product brief or PRD pack — find gaps, hidden assumptions, inconsistencies, and failure modes before stakeholder review. Use when: critique brief, critique PRD, devils advocate, red team, pressure test, find holes, what could go wrong, stress test the doc, pre-mortem.
interview-frameworks
Frameworks for user interviews, question design, and qualitative research. Use when conducting user interviews, designing interview guides, researching user needs, or gathering qualitative insights. Trigger on: 'create an interview guide', 'how do I interview users', 'customer discovery questions', 'user research…
query-datasets
Answer grounded yes/no questions about what exists in the 03-datasets/ example corpora (supporttickets, calltranscripts) using the local SQLite + FTS5 + vector hybrid index. Use when the user asks 'do/does [corpus] contain/mention/include/have requests for X?', 'any [corpus] about Y?', or similar factual queries over…
critique-prd
Rubric-score a PRD pack (02 + 03) against the 7-dimension PM Brain rubric and run a 4-persona panel review. Returns scores, panel critiques, the single weakest section, a concrete rewrite, and P0/P1 fix lists. Use when: PRD review, score my PRD, rubric review, panel review, rewrite weakest section, critique-prd.
create-prd
Write the PRD pack (02-product-requirements.md + 03-success-metrics.md) on top of an approved product brief. Use when: PRD, product requirements, requirements doc, success metrics, spec writeup, shape the PRD.
create-internal-feature-announcement
Drafts an internal feature announcement (IFA) from the PRD pack and user sources using the repo template, then writes 04-internal-feature-announcement.md. Use when: IFA, internal feature announcement, internal FAQ, Slack IFA prep, launch comms pack, or internal product documentation from the template.