create-pmos 0.38.6 → 0.38.7
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/package.json +1 -1
- package/payload/KIT-VERSION +1 -1
- package/payload/okf/core/templates/report-rubric-template.md +35 -0
- package/payload/okf/core/templates/report-weekly-template.md +21 -10
- package/payload/planning/evals/eval-calibration.md +1 -1
- package/payload/planning/okrs/health-budgets.md +1 -1
- package/payload/skills/pm-communication.skill +123 -0
- package/payload/skills/pmos-router.skill +1 -0
- package/payload/skills/technical-writing-ste.skill +5 -3
- package/payload/skills-native/pm-communication/SKILL.md +125 -0
- package/payload/skills-native/pmos-router/SKILL.md +1 -0
- package/payload/skills-native/technical-writing-ste/SKILL.md +5 -3
- package/payload/state/discoveries.md +1 -1
- package/workspace/package-lock.json +1 -1
- package/workspace/package.json +1 -1
- package/workspace/skills/report-biweekly.skill +5 -5
- package/workspace/skills/report-daily.skill +5 -5
- package/workspace/skills/report-monthly.skill +5 -5
- package/workspace/skills/report-special.skill +3 -3
- package/workspace/skills/report-weekly.skill +5 -5
- package/workspace/skills/weekly-report.skill +3 -2
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "create-pmos",
|
|
3
|
-
"version": "0.38.
|
|
3
|
+
"version": "0.38.7",
|
|
4
4
|
"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.",
|
|
5
5
|
"license": "MIT",
|
|
6
6
|
"bin": {
|
package/payload/KIT-VERSION
CHANGED
|
@@ -0,0 +1,35 @@
|
|
|
1
|
+
---
|
|
2
|
+
type: Template
|
|
3
|
+
title: Report Rubric Template
|
|
4
|
+
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.
|
|
5
|
+
tags: [template, report, rubric, review, pm-artifacts]
|
|
6
|
+
timestamp: 2026-10-03
|
|
7
|
+
---
|
|
8
|
+
|
|
9
|
+
# Report Rubric Template
|
|
10
|
+
|
|
11
|
+
**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.
|
|
12
|
+
|
|
13
|
+
> 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.
|
|
14
|
+
|
|
15
|
+
---
|
|
16
|
+
|
|
17
|
+
```markdown
|
|
18
|
+
# Rubric: <report or decision record title>
|
|
19
|
+
|
|
20
|
+
- initiative_id: <id>
|
|
21
|
+
- audience: <leadership | delivery | partner>
|
|
22
|
+
- pass_threshold: 0.80
|
|
23
|
+
|
|
24
|
+
| # | Dimension | Weight | Full credit |
|
|
25
|
+
|---|---|---|---|
|
|
26
|
+
| 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. |
|
|
27
|
+
| 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. |
|
|
28
|
+
| 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. |
|
|
29
|
+
| 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. |
|
|
30
|
+
|
|
31
|
+
## Caps
|
|
32
|
+
|
|
33
|
+
- A claim stated as fact with no pointer that the reviewer cannot find in any source: the score is capped at 0.60.
|
|
34
|
+
- A source named that the drafter did not reach: the score is capped at 0.40.
|
|
35
|
+
```
|
|
@@ -1,35 +1,46 @@
|
|
|
1
1
|
---
|
|
2
2
|
type: Template
|
|
3
3
|
title: Weekly Report Template
|
|
4
|
-
description: A regular status report (D68 report lane, light track by default)
|
|
4
|
+
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.
|
|
5
5
|
tags: [template, report, status, pm-artifacts]
|
|
6
|
-
timestamp: 2026-10-
|
|
6
|
+
timestamp: 2026-10-03
|
|
7
7
|
---
|
|
8
8
|
|
|
9
9
|
# Weekly Report Template
|
|
10
10
|
|
|
11
|
-
**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.
|
|
11
|
+
**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.
|
|
12
12
|
|
|
13
13
|
---
|
|
14
14
|
|
|
15
15
|
```markdown
|
|
16
|
+
---
|
|
17
|
+
type: Reference
|
|
18
|
+
title: "Report — <week of YYYY-MM-DD> — <scope: domain | portfolio>"
|
|
19
|
+
initiative_id: <id of the report-lane initiative>
|
|
20
|
+
audience: <leadership | delivery | partner>
|
|
21
|
+
status: draft
|
|
22
|
+
---
|
|
23
|
+
|
|
16
24
|
# Weekly report — <week of YYYY-MM-DD> — <scope: domain | portfolio>
|
|
17
25
|
|
|
18
26
|
## Headline
|
|
19
|
-
<one
|
|
27
|
+
<one or two sentences: what the reader most needs to know. Put the decision first if there is one.>
|
|
20
28
|
|
|
21
|
-
##
|
|
29
|
+
## What moved
|
|
22
30
|
| initiative | anchor (KR · domain) | what moved | evidence |
|
|
23
31
|
|---|---|---|---|
|
|
24
32
|
|
|
33
|
+
## Risks
|
|
34
|
+
| initiative | risk or blocker | what is needed | from whom |
|
|
35
|
+
|---|---|---|---|
|
|
36
|
+
|
|
25
37
|
## Metrics
|
|
26
38
|
| metric | last week | this week | target | trend |
|
|
27
39
|
|---|---|---|---|---|
|
|
28
40
|
|
|
29
|
-
##
|
|
30
|
-
|
|
31
|
-
|---|---|---|---|
|
|
41
|
+
## Needs your call
|
|
42
|
+
<each decision or review waiting on the reader: the question, the options, your recommendation, the date it is needed by>
|
|
32
43
|
|
|
33
|
-
##
|
|
34
|
-
<
|
|
44
|
+
## Sources reached and not reached
|
|
45
|
+
<each source kind: reached, or not reached and why. Say if nothing changed.>
|
|
35
46
|
```
|
|
@@ -2,7 +2,7 @@
|
|
|
2
2
|
type: Reference
|
|
3
3
|
title: "Eval calibration log"
|
|
4
4
|
description: "Append-only record of every PM override of an evaluator verdict."
|
|
5
|
-
generated: {by: process:create-pmos, at: "2026-10-
|
|
5
|
+
generated: {by: process:create-pmos, at: "2026-10-03T01:20:42Z"}
|
|
6
6
|
status: stable
|
|
7
7
|
---
|
|
8
8
|
|
|
@@ -2,7 +2,7 @@
|
|
|
2
2
|
type: Reference
|
|
3
3
|
title: "Health budgets"
|
|
4
4
|
description: "Closed registry of health-budget anchors (D59), edited only by the PM."
|
|
5
|
-
generated: {by: process:create-pmos, at: "2026-10-
|
|
5
|
+
generated: {by: process:create-pmos, at: "2026-10-03T01:20:42Z"}
|
|
6
6
|
status: stable
|
|
7
7
|
---
|
|
8
8
|
|
|
@@ -0,0 +1,123 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: pm-communication
|
|
3
|
+
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.
|
|
4
|
+
version: 1.0.0
|
|
5
|
+
owner: wawan
|
|
6
|
+
risk: low
|
|
7
|
+
category: communication
|
|
8
|
+
scope: read:okf, read:planning, read:state, write:planning/reports
|
|
9
|
+
---
|
|
10
|
+
|
|
11
|
+
# pm-communication — Draft the update for the reader
|
|
12
|
+
|
|
13
|
+
This skill is the producer for the `report` and `decision-record` lanes of the document profile
|
|
14
|
+
([D77](/okf/products/pmos/adr/d77-lane-definitions.md)). It drafts one document for one audience in
|
|
15
|
+
the report frame of [D78](/okf/products/pmos/adr/d78-one-report-shape.md). It writes a file. It sends
|
|
16
|
+
nothing.
|
|
17
|
+
|
|
18
|
+
> **Format note:** this skill follows [SKILL-FORMAT](/skills/SKILL-FORMAT.md). The text is
|
|
19
|
+
> instructional (class A of [technical-writing-ste](/skills/technical-writing-ste.skill)).
|
|
20
|
+
> The documents it drafts are class B, except the request in *Needs your call*.
|
|
21
|
+
|
|
22
|
+
## When to use vs. not
|
|
23
|
+
|
|
24
|
+
- **Use** for a status report, a stakeholder update, a decision record or a decision communication.
|
|
25
|
+
- **Use** to put a scheduled draft under the `report` lane (step 4).
|
|
26
|
+
- **Do not use** for customer-facing copy or release notes. That is the content lane and the
|
|
27
|
+
[copywriting skill](/skills/copywriting.skill).
|
|
28
|
+
- **Do not use** to decide the lane. That is the [pmos-router](/skills/pmos-router.skill).
|
|
29
|
+
- **Do not use** to gather what the PM wants to say. That is the
|
|
30
|
+
[requirements-elicitation skill](/skills/requirements-elicitation.skill), which holds the
|
|
31
|
+
questions for the `report` and `decision-record` lanes. Follow it when step 2 needs answers.
|
|
32
|
+
|
|
33
|
+
## Rules that always hold
|
|
34
|
+
|
|
35
|
+
1. The draft is a file in this repository. Never send, post, share, email, publish or upload it. The PM does that (D71).
|
|
36
|
+
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".
|
|
37
|
+
3. Write nothing that you did not read. Name each source you could not reach. If nothing changed, say so.
|
|
38
|
+
4. Never write `reviewed_by`, a review verdict, an acceptance or a handoff. Those belong to the reviewer and the PM.
|
|
39
|
+
5. A gathered note with `confidence: unconfirmed` is marked unverified in the draft. Never write it as a fact.
|
|
40
|
+
6. Skip threads and pages that are private, personal, confidential or HR. Count them. Do not read them.
|
|
41
|
+
7. Never copy message bodies, attachments, tokens or credentials. Quote at most one short sentence per item.
|
|
42
|
+
|
|
43
|
+
## Procedure
|
|
44
|
+
|
|
45
|
+
1. **Find the lane and the record.** Read the initiative record and its `type`. Run
|
|
46
|
+
`node scripts/workflow-state.js --lanes --json` (in a kit repository the script is
|
|
47
|
+
`pmos/scripts/workflow-state.js`). Find the lane in `defs`. It must be `report` or
|
|
48
|
+
`decision-record`. State the lane's `output` and `done` in plain words before you draft.
|
|
49
|
+
*Done when:* the PM has seen the lane's output and done-rule.
|
|
50
|
+
|
|
51
|
+
If the profile has no such lane (the code profile), say so. Offer the content lane with an
|
|
52
|
+
internal audience, and stop. If the script is missing or the lane is unknown, say so and ask
|
|
53
|
+
which lane applies.
|
|
54
|
+
|
|
55
|
+
2. **Name the audience.** The audience is leadership, delivery or partner. Read it from the
|
|
56
|
+
record, the PM's definition file or the PM's request. If none names it, ask the PM, with a
|
|
57
|
+
recommended answer, by the requirements-elicitation skill. Do not choose one.
|
|
58
|
+
*Done when:* the audience is one of the three and the PM has confirmed it.
|
|
59
|
+
|
|
60
|
+
3. **Gather the facts.** Read what the draft will claim: the initiatives and their acceptances
|
|
61
|
+
(`node scripts/workflow-state.js`), the runs, the notes in `<state>/requirements/` (`<state>`
|
|
62
|
+
is `pmos/state/` if it exists, and `planning/` if not), and each source the PM's definition
|
|
63
|
+
file names that you can reach. For a report, read `<state>/reports/definitions/<cadence>.md`
|
|
64
|
+
if it exists and follow it where it does not remove a part of the frame. Look facts up. Do
|
|
65
|
+
not ask the PM for a fact that a file holds.
|
|
66
|
+
*Done when:* each claim you will make has a pointer, and each source you could not reach is listed.
|
|
67
|
+
|
|
68
|
+
4. **Adopt a scheduled draft, if the PM names one.** If the PM points at an existing draft (a
|
|
69
|
+
file under `<state>/reports/`), do not draft a new one. Set the record's `doc_path` to that
|
|
70
|
+
file (step 6) and go to step 7 on it. Tell the PM that the draft was written by a schedule
|
|
71
|
+
and was not part of the lane until now.
|
|
72
|
+
*Done when:* the PM has said whether to adopt or to draft a new one.
|
|
73
|
+
|
|
74
|
+
5. **Draft in the audience's register.** For a report, copy the
|
|
75
|
+
[report template](/okf/core/templates/report-weekly-template.md). For a decision record, copy the
|
|
76
|
+
[decision-record template](/okf/core/templates/decision-record-template.md). Fill every section
|
|
77
|
+
in the order and register for the audience (see [Registers](#registers)). The Headline comes
|
|
78
|
+
first. If a decision is needed, the Headline says what it is.
|
|
79
|
+
Write the file to the record's `doc_path`. If the record has none, write
|
|
80
|
+
`planning/reports/<initiative-id>-<YYYY-MM-DD>.md`. If the file exists, do not overwrite it:
|
|
81
|
+
append a section `## Later run HH:MM`. Start with this frontmatter, one key per line:
|
|
82
|
+
`type: Reference`, `title`, `initiative_id`, `audience`, `status: draft`,
|
|
83
|
+
`generated: {by: claude-code/pm-communication, at: "<ISO 8601>"}` and
|
|
84
|
+
`sources: [{resource: "<pointer>", title: "<what it is>"}]`. Do not add `timestamp` or `verified`.
|
|
85
|
+
*Done when:* the file exists and has all the sections of its template.
|
|
86
|
+
|
|
87
|
+
6. **Point the record at it.** Set `doc_path` on the initiative record to the file. This is the
|
|
88
|
+
only key you set. If `doc_path` already names a different file, do not change it: ask the PM.
|
|
89
|
+
*Done when:* `node scripts/workflow-state.js <id>` shows the draft step done with this file as its basis.
|
|
90
|
+
|
|
91
|
+
7. **Check the draft against the done-rule.** Read the lane's `done` text. Say which part is
|
|
92
|
+
met: the document exists (yes), a reviewer has judged it (not yet), the PM has accepted it
|
|
93
|
+
(not yet), and handed off, where the lane says so (not yet). Then check the draft:
|
|
94
|
+
the Headline is first; the decision or the absence of one is visible on the first screen;
|
|
95
|
+
each claim has a pointer; *Sources reached and not reached* is last; nothing in it is
|
|
96
|
+
outside the audience's register.
|
|
97
|
+
*Done when:* every check passes or the failing one is named to the PM.
|
|
98
|
+
|
|
99
|
+
8. **Hand over.** Say where the draft is. Name the review step: the reviewer is not you, and
|
|
100
|
+
grades against the [report rubric](/okf/core/templates/report-rubric-template.md). State the open
|
|
101
|
+
questions and the sources not reached. Do not send the draft.
|
|
102
|
+
*Done when:* the PM knows where the draft is, who must review it, and what is still open.
|
|
103
|
+
|
|
104
|
+
## Registers
|
|
105
|
+
|
|
106
|
+
One register per audience. The order is fixed. What a register leaves out is as much a part of it
|
|
107
|
+
as what it includes. A decision comes before its reasoning for every audience.
|
|
108
|
+
|
|
109
|
+
| Audience | Order | Include | Leave out | Length |
|
|
110
|
+
|---|---|---|---|---|
|
|
111
|
+
| **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 |
|
|
112
|
+
| **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 |
|
|
113
|
+
| **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 |
|
|
114
|
+
|
|
115
|
+
For a decision record, the choice and its owner come first. Then who must act and by when. The
|
|
116
|
+
reasoning and the options considered come last.
|
|
117
|
+
|
|
118
|
+
## Failure behaviour
|
|
119
|
+
|
|
120
|
+
- The audience is not named and the PM does not answer: do not draft. Say what is missing.
|
|
121
|
+
- The lane definition cannot be read: say so, and ask which lane applies.
|
|
122
|
+
- No source can be reached: write a short honest draft that says so. Do not fill the gap.
|
|
123
|
+
- `doc_path` names a different file: do not change it. Ask the PM.
|
|
@@ -64,6 +64,7 @@ router is the bug (fix it via the weekly harness scan).
|
|
|
64
64
|
| 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) |
|
|
65
65
|
| **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) |
|
|
66
66
|
| "**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) |
|
|
67
|
+
| "**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 |
|
|
67
68
|
|
|
68
69
|
**Every route** still takes the universal steps: anchored initiative row (`create_initiative`),
|
|
69
70
|
branch `initiative/<id>`, and the human Acceptance Gate at the end (D12) — the router never bypasses
|
|
@@ -39,7 +39,7 @@ Ask what the reader must do with it. Derive the class from the path, not from fe
|
|
|
39
39
|
| Class | What the reader must do | Where it lives |
|
|
40
40
|
|---|---|---|
|
|
41
41
|
| **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 |
|
|
42
|
-
| **B — descriptive** | **Understand**, not obey | `okf/**` concepts and references · explainers · `**/README.md` · design and data-model docs |
|
|
42
|
+
| **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/**`) |
|
|
43
43
|
| **C — argumentative** | **Weigh a judgement under uncertainty** | ADRs and decision records · `planning/prd/**` · briefs · the discoveries log · eval verdicts · PR bodies |
|
|
44
44
|
|
|
45
45
|
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
|
|
|
48
48
|
cover your CLI output, your error strings and your component copy (A), and your architecture notes
|
|
49
49
|
(B). When a path is not on your list, ask the question in column two and add the answer to the list.
|
|
50
50
|
|
|
51
|
-
|
|
52
|
-
**new and modified text only** — never rewrite an existing corpus to satisfy it.
|
|
51
|
+
Three boundary rules. **Text the PM wrote is Class C**, whatever it is about. The profile binds
|
|
52
|
+
**new and modified text only** — never rewrite an existing corpus to satisfy it. And inside an
|
|
53
|
+
agent-drafted status report or update, the request in *Needs your call* is **Class A**: the reader
|
|
54
|
+
must act on it, so write one question, the options, your recommendation and the date.
|
|
53
55
|
|
|
54
56
|
**Done when:** you can name the class and the row that put it there.
|
|
55
57
|
|
|
@@ -0,0 +1,125 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: pm-communication
|
|
3
|
+
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.
|
|
4
|
+
license: MIT
|
|
5
|
+
metadata:
|
|
6
|
+
pmos-version: 1.0.0
|
|
7
|
+
pmos-owner: wawan
|
|
8
|
+
pmos-risk: low
|
|
9
|
+
pmos-category: communication
|
|
10
|
+
pmos-scope: read:okf, read:planning, read:state, write:planning/reports
|
|
11
|
+
---
|
|
12
|
+
|
|
13
|
+
# pm-communication — Draft the update for the reader
|
|
14
|
+
|
|
15
|
+
This skill is the producer for the `report` and `decision-record` lanes of the document profile
|
|
16
|
+
([D77](/okf/products/pmos/adr/d77-lane-definitions.md)). It drafts one document for one audience in
|
|
17
|
+
the report frame of [D78](/okf/products/pmos/adr/d78-one-report-shape.md). It writes a file. It sends
|
|
18
|
+
nothing.
|
|
19
|
+
|
|
20
|
+
> **Format note:** this skill follows [SKILL-FORMAT](/skills/SKILL-FORMAT.md). The text is
|
|
21
|
+
> instructional (class A of [technical-writing-ste](/skills/technical-writing-ste.skill)).
|
|
22
|
+
> The documents it drafts are class B, except the request in *Needs your call*.
|
|
23
|
+
|
|
24
|
+
## When to use vs. not
|
|
25
|
+
|
|
26
|
+
- **Use** for a status report, a stakeholder update, a decision record or a decision communication.
|
|
27
|
+
- **Use** to put a scheduled draft under the `report` lane (step 4).
|
|
28
|
+
- **Do not use** for customer-facing copy or release notes. That is the content lane and the
|
|
29
|
+
[copywriting skill](/skills/copywriting.skill).
|
|
30
|
+
- **Do not use** to decide the lane. That is the [pmos-router](/skills/pmos-router.skill).
|
|
31
|
+
- **Do not use** to gather what the PM wants to say. That is the
|
|
32
|
+
[requirements-elicitation skill](/skills/requirements-elicitation.skill), which holds the
|
|
33
|
+
questions for the `report` and `decision-record` lanes. Follow it when step 2 needs answers.
|
|
34
|
+
|
|
35
|
+
## Rules that always hold
|
|
36
|
+
|
|
37
|
+
1. The draft is a file in this repository. Never send, post, share, email, publish or upload it. The PM does that (D71).
|
|
38
|
+
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".
|
|
39
|
+
3. Write nothing that you did not read. Name each source you could not reach. If nothing changed, say so.
|
|
40
|
+
4. Never write `reviewed_by`, a review verdict, an acceptance or a handoff. Those belong to the reviewer and the PM.
|
|
41
|
+
5. A gathered note with `confidence: unconfirmed` is marked unverified in the draft. Never write it as a fact.
|
|
42
|
+
6. Skip threads and pages that are private, personal, confidential or HR. Count them. Do not read them.
|
|
43
|
+
7. Never copy message bodies, attachments, tokens or credentials. Quote at most one short sentence per item.
|
|
44
|
+
|
|
45
|
+
## Procedure
|
|
46
|
+
|
|
47
|
+
1. **Find the lane and the record.** Read the initiative record and its `type`. Run
|
|
48
|
+
`node scripts/workflow-state.js --lanes --json` (in a kit repository the script is
|
|
49
|
+
`pmos/scripts/workflow-state.js`). Find the lane in `defs`. It must be `report` or
|
|
50
|
+
`decision-record`. State the lane's `output` and `done` in plain words before you draft.
|
|
51
|
+
*Done when:* the PM has seen the lane's output and done-rule.
|
|
52
|
+
|
|
53
|
+
If the profile has no such lane (the code profile), say so. Offer the content lane with an
|
|
54
|
+
internal audience, and stop. If the script is missing or the lane is unknown, say so and ask
|
|
55
|
+
which lane applies.
|
|
56
|
+
|
|
57
|
+
2. **Name the audience.** The audience is leadership, delivery or partner. Read it from the
|
|
58
|
+
record, the PM's definition file or the PM's request. If none names it, ask the PM, with a
|
|
59
|
+
recommended answer, by the requirements-elicitation skill. Do not choose one.
|
|
60
|
+
*Done when:* the audience is one of the three and the PM has confirmed it.
|
|
61
|
+
|
|
62
|
+
3. **Gather the facts.** Read what the draft will claim: the initiatives and their acceptances
|
|
63
|
+
(`node scripts/workflow-state.js`), the runs, the notes in `<state>/requirements/` (`<state>`
|
|
64
|
+
is `pmos/state/` if it exists, and `planning/` if not), and each source the PM's definition
|
|
65
|
+
file names that you can reach. For a report, read `<state>/reports/definitions/<cadence>.md`
|
|
66
|
+
if it exists and follow it where it does not remove a part of the frame. Look facts up. Do
|
|
67
|
+
not ask the PM for a fact that a file holds.
|
|
68
|
+
*Done when:* each claim you will make has a pointer, and each source you could not reach is listed.
|
|
69
|
+
|
|
70
|
+
4. **Adopt a scheduled draft, if the PM names one.** If the PM points at an existing draft (a
|
|
71
|
+
file under `<state>/reports/`), do not draft a new one. Set the record's `doc_path` to that
|
|
72
|
+
file (step 6) and go to step 7 on it. Tell the PM that the draft was written by a schedule
|
|
73
|
+
and was not part of the lane until now.
|
|
74
|
+
*Done when:* the PM has said whether to adopt or to draft a new one.
|
|
75
|
+
|
|
76
|
+
5. **Draft in the audience's register.** For a report, copy the
|
|
77
|
+
[report template](/okf/core/templates/report-weekly-template.md). For a decision record, copy the
|
|
78
|
+
[decision-record template](/okf/core/templates/decision-record-template.md). Fill every section
|
|
79
|
+
in the order and register for the audience (see [Registers](#registers)). The Headline comes
|
|
80
|
+
first. If a decision is needed, the Headline says what it is.
|
|
81
|
+
Write the file to the record's `doc_path`. If the record has none, write
|
|
82
|
+
`planning/reports/<initiative-id>-<YYYY-MM-DD>.md`. If the file exists, do not overwrite it:
|
|
83
|
+
append a section `## Later run HH:MM`. Start with this frontmatter, one key per line:
|
|
84
|
+
`type: Reference`, `title`, `initiative_id`, `audience`, `status: draft`,
|
|
85
|
+
`generated: {by: claude-code/pm-communication, at: "<ISO 8601>"}` and
|
|
86
|
+
`sources: [{resource: "<pointer>", title: "<what it is>"}]`. Do not add `timestamp` or `verified`.
|
|
87
|
+
*Done when:* the file exists and has all the sections of its template.
|
|
88
|
+
|
|
89
|
+
6. **Point the record at it.** Set `doc_path` on the initiative record to the file. This is the
|
|
90
|
+
only key you set. If `doc_path` already names a different file, do not change it: ask the PM.
|
|
91
|
+
*Done when:* `node scripts/workflow-state.js <id>` shows the draft step done with this file as its basis.
|
|
92
|
+
|
|
93
|
+
7. **Check the draft against the done-rule.** Read the lane's `done` text. Say which part is
|
|
94
|
+
met: the document exists (yes), a reviewer has judged it (not yet), the PM has accepted it
|
|
95
|
+
(not yet), and handed off, where the lane says so (not yet). Then check the draft:
|
|
96
|
+
the Headline is first; the decision or the absence of one is visible on the first screen;
|
|
97
|
+
each claim has a pointer; *Sources reached and not reached* is last; nothing in it is
|
|
98
|
+
outside the audience's register.
|
|
99
|
+
*Done when:* every check passes or the failing one is named to the PM.
|
|
100
|
+
|
|
101
|
+
8. **Hand over.** Say where the draft is. Name the review step: the reviewer is not you, and
|
|
102
|
+
grades against the [report rubric](/okf/core/templates/report-rubric-template.md). State the open
|
|
103
|
+
questions and the sources not reached. Do not send the draft.
|
|
104
|
+
*Done when:* the PM knows where the draft is, who must review it, and what is still open.
|
|
105
|
+
|
|
106
|
+
## Registers
|
|
107
|
+
|
|
108
|
+
One register per audience. The order is fixed. What a register leaves out is as much a part of it
|
|
109
|
+
as what it includes. A decision comes before its reasoning for every audience.
|
|
110
|
+
|
|
111
|
+
| Audience | Order | Include | Leave out | Length |
|
|
112
|
+
|---|---|---|---|---|
|
|
113
|
+
| **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 |
|
|
114
|
+
| **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 |
|
|
115
|
+
| **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 |
|
|
116
|
+
|
|
117
|
+
For a decision record, the choice and its owner come first. Then who must act and by when. The
|
|
118
|
+
reasoning and the options considered come last.
|
|
119
|
+
|
|
120
|
+
## Failure behaviour
|
|
121
|
+
|
|
122
|
+
- The audience is not named and the PM does not answer: do not draft. Say what is missing.
|
|
123
|
+
- The lane definition cannot be read: say so, and ask which lane applies.
|
|
124
|
+
- No source can be reached: write a short honest draft that says so. Do not fill the gap.
|
|
125
|
+
- `doc_path` names a different file: do not change it. Ask the PM.
|
|
@@ -66,6 +66,7 @@ router is the bug (fix it via the weekly harness scan).
|
|
|
66
66
|
| 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) |
|
|
67
67
|
| **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) |
|
|
68
68
|
| "**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) |
|
|
69
|
+
| "**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 |
|
|
69
70
|
|
|
70
71
|
**Every route** still takes the universal steps: anchored initiative row (`create_initiative`),
|
|
71
72
|
branch `initiative/<id>`, and the human Acceptance Gate at the end (D12) — the router never bypasses
|
|
@@ -41,7 +41,7 @@ Ask what the reader must do with it. Derive the class from the path, not from fe
|
|
|
41
41
|
| Class | What the reader must do | Where it lives |
|
|
42
42
|
|---|---|---|
|
|
43
43
|
| **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 |
|
|
44
|
-
| **B — descriptive** | **Understand**, not obey | `okf/**` concepts and references · explainers · `**/README.md` · design and data-model docs |
|
|
44
|
+
| **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/**`) |
|
|
45
45
|
| **C — argumentative** | **Weigh a judgement under uncertainty** | ADRs and decision records · `planning/prd/**` · briefs · the discoveries log · eval verdicts · PR bodies |
|
|
46
46
|
|
|
47
47
|
The three classes are the rule. **The paths are your repo's, so write them down once.** In PMOS they
|
|
@@ -50,8 +50,10 @@ also cover `build-skills/**` and `okf/core/playbooks/**` (A), `planning/explaine
|
|
|
50
50
|
cover your CLI output, your error strings and your component copy (A), and your architecture notes
|
|
51
51
|
(B). When a path is not on your list, ask the question in column two and add the answer to the list.
|
|
52
52
|
|
|
53
|
-
|
|
54
|
-
**new and modified text only** — never rewrite an existing corpus to satisfy it.
|
|
53
|
+
Three boundary rules. **Text the PM wrote is Class C**, whatever it is about. The profile binds
|
|
54
|
+
**new and modified text only** — never rewrite an existing corpus to satisfy it. And inside an
|
|
55
|
+
agent-drafted status report or update, the request in *Needs your call* is **Class A**: the reader
|
|
56
|
+
must act on it, so write one question, the options, your recommendation and the date.
|
|
55
57
|
|
|
56
58
|
**Done when:** you can name the class and the row that put it there.
|
|
57
59
|
|
|
@@ -2,7 +2,7 @@
|
|
|
2
2
|
type: Reference
|
|
3
3
|
title: "Discoveries and friction log"
|
|
4
4
|
description: "Append-only record of what runs discovered and where the process rubbed."
|
|
5
|
-
generated: {by: process:create-pmos, at: "2026-10-
|
|
5
|
+
generated: {by: process:create-pmos, at: "2026-10-03T01:20:42Z"}
|
|
6
6
|
status: stable
|
|
7
7
|
---
|
|
8
8
|
|
package/workspace/package.json
CHANGED
|
@@ -5,7 +5,7 @@ description: "Prepare the biweekly report as a draft, following the PM's own def
|
|
|
5
5
|
run: agent
|
|
6
6
|
agent: claude
|
|
7
7
|
output:
|
|
8
|
-
-
|
|
8
|
+
- Headline
|
|
9
9
|
- Sections from the definition
|
|
10
10
|
- Needs your call
|
|
11
11
|
- Sources reached and not reached
|
|
@@ -40,14 +40,14 @@ Procedure:
|
|
|
40
40
|
---
|
|
41
41
|
```
|
|
42
42
|
`definition` says whether the definition used is confirmed (`stable`) or only proposed (`draft`). Do not add a `timestamp` or `verified`.
|
|
43
|
-
5. Under the frontmatter: a
|
|
44
|
-
6. If the definition was a draft, say so in the first line of the
|
|
43
|
+
5. Under the frontmatter: a Headline (one or two sentences: what the reader most needs to know), then the sections the definition names in its order, then "Needs your call" (decisions or answers only the PM can give), then "Sources reached and not reached" (each source kind: reached or not reached and why; private items skipped).
|
|
44
|
+
6. If the definition was a draft, say so in the first line of the Headline so the PM sees it.
|
|
45
45
|
7. Finish by saying in one line where the draft is. Do not commit; the PM's Sync carries the file.
|
|
46
46
|
|
|
47
|
-
Default shape, used ONLY when proposing a definition: a two-week
|
|
47
|
+
Default shape, used ONLY when proposing a definition: a two-week report: progress, decisions, risks, what is next. Use the report frame of D78: a Headline, then What moved, Risks and Metrics, then Needs your call and Sources reached and not reached.
|
|
48
48
|
|
|
49
49
|
Output contract — produce EXACTLY these sections, the same shape every run:
|
|
50
|
-
-
|
|
50
|
+
- Headline
|
|
51
51
|
- Sections from the definition
|
|
52
52
|
- Needs your call
|
|
53
53
|
- Sources reached and not reached
|
|
@@ -5,7 +5,7 @@ description: "Prepare the daily report as a draft, following the PM's own defini
|
|
|
5
5
|
run: agent
|
|
6
6
|
agent: claude
|
|
7
7
|
output:
|
|
8
|
-
-
|
|
8
|
+
- Headline
|
|
9
9
|
- Sections from the definition
|
|
10
10
|
- Needs your call
|
|
11
11
|
- Sources reached and not reached
|
|
@@ -40,14 +40,14 @@ Procedure:
|
|
|
40
40
|
---
|
|
41
41
|
```
|
|
42
42
|
`definition` says whether the definition used is confirmed (`stable`) or only proposed (`draft`). Do not add a `timestamp` or `verified`.
|
|
43
|
-
5. Under the frontmatter: a
|
|
44
|
-
6. If the definition was a draft, say so in the first line of the
|
|
43
|
+
5. Under the frontmatter: a Headline (one or two sentences: what the reader most needs to know), then the sections the definition names in its order, then "Needs your call" (decisions or answers only the PM can give), then "Sources reached and not reached" (each source kind: reached or not reached and why; private items skipped).
|
|
44
|
+
6. If the definition was a draft, say so in the first line of the Headline so the PM sees it.
|
|
45
45
|
7. Finish by saying in one line where the draft is. Do not commit; the PM's Sync carries the file.
|
|
46
46
|
|
|
47
|
-
Default shape, used ONLY when proposing a definition: a one-page end-of-day
|
|
47
|
+
Default shape, used ONLY when proposing a definition: a one-page end-of-day report: what moved, what is blocked, what needs the PM tomorrow. Use the report frame of D78: a Headline, then What moved, Risks and Metrics, then Needs your call and Sources reached and not reached.
|
|
48
48
|
|
|
49
49
|
Output contract — produce EXACTLY these sections, the same shape every run:
|
|
50
|
-
-
|
|
50
|
+
- Headline
|
|
51
51
|
- Sections from the definition
|
|
52
52
|
- Needs your call
|
|
53
53
|
- Sources reached and not reached
|
|
@@ -5,7 +5,7 @@ description: "Prepare the monthly report as a draft, following the PM's own defi
|
|
|
5
5
|
run: agent
|
|
6
6
|
agent: claude
|
|
7
7
|
output:
|
|
8
|
-
-
|
|
8
|
+
- Headline
|
|
9
9
|
- Sections from the definition
|
|
10
10
|
- Needs your call
|
|
11
11
|
- Sources reached and not reached
|
|
@@ -40,14 +40,14 @@ Procedure:
|
|
|
40
40
|
---
|
|
41
41
|
```
|
|
42
42
|
`definition` says whether the definition used is confirmed (`stable`) or only proposed (`draft`). Do not add a `timestamp` or `verified`.
|
|
43
|
-
5. Under the frontmatter: a
|
|
44
|
-
6. If the definition was a draft, say so in the first line of the
|
|
43
|
+
5. Under the frontmatter: a Headline (one or two sentences: what the reader most needs to know), then the sections the definition names in its order, then "Needs your call" (decisions or answers only the PM can give), then "Sources reached and not reached" (each source kind: reached or not reached and why; private items skipped).
|
|
44
|
+
6. If the definition was a draft, say so in the first line of the Headline so the PM sees it.
|
|
45
45
|
7. Finish by saying in one line where the draft is. Do not commit; the PM's Sync carries the file.
|
|
46
46
|
|
|
47
|
-
Default shape, used ONLY when proposing a definition: a monthly review: outcomes against goals, decisions, risks, learning, next month.
|
|
47
|
+
Default shape, used ONLY when proposing a definition: a monthly review: outcomes against goals, decisions, risks, learning, next month. Use the report frame of D78: a Headline, then What moved, Risks and Metrics, then Needs your call and Sources reached and not reached.
|
|
48
48
|
|
|
49
49
|
Output contract — produce EXACTLY these sections, the same shape every run:
|
|
50
|
-
-
|
|
50
|
+
- Headline
|
|
51
51
|
- Sections from the definition
|
|
52
52
|
- Needs your call
|
|
53
53
|
- Sources reached and not reached
|
|
@@ -5,7 +5,7 @@ description: "Prepare a one-off report as a draft. The PM says what it is for; t
|
|
|
5
5
|
run: agent
|
|
6
6
|
agent: claude
|
|
7
7
|
output:
|
|
8
|
-
-
|
|
8
|
+
- Headline
|
|
9
9
|
- Sections from the definition
|
|
10
10
|
- Needs your call
|
|
11
11
|
- Sources reached and not reached
|
|
@@ -26,7 +26,7 @@ Procedure:
|
|
|
26
26
|
2. Find the state directory: `pmos/state/` if it exists, otherwise `planning/`. Call it <state>.
|
|
27
27
|
3. If `<state>/reports/definitions/special.md` exists, read it for the house style and use it where it does not contradict what the PM just asked.
|
|
28
28
|
4. Gather the material: the requirement notes in `<state>/requirements/`, the initiatives and acceptances, and every connected source you can reach that bears on the topic.
|
|
29
|
-
5. Write the draft to `<state>/reports/special/YYYY-MM-DD-<short-topic-slug>.md`, then the sections the PM asked for, then "Needs your call" and "Sources reached and not reached". Start it with this frontmatter (OKF v0.2, D73). Every key is on ONE line — never indent a key under another:
|
|
29
|
+
5. Write the draft to `<state>/reports/special/YYYY-MM-DD-<short-topic-slug>.md`, then a Headline (one or two sentences), then the sections the PM asked for (the report frame of D78 by default: What moved, Risks, Metrics), then "Needs your call" and "Sources reached and not reached". Start it with this frontmatter (OKF v0.2, D73). Every key is on ONE line — never indent a key under another:
|
|
30
30
|
```
|
|
31
31
|
---
|
|
32
32
|
type: Reference
|
|
@@ -43,7 +43,7 @@ Procedure:
|
|
|
43
43
|
7. Finish by saying in one line where the draft is. Do not commit; the PM's Sync carries the file.
|
|
44
44
|
|
|
45
45
|
Output contract — produce EXACTLY these sections, the same shape every run:
|
|
46
|
-
-
|
|
46
|
+
- Headline
|
|
47
47
|
- Sections from the definition
|
|
48
48
|
- Needs your call
|
|
49
49
|
- Sources reached and not reached
|
|
@@ -5,7 +5,7 @@ description: "Prepare the weekly report as a draft, following the PM's own defin
|
|
|
5
5
|
run: agent
|
|
6
6
|
agent: claude
|
|
7
7
|
output:
|
|
8
|
-
-
|
|
8
|
+
- Headline
|
|
9
9
|
- Sections from the definition
|
|
10
10
|
- Needs your call
|
|
11
11
|
- Sources reached and not reached
|
|
@@ -40,14 +40,14 @@ Procedure:
|
|
|
40
40
|
---
|
|
41
41
|
```
|
|
42
42
|
`definition` says whether the definition used is confirmed (`stable`) or only proposed (`draft`). Do not add a `timestamp` or `verified`.
|
|
43
|
-
5. Under the frontmatter: a
|
|
44
|
-
6. If the definition was a draft, say so in the first line of the
|
|
43
|
+
5. Under the frontmatter: a Headline (one or two sentences: what the reader most needs to know), then the sections the definition names in its order, then "Needs your call" (decisions or answers only the PM can give), then "Sources reached and not reached" (each source kind: reached or not reached and why; private items skipped).
|
|
44
|
+
6. If the definition was a draft, say so in the first line of the Headline so the PM sees it.
|
|
45
45
|
7. Finish by saying in one line where the draft is. Do not commit; the PM's Sync carries the file.
|
|
46
46
|
|
|
47
|
-
Default shape, used ONLY when proposing a definition: a weekly
|
|
47
|
+
Default shape, used ONLY when proposing a definition: a weekly report: progress against initiatives, decisions made, risks, what is next. Use the report frame of D78: a Headline, then What moved, Risks and Metrics, then Needs your call and Sources reached and not reached.
|
|
48
48
|
|
|
49
49
|
Output contract — produce EXACTLY these sections, the same shape every run:
|
|
50
|
-
-
|
|
50
|
+
- Headline
|
|
51
51
|
- Sections from the definition
|
|
52
52
|
- Needs your call
|
|
53
53
|
- Sources reached and not reached
|
|
@@ -1,12 +1,13 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: weekly-report
|
|
3
3
|
label: "Weekly report"
|
|
4
|
-
description: "A weekly status report across the workspace — in flight,
|
|
4
|
+
description: "A weekly status report across the workspace — in flight, delivered (acceptance not recorded), accepted, needs-you, and a metrics pulse."
|
|
5
5
|
run: deterministic
|
|
6
6
|
surface: report
|
|
7
7
|
output:
|
|
8
8
|
- In flight
|
|
9
|
-
-
|
|
9
|
+
- Delivered — acceptance not recorded
|
|
10
|
+
- Accepted
|
|
10
11
|
- Needs you
|
|
11
12
|
- Metrics pulse
|
|
12
13
|
---
|