em-okr-management v0.2.1 Delivery

Setting, reviewing, scoring and auditing OKRs. Grounds OKRs in the live Notion Client database and writes them to Tability as the system of record, enforcing real OKR craft at every stage.

Problem it solves: gives a full, opinionated OKR lifecycle that enforces bets-not-tasks, value-not-effort, binary scoring and the 80% owner pass rule - instead of vibes - with a quality rubric gate so weak OKRs never ship.

Quarter lifecycle em-okr-builder (start)→ em-okr-reviewer (mid)→ em-okr-scorer (close) · em-okr-auditor (anytime)
em-okr-builderUser skillMedium · ~20-80k

Drafts a quarter's OKRs from a need-first interview, runs a mandatory quality-rubric gate, then writes Outcomes, opening check-ins and Initiatives to Tability after explicit confirmation. Pushes back when a "KR" is really a task.

When to use it
build OKRsplan OKRscreate OKRsset OKRs for the accountwhat should our OKRs be
How it works
  1. Resolve the Tability planFetches the account's Client DB row and Tability workspace, creating the plan shell if it does not exist yet.
  2. Frame the bets firstRuns a need-first interview - what 1-3 bets the account is making, what problems they solve, what success looks like.
  3. Turn each need into metricsWrites the qualitative objective, identifies value drivers, and defines measurable KRs with initial and target values, gated against the rubric.
  4. Present a copy-paste draftShows the objectives and KR matrix (outcome type, score format, initial, target) for EM review or straight-to-Tability.
  5. Create outcomes and initiativesAfter the EM confirms, writes the Outcomes with opening check-ins and auto-creates Initiatives for milestones and TBD baselines.
Example
You say
"build OKRs for Acme Robotics Q3" - Alex Rivera says the team is betting on (1) launching robotic arm v2 with better precision, (2) cutting support tickets 30%, (3) onboarding the first partner integrations.
You get back
Three Objectives in Tability with measurable KRs (e.g. "support tickets 450 → 315", "partner integrations live 0 → 3"), opening check-ins, and auto-created Initiatives for the precision milestone and the partner decision gate.

Gotcha: It never invents an initial value - if a baseline is unknown it pauses and asks rather than guessing.

Gotcha: Activity-shaped KRs ("run the workshop") are demoted to Initiatives - the headline KRs stay outcomes.

Reference - what it brings, its process, and what it needs
BringsTurns a blank quarter into a publishable, rubric-clean OKR set without hand-crafting Tability metric types; produces a copy-paste list + KR matrix.
Process
  1. Resolve plan; gather Client DB context.
  2. Frame 1-3 bets; build need → value → metric.
  3. Pass the quality-rubric gate.
  4. EM makes Objective shells; skill creates Outcomes, check-ins, Initiatives; logs to changelog.
NeedsTabilityNotion (Client DB)engagement_level_db
em-okr-reviewerUser skillMedium · ~20-80k

Mid-quarter check-in. Pulls the plan, computes pace per Outcome by type, runs the off-track escalation chain and an 80% "pass-the-quarter" simulator, then posts a per-KR check-in anchored to the previous one.

When to use it
review OKRsmid-quarter checkhow are we trackingrun the OKR simulatorcheck-in for the account
How it works
  1. Pull the current plan stateFetches the Tability plan with each Outcome's two latest check-ins, scores, and Initiatives in one call.
  2. Compute pace per outcomeCalculates actual vs expected progress and infers confidence (on track / at risk / off track) from elapsed days and metric deltas.
  3. Run the escalation chainFlags any KR off-track or at-risk for two consecutive cycles, which triggers a meeting request within five business days.
  4. Simulate the 80% quarterProjects each KR's final score at current pace, computes the owner pass rate, and names the KRs that would flip the result.
  5. Post per-KR check-insAnchors each check-in on the prior state, captures the new state, and posts it after the EM confirms.
