Delivery digest
The same change, told to the person who owns the what and the when rather
than the how. Its twin is impact-analysis,
which serves the developers.
Compartmentalisation is the point. The digest is the file that gets
forwarded — to a client, into a steering committee deck, onto a wiki. Write it
so that forwarding it is safe.
Read before writing
- The change:
git diff --stat <base>...HEAD and git log <base>..HEAD.
- The developer note, if it exists:
docs/delivery/impacts/. Reuse its
findings — do not re-derive them differently.
- The requirements the change serves:
specs/.
- Who is affected:
docs/delivery/personas.json and
docs/delivery/assignments.json.
- The cost frame, when planning moved:
docs/delivery/costing/*.json
(mandays, moscow, priority).
When the host project puts an artifact somewhere else, use the host path.
Translate, do not summarise
Every line answers so what? for delivery.
| Instead of |
Write |
| a file or module name |
the feature or screen the user sees |
| a refactor |
"no visible change; reduces the risk of X" — or drop it |
| an endpoint |
the action it enables, and for whom |
| a migration |
whether there is downtime, and whether data is affected |
| a library bump |
only if it changes behaviour, cost, or a compliance answer |
Group by feature, never by commit and never by file.
Redaction rules — non-negotiable
Never put in this file:
- secrets, tokens, keys, connection strings, internal hostnames or IPs
- file paths, function names, stack traces, SQL, code snippets
- individual names attached to a judgement ("X was late", "Y broke it")
- internal disagreements, or anything said in confidence
- vulnerability detail beyond "a security fix was applied in "
Refer to work by profile (Backend developer), not by person, unless the
user explicitly asked for named attribution.
If a change genuinely cannot be described without one of the above, write the
business consequence and add Technical detail available on request.
Output
File: docs/delivery/digests/<YYYY-MM-DD>-<kebab-slug>.md
---
title: <one line a PO would recognise>
date: <YYYY-MM-DD>
base: <the base reference>
audience: product
---
# <title>
**In one sentence:** …
## What is now available
- **<Feature>** — what a user can do that they could not before.
## What changed for users
Behaviour that moved for someone already using the product. `None.` if nothing did.
## Scope and planning
| Item | Before | Now | Why |
| --- | --- | --- | --- |
Only rows where scope, priority, MoSCoW or effort actually moved.
## Decisions taken
One line per decision, with what it rules out. Link the decision record by title.
## Waiting on
| What we need | From whom | Blocking | Since |
| --- | --- | --- | --- |
This is the section the reader acts on. Be specific and be honest about dates.
## Risks and watch points
Plain language. What might slip, and what would tell us early.
## Not in this delivery
Explicitly out of scope, so nobody assumes it landed.
Rules
- No jargon without a plain-language gloss on first use.
- Numbers only when you can source them. "Faster" without a measurement is noise.
- Never mark something delivered because a task is ticked — it counts only when
it is wired and tested end to end. See
verified-progress-signal.
Waiting on rows must name a person or a role, never "the team".- Do not commit or push. The user commits.
1---2name: delivery-digest3description: Write the Product Owner / Project Manager digest of what changed — plain language, business impact, scope and planning consequences, no code. Use when the user asks for a status update for the PO, a stakeholder or client summary, release notes, a non-technical changelog, or a sprint/delivery report.4license: MIT5---67# Delivery digest89The same change, told to the person who owns the *what* and the *when* rather10than the *how*. Its twin is [`impact-analysis`](../impact-analysis/SKILL.md),11which serves the developers.1213**Compartmentalisation is the point.** The digest is the file that gets14forwarded — to a client, into a steering committee deck, onto a wiki. Write it15so that forwarding it is safe.1617## Read before writing18191. The change: `git diff --stat <base>...HEAD` and `git log <base>..HEAD`.202. The developer note, if it exists: `docs/delivery/impacts/`. Reuse its21 findings — do not re-derive them differently.223. The requirements the change serves: `specs/`.234. Who is affected: `docs/delivery/personas.json` and24 `docs/delivery/assignments.json`.255. The cost frame, when planning moved: `docs/delivery/costing/*.json`26 (`mandays`, `moscow`, `priority`).2728When the host project puts an artifact somewhere else, use the host path.2930## Translate, do not summarise3132Every line answers *so what?* for delivery.3334| Instead of | Write |35| --- | --- |36| a file or module name | the feature or screen the user sees |37| a refactor | "no visible change; reduces the risk of X" — or drop it |38| an endpoint | the action it enables, and for whom |39| a migration | whether there is downtime, and whether data is affected |40| a library bump | only if it changes behaviour, cost, or a compliance answer |4142Group by **feature**, never by commit and never by file.4344## Redaction rules — non-negotiable4546Never put in this file:4748- secrets, tokens, keys, connection strings, internal hostnames or IPs49- file paths, function names, stack traces, SQL, code snippets50- individual names attached to a judgement ("X was late", "Y broke it")51- internal disagreements, or anything said in confidence52- vulnerability detail beyond "a security fix was applied in <area>"5354Refer to work by **profile** (`Backend developer`), not by person, unless the55user explicitly asked for named attribution.5657If a change genuinely cannot be described without one of the above, write the58business consequence and add `Technical detail available on request.`5960## Output6162File: `docs/delivery/digests/<YYYY-MM-DD>-<kebab-slug>.md`6364```markdown65---66title: <one line a PO would recognise>67date: <YYYY-MM-DD>68base: <the base reference>69audience: product70---7172# <title>7374**In one sentence:** …7576## What is now available7778- **<Feature>** — what a user can do that they could not before.7980## What changed for users8182Behaviour that moved for someone already using the product. `None.` if nothing did.8384## Scope and planning8586| Item | Before | Now | Why |87| --- | --- | --- | --- |8889Only rows where scope, priority, MoSCoW or effort actually moved.9091## Decisions taken9293One line per decision, with what it rules out. Link the decision record by title.9495## Waiting on9697| What we need | From whom | Blocking | Since |98| --- | --- | --- | --- |99100This is the section the reader acts on. Be specific and be honest about dates.101102## Risks and watch points103104Plain language. What might slip, and what would tell us early.105106## Not in this delivery107108Explicitly out of scope, so nobody assumes it landed.109```110111## Rules112113- No jargon without a plain-language gloss on first use.114- Numbers only when you can source them. "Faster" without a measurement is noise.115- Never mark something delivered because a task is ticked — it counts only when116 it is wired and tested end to end. See117 [`verified-progress-signal`](../../knowledge/instincts/verified-progress-signal.md).118- `Waiting on` rows must name a person or a role, never "the team".119- Do not commit or push. The user commits.
me-cedric