create-pmos 0.3.0 → 0.5.0

package/README.md

@@ -2,9 +2,10 @@
 
 **A product manager's operating system you can adopt in five minutes — no coding expertise
 required.** One command puts a disciplined, eval-driven PM workflow inside your own repo:
-initiative → PRD → eval rubric → agreed contract → build → three gates. Your AI coding agent
-(e.g. Claude Code) does the building. You do the judging. Everything stays in your folder — no
-database, no account, no network calls, no telemetry.
+initiative → PRD → eval rubric → agreed contract → build → three gates. **Any capable coding
+agent** does the building — Claude Code, Codex/ChatGPT, Cursor, Gemini, Copilot; PMOS is
+provider- and model-agnostic. You do the judging. Everything stays in your folder — no database,
+no account, no network calls, no telemetry.
 
 ## Whose task is what
 
@@ -43,7 +44,7 @@ What you'll see:
 
 Next steps in /home/you/my-product:
   1. cp pmos/templates/pmos-gate.yml .github/workflows/pmos-gate.yml   (only if on GitHub)
-  2. Add to the repo's CLAUDE.md: "This product is PMOS-managed (file mode) — read pmos/AGENTS.md before any work."
+  2. Wire PMOS into your agent's instruction file (CLAUDE.md, AGENTS.md, .cursorrules, GEMINI.md, or copilot-instructions): "This product is PMOS-managed (file mode) — read pmos/AGENTS.md before any work."
   3. Commit the pmos/ folder. Then follow pmos/AGENTS.md for every run.
 ```
 
@@ -249,6 +250,66 @@ Refreshes the skills, concepts, and scripts only. Your records — `state/`, `pl
 `okf/product/` — are yours, and an update never touches them. `pmos/KIT-VERSION` always says
 exactly what you're running.
 
+## What's new in 0.5.0
+
+0.4.0 opened the front of the loop. 0.5.0 makes explicit what was always the intent: **the kit is
+provider- and model-agnostic**, and the harness kernel now says so in its own words.
+
+- **Any capable coding agent runs the loop — not just Claude Code.** The runtime amendment
+  (D09/D34, ratified 2026-07-23) generalizes the evaluator, ingest, and design skills from
+  "runs in Claude Code" to "runs in the interactive agent runtime — any capable coding agent;
+  PMOS-self happens to use Claude Code, but the runtime is not Claude-specific." Point Codex,
+  Cursor, Gemini, or Copilot at `pmos/AGENTS.md` and the same protocol holds.
+
+  > Works the same in any of them: open your product folder in the agent, then
+  > "Read pmos/AGENTS.md and follow it." The gates, records, and metrics don't care which model
+  > wrote the code.
+
+- **Per-model calibration.** When you log a run or an eval you can now name the model that did the
+  work (`model`) or the judging (`evaluator_model`), so the evaluator's calibration is read *per
+  model* instead of silently pooling providers — `scripts/metrics.py` warns when labeled evals span
+  more than one evaluator model, because a trust score one model earned isn't inherited by another.
+  The design surface is documented as pluggable too (any surface that can take a brief and export a
+  component library), not tied to one vendor.
+
+- **A stated security posture that travels with the kit** (`pmos/SECURITY.md`), a `frontier.sh`
+  metrics helper, a file-mode `ticket-template.md`, and a sharper `SKILL-FORMAT.md` — all now part
+  of the vendored kernel.
+
+**Upgrade note:** `npx create-pmos@latest --update` brings all of this in and never touches your
+`state/`, `planning/`, or `okf/product/` records. Purely additive — no change to how the gate
+behaves on your existing initiatives.
+
+## What's new in 0.4.0
+
+0.3.0 sharpened the judging. 0.4.0 adds the **front of the loop** — deciding *what* to build and
+whether a user-facing idea is even right *before* a PRD locks it in.
+
+- **A front door: the `pmos-router` skill.** Not sure which lane a piece of work takes? Start here.
+  It maps any entry — "I have an idea", "is this feasible?", "production is broken", "we need copy",
+  "just upkeep" — to its lane, its spec artifact, the next skill, and the gates to expect, running
+  a sharpness check ("can you *state* the question yet?") and a prior-rejection check on the way. It
+  decides nothing; it routes to lanes that already exist.
+
+  > Read pmos/AGENTS.md, then follow pmos/skills/pmos-router.skill: I want to [X] — route it.
+
+- **The prototype lane: see it before you spec it.** For a user-facing idea, the new
+  `prototype` skill runs a pre-PRD visual validation — you give a *quick* brief, a design agent
+  produces 2–3 genuinely different lookable options with real draft copy, a designer-grade grilling
+  sharpens them (a dialogue, never a score), and you dispose promote / iterate / kill. Promote
+  derives the PRD from what you actually validated. It's the cheapest way to kill a bad idea — before
+  it's a spec, not after four rebuilds.
+
+  > Follow pmos/skills/prototype.skill: here's my idea — [two sentences]. Give me lookable options.
+
+- **A design-craft concept + prototype-brief template** now ship, and the `prd`/`eval-rubric`
+  skills gained a "grill before you write, write for durability (name interfaces, not file paths)"
+  discipline.
+
+**Upgrade note:** `npx create-pmos@latest --update` brings all of this in and never touches your
+`state/`, `planning/`, or `okf/product/` records. Purely additive — nothing about how the gate
+behaves on your existing initiatives changes.
+
 ## What's new in 0.3.0
 
 0.2.0 made the workflow fit real work. 0.3.0 goes after the two ways the *judging* half quietly

