Okr Mastery

OKR Mastery

File Map

skills/okr-mastery/
├── SKILL.md                        ← You are here (router & directives)
├── references/                     ← All knowledge and reference files
│   ├── skill-model.md              ← Core OKR methodology and principles
│   ├── prompt-library.md           ← Step-by-step workflow instructions
│   ├── quick-reference.md          ← Working checklist for quality checks
│   └── review-rubric.md            ← 10-criterion quality scoring tool
├── company/                        ← Company customization layer
│   ├── setup-instructions.md       ← How to fill in the company layer
│   └── context.md                  ← Company-specific OKR context
└── assets/                         ← Templates and output format files
    └── okr-template.md             ← OKR drafting template

When This Skill Activates

This skill handles all OKR-related work: drafting, reviewing, refining, decomposing, coaching, red-teaming, and scoring objectives and key results.

Trigger on any of these signals:

• User asks to write, draft, create, or set OKRs
• User asks to review, critique, or improve existing OKRs
• User pastes or uploads draft OKRs for feedback
• User asks to decompose company goals into team-level OKRs
• User asks to generate key results for a given objective
• User mentions quarterly goals, objectives and key results, or OKR planning
• User asks to score or reflect on a completed OKR cycle

Before Starting Any Task

Follow these steps every time this skill activates:

1. Check company/context.md first. If it contains filled-in company data (not [Fill in: ...] placeholders), incorporate the company's org structure, strategic priorities, terminology, planning cadence, cultural norms, and tooling conventions into all output. If it still contains only placeholders, work from the universal methodology only.

2. Read references/skill-model.md for the full methodology — philosophy, key distinctions, the six-phase process, quality criteria, and anti-patterns.

3. Keep references/quick-reference.md as your working checklist. Run the quality checklist from this file before presenting any OKRs to the user.

4. Ask for strategic context before drafting. Never start writing OKRs without understanding: company/team priorities, the team's mission, current challenges, and the time horizon. If the user hasn't provided this, ask for it.

Core Workflows

Workflow 1: Draft OKRs from Scratch

When the user wants to create new OKRs:

1. Gather context. Ask the user for:

   • Who these OKRs are for (company, team, individual)
   • The time period (quarter, annual)
   • Strategic priorities, team mission, current challenges
   • Any parent OKRs these must align to
   • Whether company context is available in company/context.md

2. Read references/skill-model.md — pay attention to the philosophy, key distinctions (especially outcomes vs outputs, committed vs aspirational), and the templates section.

3. Draft the OKRs following these rules:

   • 3-5 objectives maximum
   • 3-5 key results per objective
   • Objectives: qualitative, inspirational, concise (one line), action-oriented
   • Key results: measurable, time-bound, outcome-focused, unambiguous
   • Pair every significant quantity KR with a quality safeguard KR
   • Classify each OKR as COMMITTED or ASPIRATIONAL
   • Make cross-functional dependencies explicit
   • Use the formula: "I will [objective] as measured by [key results]"

4. If company context is available, adapt the output:

   • Use the company's terminology and metric names
   • Align to stated strategic priorities and initiatives
   • Follow the company's format conventions (e.g., NCT-style narratives if applicable)
   • Respect the planning cadence and scope expectations
   • Use the OKR template from assets/okr-template.md as a starting structure

5. Run the quality checklist from references/quick-reference.md on every OKR before presenting. Report which checks pass and which need attention.

6. Self-score against references/review-rubric.md. Flag any criterion scoring below 4.

Workflow 2: Review and Critique Existing OKRs

When the user provides draft OKRs for feedback:

1. Read references/review-rubric.md — apply every criterion.

2. Score each criterion on a 1-5 scale using the rubric's anchors. Present scores in a summary table.

3. For any criterion below 4, explain what's wrong with specific examples from the user's OKRs, and suggest concrete fixes.

4. Check for anti-patterns from references/skill-model.md:

   • Task list disguised as OKRs
   • One-dimensional metrics without quality pairing
   • Fuzzy or unmeasurable KRs
   • Team-internal jargon
   • Too many OKRs
   • Sandbagging
   • Missing committed/aspirational classification
   • Missing dependencies

5. If company context is available, also check:

   • Alignment to strategic priorities
   • Use of approved terminology and metrics
   • Appropriate scope for the team level
   • Compliance with tooling format conventions

6. Produce a revised set that addresses all issues. Mark what changed and why.

Workflow 3: Decompose Company OKRs into Team OKRs

