codexkit-okr-writer

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