Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →avizmarlon/impact-metrics-gate
Measure before building — enforce impact metrics definition before project/feature development.
Passed 18 of 22 test cases with the skill, and 12 of 22 without it.
and 10 more in the full report
8 fixed11 passed either way2 still failing2 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 7 test cases the skill fixed. Same model, same prompt, with and without the skill.
We have drafted our primary metric, baseline, and measurement method for a new export feature. What specific review step must happen immediately before developers begin writing code?
| Checked | Without skill | With skill |
|---|---|---|
| requires reviewing metrics with stakeholders before writing code | Passed | Passed |
| requires verifying that the measurement method functions before building | Missed | Passed |
The instructions your model reads when the skill loads.
Every project, feature, or solution must define its impact metrics before development begins. The impact of any deliverable should be expressible in a single sentence that a non-technical stakeholder can understand.
If you cannot define impact in one clear sentence, the project is not yet ready to build.
| Item | What It Is | Example |
|---|---|---|
| Primary impact metric (quantifiable) | The single, most important measurement of success. Must be a number. | "Reduce average task completion time from 45 min to 20 min" / "Increase monthly recurring revenue by $5k" / "Achieve 80% test coverage" |
| Measurement method (source + collection) | Where the data comes from and how it is collected. Be specific about tooling and frequency. | "Timestamp delta in task tracking API, 7-day rolling average" / "Payment processor dashboard, monthly export" / "Code coverage tool CI report" |
| Baseline or benchmark (starting point) | The current state or competitive reference point. Do not leave this as "zero" if measurable data exists. | "Current: 45 min (measured week of 2026-01-15)" / "Baseline: $0 MRR" / "Competitor average: 60% coverage" |
Retroactive application: Projects already in progress without defined metrics should add this section during the next development session. Do not block ongoing work, but make the gap visible in session handoff or progress documents.
| Anti-Pattern | Why It Fails | Fix |
|---|---|---|
| "Improves user experience" (no number) | Immeasurable. Improves how much? For whom? | Define the metric: "Reduces task time by X%", "Increases satisfaction score from Y to Z" |
| Metric without method | Theater. If you cannot measure it, it is not a metric. | Specify exact source, tool, and collection frequency. |
| "Baseline: zero" when current state exists | Lazy. Measure the before. | Run a 1-week baseline before build and record it. |
| Build without any metric defined | Waste. You cannot verify impact after launch. | Define metric + method + baseline. This is mandatory, not optional. |
| Metric that depends on future data you cannot collect | Impossible to validate. | Ensure the metric is observable before you ship. |
test cases passed, vs 12 / 22 without
More skills from the same source and nearby in the registry, with their headline benchmark lift.