From coordinator
Define OKRs (Objectives and Key Results) for a product initiative, quarter, or team. Enforces baselines, measurement methods, and the 70% completion target philosophy.
npx claudepluginhub hpsgd/turtlestack --plugin coordinatorThis skill is limited to using the following tools:
Define OKRs for $ARGUMENTS.
Provides UI/UX resources: 50+ styles, color palettes, font pairings, guidelines, charts for web/mobile across React, Next.js, Vue, Svelte, Tailwind, React Native, Flutter. Aids planning, building, reviewing interfaces.
Fetches up-to-date documentation from Context7 for libraries and frameworks like React, Next.js, Prisma. Use for setup questions, API references, and code examples.
Calculates TAM/SAM/SOM using top-down, bottom-up, and value theory methodologies for market sizing, revenue estimation, and startup validation.
Define OKRs for $ARGUMENTS.
Follow every step below. OKRs without baselines and measurement methods are useless — this process ensures every OKR is actionable.
Before writing any OKRs, establish:
Each objective must meet ALL of these criteria:
Qualitative, not quantitative. Objectives describe the desired future state in human language. Numbers go in Key Results, never in Objectives.
Inspiring and memorable. If you cannot remember the objective without looking it up, it is too bland. Objectives should create energy.
Time-bound by the OKR period. The objective should be achievable within the quarter (or whatever period is set). Multi-quarter objectives belong one level up.
Outcome-oriented, not activity-oriented.
Limited to 2-4 objectives per team per quarter. More than 4 means nothing is truly a priority. If you have more than 4 candidates, force-rank and cut.
Each objective gets 3-5 Key Results. Fewer than 3 means the objective is not well-defined. More than 5 means the objective is too broad — split it.
Quantitative with a specific number. Every KR has a metric, a baseline, and a target.
KR: Reduce median time-to-first-value from 14 minutes to 4 minutes
↑ metric ↑ baseline ↑ target
Baselines are mandatory. A target without a baseline is a guess, not a goal.
Outcomes, not outputs.
70% completion = success. Targets should be ambitious enough that achieving 70% represents a strong result. 100% means you set the bar too low. Below 50% means the target was unrealistic or the approach was wrong.
No binary KRs. "Launch feature X" is binary — it is either done or not. Convert to: "Feature X adopted by 30% of eligible users within 4 weeks of launch."
Include the measurement method. For each KR, state exactly how it will be measured:
Every set of Key Results should include both:
Leading indicators — things that change quickly and predict future outcomes:
Lagging indicators — things that confirm the outcome but take time to materialise:
A good OKR set has at least one leading KR (so you can course-correct early) and at least one lagging KR (so you know if the outcome was real).
Run every OKR through this checklist:
At the end of the period, each KR is scored on a 0-1 scale:
| Score | Meaning |
|---|---|
| 0.0 | No progress |
| 0.3 | Some progress but fell well short |
| 0.5 | Made meaningful progress, hit roughly half the target |
| 0.7 | Strong result — this is the expected "good" outcome |
| 1.0 | Fully achieved — target may have been too easy |
Team OKR score = average of all KR scores. A team score of 0.6-0.7 indicates healthy ambition and strong execution.
# OKRs: [Team/Initiative] — [Period]
**Context:** [1-2 sentences on what happened last period and what is driving this period's focus]
**Parent objective:** [Reference to the company/department OKR this ladders up to, if applicable]
---
## Objective 1: [Qualitative, inspiring statement]
| KR | Metric | Baseline | Target | Measurement | Type |
|----|--------|----------|--------|-------------|------|
| KR1 | [Metric name] | [Current value + source] | [Target value] | [Tool, query, frequency] | Leading |
| KR2 | [Metric name] | [Current value + source] | [Target value] | [Tool, query, frequency] | Lagging |
| KR3 | [Metric name] | [Current value + source] | [Target value] | [Tool, query, frequency] | Guardrail |
**Why this objective:** [2-3 sentences on why this matters now]
**Key initiatives (inputs, not measured):** [What the team plans to do to move these KRs — listed for context, not as commitments]
---
## Objective 2: [Qualitative, inspiring statement]
[Same format]
---
## Risks and Dependencies
- [Risk or dependency that could affect achievement]
- [Risk or dependency that could affect achievement]
Write the output to a file: docs/okrs-[team-or-initiative]-[period].md.
/coordinator:decompose-initiative — decompose the initiative into workstreams before defining OKRs. Decompose first (who does what), then define OKRs (how we measure success).