okrdev

View saved version →

---
name: checkin
description: Run the weekly okrdev check-in — pre-drafts the confidence table, "what moved" from git and merged PRs, the drift check, and health metrics before the humans arrive, then walks them through the parts only they can do. Use when someone says "run our check-in", "weekly check-in", "let's do the OKR check-in", "time for the checkin", when a check-in is overdue and the user agrees to catch up, or when a single DRI wants to file their async contribution to this week's check-in.
---

# Weekly check-in

The check-in is fifteen minutes because you do the homework first. Everything computable gets
pre-drafted from git, PRs, and last week's file before you engage anyone. The humans only do
what humans must: adjust confidence, make triage calls, name next week's focus. If this ritual
costs more than its minutes, it dies — protect the fifteen.

## Preflight

1. Check that `okrdev/config.md` exists. If not, okrdev isn't installed in this repo — say so
   and point at `/okrdev:install`. Stop.

2. Read `okrdev/config.md`: `level`, `checkin_cadence`, `side_quest_box_hours_per_week`, and
   `backstop`. If `level: 0`, there is no cycle and no check-in ritual yet — that's by design.
   Offer the two things that make sense instead: triage the parking lot now (`/okrdev:triage`),
   or draft a first cycle (`/okrdev:plan`). Stop.

3. Find the active cycle: the file in `okrdev/okrs/` whose frontmatter says `status: active`.
   - A `draft` but nothing active → planning isn't finished; point at `/okrdev:plan`. Stop.
   - Nothing at all → point at `/okrdev:plan`. Stop.
   Read the cycle file fully: objectives, KR ids, types, DRIs, current confidence, the health
   metrics table, and the `start`/`end` dates. Compute how far through the cycle you are —
   `(today − start) / (end − start)` — you'll need it for the sandbag triggers.

4. Compute this week's file path. ISO week via `date +%G-W%V` (today that gives something like
   `2026-W29`). The path is deterministic: `okrdev/checkins/<cycle>/<yyyy-Www>.md`, e.g.
   `okrdev/checkins/2026-Q3/2026-W29.md`. Deterministic paths are the point — overrides logged
   on a Tuesday and async contributions on a Thursday land in the same file without anyone
   coordinating.

5. If the file already exists, do not clobber it. It may hold judgment calls logged mid-week or
   another DRI's async section. Load it, fill only what's empty, and append — never rewrite
   someone else's lines.

## Handle gaps first

6. Find the most recent **held** check-in in `okrdev/checkins/<cycle>/` — the newest file whose
   KR confidence table has at least one KR row. Skip files that have one but left it empty:
   those are week files created to log a judgment call or pre-drafted and never held, and
   counting them as check-ins is how a skipped ritual silences its own alarm (the definition
   and the reasoning are in [rituals.md](../../docs/rituals.md)). If it's more than 10 days
   old (or there is none and the cycle started more than 10 days ago), offer the gap-spanning
   catch-up before anything else: one "what moved" covering the whole gap, one confidence pass,
   two minutes total. No week-by-week archaeology, and no guilt trip — systems die by silent
   decay, and the recovery has to be cheaper than the shame of the lapse. Note the span in the
   What moved section ("covers W27–W29").

7. If the cycle is effectively dead — the end date has passed unscored, or the team says they
   quietly stopped — offer to close it without ceremony: set `status: abandoned` in the cycle
   file, then point at `/okrdev:plan` for a fresh start. A dead cycle closed honestly is worth
   more than a zombie one maintained out of duty.

## Pre-draft everything

