Use success-metrics

Define how a feature's success will be measured before it's built

Define how a feature's success will be measured before it's built — one primary metric with target, timeframe, and baseline; guardrail and counter-metrics; an instrumentation plan naming every event; and a pre-committed decision rule for what happens if the target is missed.

Reach for it when the user asks "how do we know this worked", needs KPIs or success criteria for a feature, or wants a measurement/instrumentation plan before launch.

Install it

npx skilldrop-cli install success-metrics                 # Claude Code, your user folder
npx skilldrop-cli install success-metrics --project       # Claude Code, this repo
npx skilldrop-cli install success-metrics --ide cursor    # or kiro, codex, antigravity, copilot

It is part of the Product manager pack: --pack product-manager installs it with its neighbours.

Ask for it

Say it the way you would to a colleague. Requests like these route to it:

• "How do we know this feature worked? Define the KPIs"
• "Set up success criteria and an instrumentation plan before we launch"
• "What should we measure to judge the new onboarding flow?"
• "Define the success metrics for this PRD's goals"

Requests like these belong to a different skill, so it shouldn't answer them:

• "Cascade company OKRs down to the teams"
• "Analyze last month's launch results"
• "Design the eval harness for our LLM feature"

If another skill answers instead, ask for this one by name: "use success-metrics".

Check what you get

A good result:

• Exactly one primary metric, and it's an outcome, not an output or a vanity count. The doc states why it was chosen over the runner-up.
• Baseline, target, timeframe all present — or "measure baseline" is explicitly milestone 1. No target hangs in the air.
• Every metric maps to a named event marked exists/must-build. A metric without an event is fiction with a chart placeholder.
• The counter-metric names the gaming path. "Could this number improve while the user's life gets worse?" has a written answer.
• The decision rule is action-shaped and pre-committed — who does what at which threshold — not "we'll review the data".
• Guardrails have current values and alert thresholds, so "don't degrade X" is checkable, not sentimental.

Use something else when

• No goal exists yet — prd-draft first; metrics can't rescue an unstated goal
• Org/quarterly OKR setting — this skill measures one feature, not a company
• Analyzing results after the fact — this designs the measurement; analysis is a conversation with the data
• A/B-test statistics (power, sample size) — name the need, hand to the data team; don't improvise math

Next

• SKILL.md, the instructions the agent reads
• Its page on the site
• Related: prd-draft

Edit this page on GitHub · View source