create-pmos 0.38.5 → 0.38.7

package/payload/skills/requirements-elicitation.skill

@@ -0,0 +1,231 @@
+---
+name: requirements-elicitation
+description: Turn a vague ask, or notes the PM gathered, into a requirements brief by asking the PM questions one at a time. Use when the PM wants to gather, clarify or sharpen requirements, or before any lane writes its first artifact (PRD, spike brief, fix specification, content brief).
+version: 1.0.0
+owner: wawan
+risk: low
+category: planning
+scope: read:okf, read:planning, read:state, write:planning/briefs
+---
+
+# requirements-elicitation — Ask until the requirement is sharp
+
+This skill is the one place where PMOS states how an agent asks the PM questions. It also
+holds the questions each lane needs. Its output is a requirements brief that a PRD, a spike
+brief or a fix specification starts from. It does not write those documents.
+
+> **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)).
+
+## When to use vs. not
+
+- **Use** when the PM asks to gather, clarify or sharpen requirements.
+- **Use** before the first artifact of any lane, when the intent is not yet unambiguous.
+- **Do not use** to decide the lane. That is the [pmos-router](/skills/pmos-router.skill).
+- **Do not use** to judge whether to build at all. That is the
+  [strategic-brief](/skills/strategic-brief.skill).
+- **Do not use** when an instance of the idea is needed before the PM can judge it. Route to the
+  prototype lane first.
+
+## The asking rule
+
+This rule holds in every step below. Other skills point here and do not repeat it.
+
+1. Ask one question at a time.
+2. Give a recommended answer with each question.
+3. Do not set a limit on the number of questions. Stop when the intent is unambiguous.
+4. Do not send a batch questionnaire. A batch does not satisfy this rule.
+5. Look up each fact that the repository or the record can answer. Do not ask the PM for it.
+6. Leave each decision to the PM.
+7. Write nothing until the PM confirms the shared understanding.
+
+## Procedure
+
+1. **Find the lane.** 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`.
+   State the lane's `input`, `output` and `done` in plain words before the first question.
+   *Done when:* the PM has seen the lane's input, output and done-rule.
+
+   If the script is missing or the lane is not in `defs`, say so. Ask the PM which lane applies.
+   Do not guess a question set.
+
+2. **Look up what exists.** Read the record, the PRD or brief if one exists, the OKR the
+   record names, and the explainer if the surface exists. Collect the facts you found.
+   *Done when:* every fact you will use has a source, and none of them is a question for the PM.
+
+3. **Read the gathered notes.** List `<state>/requirements/*.md`. `<state>` is `pmos/state/`
+   if it exists, and `planning/` if not. Select each item whose `initiative` names this
+   initiative. Show each item to the PM with its pointer and its `confidence`. Ask for one
+   answer per item: confirmed, rejected or deferred. Record the answer.
+   - A confirmed item goes in the brief under *Decisions*, with its pointer.
+   - A rejected item is dropped. Name it in *Gathered notes used* as rejected.
+   - A deferred item goes in *Open questions*.
+   - An item with `confidence: unconfirmed` stays unconfirmed until the PM answers. Never write
+     it as a fact.
+   - Name a note that does not parse. Skip it.
+   - If no notes exist, say so and continue.
+
+   Never edit a note. The notes are read-only drafts (D71).
+   *Done when:* every selected item has an answer, or the PM has said to skip the notes.
+
+4. **Ask the topic questions.** Work through the [question inventory](#question-inventory).
+   Skip a topic the lane's input does not need, and say that you skipped it.
+   Skip a question that step 2 or step 3 already answered.
+   *Done when:* each topic is answered, skipped with a reason, or listed in *Open questions*.
+
+5. **Ask the lane questions.** Find the lane in [Question sets by lane](#question-sets-by-lane).
+   Ask each question there that the earlier steps did not answer.
+   *Done when:* every element of the lane's `input` has an answer or an *Open questions* entry.
+
+6. **Confirm.** Say the shared understanding back to the PM in one short list. Ask the PM to
+   confirm or correct it.
+   *Done when:* the PM has confirmed. If the PM corrects it, go back to step 4.
+
+7. **Write the brief.** Copy the
+   [requirements-brief-template](/okf/core/templates/requirements-brief-template.md). Fill every
+   section from the confirmed answers, in the PM's words where the PM gave words. Write it to
+   `planning/briefs/<id>-requirements.md`. Set `brief_path` on the initiative record. If the lane
+   uses `prd_path` for its first artifact and that file does not exist yet, tell the PM that the
+   brief is the input and that the lane's own skill writes `prd_path`.
+   *Done when:* the file exists, no section is empty, and `brief_path` is set.
+
+8. **Hand over.** Name the next skill for the lane: [prd](/skills/prd.skill) for
+   feature and new-feature, [discovery](/skills/discovery.skill) for discovery,
+   [copywriting](/skills/copywriting.skill) for content, and the lane's own
+   template for the others. State the open questions that remain.
+   *Done when:* the PM knows what comes next and what is still open.
+
+## Question inventory
+
+Each topic has an opening question. Add follow-up questions when the answer is vague.
+
+| Topic | Opening question |
+|---|---|
+| Problem and user | Who has this problem, and what do they do today instead? |
+| Evidence | What shows that the problem is real: a number, a ticket, a quote, an incident? |
+| Constraints | What is fixed: a date, a budget, a technology, a rule or a promise 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, before this can work? |
+| Data | What data does this read or change, and who owns it? |
+| Non-functional needs | What must hold about speed, security, privacy, access or cost? |
+| Risks | What is the worst way this fails, and how would we notice? |
+| Success measure | Which measure moves if this works, from what value to what value, by when? |
+| Out of scope | What will this not do, even though someone might expect it to? |
+
+## Question sets by lane
+
+Each lane has its own heading. The headings use the lane names in `scripts/lane-defs.js`.
+A lane name that both profiles use (discovery, chore) has one set.
+
+### Lane `feature`
+
+1. What behaviour changes for the user, in one sentence?
+2. Does the surface exist today? If yes, what does it do now?
+3. Which KR or health budget does this serve?
+4. Can the PM judge this from a description, or must the PM see an instance first?
+5. What would the PM check by hand to accept it?
+
+### Lane `new-feature`
+
+1. Who has the problem, and how often does it happen?
+2. What shows that it is real?
+3. What do users do today?
+4. What must a first version do, and what can wait?
+5. What would make the PM drop it?
+
+### Lane `improvement`
+
+1. What does the feature do now? Look it up first.
+2. What is wrong or missing, and for whom?
+3. Which measure should the change move, and by how much?
+4. What must stay the same?
+5. How will we tell that it worked?
+
+### Lane `bug-fix`
+
+1. What are the steps that reproduce it?
+2. What is the expected result?
+3. What is the actual result?
+4. How severe is it, and who is affected?
+5. Is there a workaround?
+
+### Lane `discovery`
+
+1. What is the question, in one sentence?
+2. What is unknown, and what is already known?
+3. What evidence would end the spike?
+4. What would make this worth picking up, and what would make it worth dropping?
+5. How long may it take?
+
+### Lane `chore`
+
+1. What is the intent, in one paragraph?
+2. Which health budget does it serve?
+3. What must not change?
+4. How will the PM see that it is done?
+
+### Lane `incident`
+
+1. What broke, and who noticed?
+2. What is the cause?
+3. What was the repair, and is it permanent?
+4. What stops it from happening again?
+5. When was it fixed? The record is due within 48 hours.
+
+### Lane `content`
+
+1. Who reads it, and what should they do after?
+2. What is the one message?
+3. What tone and length does the reader expect?
+4. What facts must it contain, and where are they?
+5. Does the PM want a rubric?
+
+### Lane `prototype`
+
+1. What judgement does the PM need to make?
+2. Which format fits the specimens: a screen, a sample output, a transcript or a schema?
+3. What should the 2–3 specimens differ on?
+4. Which conventions does the class need before the specimens (design system, skill format)?
+
+### Lane `prd`
+
+1. What is the question the document answers?
+2. Who reads it?
+3. Which decision does it inform?
+4. What do the readers already know?
+
+### Lane `strategy`
+
+1. What is the question the document answers?
+2. Who reads it?
+3. Which decision does it inform?
+4. Over what period?
+
+### Lane `project-plan`
+
+1. What is in scope, and what is out?
+2. Who is on it, and for how much of their time?
+3. Which dates are fixed, and who fixed them?
+4. What does it depend on?
+
+### Lane `decision-record`
+
+1. What are the options?
+2. Which one was chosen, and by whom?
+3. What is the reason?
+4. What would reverse the choice?
+
+### Lane `report`
+
+1. What period or subject does it cover?
+2. Who reads it?
+3. What should the reader do after reading?
+4. Which sources does it use, and which can it not reach?
+
+## Failure behaviour
+
+- The lane definition cannot be read: say so, and ask the PM which lane applies.
+- No gathered notes exist: say so, and continue.
+- A note does not parse: name it, and skip it.
+- The PM leaves a question open: write it under *Open questions*. Do not answer it.

package/payload/skills/technical-writing-ste.skill

@@ -39,7 +39,7 @@ Ask what the reader must do with it. Derive the class from the path, not from fe
 | Class | What the reader must do | Where it lives |
 |---|---|---|
 | **A — instructional** | **Act**, correctly, on one reading | `skills/**` · playbooks and runbooks · gate and CI failure strings · UI copy and microcopy · tool descriptions · template usage notes |
-| **B — descriptive** | **Understand**, not obey | `okf/**` concepts and references · explainers · `**/README.md` · design and data-model docs |
+| **B — descriptive** | **Understand**, not obey | `okf/**` concepts and references · explainers · `**/README.md` · design and data-model docs · agent-drafted status reports and stakeholder updates (`planning/reports/**`, `<state>/reports/**`) |
 | **C — argumentative** | **Weigh a judgement under uncertainty** | ADRs and decision records · `planning/prd/**` · briefs · the discoveries log · eval verdicts · PR bodies |
 
 The three classes are the rule. **The paths are your repo's, so write them down once.** In PMOS they
@@ -48,8 +48,10 @@ also cover `build-skills/**` and `okf/core/playbooks/**` (A), `planning/explaine
 cover your CLI output, your error strings and your component copy (A), and your architecture notes
 (B). When a path is not on your list, ask the question in column two and add the answer to the list.
 
-Two boundary rules. **Text the PM wrote is Class C**, whatever it is about. And the profile binds
-**new and modified text only** — never rewrite an existing corpus to satisfy it.
+Three boundary rules. **Text the PM wrote is Class C**, whatever it is about. The profile binds
+**new and modified text only** — never rewrite an existing corpus to satisfy it. And inside an
+agent-drafted status report or update, the request in *Needs your call* is **Class A**: the reader
+must act on it, so write one question, the options, your recommendation and the date.
 
 **Done when:** you can name the class and the row that put it there.
 

package/payload/skills-native/design-brief/SKILL.md

@@ -40,12 +40,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-native/discovery/SKILL.md

@@ -73,5 +73,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-native/eval-rubric/SKILL.md

@@ -81,11 +81,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-native/pm-communication/SKILL.md

@@ -0,0 +1,125 @@
+---
+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.
+license: MIT
+metadata:
+  pmos-version: 1.0.0
+  pmos-owner: wawan
+  pmos-risk: low
+  pmos-category: communication
+  pmos-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-native/pmos-router/SKILL.md

@@ -65,6 +65,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
@@ -99,5 +101,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-native/prd/SKILL.md

@@ -32,22 +32,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
@@ -109,8 +104,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) +