Activate on "define metrics", "what should I measure", "success metrics for [feature]", "KPIs for [initiative]".
Scanned 5/30/2026
Install via CLI
openskills install ComeOnOliver/skillshub# Metrics Definer
## Trigger
Activate on "define metrics", "what should I measure", "success metrics for [feature]", "KPIs for [initiative]".
## Behavior
### Step 1: Get Context
Ask:
1. What feature or initiative?
2. What's the goal?
3. What can we currently measure?
### Step 2: Define Metrics
**Primary Metric**
- Name, exact definition, measurement method, target, timeframe
**Secondary Metrics (2-3)**
- Name, definition, why it matters
**Guardrail Metrics (2-3)**
- What should NOT get worse. Current baseline and acceptable range.
**Leading Indicators**
- What to measure in week 1 that predicts long-term success
**Anti-Metrics**
- What metric going UP would actually be bad
## Example
**Bad metrics (vague, unmeasurable):**
```
Primary Metric: Engagement
Secondary: User satisfaction
Guardrail: Performance
```
**Good metrics (precise, measurable, useful):**
```
Primary Metric:
- Name: 7-day feature activation rate
- Definition: % of users who complete at least one [action] within
7 days of first exposure to the feature
- Measurement: Event tracking via Mixpanel. Event: "feature_action_completed"
- Baseline: N/A (new feature)
- Target: 30% within 90 days of launch
- Timeframe: Measured weekly, evaluated at 90 days
Guardrail Metrics:
- Overall page load time stays under 2s (p95). Currently: 1.4s.
Acceptable range: up to 2.0s. Beyond 2.0s = performance regression, pause rollout.
- Support ticket volume for this feature area stays below 50/week.
Anti-Metric:
- Daily active usage going UP could be bad if it means users are
confused and returning to retry failed actions. Cross-reference
with task completion rate — high DAU + low completion = friction.
```
## Rules
- Every metric needs a precise definition. "Engagement" without defining what counts is not a metric.
- Flag metrics requiring new instrumentation with [NEEDS INSTRUMENTATION]
- Always specify the data source. No metric exists without a measurement method.
- Anti-metrics are mandatory. If you cannot identify one, you have not thought hard enough about perverse incentives.
No comments yet. Be the first to comment!
Ultra-compressed communication mode. Cuts token usage ~75% by speaking like caveman while keeping full technical accuracy. Supports intensity levels: lite, full (default), ultra, wenyan-lite, wenyan-full, wenyan-ultra. Use when user says "caveman mode", "talk like caveman", "use caveman", "less tokens", "be brief", or invokes /caveman. Also auto-triggers when token efficiency is requested.
Adversarial multi-agent planning skill. Self-orchestrates 5 hostile category members (unspecified-low, unspecified-high, deep, ultrabrain, artistry) via team-mode for ruthless cross-critique debate, distills only the defensible insights, then MANDATORILY hands the distilled insight bundle to the `plan` agent for executable plan formalization. Use when planning needs maximum rigor and surfacing of weak assumptions, blind spots, and over-engineering. Triggers: 'hyperplan', 'hpp', '/hyperplan', ...
**Complete production-ready guide for Google Gemini embeddings API** This skill provides comprehensive coverage of the `gemini-embedding-001` model for generating text embeddings, including SDK usage, REST API patterns, batch processing, RAG integration with Cloudflare Vectorize, and advanced use cases like semantic search and document clustering. ---
Interview, source-challenge, verify, save, and ADR-gate fuzzy coding requests into Codex-ready implementation specs. Use when a feature, bugfix, refactor, migration, repo-wide change, or architecture task needs user-verified requirements, source-backed decisions, durable architecture decisions, acceptance criteria, validation commands, rollout notes, saved spec/ADR files, and a Codex execution prompt. Do not use when already fully specified or when the user wants direct implementation now.
Use when a repo needs CodeGraph plus ast-grep for Codex MCP setup, exploration, impact analysis, structural search, or safe refactor planning.