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 skills add rampstackco/claude-skills-starter --skill pm-spec-writinggit clone --depth 1 https://github.com/rampstackco/claude-skills-starterWrote 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/skills/rampstackco/claude-skills-starter/pm-spec-writing)<a href="https://agentmods.dev/skills/rampstackco/claude-skills-starter/pm-spec-writing"><img src="https://agentmods.dev/badge/skills/rampstackco/claude-skills-starter/pm-spec-writing/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/skills/rampstackco/claude-skills-starter/pm-spec-writing"><img src="https://agentmods.dev/badge/skills/rampstackco/claude-skills-starter/pm-spec-writing.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.00137 | $0.01964 |
| Opus 5 | $0.00068 | $0.00982 |
| Sonnet 5 | $0.00027 | $0.00393 |
| Haiku 4.5 | $0.00014 | $0.00196 |
Grade A, and why
pm-spec-writing 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 10d 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.
This is a copy
94% identical to pm-spec-writing — 6 lines differ, which has more behind it and is treated as the original. This page carries a canonical link to it rather than competing with it.
How it starts
The opening of the file, as written. The whole thing — 227 lines — stays where its author put it; the contents beside it link to each section on GitHub.
PM Spec Writing
Take an idea (often vague) and turn it into a specification a developer or AI agent can actually build from. Stack-agnostic. Works for new features, bug fixes, content changes, or infrastructure work.
When to use
- Translating an idea into a buildable feature spec
- Writing a PRD or product requirement document
- Filing a bug report that someone else can act on
- Scoping a project before kickoff
- Prioritizing a backlog of feature requests
- Writing acceptance criteria for an existing feature
- Breaking a large initiative into shippable increments
When NOT to use
- Quarterly or annual planning across multiple initiatives (use
roadmap-planning) - Code review or debugging existing code (use
code-review-web) - Design decisions for a feature already specced (use
design-standards) - User research to validate an idea (use
ux-research)
Required inputs
- The idea, request, or problem being addressed
- The audience or user affected
- Any existing constraints (stack, deadlines, dependencies)
- The success metric (how will you know it worked?)
If the idea is vague, the workflow's first step is clarification. Do not write specs around vagueness.
The framework: 4 phases
Every PM workflow follows the same arc. The phases are universal even if the specific outputs vary.
Phase 1: Clarify the idea
Before any spec, answer four questions. If any answer is "I don't know," go back to the user.
- What user problem does this solve? Not "what does it do." The problem comes first; the feature is the proposed solution.
- Who specifically benefits? Be precise. "Users" is not specific. "First-time visitors who don't convert" is.
- What is the success metric? How will you know it worked? Pick one primary metric.
- Why now? What changed that makes this the right time to build it? If "nothing changed," it might not be the right time.
Phase 2: Scope by impact and effort
Plot every candidate idea on the impact/effort grid:
What ships with it
3 files beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
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.
- 10d ago First seen · 227 lines · 137 tokens per session scan A a0863ad6146f
pm-spec-writing is a skill published in the GitHub repository rampstackco/claude-skills-starter (2 stars, last pushed 1mo ago), licensed MIT. It adds 137 tokens to every session and 1,964 once invoked, about $0.0007 per session on Opus 5. A static security scan graded it A with 0 findings. It is 94% identical to pm-spec-writing, differing in 6 lines, and is treated as a copy.
Other skills, from other repositories
data-warehouse-experimentation
Running experiments out of the data warehouse instead of via dedicated experiment platforms. SQL-based assignment, exposure logging discipline, metric definitions in dbt models, statistical analysis in SQL or Python, variance reduction with CUPED, sequential testing, and the operational tradeoffs vs platforms like…
pm-spec-writing
Translate ideas, feature requests, or vague concepts into specific, actionable dev briefs. Use this skill whenever the user has an idea they want to build, a feature to spec out, a bug to file, a project to scope, or needs to convert a half-formed idea into a clear implementation brief. Triggers on I want to add, we…
experimentation-analytics
How to read experiment results without fooling yourself. Confidence intervals, p-values, multiple testing, sequential testing, CUPED, heterogeneous treatment effects, ratio metrics, network effects, dashboard reconciliation, and the interpretation failures that produce confidently wrong shipping decisions. Use this…
experiment-design
A discipline for designing experiments (A/B tests, multivariate, holdouts) so the results actually answer the question you asked. Hypothesis writing, sample size, duration, segment analysis, running discipline, matching a result to a pre-committed decision rule, and the common failure modes that produce confidently…
experimentation-platform-orchestrator
A platform decision framework for experimentation. When to use Statsig vs PostHog vs GrowthBook vs Optimizely vs Amplitude vs Eppo vs Kameleoon. How to migrate between them. How to coordinate when multi-platform is genuinely warranted. The decisions that compound for years and the ones you can defer. Triggers on which…
feature-flagging
Operational discipline for feature flags as production infrastructure. Flag types, naming, targeting rules, rollout strategy, lifecycle, governance, stale flag management, and the technical debt patterns that bite teams who weren't deliberate about it.