- name
- codexkit-okr-writer
- description
- Write and cascade OKRs (Objectives and Key Results) for company, department, team, or project level. Ensure objectives are inspiring and key results are measurable outcomes. Includes weekly check-in template. Use at the start of each quarter or when aligning strategy to execution. Do not use for KPI performance reviews or daily task tracking.
- version
- 1.0.0
- category
- scaffolding
# OKR Writer
## Purpose
Create well-structured OKRs that connect strategic ambition to measurable outcomes, with proper cascade from company level down to team or project level.
## When to use
- quarterly or annual OKR setting cycles
- aligning a new project to company strategy
- when OKRs are vague, activity-based, or poorly measurable
- creating a check-in cadence for tracking OKR progress
## When not to use
- KPI dashboards or operational metrics tracking
- individual performance reviews or compensation decisions
- daily or weekly task management
## Inputs
- organizational level (company / department / team / project)
- strategic context or parent OKR to cascade from
- time horizon (quarter, half-year, or annual)
- current baseline metrics for proposed key results
- known constraints or dependencies
## Procedure
1. **Draft Objective** — must be:
- Inspiring and qualitative (no numbers in the objective)
- Achievable within the time horizon
- Within the team's sphere of influence
- Example: "Become the most trusted partner for enterprise clients"
2. **Write 3–5 Key Results** per Objective — each must be:
- Measurable with a specific number
- Outcome-based, not activity-based
- Ambitious: 70% achievement = success
- Template: "Increase/Reduce [metric] from [baseline] to [target] by [date]"
3. **Validate quality** — reject common anti-patterns:
- ❌ Activity KR: "Launch 3 features" → ✅ Outcome KR: "Increase feature adoption to 40%"
- ❌ Binary KR: "Complete migration" → ✅ Measurable KR: "Migrate 95% of accounts by Q2"
4. **Cascade alignment** — map each team OKR to its parent department/company OKR.
5. **Create check-in template** for weekly or bi-weekly tracking:
- Confidence score (0–10, where 7 = on track)
- Current value vs target
- Blockers and help needed
6. **Set scoring method** — at quarter-end:
- 0.0–0.3: Failed to make progress
- 0.4–0.6: Made progress but fell short
- 0.7–1.0: Delivered (0.7 is the sweet spot for stretch OKRs)
## Output
- complete OKR set (1–3 Objectives, each with 3–5 Key Results)
- cascade alignment map to parent OKRs
- baseline metrics and measurement plan
- weekly check-in template
- quarter-end scoring rubric
## Definition of done
- every Objective is qualitative and inspiring
- every Key Result has a numeric target with baseline
- no Key Result is activity-based
- cascade to parent OKR is documented
- check-in cadence is defined
## Examples
- "Write Q2 OKRs for the product team that align to the company goal of market expansion."
- "Our team OKRs feel like a task list — help us rewrite them as outcome-based KRs."
- "Create a weekly OKR check-in template for a 12-person engineering team."
## Quality Criteria
- [ ] All placeholder sections are filled with domain-specific content
- [ ] Structure follows the relevant industry standard or framework
- [ ] Language matches target audience (technical / executive / legal)
- [ ] Output is ready for review — not a rough draft requiring major rework
## Verification (4C)
| Check | Question |
|-------|----------|
| **Correctness** | Does the draft structure follow the stated framework or industry standard? |
| **Completeness** | Are all required sections present with substantive (not placeholder) content? |
| **Context-fit** | Does tone, detail level, and terminology match the intended audience? |
| **Consequence** | If sent to the intended recipient without further editing, what would fail? |
## Edge Cases
- **No existing template for this type** — Use the closest available template and document all customizations made.
- **Stakeholder requirements conflict** — Flag conflicts explicitly in the draft. Do not silently choose one requirement over another.
- **Output required in multiple formats** — Produce the canonical format first, then derive others. Note any formatting limitations.
## Changelog
- v1.0.0 — Initial release
View on GitHub