create-pmos 0.38.5 → 0.38.7

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "create-pmos",
-  "version": "0.38.5",
+  "version": "0.38.7",
   "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. Includes `workflow-sweep`, which audits the state every board derives from and separates real defects from work you simply have not done. `create-pmos workspace` also installs + launches the local Terminal Workspace GUI. No database, no network, no telemetry.",
   "license": "MIT",
   "bin": {

package/payload/AGENTS.md

@@ -81,7 +81,7 @@ Every initiative carries a `type` — the lane picks what the gate requires **be
    - **Choose the model for the work (D75).** Before you delegate a sub-task or start a long routine one, run `node pmos/scripts/pmos-model.js recommend "<the work>"`: it returns a tier (`fast` for routine, `balanced`, `deep` where a mistake is costly to find later), the model and effort it maps to in the PM's policy, and why. Use it; do not pick the strongest model for everything. Review and evaluation work is pinned and is never downgraded.
    - **Documents you write here follow OKF v0.2 (D73).** `type`, `title`, `description`, then `generated: {by: claude-code/<skill>, at: "<ISO time>"}`, `sources: [{resource: "<link or id>", title: "…"}]` and `status: draft` — **one key per line, nothing indented** (the readers stop at the first indented line), no `timestamp`. Only the PM sets `status: stable` or adds `verified`. This does not apply to initiative records, tickets or ledgers. `node pmos/scripts/okf-upgrade.js .` reports what in this repository is not yet conformant.
    - **Existing surface → the PM needs the understanding too.** That retrieval warms *you*. When the work touches something that already exists — the test is *would specifying this honestly require reading code that already exists?* — run `skills/explain-surface.skill` on that region **before** the brief/PRD is authored, in a fresh context and **not** by the agent that will write it. Standard for existing surfaces, skipped for greenfield. Without it, the agent acquires the understanding and the **PM approves a spec built on facts they never saw**.
-4. Anchor: the initiative file must exist at stage `intake`/`spec` with its **lane's** spec/eval artifacts authored **before** build (eval-first, D13, generalized per lane — see the lane table above; `feature` = PRD + rubric; the incident lane alone records post-hoc). Contract per lane: `feature` = the rubric's sprint-contract section with the PM's explicit `PM_approved: true`; `discovery` = the PM-approved spike brief (question + timebox); `chore` = the stated intent; `content` = the PM-approved content brief; `prototype` = the PM-approved quick brief (the judgement exercised + the specimen format) — and **no rubric**, which is the decision, not an omission. No work before the lane's approval. Feature-lane `test_method`s SHOULD be executable checks written before build (D58) — wire `templates/product-ci-starter.yml` so tier 1 is never silently empty.
+4. Anchor: the initiative file must exist at stage `intake`/`spec` with its **lane's** spec/eval artifacts authored **before** build (eval-first, D13, generalized per lane — see the lane table above; `feature` = PRD + rubric; the incident lane alone records post-hoc). Contract per lane: `feature` = the rubric's sprint-contract section with the PM's explicit `PM_approved: true`; `discovery` = the PM-approved spike brief (question + timebox); `chore` = the stated intent; `content` = the PM-approved content brief; `prototype` = the PM-approved quick brief (the judgement exercised + the specimen format) — and **no rubric**, which is the decision, not an omission. No work before the lane's approval. When you question the PM to reach any of these, follow `skills/requirements-elicitation.skill`. Feature-lane `test_method`s SHOULD be executable checks written before build (D58) — wire `templates/product-ci-starter.yml` so tier 1 is never silently empty.
 5. Branch `initiative/<id>`; execute at control altitude; one commit per artifact.
 6. Self-evaluate against the contract — self-eval is unreliable; it is an input to the gates, never a verdict.
 7. Close the gates: **Quality** = this repo's CI plus the kit gate (`pmos/scripts/gate-initiative.sh`

package/payload/KIT-VERSION

@@ -1,3 +1,3 @@
-kernel-source: pmos@f5daae8
-assembled: 2026-10-02
+kernel-source: pmos@8c38e46
+assembled: 2026-10-03
 mode: vendor

package/payload/okf/core/templates/report-rubric-template.md

@@ -0,0 +1,35 @@
+---
+type: Template
+title: Report Rubric Template
+description: The scaffold for judging a report or decision record (D68 report and decision-record lanes) — accuracy and sourcing, audience fit, decision clarity and honest gaps, with a pass threshold and two caps. Copy it as the rubric the lane's review step grades against.
+tags: [template, report, rubric, review, pm-artifacts]
+timestamp: 2026-10-03
+---
+
+# Report Rubric Template
+
+**Situating context:** Authored with [D78](/okf/products/pmos/adr/d78-one-report-shape.md). The review step of the `report` and `decision-record` lanes turned green on any non-empty `reviewed_by`, with no standard to grade against. This rubric is that standard. The [pm-communication skill](/skills/pm-communication.skill) hands it to the reviewer. Copy the block below, set the audience, and keep the weights unless the PM changes them. The copy is an operational instance, not OKF knowledge.
+
+> Usage: the reviewer is not the drafter. Grade the document, not the process that made it. Score each dimension from 0 to 1, multiply by its weight, add them, and compare to the threshold. Record the verdict in `evals.jsonl`. The PM's acceptance is separate and binds.
+
+---
+
+```markdown
+# Rubric: <report or decision record title>
+
+- initiative_id: <id>
+- audience: <leadership | delivery | partner>
+- pass_threshold: 0.80
+
+| # | Dimension | Weight | Full credit |
+|---|---|---|---|
+| D1 | Accuracy and sourcing | 0.30 | Every claim carries a pointer: an initiative id, an acceptance, a note, or a source item. A reviewer can open each pointer and find the claim. Numbers match their source. |
+| D2 | Audience fit | 0.25 | The order and content match the audience. Leadership: the decision or headline first, then the risk, then the evidence. Delivery: scope, state, acceptance and what blocks. Partner: what changed for them and what they must do, with a date. Nothing the audience cannot act on is included. |
+| D3 | Decision clarity | 0.25 | The reader can tell, from the first screen, whether a decision is needed, what it is, the options, the recommendation and the date. A document with no decision says so. A decision record states the choice before the reasoning. |
+| D4 | Honest gaps | 0.20 | Sources that could not be reached are named. Items that could not be verified are marked unverified. A quiet period is reported as quiet. Nothing is filled in to make the report look complete. |
+
+## Caps
+
+- A claim stated as fact with no pointer that the reviewer cannot find in any source: the score is capped at 0.60.
+- A source named that the drafter did not reach: the score is capped at 0.40.
+```

package/payload/okf/core/templates/report-weekly-template.md

@@ -1,35 +1,46 @@
 ---
 type: Template
 title: Weekly Report Template
-description: A regular status report (D68 report lane, light track by default): what moved, against which KR or domain goal, what is blocked, and what needs the reader.
+description: A regular status report (D68 report lane, light track by default) in the one report frame of D78 — Headline, What moved, Risks, Metrics, Needs your call, Sources reached and not reached — for a named audience.
 tags: [template, report, status, pm-artifacts]
-timestamp: 2026-10-01
+timestamp: 2026-10-03
 ---
 
 # Weekly Report Template
 
-**Situating context:** Authored with [D68](/okf/products/pmos/adr/d68-repository-profiles.md) for the pm-artifacts profile, by release R3 of [the PMOS overhaul plan](/planning/research/pm-overhaul-plan.md). Copy the block below into the repository's planning area, fill every `<…>`, and point the initiative record at it (`brief_path` for a brief, `doc_path` for the deliverable). The copy is an operational instance, not OKF knowledge.
+**Situating context:** Authored with [D68](/okf/products/pmos/adr/d68-repository-profiles.md) for the pm-artifacts profile, by release R3 of [the PMOS overhaul plan](/planning/research/pm-overhaul-plan.md). Copy the block below into the repository's planning area, fill every `<…>`, and point the initiative record at it (`brief_path` for a brief, `doc_path` for the deliverable). The copy is an operational instance, not OKF knowledge. The section list is the report frame of [D78](/okf/products/pmos/adr/d78-one-report-shape.md): Headline first, Needs your call and Sources reached and not reached last. A PM's definition file may replace the middle sections (What moved, Risks, Metrics). The [pm-communication skill](/skills/pm-communication.skill) drafts this document for a named audience. Keep the `initiative_id` line: the workflow audit uses it to find the report.
 
 ---
 
 ```markdown
+---
+type: Reference
+title: "Report — <week of YYYY-MM-DD> — <scope: domain | portfolio>"
+initiative_id: <id of the report-lane initiative>
+audience: <leadership | delivery | partner>
+status: draft
+---
+
 # Weekly report — <week of YYYY-MM-DD> — <scope: domain | portfolio>
 
 ## Headline
-<one sentence: the most important change this week>
+<one or two sentences: what the reader most needs to know. Put the decision first if there is one.>
 
-## Moved this week
+## What moved
 | initiative | anchor (KR · domain) | what moved | evidence |
 |---|---|---|---|
 
+## Risks
+| initiative | risk or blocker | what is needed | from whom |
+|---|---|---|---|
+
 ## Metrics
 | metric | last week | this week | target | trend |
 |---|---|---|---|---|
 
-## Blocked or at risk
-| initiative | blocker | what is needed | from whom |
-|---|---|---|---|
+## Needs your call
+<each decision or review waiting on the reader: the question, the options, your recommendation, the date it is needed by>
 
-## Needs you
-<the decisions or reviews waiting on the reader>
+## Sources reached and not reached
+<each source kind: reached, or not reached and why. Say if nothing changed.>
 ```

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

@@ -0,0 +1,61 @@
+---
+type: Template
+title: Requirements Brief Template
+description: The scaffold for the brief that the requirements-elicitation skill writes — problem, evidence, constraints, stakeholders, dependencies, success measure, out of scope, open questions, gathered notes used and decisions. Copy into /planning/briefs/ as <id>-requirements.md and set it as the initiative's brief_path.
+tags: [template, requirements, elicitation, lanes]
+timestamp: 2026-10-03
+---
+
+# Requirements Brief Template
+
+**Situating context:** Authored with the `requirements-skills-overhaul` initiative. Each lane used to start from its own artifact with no shared record of what the PM said. The [requirements-elicitation skill](/skills/requirements-elicitation.skill) fills this brief from a dialogue with the PM. A PRD, a spike brief or a fix specification starts from it. Copy the block below into `/planning/briefs/<id>-requirements.md`. The copy is an operational instance, not OKF knowledge.
+
+> Usage: replace every `<…>` placeholder. Write each answer in the PM's words where the PM gave words. Leave no section empty: write `none` or move the item to *Open questions*. Never write an unconfirmed item as a fact.
+
+---
+
+```markdown
+# Requirements Brief: <initiative title>
+
+## Identity
+- initiative_id: <id>
+- lane: <lane name>
+- parent_KR: <objective or KR reference, or health:<id>>
+- date: <YYYY-MM-DD>
+
+## Problem and user
+<!-- Who has the problem, and what do they do today instead? -->
+
+## Evidence
+<!-- What shows that the problem is real? Give a source for each item. -->
+
+## Constraints
+<!-- What is fixed: dates, budget, technology, rules, promises already made. -->
+
+## Stakeholders and decision owner
+<!-- Who is affected, who must agree, and who decides if they disagree. -->
+
+## Dependencies
+<!-- What must exist, or be done by someone else, first. -->
+
+## Success measure
+<!-- The measure, its start value, its target and the date. -->
+
+## Out of scope
+<!-- What this will not do, even though someone might expect it to. -->
+
+## Lane answers
+<!-- The answers to the lane's own questions: bug report fields for a bug-fix,
+     the question and drop criteria for a discovery, and so on. -->
+
+## Open questions
+<!-- Each question the PM left open, and each deferred note item. Do not answer them here. -->
+
+## Gathered notes used
+<!-- For each note item shown to the PM: the pointer, its confidence, and the PM's answer
+     (confirmed, rejected or deferred). Write `none` if no notes existed. -->
+
+## Decisions
+<!-- The PM's confirmed decisions, in the PM's words. A confirmed note item goes here with
+     its pointer. -->
+```

package/payload/planning/evals/eval-calibration.md

@@ -2,7 +2,7 @@
 type: Reference
 title: "Eval calibration log"
 description: "Append-only record of every PM override of an evaluator verdict."
-generated: {by: process:create-pmos, at: "2026-10-02T23:30:04Z"}
+generated: {by: process:create-pmos, at: "2026-10-03T01:20:42Z"}
 status: stable
 ---
 

package/payload/planning/okrs/health-budgets.md

@@ -2,7 +2,7 @@
 type: Reference
 title: "Health budgets"
 description: "Closed registry of health-budget anchors (D59), edited only by the PM."
-generated: {by: process:create-pmos, at: "2026-10-02T23:30:04Z"}
+generated: {by: process:create-pmos, at: "2026-10-03T01:20:42Z"}
 status: stable
 ---
 

package/payload/skills/design-brief.skill

@@ -38,12 +38,11 @@ definition of *what to design* and the hard constraints, agreed before any desig
 
 ## Procedure
 
-0. **Grill before you brief** (the [prd skill](/skills/prd.skill)'s step-0 discipline, applied
-   to design intent): where the PM's aesthetic or structural intent is ambiguous, ask **one question
-   at a time with a recommended answer**, stop at unambiguous — no cap; a batch questionnaire is not
-   compliant. Look up what the environment answers (the capability ledger, the design system, the
-   promoted prototype); the taste calls are the PM's (D12). The recorded cost of skipping this is the
-   console-redesign series — "too many navigations" was stated once and unhonored twice.
+0. **Ask before you brief.** Where the PM's aesthetic or structural intent is ambiguous, follow the
+   [requirements-elicitation skill](/skills/requirements-elicitation.skill). Look up what the
+   environment answers (the capability ledger, the design system, the promoted prototype); the taste
+   calls are the PM's. The recorded cost of skipping this is the console-redesign series — "too many
+   navigations" was stated once and unhonored twice.
 1. **Confirm the anchor.** The initiative has a PRD and an anchor — a parent KR, or a declared
    health budget `health:<id>` (D59). The brief does not re-argue *whether*
    to build the surface; it says how it should look.

package/payload/skills/discovery.skill

@@ -71,5 +71,4 @@ initiative; prototype code deleted or explicitly quarantined.
 
 ## Level 3 sub-cases
 
-- None yet. (Multi-question research programs spanning several spikes: author
-  `discovery-program.md` on first need.)
+- None yet.

package/payload/skills/eval-rubric.skill

@@ -79,11 +79,8 @@ Before any work begins, the generator and evaluator **agree on done-criteria**
 contract stage of the [SDLC loop](/okf/core/concepts/sdlc-loop.md). A rubric is incomplete without
 one.
 
-**Reach the criteria by grilling, not assumption** (the [prd skill](/skills/prd.skill)'s step-0
-discipline applies here too): where the PM's intent is ambiguous, ask **one question at a time with a
-recommended answer**, stop at unambiguous — no cap, and a batch questionnaire is not compliant. If a
-fact can be found by exploring the environment, look it up rather than asking — the decisions are the
-PM's (D12). **Write criteria for durability:** behavioral contracts and interfaces, never file paths
+**Reach the criteria by asking, not assumption.** Where the PM's intent is ambiguous, follow the
+[requirements-elicitation skill](/skills/requirements-elicitation.skill). **Write criteria for durability:** behavioral contracts and interfaces, never file paths
 or line numbers (they stale while work waits); each criterion independently verifiable.
 
 **Format:**

package/payload/skills/pm-communication.skill

@@ -0,0 +1,123 @@
+---
+name: pm-communication
+description: Draft a status report, stakeholder update or decision record for one named audience (leadership, delivery or partner), write it where the initiative's record points, and set doc_path. Use when the PM asks for a status update, a stakeholder update, a decision communication, a report, or to put a scheduled draft under a lane.
+version: 1.0.0
+owner: wawan
+risk: low
+category: communication
+scope: read:okf, read:planning, read:state, write:planning/reports
+---
+
+# pm-communication — Draft the update for the reader
+
+This skill is the producer for the `report` and `decision-record` lanes of the document profile
+([D77](/okf/products/pmos/adr/d77-lane-definitions.md)). It drafts one document for one audience in
+the report frame of [D78](/okf/products/pmos/adr/d78-one-report-shape.md). It writes a file. It sends
+nothing.
+
+> **Format note:** this skill follows [SKILL-FORMAT](/skills/SKILL-FORMAT.md). The text is
+> instructional (class A of [technical-writing-ste](/skills/technical-writing-ste.skill)).
+> The documents it drafts are class B, except the request in *Needs your call*.
+
+## When to use vs. not
+
+- **Use** for a status report, a stakeholder update, a decision record or a decision communication.
+- **Use** to put a scheduled draft under the `report` lane (step 4).
+- **Do not use** for customer-facing copy or release notes. That is the content lane and the
+  [copywriting skill](/skills/copywriting.skill).
+- **Do not use** to decide the lane. That is the [pmos-router](/skills/pmos-router.skill).
+- **Do not use** to gather what the PM wants to say. That is the
+  [requirements-elicitation skill](/skills/requirements-elicitation.skill), which holds the
+  questions for the `report` and `decision-record` lanes. Follow it when step 2 needs answers.
+
+## Rules that always hold
+
+1. The draft is a file in this repository. Never send, post, share, email, publish or upload it. The PM does that (D71).
+2. Every claim carries a pointer: an initiative id, an acceptance, a note, a run or a source item. A claim with no pointer is left out or marked "unverified".
+3. Write nothing that you did not read. Name each source you could not reach. If nothing changed, say so.
+4. Never write `reviewed_by`, a review verdict, an acceptance or a handoff. Those belong to the reviewer and the PM.
+5. A gathered note with `confidence: unconfirmed` is marked unverified in the draft. Never write it as a fact.
+6. Skip threads and pages that are private, personal, confidential or HR. Count them. Do not read them.
+7. Never copy message bodies, attachments, tokens or credentials. Quote at most one short sentence per item.
+
+## Procedure
+
+1. **Find the lane and the record.** Read the initiative record and its `type`. Run
+   `node scripts/workflow-state.js --lanes --json` (in a kit repository the script is
+   `pmos/scripts/workflow-state.js`). Find the lane in `defs`. It must be `report` or
+   `decision-record`. State the lane's `output` and `done` in plain words before you draft.
+   *Done when:* the PM has seen the lane's output and done-rule.
+
+   If the profile has no such lane (the code profile), say so. Offer the content lane with an
+   internal audience, and stop. If the script is missing or the lane is unknown, say so and ask
+   which lane applies.
+
+2. **Name the audience.** The audience is leadership, delivery or partner. Read it from the
+   record, the PM's definition file or the PM's request. If none names it, ask the PM, with a
+   recommended answer, by the requirements-elicitation skill. Do not choose one.
+   *Done when:* the audience is one of the three and the PM has confirmed it.
+
+3. **Gather the facts.** Read what the draft will claim: the initiatives and their acceptances
+   (`node scripts/workflow-state.js`), the runs, the notes in `<state>/requirements/` (`<state>`
+   is `pmos/state/` if it exists, and `planning/` if not), and each source the PM's definition
+   file names that you can reach. For a report, read `<state>/reports/definitions/<cadence>.md`
+   if it exists and follow it where it does not remove a part of the frame. Look facts up. Do
+   not ask the PM for a fact that a file holds.
+   *Done when:* each claim you will make has a pointer, and each source you could not reach is listed.
+
+4. **Adopt a scheduled draft, if the PM names one.** If the PM points at an existing draft (a
+   file under `<state>/reports/`), do not draft a new one. Set the record's `doc_path` to that
+   file (step 6) and go to step 7 on it. Tell the PM that the draft was written by a schedule
+   and was not part of the lane until now.
+   *Done when:* the PM has said whether to adopt or to draft a new one.
+
+5. **Draft in the audience's register.** For a report, copy the
+   [report template](/okf/core/templates/report-weekly-template.md). For a decision record, copy the
+   [decision-record template](/okf/core/templates/decision-record-template.md). Fill every section
+   in the order and register for the audience (see [Registers](#registers)). The Headline comes
+   first. If a decision is needed, the Headline says what it is.
+   Write the file to the record's `doc_path`. If the record has none, write
+   `planning/reports/<initiative-id>-<YYYY-MM-DD>.md`. If the file exists, do not overwrite it:
+   append a section `## Later run HH:MM`. Start with this frontmatter, one key per line:
+   `type: Reference`, `title`, `initiative_id`, `audience`, `status: draft`,
+   `generated: {by: claude-code/pm-communication, at: "<ISO 8601>"}` and
+   `sources: [{resource: "<pointer>", title: "<what it is>"}]`. Do not add `timestamp` or `verified`.
+   *Done when:* the file exists and has all the sections of its template.
+
+6. **Point the record at it.** Set `doc_path` on the initiative record to the file. This is the
+   only key you set. If `doc_path` already names a different file, do not change it: ask the PM.
+   *Done when:* `node scripts/workflow-state.js <id>` shows the draft step done with this file as its basis.
+
+7. **Check the draft against the done-rule.** Read the lane's `done` text. Say which part is
+   met: the document exists (yes), a reviewer has judged it (not yet), the PM has accepted it
+   (not yet), and handed off, where the lane says so (not yet). Then check the draft:
+   the Headline is first; the decision or the absence of one is visible on the first screen;
+   each claim has a pointer; *Sources reached and not reached* is last; nothing in it is
+   outside the audience's register.
+   *Done when:* every check passes or the failing one is named to the PM.
+
+8. **Hand over.** Say where the draft is. Name the review step: the reviewer is not you, and
+   grades against the [report rubric](/okf/core/templates/report-rubric-template.md). State the open
+   questions and the sources not reached. Do not send the draft.
+   *Done when:* the PM knows where the draft is, who must review it, and what is still open.
+
+## Registers
+
+One register per audience. The order is fixed. What a register leaves out is as much a part of it
+as what it includes. A decision comes before its reasoning for every audience.
+
+| Audience | Order | Include | Leave out | Length |
+|---|---|---|---|---|
+| **Leadership** | The decision or headline; the risk; the evidence | The call you need and by when; the effect on a goal or a date; one number that shows it | Task lists, tool names, how the work was done | One screen |
+| **Delivery** | Scope and state; acceptance; what blocks | Initiative ids, acceptance state, blockers with an owner, next step | Strategy, history before this period | As long as the work needs, in tables |
+| **Partner** | What changed for them; what they must do, and by when | The change in their terms, the date, who to ask | Internal ids, internal debate, anything they cannot act on | Short: the action first |
+
+For a decision record, the choice and its owner come first. Then who must act and by when. The
+reasoning and the options considered come last.
+
+## Failure behaviour
+
+- The audience is not named and the PM does not answer: do not draft. Say what is missing.
+- The lane definition cannot be read: say so, and ask which lane applies.
+- No source can be reached: write a short honest draft that says so. Do not fill the gap.
+- `doc_path` names a different file: do not change it. Ask the PM.

package/payload/skills/pmos-router.skill

@@ -63,6 +63,8 @@ router is the bug (fix it via the weekly harness scan).
 | "**Production is broken**" | **Incident lane** | `type: incident`; fix now, record post-hoc within 48h at `prd_path` (the one sanctioned inversion; [incident template](/okf/core/templates/incident-record-template.md)) | Initiative Gate (record, post-hoc) |
 | A **text deliverable** (landing page, microcopy, release notes, campaign) | **Content lane** | `type: content`; content brief at `prd_path`, rubric recommended not required (D58); [copywriting skill](/skills/copywriting.skill). Copy for a prototype rides the prototype instead (D60) | Initiative Gate (content brief) |
 | **Upkeep** — refactor/ops/security with no honest KR | **Chore lane, health-anchored** | `type: chore`; one-paragraph intent in `status`; anchor `health:<id>` from [health-budgets](/planning/okrs/health-budgets.md) (D59) — never a faked KR | Initiative Gate (intent + anchor) |
+| "**Gather**, **clarify** or **sharpen** the requirements" — the PM has a vague ask or notes from gathering and no brief yet | **Requirements elicitation** (before the lane's first artifact) | [requirements-elicitation skill](/skills/requirements-elicitation.skill) → `planning/briefs/<id>-requirements.md` at `brief_path`; reads the lane's input from `scripts/lane-defs.js` and the notes `gather-requirements` filed (D71); the PM confirms each note item. It does not choose the lane and does not write the PRD | none (the brief is never a gate) |
+| "**Write a status update**, a **stakeholder update** or a **decision communication**", or put a scheduled report draft under a lane — a report, an update or a decision record for a named audience (leadership, delivery or partner) | **Document profile: the `report` or `decision-record` lane.** **Code profile: the content lane**, with an internal audience (customer-facing copy is a different request) | [pm-communication skill](/skills/pm-communication.skill) → a draft at `doc_path`, in the report frame of D78 (Headline, the middle sections, Needs your call, Sources reached and not reached); it asks for the audience, sets `doc_path`, never sends and never writes the review or the acceptance. The reviewer grades against the [report rubric](/okf/core/templates/report-rubric-template.md) | Initiative Gate (the lane's record); the review and acceptance steps stay open for the reviewer and the PM |
 
 **Every route** still takes the universal steps: anchored initiative row (`create_initiative`),
 branch `initiative/<id>`, and the human Acceptance Gate at the end (D12) — the router never bypasses
@@ -97,5 +99,5 @@ Check your position at any time with `node scripts/workflow-state.js <id>`.
   already decided to explore, go straight to prototype.
 - **Anchor-free trivia** (a typo, a broken link): the `no-initiative` label, no lane. Real work
   never takes the hatch.
-- **Unknown shape after the checks:** ask the PM one routing question with a recommended answer —
-  do not guess a lane.
+- **Unknown shape after the checks:** ask the PM one routing question, as the
+  [requirements-elicitation skill](/skills/requirements-elicitation.skill) describes. Do not guess a lane.

package/payload/skills/prd.skill

@@ -30,22 +30,17 @@ agreed.
 
 ## Procedure
 
-0a. **Existing surface? Understand it first — before grilling.** If specifying this honestly
+0a. **Existing surface? Understand it first — before asking.** If specifying this honestly
    requires reading code that already exists, an [explain-surface](/skills/explain-surface.skill)
    pass runs on that region **first**, in a fresh context and **not by you**. Its *Open questions*
-   section is a declared input to the grilling below: those are the things that could not be
+   section is a declared input to the questions in step 0: those are the things that could not be
    determined from the code, and they must be resolved with the PM or carried explicitly into the
    PRD's risks — never silently answered by assumption. Greenfield → skip. This exists because step 0b's
    boundary rule, on its own, gives the **agent** the understanding and the PM none.
-0. **Grill before you write.** Before any authoring, interrogate the PM's intent as a dialogue —
-   **one question at a time, a recommended answer offered with each**, no authoring until shared
-   understanding is confirmed. Stop when the intent is **unambiguous**, not at a count — there is
-   deliberately **no question cap** (under-specification needs unlimited digging; a redundant
-   question is a quality bug, not a quantity bug). A batch questionnaire is **not** compliant with
-   this step. Boundary rule, near-verbatim from AGENTS.md: *if a fact can be found by exploring the
-   environment, look it up rather than asking — the decisions, though, are the PM's* (D12 at
-   optimal altitude). A stated requirement that later goes unhonored in a build (the recorded
-   "too many navigations" class) is exactly what this step exists to pin down in writing.
+0. **Ask before you write.** Follow the [requirements-elicitation skill](/skills/requirements-elicitation.skill):
+   its asking rule holds here, and no authoring starts until the PM confirms the shared understanding.
+   A stated requirement that later goes unhonored in a build (the recorded "too many navigations"
+   class) is what this step pins down in writing.
 1. **Anchor to strategy first.** Identify the parent KR in the
    [OKR tree](/okf/core/concepts/okr-tree.md) — or, for maintenance work with no honest KR, the
    declared [health budget](/okf/core/concepts/health-anchors.md) (`health:<id>`, D59). If the
@@ -107,8 +102,7 @@ its situating sentence (D58); the eval rubric is queued to be written first.
 
 ## Level 3 sub-cases
 
-- Multi-product or platform PRDs that span more than one `product_slug`: see `prd-multiproduct.md`
-  (author on first need).
+- None yet.
 - Spike / discovery work where the deliverable is a learning, not a feature, is **not a PRD
   case** — take the discovery lane ([D56](/okf/products/pmos/adr/d56-initiative-lanes.md)):
   [discovery skill](/skills/discovery.skill) +