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 product-on-purpose/pm-skills --skill measure-instrumentation-specgit clone --depth 1 https://github.com/product-on-purpose/pm-skillsWrote 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/product-on-purpose/pm-skills/measure-instrumentation-spec)<a href="https://agentmods.dev/skills/product-on-purpose/pm-skills/measure-instrumentation-spec"><img src="https://agentmods.dev/badge/skills/product-on-purpose/pm-skills/measure-instrumentation-spec/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/product-on-purpose/pm-skills/measure-instrumentation-spec"><img src="https://agentmods.dev/badge/skills/product-on-purpose/pm-skills/measure-instrumentation-spec.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- Socket pass
- Snyk pass
- NVIDIA SkillSpector pass
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.00069 | $0.01252 |
| Opus 5 | $0.00034 | $0.00626 |
| Sonnet 5 | $0.00014 | $0.00250 |
| Haiku 4.5 | $0.00007 | $0.00125 |
Grade A, and why
measure-instrumentation-spec 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 9d 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 — 88 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Instrumentation Spec
An instrumentation spec defines what analytics events to track, when to fire them, and what properties to include. It serves as a contract between product and engineering, ensuring consistent data collection that enables accurate measurement. Good instrumentation specs prevent the "we can't answer that question because we didn't track it" problem.
When to Use
- Before engineering implements a new feature
- When defining analytics requirements for experiments
- When auditing existing tracking for gaps or inconsistencies
- When onboarding a new analytics tool
- Before launch to ensure measurement is in place
When NOT to Use
- You are specifying the dashboard built on top of the events -> use
measure-dashboard-requirements - You need experiment-specific metrics and variants, not product-wide tracking -> use
measure-experiment-design - The feature itself is not yet specified (no flows to instrument) -> use
deliver-prdfirst - You are analyzing data you already collect -> use
measure-experiment-resultsormeasure-survey-analysis
Instructions
When asked to create an instrumentation spec, follow these steps:
-
Define Analytics Goals Start with the questions you need to answer. What will you measure? What decisions will this data inform? This prevents over-instrumentation while ensuring nothing important is missed.
-
Identify Events to Track List each user action or system event that should be tracked. Follow consistent naming conventions (typically
noun_verborverb_nounin snake_case). Each event should represent a distinct, meaningful action. -
Specify Event Triggers For each event, describe exactly when it fires. Be precise: "When user clicks Submit button" vs. "When form is submitted successfully." These are different events with different meanings.
-
Define Event Properties List the properties (attributes) attached to each event. Include property name, data type, description, and example values. Properties provide context that makes events useful.
What ships with it
4 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.
- 9d ago First seen · 88 lines · 69 tokens per session scan A 815de91e0bba
measure-instrumentation-spec is a skill published in the GitHub repository product-on-purpose/pm-skills (663 stars, last pushed yesterday), licensed Apache-2.0. It adds 69 tokens to every session and 1,252 once invoked, about $0.0003 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-09-03.
Other skills, from other repositories
agent-communication-protocol
Open protocol for AI agent interoperability enabling standardized communication between agents, applications, and humans across different frameworks.
endpoint-validator
Deterministic API endpoint validation with pass/fail reporting.
api-patterns
API design: naming, versioning, pagination, idempotency, OpenAPI, error contracts and safe retries. Triggers: API design, REST, GraphQL, OpenAPI, Swagger, error response, HTTP status, rate limit.
csharp-patterns
C#/.NET: LINQ, async/await, DI, records, nullable refs, ASP.NET Core, EF Core, MediatR. Triggers: C#, .NET, dotnet, ASP.NET, EF Core, LINQ, record type, IServiceCollection.
java-patterns
Java: Spring Boot, CompletableFuture, records, sealed types, JPA/Hibernate, virtual threads. Triggers: Java, Spring, JPA, Hibernate, Maven, Gradle, virtual thread, sealed class.
kafka-event-driven-design
Kafka event-driven architecture designer and reviewer, at the application/client layer. ALWAYS use when designing, reviewing, or troubleshooting how a service produces or consumes Kafka events — topic and partition-key design, producer and consumer client configuration, consumer group topology, event schema definition…