Example
You say
"review OKRs for Acme Robotics mid-Q3" - precision moved 0% → 40%, support tickets 450 → 380 (target 315), partner integrations stuck at 0 of 3 on API blockers.
You get back
Pace computed (precision on track, support at risk, partners off track), partners flagged as a new off-track cycle, three check-ins posted, the API-sync risk carried forward, and a simulator projection showing 2/3 passing (below the 80% bar).

Gotcha: It quotes full KR titles verbatim in every output - never abbreviated or paraphrased.

Gotcha: Early-quarter projections (under ~15% elapsed) are unreliable and are suppressed or labelled low-confidence.

Reference - what it brings, its process, and what it needs
BringsConverts raw scores into pace / confidence and surfaces the 2-consecutive-cycle mandatory-meeting trigger before it becomes a fire.
Process
  1. Pull current state; compute pace + confidence.
  2. Detect off-track patterns; run the 80% simulator.
  3. Per-KR check-in loop; collect new state; post.
  4. Auto-create Initiatives; log to changelog.
NeedsTabilityNotionengagement_level_db
em-okr-scorerUser skillLight · ~5-20k

End-of-quarter close. Computes binary pass / fail per Outcome, applies the 80% owner pass rate, posts final check-ins and closes open Initiatives. Pulls full history for stay-above / stay-below KRs to catch mid-quarter red dips.

When to use it
score OKRsclose the quarterend of quarter scoringfinal scoring for the account
How it works
  1. Pull the full historyFetches the plan and all Outcomes; for stay-above / stay-below KRs it pulls the whole check-in history to catch mid-quarter red dips.
  2. Flag stale and TBD KRsIdentifies KRs never updated from their initial value or with null targets, asking the EM for a final value or to close as Deferred.
  3. Compute pass / fail per KRApplies the outcome-type pass condition to each KR, asking about historical red dips on stay-above / stay-below KRs.
  4. Compute the 80% owner pass rateFilters the EM's KRs in the plan and passes the quarter only when at least 80% passed, naming the gap.
  5. Post final check-insAfter the EM confirms the rationale and lessons, writes the closing check-in per Outcome, settles Initiatives, and logs to the Account Changelog.
Example
You say
"score OKRs for Acme Robotics end-Q3" - precision hit 95% (target 100%), support at 310 (target 315, passed), partners 1 of 3, one conditional partner KR never activated.
You get back
Three passing KRs and one failing, an owner pass rate of 75% (Quarter = FAIL), final check-ins with a one-line rationale and lesson, the conditional KR closed Deferred, and a changelog row recorded.

Gotcha: The 80% rule is scoped per sub-plan, not pooled across sub-plans or per-objective.

Gotcha: A conditional KR that was never activated is closed as Deferred with a note, never scored as a FAIL.

Reference - what it brings, its process, and what it needs
BringsA defensible, binary close - no partial credit, an honest one-line rationale + lesson per KR, and an owner-level PASS / FAIL.
Process
  1. Pull plan content + per-Outcome history.
  2. Stale / TBD pre-check (block until resolved).
  3. Compute binary pass/fail; apply the 80% rule.
  4. Post final check-ins; close Initiatives; log.
NeedsTabilityNotionengagement_level_db
em-okr-auditorRead-onlyLight · ~5-20k

A read-only quality audit. Grades a live plan or a pasted draft against the shared rubric, tags each finding Blocker / Warning / Nit, and gives at least two concrete before → after rewrites per flagged item. Returns SHIP-READY or NEEDS WORK.

When to use it
audit OKRsreview OKR qualityare these good OKRsgrade our OKRs for [account]check OKR quality
Reference - what it brings, its process, and what it needs
BringsA second-opinion gate you can run anytime - including on a builder draft pre-publish - that shows how to fix each weak OKR, not just what's wrong.
Process
  1. Resolve a live plan or parse a pasted draft.
  2. Run the rubric per item with severity tags.
  3. Give ≥2 rewrites per Blocker / Warning.
  4. Compute the verdict; never writes OKRs.
NeedsTability (read)Notion (read)