8. Before engaging any human, draft the full file (create it from the canonical skeleton below
   if it doesn't exist):

   ```markdown
   ---
   cycle: 2026-Q3
   week: 2026-W29
   attendees: [alex, jordan]     # omit or single-name for solo mode
   ---

   ## Wins

Preview of the first 4,000 characters. Read full instructions →

View saved version →

---
name: coach
description: On-demand status and alignment check from the okrdev coach — confidence trends, drift since the last check-in, health metrics, open-PR status in plain language, and side-quest/maintenance/emergency budget usage. Use when someone asks "how are we doing", "where do we stand on the OKRs", "is this aligned?", "should I build this?", "what should I work on today?", "what's drifting", "any red flags this week", or wants a mid-week pulse without running a full check-in.
---

# Coach

This is the anytime entry point to the okrdev coach. A check-in (`/okrdev:checkin`) writes
the weekly file; this skill mostly reads and talks. It writes exactly one thing: judgment-call
lines when a human overrides you. The full coach contract — authority, tone, everything you
may and may not do — is `docs/ai-coach.md`.

## Procedure

1. **Check the install.** If `okrdev/config.md` doesn't exist, okrdev isn't installed here.
   Say so in one line, offer `/okrdev:install` (Level 0 takes ten minutes), and stop.

2. **Read the ground truth.**
   - `okrdev/config.md` — level, side-quest budget, backstop.
   - The active cycle: the file in `okrdev/okrs/` with `status: active` in its frontmatter.
   - `okrdev/PARKING_LOT.md`.
   - Open `okrdev:parked` issues, when `gh` is available and the remote is GitHub
     (`gh issue list --label okrdev:parked --state open`) — these count as un-triaged
     captures alongside the file's Captured section.
   - The latest check-in: newest file in `okrdev/checkins/<cycle>/`.
   - `okrdev/MISSION.md`, if present — alignment questions trace back to it.

3. **No active cycle? Behave for the level.**
   - **Level 0**: there is no cycle by design, so report parking-lot health instead: how many
     un-triaged captures — open `okrdev:parked` issues plus Captured lines — and how old
     (items older than about two weeks mean triage isn't happening — suggest
     `/okrdev:triage`), open side-quests against their boxes. Then answer
     whatever was actually asked. Mention once, without pushing, that `/okrdev:install` moves
     to Level 1 and `/okrdev:plan` drafts objectives when they're ready.
   - **Level 1+**: a cycle file with `status: draft` → it was never activated; offer to help
     land the PR that flips it to `active`. No cycle file at all → suggest `/okrdev:plan`. A
     cycle past its `end:` date but still `active` → suggest `/okrdev:retro`.

4. **Staleness before anything else.** If the last **held** check-in is more than 10 days old
   in an active cycle, raise it before answering the actual question, and offer the two-minute
   gap-spanning catch-up (`/okrdev:checkin`). Held means the newest check-in file whose KR
   confidence table has at least one KR row — a week file holding only a judgment call is not
   a check-in and must not suppress this (definition:
   [rituals.md](../../docs/rituals.md)). No guilt trips — systems die by silent decay,
   and the fix is a catch-up, not an apology. If the cycle is plainly dead, offer to close it
   unscored (`status: abandoned`) and start a new one. That's allowed, without ceremony.

5. **Figure out the ask.** Bare `/okrdev:coach` → full status (step 6). "Is this aligned?" or
   "should I build X?" → step 7. A specific area ("how's confidence?", "any drift?") → just
   that slice of step 6.

6. **Full status.** Gather everything first, then report short and actionable-first.

   a. **Confidence trends.** Pull the latest per-KR confidence from the cycle file and the
      check-in tables, and flag the four triggers:
      - **Below 0.5 two consecutive weeks** → the DRI owes a named decision: re-scope,
        re-staff, kill, or accept-the-miss — logged in Judgment calls. Confidence that
        changes nothing is theater.
      - **Unchanged three or more weeks** → the DRI owes one line of evidence at the next
        check-in. A number nobody re-examines is decoration.
      - **At or above 0.9 from week one, or the target already hit before 60% o

Preview of the first 4,000 characters. Read full instructions →

View saved version →

---
name: install
description: Install, upgrade, or level-up okrdev in the current repo. Walks the adoption ladder — Level 0 parking lot, Level 1 method, Level 2 collaboration rails, optional stack module — creating okrdev/ files from templates, appending the marked coach block to the host agent's instructions file (CLAUDE.md or AGENTS.md), and merging (never overwriting) anything that already exists. Use when someone says "install okrdev", "set up okrdev", "add okrdev to this repo", "upgrade okrdev", "move us to Level 1/2", or asks how to get started with okrdev.
---

# Install okrdev

You are installing okrdev into the repo the user is working in (the "target repo"). Paths
starting with `templates/` refer to files shipped with this plugin; every other path is
relative to the target repo root. If you can't locate the plugin's templates directory (skills
copied without templates, or a surface that can't reach plugin files), don't stop: recreate the
files from the canonical formats embedded in the skills and docs — the parking-lot format in
`/okrdev:park`, the check-in skeleton in `/okrdev:checkin`, the config frontmatter in step 4
below, and the coach blocks quoted in this file.

Two rules govern everything below:

- **Start at the lowest level that delivers value.** Level 0 works standalone and takes ten
  minutes. Never install a level the user didn't ask for — unused ceremony is how frameworks
  get deleted by week three.
- **Never overwrite an existing file.** Every collision gets a proposed merge and a question,
  not a silent clobber.

## Procedure

1. **Detect state.** In the target repo, check:
   - Is this a git repo? (`git rev-parse --is-inside-work-tree`)
   - Does `okrdev/` exist? Does `okrdev/config.md` carry `okrdev_version` in its frontmatter?
   - **Which file does the host agent read?** `CLAUDE.md` on Claude Code, `AGENTS.md` on
     Codex. This is the *only* platform-specific thing about an okrdev install — the coach
     block itself carries no platform tokens, so nothing else forks. Resolve it in this order,
     and stop at the first hit:
     1. **Existing markers win.** If either file already contains `<!-- okrdev:start -->`,
        that file is the destination, whatever the host. A repo that was installed from one
        agent and is now being upgraded from another must not sprout a second block.
     2. Otherwise, the host you are running in.
     3. If you genuinely cannot tell, ask — one question, with the default named.
   - Does that file contain `<!-- okrdev:start -->`?
   - **Do *both* `CLAUDE.md` and `AGENTS.md` carry the markers?** They should never. If they
     do, say so and stop: two coach blocks drift, and the repo needs a human to say which one
     is real. Offer to delete the other after they choose.
   - Do `.github/pull_request_template.md`, `.github/CODEOWNERS`, or
     `.github/workflows/okr-gate.yml` already exist?

   Classify the state:
   - **Fresh** — no okrdev traces. Continue at step 2.
   - **Partial** — some okrdev files but no version marker (hand-rolled or interrupted
     install). Fill the gaps using the steps below, skip anything that exists, and add the
     version marker and any missing frontmatter keys to `okrdev/config.md`.
   - **Existing** — version marker present. If the user wants a *higher level*, run only the
     steps for the new level and update `level:` in `okrdev/config.md`. Otherwise treat it as
     an upgrade — see "Upgrading" below.

2. **Not a git repo?** Offer to `git init`. okrdev's storage is git-native — versioned,
   reviewable by PR, greppable by agents — so a repo is required. If this is not a software
   business, say plainly: the repo can contain nothing but `okrdev/`; it's just the ledger.
   Details in `docs/adoption.md`.

3. **Walk the ladder.** Present it and ask where to start. Default to Level 0 unless the user
   clearly wants more. Each level assumes the ones below it.

   | Level | What it adds | Time |
   |-------|-------------

Preview of the first 4,000 characters. Read full instructions →

View saved version →

---
name: park
description: Capture an idea into the okrdev parking lot in ten seconds — one line, energy, effort, done — then get back to work. Use when the user says "park this", "park that idea", "add it to the parking lot", "idea for later", "don't let me forget", or when a mid-session idea is about to turn into mid-session work.
---

# Park

Capture an idea into the okrdev parking lot — a GitHub issue labeled `okrdev:parked` when the
repo lives on GitHub, a line in `okrdev/PARKING_LOT.md` otherwise — and return the human to
what they were doing. Target: ten seconds of their attention. Capture is nearly free so that acting on impulse never
has to be — that's the deal the whole parking lot rests on.

The one rule that matters: **you are recording the idea, not evaluating it.** No feasibility
take, no design sketch, no clarifying questions about scope, no "interesting — you could also…".
The moment analysis starts, the idea has started winning. Building takes days; parking takes
one line. Triage — at the weekly check-in — is where the idea gets its hearing.

## Procedure

1. **Check the install.**
   - No `okrdev/` directory → okrdev isn't installed here. Say so and point at
     `/okrdev:install` — Level 0 is this file plus a config and takes ten minutes. Offer to
     hold the idea in the conversation and park it the moment install finishes.
   - `okrdev/` exists but `okrdev/PARKING_LOT.md` is missing, or has lost its section
     headings → repair it to the format reference below (add what's missing, never delete
     existing lines), then continue.
   - No active cycle → irrelevant. Parking needs no cycle, no mission, no check-in history.
     Capture must never wait on ceremony; that's the point of Level 0.

2. **Get the line.** One sentence, in the capturer's own words. If the human already stated
   the idea, use what they said — don't make them repeat it. Then the two five-second calls,
   asked together in a single question if you can't infer them from how the idea arrived:
   - `energy:` high / med / low — how excited the capturer is, right now.
   - `effort:` S / M / L — gut-call size.

   Accept the first answer. These are instincts, not estimates — do not help the human "think
   it through"; that's analysis wearing a costume. If they wave the question off, make your
   best call from context and name it in your confirmation so they can correct you.

3. **Identify the capturer.** Use the handle this repo's okrdev files already use for this
   person (check-in `attendees`, KR `DRI:` lines, `backstop` in `okrdev/config.md`). Failing
   that, `git config user.name`, lowercased. Ask only if you genuinely can't tell.

4. **Capture it — issue first, file as fallback.** One entry per idea — if the human is
   dumping several at once ("park three things from my phone notes"), capture each with its
   own energy and effort call. Batch the questions; don't run the ritual three times.

   - **Primary — GitHub issue** (when `gh` is authed and the repo's remote is GitHub):

     ```bash
     gh issue create --label okrdev:parked \
       --title "<one-line idea, verbatim>" \
       --body "@<who> — energy: <high|med|low> — effort: <S|M|L>"
     ```

     Zero commits, zero CI, one API call — the ten-second promise, kept on any repo,
     protected or not. If the label doesn't exist yet, create it first:

     ```bash
     gh label create okrdev:parked --color F9D71C \
       --description "okrdev parking-lot inbox — triaged weekly, then closed"
     ```

     Parked issues are inert by convention: never assign, milestone, or work one. Open means
     captured; triage closes it with the decision as a comment. The idea lives in the issue
     until then — don't also write a Captured line. A side benefit worth knowing about: the
     human can park from the GitHub mobile app, and collaborators can park from the GitHub
     UI, no Claude session required.

   - **Fallback — file append** (no `gh`, no remote, or the remote isn't 

Preview of the first 4,000 characters. Read full instructions →

View saved version →

---
name: plan
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?"
---

# Cycle planning

You are running okrdev's planning ritual: read the mission and last cycle's lessons, draft a
straw man, let the humans argue it into shape, and ship the result as `okrdev/okrs/<cycle>.md`.
Budget ~90 minutes of human time. You draft; they decide. The full ritual script is in
docs/rituals.md and the full rulebook in docs/method.md (both ship with this plugin).

## 1. Preflight

1. **Is okrdev installed?** Check for `okrdev/config.md` in the repo root. If it's missing,
   okrdev isn't installed here — say so and point at `/okrdev:install`. Stop.
2. Read the `okrdev/config.md` frontmatter: `level`, `cycle_length`, `backstop`.
3. **Level 0?** Then there's no mission and no cycles yet — planning is the move to Level 1,
   and the human just asked for it by invoking you. Confirm in one line: "This takes you from
   parking-lot-only to full okrdev — a mission, cycle OKRs, weekly check-ins. Ready?" On yes:
   build `okrdev/MISSION.md` (step 2 below), create `okrdev/LESSONS.md` from
   `templates/okrdev/LESSONS.md`, set `level: 1` in `okrdev/config.md`, and replace the
   content between the `<!-- okrdev:start -->` / `<!-- okrdev:end -->` markers in `CLAUDE.md`
   with the full canonical coach block from `templates/CLAUDE-okrdev.md`, verbatim — the
   Level 0 block promises exactly this replacement, and without it the new cycle runs with a
   coach that still thinks it's parking-lot-only. On no: stop — parking and triage keep
   working fine at Level 0.
4. **Existing cycle files?** List `okrdev/okrs/`:
   - A file with `status: draft` → a planning session was left unfinished. Offer to resume it
     instead of starting over.
   - A file with `status: active` whose `end` date is still weeks away → the human probably
     wants a mid-cycle change, not a new plan. Point at the amendment protocol: a PR to the
     cycle file with a `Revised: <date> — <reason>` block preserving the original text
     (docs/method.md). Never rewrite an active cycle from here.
   - A file with `status: active` whose end date has passed or nearly passed → the cycle needs
     closing first, and its retro is a planning input. Point at `/okrdev:retro`. If the cycle
     is simply dead — weeks of silence, the team moved on — retro can close it unscored as
     `abandoned` in two minutes; then come back here. No ceremony either way.

## 2. Mission check

Read `okrdev/MISSION.md`. Planning starts here because the coach cannot answer "aligned to
what?" without it.

If it's missing or still placeholder text, build it now with a three-question interview,
one short paragraph per answer:

1. What does this business or project exist to do?
2. What's the current strategy, in a paragraph?
3. Optionally: what are the 2–3 strategic bets this year?

Write the answers to `okrdev/MISSION.md`. Keep it short — a mission that takes ten minutes to
read never gets read again.

## 3. Pick the cycle

Derive the cycle id from `cycle_length` in config.md:

- `quarterly` → `<year>-Q<1–4>` (e.g. `2026-Q3`), start/end = the calendar quarter.
- `six-week` → `<year>-C<n>` (e.g. `2026-C4`) — increment `n` from the most recent cycle file,
  or start at `C1`; start = the agreed kickoff date, end = start + 6 weeks.

Propose the id and dates; confirm with the humans. If planning mid-quarter, a short first
cycle ending on the normal boundary beats a cycle that ignores the calendar everyone else uses.

## 4. Gather inputs — before engaging the humans

Do the reading before the meeting, so the humans spend their 90 minutes arguing, not waiting:

- `okrdev/MISSION.md` — the alignment target.
- `okrdev/LES

Preview of the first 4,000 characters. Read full instructions →

View saved version →

---
name: retro
description: Score a finished OKR cycle against the rubric, challenge inflated and sandbagged scores, extract three lessons into okrdev/LESSONS.md, and close the cycle as scored (or abandoned). Use when a cycle is ending or has ended, someone says "run our retro", "score the quarter", "close out this cycle", or a dead cycle needs an honest burial before planning the next one.
---

# Cycle retro

You are running okrdev's retro: score every KR against the rubric, make the scores survive
scrutiny, turn the cycle into exactly three lessons, and close the file. Budget ~60 minutes
of human time. Like check-ins, you pre-draft everything — the humans' time goes to judgment,
not arithmetic. The ritual script is in docs/rituals.md; the scoring rules in docs/method.md
(both ship with this plugin).

## 1. Preflight

1. **Is okrdev installed?** Check for `okrdev/config.md` in the repo root. Missing → say so
   and point at `/okrdev:install`. Stop.
2. Read `okrdev/config.md` frontmatter for `level` and `cycle_length`.
3. **Level 0?** There are no cycles at Level 0 — nothing to retro. Say so and point at
   `/okrdev:plan`, which handles the upgrade to Level 1 when they're ready.
4. **Find the cycle.** Look in `okrdev/okrs/` for the file with `status: active` (or the
   cycle the human named).
   - No active cycle and no file at all → nothing to score; point at `/okrdev:plan`.
   - Only `scored` or `abandoned` files → the last cycle is already closed. Summarize its
     LESSONS.md block in two lines and point at `/okrdev:plan`.
   - Active cycle whose `end` date is still weeks away → confirm intent: "Scoring now closes
     the cycle early — right call if it's truly done, otherwise wait." Proceed only on a
     clear yes.

## 2. The abandoned path — offer it when it's honest

If the cycle is dead — check-ins stopped weeks ago, the team pivoted, nobody can say what the
numbers are — don't force a scoring theater. Offer to close it unscored:

1. Flip the cycle file to `status: abandoned`.
2. Append one dated line to `okrdev/LESSONS.md`: the cycle id, `abandoned`, and the reason in
   the team's own words.
3. Commit, and point straight at `/okrdev:plan`.

Two minutes, no inquisition. Systems die by silent decay, not by decision — an honest
abandonment is a decision, and it beats a zombie cycle blocking the next real one.

## 3. Pre-draft the scoring sheet — before engaging the humans

Read, compute, and assemble everything first:

- **The cycle file**: every KR with its type, DRI, baseline, target, milestone anchors
  (`Notes:`), `Revised:` blocks, and `Status: dropped` markers.
- **Every check-in in `okrdev/checkins/<cycle>/`**: build a per-KR confidence history
  (needed for sandbag detection and for confronting score/confidence mismatches), pull
  evidence from "What moved," and collect the cycle's Judgment calls — overrides, emergency
  post-hoc reviews, mid-cycle revisions.
- **Check-in adherence**: check-ins held ÷ weeks in the cycle (e.g. `11/13`). This goes in
  LESSONS.md; a low number is usually the first lesson writing itself.
- **Proposed scores**: pre-fill wherever the actual is already in evidence. For each metric
  KR you'll need the actual number — pull it from check-ins if recorded, otherwise flag it
  for the DRI to bring.
- **Cycle-wide tallies**: emergency count (more than 2 in a cycle gets said out loud — the
  one unaudited escape hatch is where all gaming funnels), side-quest box-hours spent, and
  maintenance share if computable from PR/commit `KR:` tags.

## 4. Score, KR by KR

Walk the sheet with the room (solo mode: with the one human — you argue the other side).
For each KR, the DRI states the actual; you apply the rubric:

- **Metric KRs**: `score = clamp((actual − baseline) / (target − baseline), 0, 1)`.
  The formula exists so retros don't degenerate into vibes. No actual number available →
  that's not a scoring problem, it's an instrumentation lesson; score conservatively from
  what evidence exis

Preview of the first 4,000 characters. Read full instructions →

View saved version →

---
name: side-quest
description: Sanction a distraction on the spot — time-box it, log it in the parking lot, and note what the human is stepping away from. Use when someone wants to chase an off-OKR idea right now ("I know it's not a KR but I want to build this today"), says "side quest", asks to spend an afternoon on something off-plan, wants to extend or close a running side quest, or asks how much side-quest budget is left this week.
---

# Side quest

The parking lot only works if it isn't a straitjacket. Sometimes a human wants to chase the
shiny thing today, and the honest move is to sanction it — with a box, on the record — rather
than watch them do it anyway and call it something else. A side quest is a distraction that
said its name out loud. Your job is to make that take under a minute.

## Preflight

1. Check that `okrdev/config.md` exists. If not, okrdev isn't installed — point at
   `/okrdev:install` and stop. Read `side_quest_box_hours_per_week` from the config frontmatter
   (default 4).

2. Check that `okrdev/PARKING_LOT.md` exists — every install level has it, including Level 0.
   If it's somehow missing from an otherwise-installed repo, recreate it with the four standard
   sections (Captured / Side quests / Promoted / Archived) and carry on.

3. This skill works at every level. No active cycle is fine — Level 0 users get boxes and logs
   too; they just don't get the "stepping away from" reminder, because there's nothing on
   record to step away from yet.

## Check it's actually a side quest

4. One quick classification pass — not an interrogation, one question at most:
   - Serves an active KR? Then it's just work. Tag it `KR: <id>` and go — no box needed.
   - Something's broken and users are hurting? That's `emergency`. Tag it, go, and it gets its
     post-hoc review ("was it? what did it protect?") at the next check-in.
   - A bugfix, config change, or small cleanup? That's `maintenance`. Say so in one line, go.
   - None of the above, and they want to do it anyway? Side quest. Continue.

## Sanction it

5. **Find or capture the idea.** Check both inboxes: the Captured section of
   `okrdev/PARKING_LOT.md`, and — when `gh` is available — open `okrdev:parked` issues
   (`gh issue list --label okrdev:parked --state open`). A file line gets used as-is; an
   issue gets its close-with-comment in step 9, once the box is set. If it's parked nowhere,
   capture it now at the standard 10-second bar: one line, `energy` (high/med/low — how
   excited they are), `effort` (S/M/L — gut call). Do not start analyzing the idea; analysis
   is how a 10-second capture becomes a 40-minute detour.

6. **Set the box.** Required, always — a side quest without a time-box is just drift with
   permission. Ask for hours, or propose from the effort call: S ≈ 2h, M ≈ 4h. If it's an L,
   challenge it: that's not a side quest, that's a project wearing a costume. Offer to leave it
   in Captured as a promotion candidate for the next `/okrdev:plan` instead.

7. **Check the budget.** Sum the `box:` hours on side quests this person opened this ISO week
   and compare against `side_quest_box_hours_per_week`. Budgets are in box-hours because
   "10% of your time" is unmeasurable and box-hours are already captured. If this quest would
   blow the budget, say so plainly, once. If they proceed anyway, that's an override — proceed
   immediately and log one line in the Judgment calls section of this week's check-in file
   (`okrdev/checkins/<cycle>/<yyyy-Www>.md`, created from the skeleton if missing):
   `- <date> — <who> — <reason> — <branch/PR>`. At Level 0 there are no check-in files; put
   the overage note in the quest's `notes:` field instead.

8. **Say what they're stepping away from.** If there's an active cycle, name their KRs and
   their focus lines from the latest check-in — one or two lines, maximum. The point is a
   conscious trade, not guilt: "You're boxing 4h away from KR1.2, which is at 0.4 confidence.
   Still want i

Preview of the first 4,000 characters. Read full instructions →

View saved version →

---
name: triage
description: Walk every parked idea — open okrdev:parked GitHub issues plus the parking lot's Captured section — to a decision (promote, archive, or side-quest with a time-box); then check the side-quest budget. Use when the user says "triage the parking lot", "triage the parked issues", "go through my parked ideas", "clean up the ideas list", or as the parking-lot step of a weekly check-in.
---

# Triage

Give every parked idea a decision — the inbox is open `okrdev:parked` issues plus
`okrdev/PARKING_LOT.md`'s Captured section — then sweep the open side-quests and report the
box-hours budget. Triage is the other half of the capture deal:
"park it" is only an acceptable answer because every parked idea gets a fair hearing within a
week. Skip triage for a few weeks and the parking lot stops being a rudder and becomes a
graveyard — and people stop parking.

Usually this runs inside `/okrdev:checkin` as the "Parking lot triage" section. It also runs
standalone, any day, at any install level — a Level 0 install is exactly a parking lot plus
this ritual.

Pace matters: seconds to a minute per item, not a debate. An item that needs real discussion
has answered its own question — it's a planning topic. Promote it as a next-cycle candidate
and argue about it at planning, where arguing is the job.

## Procedure

1. **Check the install and load context.**
   - No `okrdev/` directory → point at `/okrdev:install` and stop.
   - `okrdev/PARKING_LOT.md` missing or missing its section headings → repair it to the
     canonical format (see the format reference in [../park/SKILL.md](../park/SKILL.md)),
     preserving any existing lines, then continue.
   - Read `okrdev/config.md` for `side_quest_box_hours_per_week` (default 4).
   - Gather the second inbox: when `gh` is authed and the repo's remote is GitHub, list the
     open parked issues with `gh issue list --label okrdev:parked --state open`. Two inboxes
     — issues and the file's Captured section — one ledger: every item gets the same
     three-way decision, and every decision lands in the file.
   - Find the active cycle: the file in `okrdev/okrs/` with `status: active`. No active cycle
     (Level 0, or between cycles) is fine — triage still runs; it just changes what "promote"
     means (step 4).
   - Note whether you were invoked from a check-in. If so, decisions also get mirrored into
     the check-in file (step 6).

2. **Report the state before deciding anything.** Two lines: how many items are in the
   inboxes (open `okrdev:parked` issues plus Captured lines, oldest first — ideas shouldn't
   rot at the bottom), and the side-quest budget: for each
   person, sum the `box:` hours of side quests they opened this ISO week (by the line's date)
   and compare to the weekly budget. Box-hours are a crude proxy for committed distraction
   time — say so — but it's the number everyone agreed to steer by. Quests still open from
   earlier weeks don't count against this week's budget; the step-5 sweep handles their
   staleness. If both inboxes are empty, say so, do the side-quest sweep (step 5), and be
   done in a minute.

3. **Walk every inbox item to a decision — issues and Captured lines alike.** Read the item
   back — one line, no elaboration — and ask: promote, archive, or side-quest? Three options, because each maps to a distinct
   claim about the idea: it serves an objective, it doesn't, or it's worth a bounded detour.

   - **Promote** — the idea earns real work.
     - Maps to an existing KR in the active cycle: move it to `## Promoted` as
       `- [<today>] <idea> → KR2.1`. The KR's DRI decides when it gets built; promotion is
       alignment, not a start date.
     - Worth pursuing but not this cycle: `- [<today>] <idea> → next-cycle candidate`.
       Planning reads Promoted before drafting, so nothing promoted gets lost.
     - Wants to be a *new* KR mid-cycle: rare, and never silent. That's a mid-cycle amendment
       — a PR to the cycle file per

Preview of the first 4,000 characters. Read full instructions →