Agent skill
okr-design
OKR trees, KPI dashboards, North Star Metric, leading/lagging indicators, and experiment design. Use when setting team goals, defining success metrics, building measurement frameworks, or designing A/B experiment guardrails.
Install this agent skill to your Project
npx add-skill https://github.com/yonatangross/orchestkit/tree/main/plugins/ork/skills/okr-design
Metadata
Additional technical details for this skill
- category
- document-asset-creation
SKILL.md
OKR Design & Metrics Framework
Structure goals, decompose metrics into KPI trees, identify leading indicators, and design rigorous experiments.
OKR Structure
Objectives are qualitative and inspiring. Key Results are quantitative and outcome-focused — never a list of outputs.
Objective: Qualitative, inspiring goal (70% achievable stretch)
+-- Key Result 1: [Verb] [metric] from [baseline] to [target]
+-- Key Result 2: [Verb] [metric] from [baseline] to [target]
+-- Key Result 3: [Verb] [metric] from [baseline] to [target]
## Q1 OKRs
### Objective: Become the go-to platform for enterprise teams
Key Results:
- KR1: Increase enterprise NPS from 32 to 50
- KR2: Reduce time-to-value from 14 days to 3 days
- KR3: Achieve 95% feature adoption in first 30 days of onboarding
- KR4: Win 5 competitive displacements from [Competitor]
OKR Quality Checks
| Check | Objective | Key Result |
|---|---|---|
| Has a number | NO | YES |
| Inspiring / energizing | YES | not required |
| Outcome-focused (not "ship X features") | YES | YES |
| 70% achievable (stretch, not sandbagged) | YES | YES |
| Aligned to higher-level goal | YES | YES |
See references/okr-workshop-guide.md for a full facilitation agenda (3-4 hours, dot voting, finalization template). See rules/metrics-okr.md for pitfalls and alignment cascade patterns.
KPI Tree & North Star
Decompose the top-level metric into components with clear cause-effect relationships.
Revenue (Lagging — root)
├── New Revenue = Leads × Conv Rate (Leading)
├── Expansion = Users × Upsell Rate (Leading)
└── Retained = Existing × (1 - Churn) (Lagging)
North Star + Input Metrics Template
## Metrics Framework
North Star: [One metric that captures core value — e.g., Weekly Active Teams]
Input Metrics (leading, actionable by teams):
1. New signups — acquisition
2. Onboarding completion rate — activation
3. Features used per user/week — engagement
4. Invite rate — virality
5. Upgrade rate — monetization
Lagging Validation (confirm inputs translate to value):
- Revenue growth
- Net retention rate
- Customer lifetime value
North Star Selection by Business Type
| Business | North Star Example | Why |
|---|---|---|
| SaaS | Weekly Active Users | Indicates ongoing value delivery |
| Marketplace | Gross Merchandise Value | Captures both buyer and seller sides |
| Media | Time spent | Engagement signals content value |
| E-commerce | Purchase frequency | Repeat = satisfaction |
See rules/metrics-kpi-trees.md for the full revenue and product health KPI tree examples.
Leading vs Lagging Indicators
Every lagging metric you want to improve needs 2-3 leading predictors.
## Metric Pairs
Lagging: Customer Churn Rate
Leading:
1. Product usage frequency (weekly)
2. Support ticket severity (daily)
3. NPS score trend (monthly)
Lagging: Revenue Growth
Leading:
1. Pipeline value (weekly)
2. Demo-to-trial conversion (weekly)
3. Feature adoption rate (weekly)
| Indicator | Review Cadence | Action Timeline |
|---|---|---|
| Leading | Daily / Weekly | Immediate course correction |
| Lagging | Monthly / Quarterly | Strategic adjustments |
See rules/metrics-leading-lagging.md for a balanced dashboard template.
Metric Instrumentation
Every metric needs a formal definition before instrumentation.
## Metric: Feature Adoption Rate
Definition: % of active users who used [feature] at least once in their first 30 days.
Formula: (Users who triggered feature_activated in first 30 days) / (Users who signed up)
Data Source: Analytics — feature_activated event
Segments: By plan tier, by signup cohort
Calculation: Daily
Review: Weekly
Events:
user_signed_up { user_id, plan_tier, signup_source }
feature_activated { user_id, feature_name, activation_method }
Event naming: object_action in snake_case — user_signed_up, feature_activated, subscription_upgraded.
See rules/metrics-instrumentation.md for the full metric definition template, alerting thresholds, and dashboard design principles.
Experiment Design
Every experiment must define guardrail metrics before launch. Guardrails prevent shipping a "win" that causes hidden damage.
## Experiment: [Name]
### Hypothesis
If we [change], then [primary metric] will [direction] by [amount]
because [reasoning based on evidence].
### Metrics
- Primary: [The metric you are trying to move]
- Secondary: [Supporting context metrics]
- Guardrails: [Metrics that MUST NOT degrade — define thresholds]
### Design
- Type: A/B test | multivariate | feature flag rollout
- Sample size: [N per variant — calculated for statistical power]
- Duration: [Minimum weeks to reach significance]
### Rollout Plan
1. 10% — 1 week canary, monitor guardrails daily
2. 50% — 2 weeks, confirm statistical significance
3. 100% — full rollout with continued monitoring
### Kill Criteria
Any guardrail degrades > [threshold]% relative to baseline.
Pre-Launch Checklist
- Hypothesis documented with expected effect size
- Primary, secondary, and guardrail metrics defined
- Sample size calculated for minimum detectable effect
- Dashboard or alerts configured for guardrail metrics
- Staged rollout plan with kill criteria at each stage
- Rollback procedure documented
See rules/metrics-experiment-design.md for guardrail thresholds, performance and business guardrail tables, and alert SLAs.
Common Pitfalls
| Pitfall | Mitigation |
|---|---|
| KRs are outputs ("ship 5 features") | Rewrite as outcomes ("increase conversion by 20%") |
| Tracking only lagging indicators | Pair every lagging metric with 2-3 leading predictors |
| No baseline before setting targets | Instrument and measure for 2 weeks before setting OKRs |
| Launching experiments without guardrails | Define guardrails before any code is shipped |
| Too many OKRs (>5 per team) | Limit to 3-5 objectives, 3-5 KRs each |
| Metrics without owners | Every metric needs a team owner |
Related Skills
prioritization— RICE, WSJF, ICE, MoSCoW scoring; OKRs define which KPIs drive RICE impactproduct-frameworks— Full PM toolkit: value prop, competitive analysis, user research, business caseproduct-analytics— Instrument and query the metrics defined in OKR treeswrite-prd— Embed success metrics and experiment hypotheses into product requirementsmarket-sizing— TAM/SAM/SOM that anchors North Star Metric targetscompetitive-analysis— Competitor benchmarks that inform KR targets
Version: 1.0.0
Recommended Agent Skills
Expand your agent's capabilities with these related and highly-rated skills.
expect
Diff-aware AI browser testing — analyzes git changes, generates targeted test plans, and executes them via agent-browser. Reads git diff to determine what changed, maps changes to affected pages via route map, generates a test plan scoped to the diff, and runs it with pass/fail reporting. Use when testing UI changes, verifying PRs before merge, running regression checks on changed components, or validating that recent code changes don't break the user-facing experience.
github-operations
GitHub CLI operations for issues, PRs, milestones, and Projects v2. Covers gh commands, REST API patterns, and automation scripts. Use when managing GitHub issues, PRs, milestones, or Projects with gh.
chain-patterns
Chain patterns for CC 2.1.71 pipelines — MCP detection, handoff files, checkpoint-resume, worktree agents, CronCreate monitoring. Use when building multi-phase pipeline skills. Loaded via skills: field by pipeline skills (fix-issue, implement, brainstorm, verify). Not user-invocable.
storybook-mcp-integration
Storybook MCP server integration for component-aware AI development. Covers 6 tools across 3 toolsets (dev, docs, testing): component discovery via list-all-documentation/get-documentation, story previews via preview-stories, and automated testing via run-story-tests. Use when generating components that should reuse existing Storybook components, running component tests via MCP, or previewing stories in chat.
component-search
Search 21st.dev component registry for production-ready React components. Finds components by natural language description, filters by framework and style system, returns ranked results with install instructions. Use when looking for UI components, finding alternatives to existing components, or sourcing design system building blocks.
ai-ui-generation
AI-assisted UI generation patterns for json-render, v0, Bolt, and Cursor workflows. Covers prompt engineering for component generation, review checklists for AI-generated code, design token injection, refactoring for design system conformance, and CI gates for quality assurance. Use when generating UI components with AI tools, rendering multi-surface MCP visual output, reviewing AI-generated code, or integrating AI output into design systems.
Didn't find tool you were looking for?