Update to okrdev

{
  "description": "Draft, pressure-test, and activate a cycle of OKRs — 1–3 objectives with measurable key results, one DRI each, and health metrics — written to okrdev/okrs/<cycle>.md. Use when someone wants to plan the next cycle or quarter, set or draft OKRs, start okrdev Level 1, restart after a finished or abandoned cycle, or asks \"what should our objectives be?\"",
  "included_files": [],
  "name": "plan",
  "skill_md_contents": "---\nname: plan\ndescription: Draft, pressure-test, and activate a cycle of OKRs — 1–3 objectives with measurable key results, one DRI each, and health metrics — written to okrdev/okrs/<cycle>.md. Use when someone wants to plan the next cycle or quarter, set or draft OKRs, start okrdev Level 1, restart after a finished or abandoned cycle, or asks \"what should our objectives be?\"\n---\n\n# Cycle planning\n\nYou are running okrdev's planning ritual: read the mission and last cycle's lessons, draft a\nstraw man, let the humans argue it into shape, and ship the result as `okrdev/okrs/<cycle>.md`.\nBudget ~90 minutes of human time. You draft; they decide. The full ritual script is in\ndocs/rituals.md and the full rulebook in docs/method.md (both ship with this plugin).\n\n## 1. Preflight\n\n1. **Is okrdev installed?** Check for `okrdev/config.md` in the repo root. If it's missing,\n   okrdev isn't installed here — say so and point at `/okrdev:install`. Stop.\n2. Read the `okrdev/config.md` frontmatter: `level`, `cycle_length`, `backstop`.\n3. **Level 0?** Then there's no mission and no cycles yet — planning is the move to Level 1,\n   and the human just asked for it by invoking you. Confirm in one line: \"This takes you from\n   parking-lot-only to full okrdev — a mission, cycle OKRs, weekly check-ins. Ready?\" On yes:\n   build `okrdev/MISSION.md` (step 2 below), create `okrdev/LESSONS.md` from\n   `templates/okrdev/LESSONS.md`, set `level: 1` in `okrdev/config.md`, and replace the\n   content between the `<!-- okrdev:start -->` / `<!-- okrdev:end -->` markers in `CLAUDE.md`\n   with the full canonical coach block from `templates/CLAUDE-okrdev.md`, verbatim — the\n   Level 0 block promises exactly this replacement, and without it the new cycle runs with a\n   coach that still thinks it's parking-lot-only. On no: stop — parking and triage keep\n   working fine at Level 0.\n4. **Existing cycle files?** List `okrdev/okrs/`:\n   - A file with `status: draft` → a planning session was left unfinished. Offer to resume it\n     instead of starting over.\n   - A file with `status: active` whose `end` date is still weeks away → the human probably\n     wants a mid-cycle change, not a new plan. Point at the amendment protocol: a PR to the\n     cycle file with a `Revised: <date> — <reason>` block preserving the original text\n     (docs/method.md). Never rewrite an active cycle from here.\n   - A file with `status: active` whose end date has passed or nearly passed → the cycle needs\n     closing first, and its retro is a planning input. Point at `/okrdev:retro`. If the cycle\n     is simply dead — weeks of silence, the team moved on — retro can close it unscored as\n     `abandoned` in two minutes; then come back here. No ceremony either way.\n\n## 2. Mission check\n\nRead `okrdev/MISSION.md`. Planning starts here because the coach cannot answer \"aligned to\nwhat?\" without it.\n\nIf it's missing or still placeholder text, build it now with a three-question interview,\none short paragraph per answer:\n\n1. What does this business or project exist to do?\n2. What's the current strategy, in a paragraph?\n3. Optionally: what are the 2–3 strategic bets this year?\n\nWrite the answers to `okrdev/MISSION.md`. Keep it short — a mission that takes ten minutes to\nread never gets read again.\n\n## 3. Pick the cycle\n\nDerive the cycle id from `cycle_length` in config.md:\n\n- `quarterly` → `<year>-Q<1–4>` (e.g. `2026-Q3`), start/end = the calendar quarter.\n- `six-week` → `<year>-C<n>` (e.g. `2026-C4`) — increment `n` from the most recent cycle file,\n  or start at `C1`; start = the agreed kickoff date, end = start + 6 weeks.\n\nPropose the id and dates; confirm with the humans. If planning mid-quarter, a short first\ncycle ending on the normal boundary beats a cycle that ignores the calendar everyone else uses.\n\n## 4. Gather inputs — before engaging the humans\n\nDo the reading before the meeting, so the humans spend their 90 minutes arguing, not waiting:\n\n- `okrdev/MISSION.md` — the alignment target.\n- `okrdev/LESSONS.md` — the most recent block: scores by type, adherence, lessons, revisions.\n  Carry its challenges into step 6. If last cycle's aspirational average was 0.4 and this\n  draft assumes double the throughput, you are the one who asks why this time is different.\n- `okrdev/PARKING_LOT.md`, the **Promoted** section — ideas that earned candidacy through\n  triage. These are the only ideas with a fast lane into planning; that's the parking lot\n  keeping its promise.\n- **Brownfield scan** (any repo with history): recent `git log`, open issues, merged PRs.\n  You're learning what the team actually spends effort on, versus what the mission says.\n  Anything that will consume real capacity this cycle should either become a KR or be named\n  as maintenance out loud — invisible workstreams are how cycles get quietly eaten.\n  Translate upward as you draft: `git log` speaks implementation language, so straw-man KRs\n  built from the scan take their vocabulary from `okrdev/MISSION.md` and prior check-ins'\n  \"What moved\" lines — the straw man arrives in the DRI's words, not the repo's.\n- **First cycle, no data anywhere?** Note which candidate KRs will need `baseline: unknown`\n  plus an instrumentation pairing (step 6). Don't invent numbers to look rigorous.\n\n## 5. Draft the straw man\n\nWrite a complete candidate cycle file before asking for opinions. Humans argue far better\nagainst something concrete than into a void — and arguing is the valuable part.\n\nHard constraints:\n\n- **1–3 objectives, 2–4 KRs each.** If you drafted more, cut before showing. Focus is the\n  whole point of the framework.\n- Each objective: qualitative, inspiring, time-bound.\n- **Exactly one human DRI per objective and per KR.** Never shared — shared ownership is no\n  ownership — and never you: the AI builds, coaches, and keeps the books, but accountability\n  stays human (docs/roles.md).\n- Each KR: `Type: committed | aspirational`, `Confidence: 0.5`, `Score: —`, and a heading of\n  the form `<metric> from <baseline> to <target>`.\n- **Milestone-shaped KRs** (no continuous metric): define the 0.3 / 0.7 / 1.0 stage anchors\n  now, in `Notes:` — e.g. `Notes: milestones — 0.3 pilot agreement signed / 0.7 three studios\n  live / 1.0 ten studios live`. Phrase every anchor as an observable past-tense event, never\n  an implementation state — \"pilot agreement signed,\" not \"backend deployed\" — which is\n  exactly why that example is the example: each stage either happened or it didn't. Retro\n  scoring uses these anchors; anchors invented at retro time are just vibes with a decimal\n  point, and a state-phrased anchor is a negotiation waiting for the retro.\n- **Health metrics**: 2–4 for the cycle, monitored not targeted, each with a red line and a\n  source. These are the things the cycle's pushing could break.\n\nThe exact file shape (also in `templates/okrdev/okrs/cycle.md`):\n\n```markdown\n---\ncycle: 2026-Q3\nstart: 2026-07-01\nend: 2026-09-30\nstatus: draft                 # flips to active at step 9; ids freeze then\n---\n\n# O1: <qualitative, inspiring, time-bound objective>\nDRI: alex\n\n## KR1.1: <metric> from <baseline> to <target>\nType: aspirational            # committed | aspirational\nDRI: alex\nConfidence: 0.5\nScore: —                      # set at retro\nNotes: —\n\n## KR1.2: ...\n\n# O2: ...\n\n## Health metrics (monitored, not targeted)\n| Metric | Red line | Source |\n|--------|----------|--------|\n| Support ticket volume | >40/wk | Helpdesk dashboard |\n```\n\n## 6. Pressure-test the draft\n\nWalk every KR through the quality gauntlet. This pushback is why planning has a coach —\ntranscribing whatever the room says first is the one failure mode you're here to prevent.\n\n- **Outcome, not output.** \"Ship the referral feature\" measures motion; \"referred signups\n  from 0 to 30/month\" measures the point of shipping it. If a KR is done the moment the code\n  merges, it's an output.\n- **Customer's words, not the toolchain's.** Every noun in a KR heading should survive being\n  said to a customer or stakeholder of the objective. The stakeholder test is primary; the\n  tool-name ban is only its most common verdict (\"Postgres is how, not what — what does the\n  studio owner notice when this works?\"). A technical domain's own terms pass (\"sev-1\n  incidents from 4 to ≤1\" is fine — sev-1 is a first-class noun of the reliability domain),\n  and when the objective's stakeholders are engineers — platform, infra, dev tools — their\n  tools are the domain's own nouns and pass too. Implementation-speak is the surface form of\n  an output KR: you can complete it while the business stands still.\n- **One objective, one vocabulary.** If arguing the KRs makes the DRI switch vocabularies\n  mid-list — half \"churn, activation, studio,\" half \"leads, quota, pipeline\" — it's two\n  objectives. The test: one DRI can argue every KR of the objective in its own words, without\n  a translator. And the lights-on challenge for the objective itself: \"this keeps the lights\n  on; it doesn't win anything — an objective, or a maintenance budget?\"\n- **Measurable, baseline → target stated.** `baseline: unknown` is allowed only when paired\n  with an instrumentation task that will establish it. First-cycle exception: \"Instrument X\n  and establish a baseline\" is itself a valid KR — new or unmeasured businesses can't state\n  numbers they don't have, and pretending otherwise poisons the first retro.\n- **\"Launch X\" needs a partner.** A launch KR is valid only alongside a usage or outcome KR.\n  Launches are the most seductive output-dressed-as-outcome.\n- **Sandbag check, now — not at retro.** Compare each target against the baseline's trend:\n  if the trend line lands there anyway, the KR is a prediction, not a goal. Challenge it with\n  the data. Catching this at planning is cheap; catching it at retro is too late.\n- **Committed vs aspirational mix.** Committed means expected score 1.0 — a miss requires a\n  root-cause note. Aspirational means 0.7 ≈ success. Reserve committed for genuine must-hits:\n  a 0.7 on payroll is a failure, not a stretch. Then check the mix: all-committed means no\n  ambition; all-aspirational means nothing is actually promised.\n- **Confidence starts at 0.5** — a good stretch KR is a coin flip at kickoff. Flag two smells:\n  a committed KR at 0.5 (if it's a coin flip, it isn't a commitment) and anything at 0.9\n  (either a sandbag or it belongs in maintenance).\n- **Quality pair.** Every volume or speed KR names the quality metric it could break, in its\n  `Notes:` or the health table. Goodhart's law does not take the cycle off.\n- **DRI load.** One person owning every KR is shared ownership wearing a trench coat. Spread\n  it, or shrink the plan.\n\nSolo founder? Run the same gauntlet arguing both sides, and push twice as hard — no colleague\nis going to.\n\n## 7. Humans decide\n\nPresent the straw man section by section and let them tear at it. Your pushback is advisory:\nif a DRI hears the challenge and keeps the KR, it stays, and you move on — planning pushback\nis not drift and nothing gets logged. The one non-negotiable exit condition: every objective\nand every KR leaves this step with a named human who said \"mine.\"\n\n## 8. Write the draft file\n\nWrite `okrdev/okrs/<cycle>.md` with `status: draft`, KR ids `KR<obj>.<n>` numbered in order\n(`KR1.1`, `KR1.2`, `KR2.1`, …). Warn the room now: ids freeze the moment the cycle goes\nactive. Dropped KRs keep their number forever with `Status: dropped`; renumbering is\nforbidden, because positional ids silently corrupt every downstream reference — check-ins,\nPR tags, commit trailers, lessons.\n\n## 9. Review and activate\n\nThe draft becomes official through a pull request — the review is the point: every DRI signs\noff on their own numbers where the diff is visible, and the PR is the audit trail of what was\nagreed.\n\n1. Create a branch, commit the cycle file, open the PR. With non-technical humans, narrate as\n   you go: \"I'm opening a pull request — a proposal page with a link where everyone can\n   comment before this becomes official.\"\n2. Take review as PR comments or in-session; push revisions.\n3. When every DRI has signed off, push a final commit flipping `status: draft` →\n   `status: active`, then merge. Merge is go-live. **Ids are frozen from this moment.**\n4. No remote, or the repo doesn't do PRs? Get an explicit go from each DRI in-session, then\n   commit straight to main with `status: active`. The sign-off is what matters, not the\n   button that recorded it.\n\n## 10. Close out\n\n- Confirm the active cycle in one screenful: objectives, KR ids, DRIs, health metrics, and\n  the date of the first check-in.\n- Update `okrdev/PARKING_LOT.md`: annotate Promoted items that made the cut (`→ KR2.1`);\n  items promoted but not taken stay put as next-cycle candidates.\n- Anything that came up during planning and didn't make the plan → park it now, one line in\n  Captured. Ten seconds. That's the habit the whole framework runs on (`/okrdev:park`).\n- Point at the cadence: `/okrdev:checkin`, weekly, ~15 real minutes because the coach\n  pre-drafts it. The first one anchors the ritual — get it on the calendar before everyone\n  leaves the room.\n"
}