package/bin/create-pmos.js

@@ -21,8 +21,10 @@ const PKG = require(path.join(__dirname, '..', 'package.json'));
 const KERNEL = [
   'AGENTS.md',
   'README.md',
+  'SECURITY.md',
   'KIT-VERSION',
   'skills',
+  'skills-native',
   'okf/core',
   'scripts',
   'templates',
@@ -59,7 +61,8 @@ function vendor(targetRoot) {
 Next steps in ${targetRoot}:
   1. If the repo is not git yet:  git init
   2. If it lives on GitHub:       cp pmos/templates/pmos-gate.yml .github/workflows/pmos-gate.yml
-  3. Add to the repo's CLAUDE.md: "This product is PMOS-managed (file mode) — read pmos/AGENTS.md before any work."
+  3. Wire PMOS into your agent's instruction file (CLAUDE.md, AGENTS.md, .cursorrules, GEMINI.md, or
+     .github/copilot-instructions.md): "This product is PMOS-managed (file mode) — read pmos/AGENTS.md before any work."
   4. Commit the pmos/ folder. Then follow pmos/AGENTS.md for every run.`);
 }
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "create-pmos",
-  "version": "0.3.0",
+  "version": "0.5.0",
   "description": "Scaffold the PMOS portable kit — run the PMOS product-management workflow (initiative → lane-fit spec → contract → build → three gates, with work-type lanes for features, research, maintenance, incidents, and content) entirely inside your own repo, with all state as git-versioned files. No database, no network, no telemetry.",
   "license": "MIT",
   "bin": {

package/payload/AGENTS.md

@@ -24,8 +24,8 @@ yourself wanting an MCP tool, use the state adapter below instead.
 | `get_skill` | read `pmos/skills/<name>.skill` |
 | `get_okf_concepts` | read `pmos/okf/…` (index-first, then the concept body — progressive disclosure) |
 | `get_eval_rubric` | read `pmos/planning/evals/<id>-eval-rubric.md` |
-| `log_agent_run` | append one JSON line to `pmos/state/runs.jsonl` (`{run_id, initiative_id, pre_run_contract, self_eval, human_corrections, date}`) |
-| `save_eval` | append one JSON line to `pmos/state/evals.jsonl` (`{run_id, initiative_id, rubric_path, score, verdict, dimensions, date}`) |
+| `log_agent_run` | append one JSON line to `pmos/state/runs.jsonl` (`{run_id, initiative_id, pre_run_contract, self_eval, human_corrections, date, model}`) — record `model` = the model that produced the run so metrics stay honest across model switches |
+| `save_eval` | append one JSON line to `pmos/state/evals.jsonl` (`{run_id, initiative_id, rubric_path, score, verdict, dimensions, date, evaluator_model}`) — record `evaluator_model` = the model that rendered the verdict; κ is calibrated **per evaluator model** (a model swap does not inherit a prior κ) |
 | `record_acceptance` | append one JSON line to `pmos/state/acceptances.jsonl` (`{run_id, initiative_id, accepted, pm_label, note, date}`) — **written only on the PM's explicit word** |
 | `record_outcome_check` | append one JSON line to `pmos/state/outcome_checks.jsonl` (`{initiative_id, disposition, evidence, date}`) — the D57 post-acceptance outcome verdict (`validated | refuted | inconclusive`; evidence required for the first two). **PM's word only — never auto-dispose from metrics**; a re-judgment is a new line |
 | `save_okf_doc` | write the doc under `pmos/okf/product/…` marked as a DRAFT; the PM approves it via PR review (the file-mode form of draft→approved) |
@@ -93,6 +93,22 @@ honest.
   not install the pmos gate, or mirror the initiative file locally** — a vendored sibling gate
   fails closed on a missing local record by design (S5 Review Gate finding).
 
+## Decomposing an initiative into tickets (file mode has no board)
+
+When an initiative is bigger than one run, break it into **tickets** — the plain-file equivalent of
+the hosted product's SDLC board. One file per ticket in `pmos/state/tickets/NNN-slug.md`, numbered
+in **dependency order**, from [templates/ticket-template.md](templates/ticket-template.md):
+
+- Frontmatter: `id` (the NNN), `title`, `status` (`todo | doing | done`), and `blocked_by` — an
+  explicit list of the ticket ids that must be `done` first. Blocking edges are **text**, not a
+  hidden graph.
+- **Work the frontier.** `pmos/scripts/frontier.sh` lists exactly the tickets that are not done and
+  whose every blocker is done — the workable set. Start only from there. If it reports the frontier
+  is *blocked*, there is a cycle or an undone blocker to resolve before more work is startable.
+- Each ticket names **one deliverable**, behaviorally (interfaces/types/contracts, never file paths
+  or line numbers — they stale while the ticket waits). Tickets decompose an initiative; they do not
+  replace it — the initiative record, PRD, rubric, and the three gates are unchanged.
+
 ## New agent paths — the lethal-trifecta audit
 
 Before creating any new agent path or widening a tool grant, verify it does **not** hold all three
@@ -117,6 +133,15 @@ deployment until this repo has accumulated its own PM-vs-evaluator record (appen
 `pmos/scripts/metrics.py` computes the north star (human corrections per accepted run), pass rates,
 and the Goodhart tripwire from `pmos/state/`.
 
+**Model-awareness (any provider).** PMOS is provider/model-agnostic — any capable coding agent can
+run this loop — but calibration is a property of the **evaluator model**, not of "the Review Gate"
+abstractly. Record the model on every run/eval (the `model` / `evaluator_model` fields above); a
+model swap **forks** the calibration record — you do not inherit a κ another model earned, and
+`metrics.py` warns when labeled evals pool more than one evaluator model. The high-judgment roles
+(the adversarial evaluator, `explain-run`) assume a **frontier-tier reasoner**: a weaker model
+degrades *silently* to leniency and grep-clean while its output still looks well-formed — the
+per-model κ is what makes that degradation visible.
+
 ## PM protocol (weekly)
 
 Scan `discoveries.md`; a friction theme seen twice with no resolving decision must be promoted to a

package/payload/KIT-VERSION

@@ -1,3 +1,3 @@
-kernel-source: pmos@25d32ad
-assembled: 2026-07-20
+kernel-source: pmos@917d29e
+assembled: 2026-07-23
 mode: vendor

package/payload/README.md

@@ -13,16 +13,24 @@ personally-owned PMOS backend).
 - `AGENTS-HUMAN.md` — the same loop for a **human** builder (D58): plain terms + the
   `scripts/pmos-log.sh` helper that appends validated state records in one command. Mixed
   human+agent teams share the same state.
+- `SECURITY.md` — the kit's **security posture**: skills are executable instructions, what the kit
+  does structurally to be safe to install, and what stays your responsibility. Read it before you
+  install skills into your agent.
 - `skills/` — the PMOS skill kernel (prd, eval-rubric, okr, evaluator, …). Single-sourced from the
   PMOS repo; where a skill names a hosted tool, apply the AGENTS.md state adapter.
+- `skills-native/` — the same skills in **Agent-Skills standard** form (`<name>/SKILL.md`
+  directories), generated from `skills/` so a Claude Code / Codex / skills.sh harness can load them.
+  The flat `skills/` files stay the source of truth; this is the portable mirror.
 - `okf/core/` — kernel concepts (the sdlc loop, the three-tier gate, watermelon flags, …).
   `okf/product/` — YOUR product's knowledge; drafted by ingest, approved via PR review.
 - `planning/` — okrs, PRDs, rubrics (`agent-run-eval-rubric.md` is the per-initiative template),
   `eval-calibration.md` (append every PM override of an evaluator verdict).
 - `state/` — the operational record, **append-only**: `initiatives/<id>.md`, `runs.jsonl`,
-  `evals.jsonl`, `acceptances.jsonl`, `discoveries.md`.
+  `evals.jsonl`, `acceptances.jsonl`, `discoveries.md`. `tickets/NNN-slug.md` decompose an
+  initiative into ordered, dependency-numbered work (file-mode's board — see AGENTS.md).
 - `scripts/` — `gate-initiative.sh` (the fail-closed CI gate), `metrics.py` (north star +
-  calibration + Goodhart tripwire), `kit-update.sh` (kernel refresh).
+  calibration + Goodhart tripwire), `kit-update.sh` (kernel refresh), `frontier.sh` (lists the
+  workable tickets — those not done whose blockers are all done).
 - `templates/pmos-gate.yml` — CI drop-in; copy to `.github/workflows/`.
 - `KIT-VERSION` — which PMOS kernel this was assembled from.
 

package/payload/SECURITY.md

@@ -0,0 +1,53 @@
+# PMOS kit — security posture
+
+A skill is not a document. It is **instructions that run inside your agent**, with your agent's
+tools and your agent's access. Anything the kit ships into your repo can shape what your agent does.
+This file states, concretely, what the PMOS kit does to be safe to install — and where the
+responsibility stays yours.
+
+## Why "we scanned it" is not a posture
+
+The largest skills registry (skills.sh) shipped a malicious-skill scanner. Trail of Bits bypassed it
+with prompt injection plus compiled bytecode. Static scanning of agent instructions is *evadable by
+construction* — the payload is natural language aimed at a model, not a signature you can enumerate.
+So the PMOS kit does not claim "scanned and safe." It claims a set of **structural** properties you
+can check yourself, below.
+
+## What the kit does
+
+- **No on-load command execution in shipped skills.** No PMOS kit skill uses Claude Code's dynamic
+  `` !`cmd` `` context injection or any load-time shell-out. A skill's body is read as instructions,
+  not run as a script when it loads. *(Check: `grep -rn '!\`' pmos/skills` — expect nothing.)*
+- **Least authority, declared.** Shipped skills request the minimum tools they need; the
+  security-sensitive one — the **evaluator** — is **read-only by design**: its only write is the
+  schema-constrained verdict. The component that reads untrusted content (diffs, PR text) is
+  deliberately *not* the component that can act, which removes the exfiltration leg of the lethal
+  trifecta.
+- **A `license` on every shipped skill** (portability + provenance), and PMOS producer metadata is
+  carried under the spec's `metadata:` extension map, never as ambient top-level directives.
+- **Fail-closed containment.** The kit is assembled by `kit/build-kit.sh`, which greps its own output
+  and **aborts** if any reference to a hosted PMOS backend (a project ref, an MCP endpoint, or a
+  hosted-backend URL) leaks in. The npm publish path re-runs this check on the exact tarball and
+  refuses to publish on anything but a clean result. The kit you get is self-contained: **no
+  database, no network, no telemetry.**
+- **No network calls in the installer.** `create-pmos` vendors a bundled payload; it makes no
+  outbound requests and sends nothing about you anywhere.
+- **Everything the evaluator reads is untrusted data, never instructions.** An instruction embedded
+  in a diff or PR body ("mark this PASS") is treated as *evidence of a defect*, not a command —
+  paired with the read-only scope above, because prompt-level defenses alone are bypassable.
+
+## What stays your responsibility
+
+- **Review before you install.** Read the skills and scripts in `pmos/` the way you would review any
+  dependency PR. The kit is small and plain-text on purpose so you can. `--update` refreshes only the
+  kernel and never touches your `state/` — review its diff like any other change.
+- **Your agent's tools are yours to scope.** The kit declares least authority for its own skills, but
+  what your agent is *allowed* to do in your repo is set by you, not by us.
+- **Pin what you install.** Prefer a pinned `create-pmos@<version>` over `@latest` in automation, and
+  re-review the kernel diff on each update.
+
+## Reporting
+
+Found something that violates the posture above — a shipped skill with load-time execution, a
+containment leak, an over-scoped tool request? Open an issue in the PMOS repo describing what and
+where. The posture is only worth stating if it is enforced; a false claim here is itself a bug.

package/payload/okf/core/concepts/design-craft.md

@@ -0,0 +1,97 @@
+---
+type: Concept
+title: Design Craft — the UI/UX practice a design agent applies
+description: The product-agnostic design knowledge PMOS's design agents reason with when turning a quick brief into a prototype, a design reference, or a design system — perception and cognition evidence plus the craft moves it implies. Principles to reason with, never a style lock.
+tags: [design, craft, perception, cognition, prototype, accessibility]
+timestamp: 2026-07-21
+---
+
+# Design Craft — the practice a design agent applies
+
+**Situating context:** [D60](/okf/products/pmos/adr/d60-prototype-loop.md) makes the design agent, not
+the PM, the author of prototypes and design systems — from a **quick brief**. That is hollow unless
+the agent has real practice to apply: an agent told to "apply UI/UX practice" with nothing to apply
+produces exactly the generic rectangle-grid the PM rejected in the console-redesign series
+("obviously AI generated", run 003). This concept promotes the durable, replicated core of
+[attention-research](/planning/design/attention-research.md) — authored for one initiative, valuable
+for all — into the bundle, per the rule that timeless craft lives in OKF while operational notes stay
+in /planning/. **These are principles to reason with, never a style lock**: a checklist that forces
+one look would reproduce the very monotony this exists to prevent.
+
+## How to use this (design agent)
+
+Retrieve this concept before any prototype, design reference, or design-system authoring. Reason from
+the principles to the *specific* product and brief — never apply them as a template. The test of good
+use is that two different briefs produce two visibly different designs, each defensible from these
+principles under [grilling](/okf/products/pmos/adr/d60-prototype-loop.md).
+
+## The evidence core (perception & cognition)
+
+Replicated classics; citations in [attention-research](/planning/design/attention-research.md).
+
+1. **Working memory holds ~4 chunks** (Miller 1956; Cowan 2001). Six-plus co-equal clusters on one
+   screen force re-scanning instead of absorption.
+2. **Cognitive load is a budget** (Sweller 1988). Layout noise, redundant chrome, and
+   undifferentiated density steal capacity from the judgment the user came to make.
+3. **Progressive disclosure outperforms everything-at-once** (Nielsen 2006) on speed *and* error
+   rate. Detail should be *available*, not *ambient*.
+4. **Attention is serial after the first glance** (eyetracking F/Z patterns; serial-position,
+   Murdock 1962). A screen needs ONE focal entry point and a deliberate last word — not a uniform
+   grid where every cell competes.
+5. **Pre-attentive vision is fast and specific** (Treisman & Gelade 1980; Cleveland & McGill 1984).
+   Hue, size, curvature, position and motion are read in <200 ms; position along a common scale beats
+   box-vs-box comparison. Encode status in hue/size/position, not in N identical bordered boxes.
+6. **Grouping does not need boxes** (Gestalt; Palmer 1992; Tufte's data-ink). Whitespace, alignment
+   and type contrast carry structure at near-zero ink; enclosure is the *heaviest* grouping device,
+   so spend it only where load-bearing.
+7. **Humans prefer curves** (Bar & Neta 2006). Sharp-cornered uniformity reads mechanical —
+   "template output" — regardless of palette.
+8. **Dual coding** (Paivio 1971). A number paired with a spatial encoding (position, sparkline) is
+   absorbed and recalled better than the number alone.
+9. **Aesthetic-usability effect** (Kurosu & Kashimura 1995). Polish is not decoration; it changes
+   tolerance, trust, and measured usability.
+
+## The craft moves (what the evidence implies)
+
+- **Visual hierarchy & focal structure.** One focal opening per surface; secondary material
+  subordinated by size, weight, and position — not just placed elsewhere. End deliberately (the last
+  thing shown is remembered).
+- **Chunking & density.** ≤4 co-equal chunks above the fold. Density is fine — *undifferentiated*
+  density is not; differentiate by hierarchy, not by removal.
+- **Progressive disclosure.** Secondary sections collapse to honest one-line summaries; things that
+  need attention may open themselves. Disclosure must never hide alarms.
+- **Typographic & spatial rhythm.** A deliberate type scale and a consistent spacing unit; vary
+  rhythm to mark importance, keep it steady to mark sameness.
+- **Contour & geometry variation.** De-rectangle: boxes only where enclosure is load-bearing; group
+  by whitespace and alignment; mix radii/organic forms deliberately. A wall of same-radius rectangles
+  is the recorded failure.
+- **Motion with restraint.** Motion is pre-attentive — spend it only on what is genuinely live or
+  needs attention; ambient motion is load.
+- **Task-fit — organise around the user's job, not the data model.** The layout mirrors the domain
+  workflow and leads with "what needs me." Perception science applied generically *loses* task-fit —
+  that was the run-004 rejection: a beautiful surface that hid the work the user actually manages.
+- **Real words are part of the design** ([D60](/okf/products/pmos/adr/d60-prototype-loop.md): copy
+  rides the prototype). Draft real headlines and microcopy; lorem defers the judgment the prototype
+  exists to enable.
+
+## Accessibility floors (non-negotiable, in every fidelity)
+
+Floors, not aspirations — they bind prototypes too, because a direction validated below the floor is
+a direction that will fail later: **WCAG contrast (4.5:1 body, 3:1 large text)** · **touch/click
+targets ≥ 44px** · **`prefers-reduced-motion` respected wherever motion is used** · **never encode
+meaning in hue alone** (pair with position, shape, or label — also how RAG status stays legible to
+color-blind users) · **keyboard reachability for anything interactive** in leg-B references.
+
+## Anti-patterns (each one recorded, not hypothetical)
+
+From the [console-redesign series](/planning/evals/eval-calibration.md): **the rectangle wall** (same
+box, same radius, everywhere — run 003) · **cosmetics over unchanged structure** (a new skin on the
+same IA does not clear "surprise me" — run 002) · **generic perception-science minimalism that loses
+the job** (run 004) · **safe, scoreable sameness** (optimising for a rubric instead of for the user —
+the reason leg A is grilled, never scored).
+
+## Related
+
+- [design-loop](/okf/core/concepts/design-loop.md) — the workflow this craft is applied inside.
+- [d60-prototype-loop](/okf/products/pmos/adr/d60-prototype-loop.md) — why the agent designs and the PM briefs.
+- [attention-research](/planning/design/attention-research.md) — the evidence base with full citations (operational note, stays in /planning/).

package/payload/okf/core/concepts/design-loop.md

@@ -1,7 +1,7 @@
 ---
 type: Concept
 title: The Design Loop
-description: How a PM runs UI/UX design as a first-class, repeatable, product-scoped sub-flow of the Build stage — brief → design → reconcile → build → design-sync — gated by the Review Gate, presentation-only, never a data decision. PMOS's own app is one instance.
+description: How a PM runs UI/UX design as a first-class, repeatable, product-scoped sub-flow of the Build stage — brief → design → reconcile → build → design-sync — gated by the Review Gate. Presentation-only for redesigns; a new surface downstream of an approved PRD may define its decided views and flows (D60), making the design the reference the build works from. PMOS's own app is one instance.
 tags: [design, ui, workflow, build, reconciliation, watermelon]
 timestamp: 2026-07-01
 ---
@@ -32,7 +32,8 @@ An initiative with a user-facing surface runs four legs *inside* Build:
 1. **Brief** — the [design-brief skill](/skills/core/design-brief.skill) writes the context handoff: what
    to design and the hard, presentation-only constraints, each surface tied to a real data source. It is to
    design what the [PRD](/skills/core/prd.skill) is to build.
-2. **Design** — the design is made in claude.ai/design (external to this repo).
+2. **Design** — the design is made in an external design surface (PMOS-self uses claude.ai/design;
+   any capable design surface fits — external to this repo).
 3. **Reconcile + build** — the [design-reconcile skill](/skills/core/design-reconcile.skill) classifies
    every surface against **the product's capability ledger** and the PM signs off before any code; then the
    design is built into the product's app on its design system, verified by the product's CI. (For PMOS's own
@@ -42,15 +43,25 @@ An initiative with a user-facing surface runs four legs *inside* Build:
    to claude.ai/design (for PMOS, see [.design-sync/conventions.md](/.design-sync/conventions.md)), so the
    next design starts from the product's actual parts.
 
-Legs 2 and 4 are external tools PMOS *references*; legs 1 and 3 are the PMOS skills that make the loop
+The design surface (legs 2 and 4) is **pluggable and provider-agnostic** — PMOS-self uses
+claude.ai/design, but the loop is not tied to it; any capable design surface that can consume a brief
+and export a component library fits (harness-model-agnosticism). Legs 2 and 4 are external tools PMOS *references*; legs 1 and 3 are the PMOS skills that make the loop
 repeatable.
 
 ## Presentation-only is the load-bearing constraint
 
-Design is **behavior-preserving**: no new views, no new data, no changed flows — presentation only. If a
-design implies a data or feature change, it is **flagged back as a separate decision**, never smuggled into
-the build. This is what keeps design at [control altitude](/okf/core/concepts/control-plane.md) and stops it
-from becoming a backdoor for architecture the PM never decided.
+For a **redesign of an existing surface**, design is **behavior-preserving**: no new views, no new data,
+no changed flows — presentation only. If such a design implies a data or feature change, it is **flagged
+back as a separate decision**, never smuggled into the build.
+
+**Scoped by [D60](/okf/products/pmos/adr/d60-prototype-loop.md) (2026-07-21):** for a **new surface
+downstream of an approved PRD**, the design *may* define the new views and flows — because the PRD already
+decided them. The constraint exists to stop design smuggling in features **nobody decided**; a PRD-decided
+feature is not smuggling. In that case the design produced here is **the reference the build works from**
+(D60 leg B), carrying the scored designer-grilling bar — not a Build-stage ornament. Anything the design
+implies **beyond** what its PRD decided is still flagged back, exactly as before. This is what keeps design
+at [control altitude](/okf/core/concepts/control-plane.md) in both cases: the PM's decisions bound the
+design; the design never makes them.
 
 ## Reconciliation is the watermelon defense for UI
 
@@ -111,7 +122,7 @@ PMOS's own instance: the `web/` app, the [D38](/okf/products/pmos/adr/d38-design
   [eval-driven](/okf/core/concepts/eval-driven-pm.md) style (the fidelity rubric before the build).
 - Reconciliation is [watermelon-flag](/okf/core/concepts/watermelon-flag.md) applied to UI.
 - PMOS stays a [control plane](/okf/core/concepts/control-plane.md): it specs and evaluates design; the design
-  itself is made in claude.ai/design and built by a build agent.
+  itself is made in an external design surface (e.g. claude.ai/design) and built by a build agent.
 - Formalized by [D48](/okf/products/pmos/adr/d48-design-loop.md); made product-scoped by
   [D50](/okf/products/pmos/adr/d50-design-loop-product-scoped.md); composes with the design *system* (D38,
   PMOS's own instance).

package/payload/okf/core/templates/design-brief-template.md

@@ -1,7 +1,7 @@
 ---
 type: Template
 title: Design Brief Template
-description: The scaffold for a design brief instance — the context handoff from Claude Code to claude.ai/design. Copy into /planning/design/ and fill; presentation-only.
+description: The scaffold for a design brief instance — the context handoff from the interactive agent to an external design surface (e.g. claude.ai/design). Copy into /planning/design/ and fill; presentation-only.
 tags: [template, design, brief, planning]
 timestamp: 2026-07-01
 ---

package/payload/okf/core/templates/prd-template.md

@@ -82,3 +82,6 @@ copy is an operational instance and does not live in the OKF bundle.
 - [ ] Paired eval rubric queued to be written first.
 - [ ] Every link carries one situating sentence; parent-KR text quoted (dual-audience, D58).
 - [ ] Stays at control altitude — specs *what/why*, not application code or the agent's path.
+- [ ] **Durable**: names interfaces/behavioral contracts, never file paths or line numbers (they
+      stale while work waits); criteria behavioral + independently verifiable. Exception: a
+      prototype-derived snippet trimmed to its decision-rich parts (D60).

package/payload/okf/core/templates/prototype-brief-template.md

@@ -0,0 +1,64 @@
+---
+type: Template
+title: Prototype Brief Template
+description: The scaffold for a QUICK leg-A prototype brief (D60) — the idea, the user, the moment, the feel, draft copy seeds. Deliberately short; if it needs PRD-level detail the flow has failed its purpose. Copy into prototype/<initiative-id>/brief.md and set it as the initiative's prd_path.
+tags: [template, prototype, design, lane]
+timestamp: 2026-07-21
+---
+
+# Prototype Brief Template
+
+**Situating context:** The [prototype lane](/okf/products/pmos/adr/d60-prototype-loop.md)'s contract
+artifact. The PM writes THIS — quick, sketchy, incomplete is fine — and the **design agent does the
+rest**: picks up the product's design system, applies the
+[design-craft layer](/okf/core/concepts/design-craft.md), drafts real copy, and returns divergent
+lookable options. The brief is deliberately NOT a PRD: it exists so the PM can see something *before*
+committing to a spec. If filling it in starts to feel like writing requirements, stop — that detail
+belongs in the PRD that follows a successful prototype, not here.
+
+> Usage: copy into `prototype/<initiative-id>/brief.md`; set it as the initiative's `prd_path`
+> (`create_initiative`, `type: 'prototype'`). Every section may be a single sentence. Only the first
+> two are required.
+
+---
+
+```markdown
+# Prototype Brief: <working title>
+
+- initiative_id: <id>
+- product_slug: <product_slug>
+- date: <YYYY-MM-DD>
+
+## The idea (required)
+<!-- One or two sentences. What is this thing? -->
+
+## Who it's for, and the moment they'd use it (required)
+<!-- The user and the situation — "a PM opening the board on Monday morning", not a persona doc. -->
+
+## How it should feel
+<!-- Adjectives and references beat specification: "calm, dense, fast to scan", "more like a
+     cockpit than a report". Leave blank to let the agent propose. -->
+
+## Copy seeds
+<!-- Any words you already hear: a headline, a button label, the tone. The agent drafts REAL copy
+     (D60 — copy rides the prototype, no lorem); seeds steer it. Blank is fine. -->
+
+## What this is NOT
+<!-- One line if you already know a direction to avoid. -->
+
+## Existing surface?
+<!-- If this improves an existing screen/flow, name it. New idea → leave blank. -->
+```
+
+---
+
+## What the agent does with this (not the PM's job)
+
+1. **Design-system check first (blocking, D60):** no design system on this product → the agent
+   authors one from this same brief and the PM approves it *before* any prototype.
+2. Produces **divergent low-fidelity options** — one safe direction is a weaker outcome than three
+   arguable ones — with **real draft copy**, into `prototype/<initiative-id>/`.
+3. Submits to **designer grilling** (dialogue, never a score — D60): one question at a time, a
+   recommended answer with each.
+4. The PM **disposes**: promote (→ a new feature-lane initiative; PRD + rubric derived from the
+   validated option) / iterate / kill.

package/payload/scripts/frontier.sh

@@ -0,0 +1,60 @@
+#!/usr/bin/env bash
+# frontier.sh — list the workable tickets in a file-mode PMOS kit (E9).
+#
+# "Work the frontier": a ticket is workable when it is NOT done and EVERY ticket it is blocked_by is
+# done. This is the plain-file equivalent of a board's dependency structure — one file per ticket in
+# state/tickets/NNN-slug.md, numbered in dependency order, blocking edges as text.
+#
+#   scripts/frontier.sh              # from the kit root; lists workable tickets
+#   scripts/frontier.sh state/tickets   # explicit tickets dir
+#
+# Dependency-free and portable: POSIX-ish bash, no associative arrays (runs on bash 3.2, e.g. stock
+# macOS). No network, no board. Reads only the YAML frontmatter fields id / status / blocked_by.
+set -euo pipefail
+
+DIR="${1:-state/tickets}"
+[ -d "$DIR" ] || { echo "frontier: no tickets dir at '$DIR' (nothing to do)"; exit 0; }
+
+# --- field readers (frontmatter only: stop at the closing --- fence) ----------------------------
+fm() { awk 'NR>1 && /^---[[:space:]]*$/{exit} {print}' "$1"; }   # lines between the opening and closing ---
+field() { printf '%s\n' "$1" | sed -n "s/^$2:[[:space:]]*//p" | head -1 | sed 's/^["'\'']//;s/["'\'']$//;s/[[:space:]]*$//'; }
+# blocked_by is an inline list "[\"002\", \"005\"]"; extract the bare ids (digits) in order.
+blockers() { printf '%s\n' "$1" | sed -n 's/^blocked_by:[[:space:]]*//p' | head -1 | grep -oE '[0-9]+' || true; }
+# derive an id: explicit `id:` field, else the leading NNN of the filename.
+idof() { local i; i="$(field "$1" id)"; [ -n "$i" ] && { printf '%s' "$i"; return; }; basename "$2" | grep -oE '^[0-9]+' || basename "$2" .md; }
+
+shopt -s nullglob
+files=("$DIR"/*.md)
+[ ${#files[@]} -eq 0 ] && { echo "frontier: no tickets in '$DIR' (nothing to do)"; exit 0; }
+
+# --- pass 1: collect the done ids (newline-delimited; no associative arrays for bash-3.2 portability)
+DONE_IDS=""
+OPEN=0
+for f in "${files[@]}"; do
+  meta="$(fm "$f")"; id="$(idof "$meta" "$f")"; st="$(field "$meta" status)"
+  if [ "$st" = "done" ]; then DONE_IDS="$DONE_IDS$id
+"; else OPEN=$((OPEN+1)); fi
+done
+is_done() { printf '%s' "$DONE_IDS" | grep -qx "$1"; }
+
+# --- pass 2: a ticket is on the frontier when not done and every blocker is done -----------------
+found=0
+for f in "${files[@]}"; do
+  meta="$(fm "$f")"; id="$(idof "$meta" "$f")"; st="$(field "$meta" status)"; st="${st:-todo}"
+  [ "$st" = "done" ] && continue
+  workable=1
+  while IFS= read -r b; do
+    [ -z "$b" ] && continue
+    is_done "$b" || workable=0
+  done < <(blockers "$meta")
+  if [ "$workable" -eq 1 ]; then
+    printf '  ▸ %-5s %-8s %s\n' "$id" "[$st]" "$(field "$meta" title)"
+    found=$((found+1))
+  fi
+done
+
+if [ "$found" -eq 0 ]; then
+  # distinguish "all done" from "everything is blocked" — a stuck frontier is a real signal.
+  if [ "$OPEN" -eq 0 ]; then echo "frontier: all tickets done ✓"
+  else echo "frontier: $OPEN open ticket(s), NONE workable — the frontier is blocked (check for a cycle or an undone blocker)."; fi
+fi