@open-product-primer/cli 2.0.0 → 2.2.0

package/dist/workflows/review.template.md

@@ -0,0 +1,69 @@
+---
+name: oprim-review
+description: Create a KPI review artifact for a completed bet, pre-filled from criteria.yaml with actuals gathered from the user
+---
+
+Create a KPI review in `oprim/reviews/`.
+
+**Interactive prompts:** Use the **AskUserQuestion tool** for every question in this skill — do not write questions as plain text.
+
+## Steps
+
+### 1. Identify the bet
+If not provided, ask: "Which bet are you reviewing? (e.g. BET-042)"
+
+### 1b. Check for custom rules
+Read `oprim/config.yaml`. If it has a non-empty `rules.review` value, treat it as additional guidance from the team — factor it into the questions you ask in step 4 and reflect it in the generated review content. If `rules.review` is absent or empty, skip this step; behavior is unchanged.
+
+### 2. Load criteria and check for a run result
+
+Read `oprim/bets/BET-NNN/criteria.yaml` if it exists (pre-fills baseline and target).
+If not found: inform user and continue with empty metrics list.
+
+**Check for measurement run result:** Scan `oprim/bets/BET-NNN/measurements/` for files matching `run-*.yaml`. If any exist, sort by filename (date-based) and read the most recent.
+
+**If a run result exists:** use it to pre-populate actuals and status for every metric. Skip step 3 for those metrics. Note the run date — include "Actuals from run: YYYY-MM-DD" in the review artifact.
+
+**If no run result exists:** proceed to step 3 to gather actuals manually.
+
+### 3. Gather actuals per metric (only when no run result)
+For each metric show name/baseline/target and ask: "What was the actual result? (number or 'pending')"
+
+Status logic:
+- actual >= target → `hit`
+- actual < target → `missed`
+- 'pending' or not provided → `pending`
+
+### 4. Get review metadata
+Ask: reviewer name, decision quality notes.
+
+### 5. Output path
+`oprim/reviews/YYYY-MM-DD-BET-NNN-kpi.md` (today's date)
+
+### 5b. Check for OKF frontmatter
+Read `oprim/templates/kpi-review.md`. If it begins with a YAML frontmatter block (`---` ... `---`), this workspace has OKF frontmatter enabled. Ask for a one-line description and comma-separated tags (derived from the reviewed bet's subject area). Prepare a frontmatter block with `type: kpi-review`, `title: <bet ID and title>`, `description: <description>`, `tags: [<tags>]`, `timestamp: <review date, ISO 8601>`, to prepend in step 6.
+If no frontmatter block is found in the template, skip this step — write the file with no frontmatter, matching current behavior.
+
+### 6. Write the review file
+Prepend the frontmatter block from step 5b, if one was prepared.
+```markdown
+# KPI Review: BET-NNN
+
+**Review date:** YYYY-MM-DD
+**Reviewed by:** <reviewer>
+**Actuals from run:** YYYY-MM-DD  ← include only when a run result was ingested
+
+| Metric | Baseline | Target | Actual | Status |
+|--------|----------|--------|--------|--------|
+| <name> | <baseline> | <target> | <actual> | <status> |
+
+## Decision quality
+<notes>
+
+## Actions
+- [ ] Update bet-decision outcome section
+- [ ] Update affected PDRs
+- [ ] Re-sequence impacted bets
+```
+
+### 7. Report what was created

package/dist/workflows/sequence.cursor-command.md

@@ -0,0 +1,12 @@
+
+Validate the primer sequencing board and suggest rebalancing if needed.
+
+**Steps**
+
+1. **Read board** — load `oprim/sequence.yaml`
+2. **Check WIP limits** — compare `now` count against `wip_limits.now`
+3. **Validate blockers** — for each bet in `now`, confirm all `blocked_by` entries are complete or absent
+4. **Validate PDR preconditions** — confirm all `requires_pdrs` entries exist in `oprim/decisions/`
+5. **Report violations** — list any WIP excess, unresolved blockers, or missing PDRs
+6. **Suggest moves** — recommend bets to defer to `next` or `later` to resolve violations
+7. **Regenerate view** — run `node oprim/scripts/generate-sequence-view.js` from the project root to update `oprim/sequence-view.md`

package/dist/workflows/sequence.inline.md

@@ -0,0 +1,10 @@
+### Sequencing board (oprim-sequence)
+Validate the primer sequencing board and regenerate the visual view.
+
+1. **Read board** — load `oprim/sequence.yaml`
+2. **Check WIP limits** — compare `now` count against `wip_limits.now`
+3. **Validate blockers** — for each bet in `now`, confirm all `blocked_by` entries are complete or absent
+4. **Validate PDR preconditions** — confirm all `requires_pdrs` entries exist in `oprim/decisions/`
+5. **Report violations** — list any WIP excess, unresolved blockers, or missing PDRs
+6. **Suggest moves** — recommend bets to defer to `next` or `later` to resolve violations
+7. **Regenerate view** — run `node oprim/scripts/generate-sequence-view.js` from the project root to update `oprim/sequence-view.md`

package/dist/workflows/sequence.schema.yaml

@@ -0,0 +1,13 @@
+id: sequence
+skillName: oprim-sequence
+title: "OPRIM: Sequence"
+description: Validate and update the primer sequencing board
+claude:
+  skill: true
+  command: sequence.md
+cursor:
+  skill: false
+  command: oprim-sequence.md
+poolside:
+  skill: true
+inline: true

package/dist/workflows/sequence.template.md

@@ -0,0 +1,88 @@
+---
+name: oprim-sequence
+description: Validate and update the primer sequencing board — triage mode computes board health and surfaces specific suggestions; seeded mode targets a specific context
+---
+
+Manage the primer sequencing board in `oprim/sequence.yaml`.
+
+**Interactive prompts:** Use the **AskUserQuestion tool** for every question in this skill — do not write questions as plain text.
+
+## Entry modes
+
+**Triage mode** — no intention provided: reads board state, computes health, surfaces specific actionable suggestions.
+**Seeded mode** — context pre-provided (e.g. from a lifecycle hook): skips full triage and targets the most relevant move for that context.
+
+## Steps
+
+### 1. Determine mode
+
+If lifecycle context was provided as an argument or pre-seeded in the conversation (e.g. `bet-created`, `bet-promoted`, or a specific bet ID was just archived), enter **Seeded mode** — go to Step 2B.
+
+Otherwise, enter **Triage mode** — go to Step 2A.
+
+### 2A. Triage mode — compute board health
+
+Read `oprim/sequence.yaml`. Compute:
+
+- **WIP utilization**: count entries in `now` vs `wip_limits.now`
+- **WIP violations**: entries in `now` that exceed the WIP limit
+- **Blocked Now bets**: entries in `now` whose `blocked_by` list contains a bet ID still present in any active lane (now/next/later/backlog)
+- **Ready-to-pull bets**: entries in `next` whose `blocked_by` list is empty or all resolved (each blocked_by ID is absent from all active lanes)
+- **PDR gaps**: entries in any lane whose `requires_pdrs` list contains a PDR ID not found in `oprim/decisions/`
+
+Surface **ranked suggestions**, most urgent first:
+1. WIP violations → name each excess bet, suggest deferring to `next` or `later`
+2. Blocked Now bets → name the bet and its unresolved blocker, suggest deferring until blocker resolves
+3. Open Now slot (count < `wip_limits.now`) with a ready Next bet → name a specific bet to pull into `now`
+4. PDR gaps → name the bet and missing PDR, suggest creating it first
+
+Each suggestion must name the exact bet ID, current lane, target lane, and reason.
+
+If the board is healthy (no violations, no ready moves): report current WIP utilization and state the board is healthy. Offer to move something anyway if the user wants.
+
+After surfacing suggestions, ask: "Which move would you like to make?"
+
+### 2B. Seeded mode — target specific context
+
+Use the provided context to jump to the most relevant suggestion:
+
+- `bet-created`: A new bet just landed in backlog. Check if `now` has an open slot and `next` has a ready bet to pull. If so, suggest the specific bet to pull. Otherwise, confirm the new bet is in backlog and the board looks healthy.
+- `bet-promoted`: A bet was just promoted to an OpenSpec change. Verify the bet is still correctly sequenced and surface any resequencing action the promotion warrants.
+- Bet archived (e.g. "BET-011 was archived"): Check if `now` dropped below `wip_limits.now`. If so, find the most ready bet in `next` and suggest pulling it.
+
+If no relevant move is found for the provided context, fall back to Triage mode (Step 2A).
+
+### 3. Validate the requested move
+
+Before executing any move, verify all three constraints:
+
+**WIP limit**: Moving a bet to `now` must not push the count above `wip_limits.now`. If it would, explain the violation and suggest deferring an existing `now` bet first.
+
+**Blocker resolution**: Moving a bet to `now` requires its `blocked_by` list to be empty or all resolved (IDs absent from all active lanes). If unresolved, name each unresolved blocker.
+
+**PDR preconditions**: Moving a bet to `now` requires all `requires_pdrs` entries to exist as files in `oprim/decisions/`. If any are missing, name them and suggest creating them first.
+
+If the move is invalid: explain which constraint failed and suggest the nearest valid alternative. Do not proceed to Step 4.
+
+### 4. Preview and confirm
+
+Show the exact YAML change before writing. Name the entry that will move: its `id`, `title`, source lane, and target lane.
+
+```
+Before:  BET-005 is in next  (now: 1/2 slots filled)
+After:   BET-005 moves to now (now: 2/2 slots filled)
+```
+
+Ask: "Apply this change? (y/N)"
+- If "n" or Enter: stop, no changes made.
+- If "y": proceed to Step 5.
+
+### 5. Write sequence.yaml
+
+Read `oprim/sequence.yaml`. Remove the bet entry from its current lane. Insert it into the target lane. Write back with 2-space indentation. Do not modify any other entries.
+
+### 6. Regenerate view
+
+Run `node oprim/scripts/generate-sequence-view.js` from the project root to update `oprim/sequence-view.md`.
+
+### 7. Report what was done

package/dist/workflows/spec-authoring.schema.yaml

@@ -0,0 +1,13 @@
+id: spec-authoring
+skillName: oprim-spec
+title: null
+description: Generate a native oprim capability spec delta at oprim/bets/BET-NNN-<slug>/specs/<capability>/spec.md while a bet is active, in RFC 2119 (SHALL/SHOULD/MAY) requirements and Gherkin scenarios — folded into oprim/specs/<capability>/spec.md (current truth) when the bet is archived
+claude:
+  skill: true
+  command: null
+cursor:
+  skill: true
+  command: null
+poolside:
+  skill: true
+inline: false

package/dist/workflows/spec-authoring.template.md

@@ -0,0 +1,68 @@
+---
+name: oprim-spec
+description: Generate a native oprim capability spec delta at oprim/bets/BET-NNN-<slug>/specs/<capability>/spec.md while a bet is active, in RFC 2119 (SHALL/SHOULD/MAY) requirements and Gherkin scenarios — folded into oprim/specs/<capability>/spec.md (current truth) when the bet is archived
+---
+
+Generate a capability spec delta for an active bet — RFC 2119 requirements plus Gherkin scenarios, no OpenSpec required. This skill never writes to `oprim/specs/` directly; `oprim-archive` folds the delta into current truth when the bet is archived.
+
+**Interactive prompts:** Use the **AskUserQuestion tool** for every question in this skill — do not write questions as plain text.
+
+## Steps
+
+### 1. Get the active bet
+If a bet ID was provided as context (e.g. invoked from `/oprim:promote`), use it directly. Otherwise ask: "Which bet is this spec change for? (e.g. BET-005)"
+
+Resolve it to a directory in `oprim/bets/` using the same two patterns `oprim-archive` uses: exact `BET-NNN/` (legacy, no slug) or the slug variant `BET-NNN-<slug>/`. If neither matches, report "Bet BET-NNN was not found in oprim/bets/ — spec deltas can only be authored against an active bet" and stop.
+
+### 2. Get the capability name and description
+If not provided, ask: "What capability are you specifying? (a short name, e.g. 'spec-authoring')" and "What does it do? (one or two sentences)"
+
+### 2b. Derive the slug
+From the capability name: lowercase all characters, replace any character that is not a letter or digit with a hyphen, collapse consecutive hyphens to one, strip leading/trailing hyphens. This becomes `<capability>`.
+Output path: `oprim/bets/<resolved-bet-dir>/specs/<capability>/spec.md` (a delta, not `oprim/specs/<capability>/spec.md` — that file is current truth and is only ever written by `oprim-archive`'s merge step).
+
+### 2c. Check for custom rules
+Read `oprim/config.yaml`. If it has a non-empty `rules.spec` value, treat it as additional guidance from the team — factor it into the requirements and scenarios you draft. If `rules.spec` is absent or empty, skip this step; behavior is unchanged.
+
+### 3. Determine the delta type for each requirement
+For each requirement, ask whether it is new (**ADDED**), a change to an existing current-truth requirement (**MODIFIED**), or a removal of one (**REMOVED**).
+
+- **ADDED**: gather the requirement statement fresh.
+- **MODIFIED / REMOVED**: read `oprim/specs/<capability>/spec.md` if it exists and list its `### Requirement:` headers so the user can pick the one being changed. The header text must match exactly (whitespace-insensitive) for `oprim-archive`'s merge step to find it later. If the file doesn't exist yet, MODIFIED/REMOVED aren't possible for this capability — fall back to ADDED.
+
+### 4. Gather requirements and scenarios
+For ADDED and MODIFIED requirements, phrase each as an RFC 2119 statement using SHALL (mandatory), SHOULD (recommended), or MAY (optional), then ask for at least one scenario: a WHEN (trigger) and a THEN (expected outcome), with an optional GIVEN (context) and additional AND steps. REMOVED requirements only need the matching header — no new scenarios.
+
+### 5. Write the delta file
+Append to (or create) `oprim/bets/<resolved-bet-dir>/specs/<capability>/spec.md`, grouping requirements under the matching section header — only include a section if it has at least one requirement under it:
+
+```markdown
+## ADDED Requirements
+
+### Requirement: <capability> SHALL/SHOULD/MAY <requirement statement>
+<one-sentence elaboration>
+
+#### Scenario: <scenario title>
+- **GIVEN** <context> (optional)
+- **WHEN** <trigger>
+- **THEN** <outcome>
+- **AND** <additional outcome> (optional)
+
+## MODIFIED Requirements
+
+### Requirement: <exact header text matched from oprim/specs/<capability>/spec.md>
+<revised elaboration>
+
+#### Scenario: <scenario title>
+- **WHEN** <trigger>
+- **THEN** <outcome>
+
+## REMOVED Requirements
+
+### Requirement: <exact header text matched from oprim/specs/<capability>/spec.md>
+```
+
+If the delta file already exists (a prior spec-authoring pass for this bet/capability), append new requirements to the matching section, creating that section if it's not yet present.
+
+### 6. Report what was created
+Show the delta file path, which bet it's scoped to, and a summary of the ADDED/MODIFIED/REMOVED requirements captured. Note that it merges into `oprim/specs/<capability>/spec.md` when `BET-NNN` is archived — nothing is current truth yet.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@open-product-primer/cli",
-  "version": "2.0.0",
+  "version": "2.2.0",
   "description": "Open Product Primer CLI — product decisions, sequencing, and KPI tracking for repositories",
   "keywords": [
     "product",
@@ -35,7 +35,7 @@
     "README.md"
   ],
   "scripts": {
-    "build": "tsc",
+    "build": "tsc && node scripts/copy-workflow-assets.js",
     "dev": "tsc --watch",
     "start": "node dist/cli.js",
     "test": "vitest run",