OKR & Metric Validity Audit Skill

What this skill changes vs. default behavior

By default, Claude reviews OKRs by polishing wording and nodding at structure — it rarely challenges whether a key result is falsifiable, whether a metric is vanity, whether an "objective" is just a feature launch in disguise, or whether hitting the target could actually harm the product. This audit forces four things: every finding names the violated principle, every metric is tested for decision-usefulness ("what would we do differently if this number changed?"), every optimization target is checked for gaming exposure and guardrails, and findings come severity-rated with concrete rewrites — not general encouragement.

This is an evaluative skill: it auto-runs whenever OKRs, KPIs, or success metrics are present in work being reviewed or generated.

Scope discipline. When invoked directly (the user named this audit), review only this concern — don't pull in sibling audits. It runs alongside other lenses only when the pm-product-review orchestrator or a generative skill calls it under docs/orchestration-policy.md, where it sits in an artifact-specific lens — offered (when metrics/OKRs are defined). Explicit scope always wins.

The framework — what to check and what a violation looks like

1. Outcome, not output

Outputs are things teams ship (features, releases, launches). Outcomes are changes in user behavior or business results. Key results and metrics must measure outcomes; counting shipped things is the feature-factory signature.

Flag when: a KR or metric counts deliverables, launches, tickets closed, or activities performed; an objective prescribes a solution ("Launch mobile app by Q3").