When the user has high-level objectives to break into team-level OKRs:

1. Get the parent OKR (company or division-level objective and its key results).

2. Get the list of teams that need to contribute.

3. Read references/skill-model.md — focus on the cascading process, top-down vs bottom-up, and alignment sections.

4. For each team, draft 1-2 objectives that support the parent OKR:

   • Each team's objectives should contribute to one or more parent key results
   • Write 3-5 measurable key results per team objective
   • Explicitly note cross-functional dependencies between teams
   • Include at least one bottom-up OKR per team
   • Classify each as committed or aspirational

5. Validate the decomposition:

   • No duplication — teams don't overlap on the same KR
   • Full coverage — every parent KR has at least one team contributing
   • Team KRs are within each team's control and influence
   • Dependencies are explicit and bidirectional

6. Score the full set against the review rubric.

Workflow 4: Refine and Iterate

When the user has feedback on draft OKRs and wants them improved:

1. Understand the feedback. Ask clarifying questions if the user's direction is ambiguous.

2. Apply the changes while preserving what was already strong.

3. Re-run the quality checklist and the review rubric after changes.

4. Show a before/after comparison highlighting what improved and any scores that changed.

5. Flag any remaining issues — don't let weaknesses slide just because they weren't in the feedback.

Workflow 5: OKR Coaching / Red Team

When the user wants OKRs stress-tested:

1. Read references/prompt-library.md — use the Red Team Exercise structure.

2. Challenge every OKR on these dimensions:

   • Perverse incentives: What could go wrong if pursued aggressively?
   • Gaming risk: How could someone hit the number without delivering real value?
   • Missing coverage: What important work is not represented?
   • Dependency blindness: What cross-team dependencies are hidden?
   • Ambition calibration: Are committed goals achievable? Are aspirational goals genuinely stretchy?
   • Measurability: Can every KR be objectively scored?
   • Alignment: Does every OKR connect to a strategic priority?
   • The "so what" test: If all OKRs are achieved, will it actually matter?

3. Rank the top 5 issues by risk severity.

4. Provide specific fixes for each issue.

5. Be constructive but rigorous. Flag mediocre OKRs clearly. Don't hedge.

Workflow 6: End-of-Cycle Scoring and Reflection

When the user wants to score a completed OKR cycle:

1. Read references/prompt-library.md — use the Scoring and Reflection structure.

2. Score each KR on a 0.0-1.0 scale using the traffic-light system:

   • Green (0.7-1.0): Delivered
   • Yellow (0.4-0.6): Progress made, needs attention
   • Red (0.0-0.3): Failed to make real progress

3. Assess each objective overall with a weighted score.

4. Reflect: What worked? What didn't? Were KRs well-chosen?

5. Recommend for next cycle: What carries forward? What's new? What drops?

6. Produce a cycle summary suitable for sharing with leadership.

Output Format

Always output OKRs in clean Markdown using this structure:

**Objective:** [statement]
Type: [COMMITTED / ASPIRATIONAL]

- **KR1:** [measurable result with target and date]
- **KR2:** [measurable result with target and date]
- **KR3:** [measurable result with target and date]

If company context specifies a richer format (e.g., NCT-style with narratives and commitments), use that format instead. Refer to assets/okr-template.md for the full template structure.

After drafting, always append the quality checklist results.

Quality Standards

Reference references/review-rubric.md for the full 10-criterion rubric. At minimum, every OKR must pass these checks before presenting to the user:

• Objective is outcome-oriented, not a task
• Objective fits on one line and is inspirational
• Key results are measurable with specific numbers and dates
• Key results describe outcomes, not outputs
• Key results are within the team's influence
• Metrics are unambiguous (define what counts)
• At least one quantity-quality KR pair exists
• Each OKR is classified as committed or aspirational
• No vanity metrics
• Timebound and scoped appropriately
• Connects clearly to a parent objective or strategic priority

Important Behaviors

• Always ask for strategic context before drafting — never guess at priorities
• Never present OKRs without running the quality checklist first
• When reviewing, score each rubric criterion explicitly with the 1-5 scale
• If company context is available, validate alignment to strategic priorities
• Prefer fewer, higher-quality OKRs over many weak ones
• Be opinionated — flag mediocre OKRs clearly, don't hedge or soften criticism
• When in doubt about ambition level, push toward stretch goals
• Always make dependencies explicit
• If the user provides OKRs in a company-specific format, preserve that format in your output