skilldrop-cli 0.16.15 → 0.16.17

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "skilldrop-cli",
-  "version": "0.16.15",
+  "version": "0.16.17",
   "description": "Portable AI-agent skills, measured against the agent without them. ADRs, PRDs, runbooks, decks and reviews, installable into Claude Code, Cursor, Kiro, and any IDE that takes custom instructions. One command per skill or per role-based pack.",
   "author": {
     "name": "Sanjay Ananthanarayan",

package/packs/ai-engineering/pack.json

@@ -43,7 +43,7 @@
       {
         "skill": "ai-usage-policy",
         "you_do": "Give the population, the tools and any data rules already in force.",
-        "you_get": "An acceptable-use policy with three data tiers, permitted and prohibited uses as behaviours, a human-review matrix, approved tools with an exception route, and an owner per section."
+        "you_get": "A policy at the length your audience needs: what's allowed first, every restriction paired with what to do instead or who decides, what to do if data has already gone in, and no claim about a tool, owner or law that you didn't give it."
       },
       {
         "skill": "ai-adoption-rollout",

package/packs/ai-engineering/skills/ai-usage-policy/SKILL.md

@@ -1,59 +1,75 @@
 ---
 name: ai-usage-policy
-description: Draft an organisation's AI acceptable-use policy — three data-sensitivity tiers with what may be put into a tool at each, permitted and prohibited uses stated as behaviours, a human-review matrix keyed to consequence, an approved-tool list with an exception route, and a named owner per rule. Use when a team needs rules for what people may put into AI tools, or asks for an AI acceptable-use or governance policy. Do NOT use to write a repo's agent-tooling policy (that's agents-md-generator) or to analyse one agent's capability surface (that's agent-threat-model).
+description: Draft an organisation's AI use policy or staff guidance from what it has told you about its people, tools, data and worries — every "don't" paired with what to do instead (or who decides, when no approved way exists yet), what to do if data has already gone into a tool, and no claim about a tool, licence, owner, regulation or commitment the input didn't give. Written in the length, labels and voice the audience needs. Use when a team needs rules for what people may put into AI tools, or asks for an AI acceptable-use or governance policy. Do NOT use to write a repo's agent-tooling policy (that's agents-md-generator) or to analyse one agent's capability surface (that's agent-threat-model).
 ---
 
 # ai-usage-policy
 
-Write the policy people will actually follow: **what may go in, what must be checked before it goes out, and who to ask when the rule doesn't fit.** The audience is every employee, not the security team — so it reads as rules for a job, not controls for an auditor.
+**The rule: every "don't" comes with what to do instead.** A policy that only forbids doesn't
+stop the work; it moves it to a personal account where nobody can see it. So each prohibition
+names the approved way to do the same task today: ✅ *"Don't paste client reports into a chat
+tool to summarise them. Use the summariser in the document system, which keeps them inside."*
+When no approved way exists yet, the policy says so and says who decides: ✅ *"There's no
+approved tool for transcribing interviews yet. Ask the operations lead before using one."*
 
-A policy that prohibits without offering a permitted path doesn't reduce risk; it moves the same work onto personal accounts where nobody can see it. Every prohibition here carries an alternative.
+The policy also says **what to do if it has already happened**: data pasted into the wrong
+tool, a draft sent unchecked. Who to tell, how fast, and that telling is what's expected.
 
-## How to respond
-
-**Four rules come before the steps and outrank them:**
-
-- **Answer what was asked, first.** Open with the answer, the decision or the artifact, in plain words. Scores, matrices, frameworks and tags come after it, and anything that doesn't change the answer is cut.
-- **Use only what you were given.** Don't add facts, names, numbers, incidents, history, steps or sections the input doesn't contain. What you need and don't have is left out of the artifact and listed once at the end under "To confirm".
-- **Deliver from what you have.** When the request gives you something to work on, state your assumptions in a line and produce the result. When it gives you nothing to work on, ask for it in one or two plain sentences and say what you will do once you have it.
-- **Write for someone who has never heard of this skill.** No skill names, no paths or scripts from this folder, no internal terms, and nothing about how the run was set up. A next step is one plain sentence at the end that describes the work.
-- **For this skill:** A usable policy says what to do when the rule has already been broken (data already pasted into a tool) and how it is enforced; include both. Check that the data classes and the approved-tools list agree with each other. Make no claim about where a tool sends data unless the user told you.
+A second rule sits beside it: **claim nothing you weren't given.** No statement about where a
+tool sends data, whether it trains on inputs, how many seats exist, who owns the policy, how
+fast exceptions are handled, or which law applies, unless the input says so. A vendor's own
+data-sheet is the vendor's claim: report it as "the vendor says", never as fact, and never
+let it be the reason sensitive data is allowed. Check the tools against what you were told
+(seat counts against headcount, a contract that has lapsed, terms not yet signed) and say
+where they don't line up.
 
-1. **Establish scope and the regulatory floor.** Which population, which tools, and any regime already binding (sector rules, customer contracts, an existing data-classification scheme). If the organisation already classifies data, **reuse those tier names** rather than inventing a parallel scheme — two classification systems means neither is followed. Cap clarifying questions at 2.
+## How to respond
 
-2. **Define three data tiers and what may enter a tool at each.** Three, because five is not memorable and one is not a policy:
+1. **Write for the people who'll read it, at the size asked for.** "A short note for our
+   twelve staff", "one page to attach for a client", "the full policy for the board": that
+   sets the length, voice and structure. Use the organisation's own words for its data and
+   roles; if it already classifies data, use those names, not a new scheme.
 
-   | Tier | Examples | Rule |
-   |---|---|---|
-   | **Open** | public docs, published marketing, open-source code | any approved tool |
-   | **Internal** | internal docs, non-personal telemetry, private repo code | approved tools with data-retention off / enterprise terms |
-   | **Restricted** | personal data, credentials, customer content under contract, regulated records | never pasted; only via a named reviewed integration, if at all |
+2. **Say what's allowed, plainly, first.** The common, low-risk uses (drafting, rewording,
+   brainstorming on non-sensitive material) are named as fine, so the restrictions read as
+   targeted rather than blanket.
 
-   Give each tier **two concrete examples from this organisation's actual work** — abstract tiers are the reason policies get ignored.
+3. **The restrictions, each with its alternative.** State them as behaviours tied to the
+   organisation's real data: what not to put in which tool, and what to do instead. Review
+   before use only where the consequence warrants it: something reaching a customer, money,
+   a legal position, a decision about a person.
 
-3. **State permitted and prohibited uses as behaviours.** ✅ "Drafting a first version of a customer email, then editing before sending." ❌ "Inappropriate use." Every prohibition names the **permitted alternative**: "Do not paste customer records to summarise them — use the approved integration, which does the same thing without the data leaving."
+4. **The tools, as far as you know them.** The tools the input names, and what each is
+   cleared for, as far as the input says. For anything else, the route to ask, with the role
+   who decides if the input names one, or "to be agreed" if it doesn't.
 
-4. **Build the human-review matrix on consequence, not on technology.** What must a human check before an AI-assisted output is acted on? Key it to blast radius: reaches a customer · commits money or a legal position · changes production · informs a personnel decision. Each row says who reviews and what "reviewed" means. Low-consequence internal drafting needs no gate — say so, or the policy loses credibility everywhere else.
+5. **If something has already gone wrong.** One short section: who to tell, and that
+   reporting quickly is what's expected.
 
-5. **List approved tools, and give an exception route.** Named tools with the tier they're cleared to. Then the route for anything else: who approves, what they check, and a target turnaround. **A policy with no exception path is a policy people route around** — the turnaround time is the part that makes it real.
+6. **Keep notes to the requester out of the policy.** The policy is a document someone will
+   circulate. Questions for the person who asked (who owns this, which tool contract to
+   check, whether a law applies) go in a short list after it, never as bracketed tags inside.
 
-6. **Name an owner per section, a review date, and the disclosure rule.** Owners as roles. A review date, because tool terms change. And one line on whether AI assistance must be disclosed, and where — the question every employee actually has.
+7. **Deliver from what you have.** With anything about the organisation to go on, write the
+   policy and state any assumption in one line. Ask first only when you don't know who it is
+   for or what kind of data they handle.
 
 ## Quality bar
 
-- **Every rule has a named owner role** and the document has a review date. An unowned policy is a document, not a control.
-- **Every prohibition names a permitted alternative**, or it drives the work into the shadows.
-- **Data tiers carry concrete examples from this organisation**, not generic labels.
-- **The review matrix is keyed to consequence, not to tool or model.** Model names age out in months; consequences don't.
-- **There is an exception route with a turnaround time.**
-- **Written for the whole staff.** If a non-technical reader hits an unexplained term, rewrite it — the audience is everyone, and unread rules govern nothing.
-- **No invented regulation.** Cite only regimes the user named; where applicability is unclear, mark `[confirm with counsel]` rather than asserting a legal position.
+- **Every prohibition names an alternative,** or says no approved way exists yet and who
+  decides.
+- **There is a line on what to do if it has already happened.**
+- **Nothing unsupplied:** no data-handling claim, seat count, owner, turnaround, commitment or
+  regulation the input didn't give; vendor claims are attributed to the vendor.
+- **The tool list is checked against the input** and mismatches are named.
+- **The length, voice and labels fit the audience asked for.**
+- **No notes, tags or questions to the requester inside the policy.**
 
 ## When to use this skill
 
 - ✅ "What are people allowed to put into these tools?" — the question every rollout hits in week one.
-- ✅ Standing up governance before or alongside an AI rollout.
-- ✅ Replacing an informal "be sensible" norm with something reviewable.
+- ✅ Standing up guidance before or alongside an AI rollout.
+- ✅ Replacing an informal "be sensible" norm with something people can follow.
 
 ## When NOT to use this skill
 
@@ -65,11 +81,14 @@ A policy that prohibits without offering a permitted path doesn't reduce risk; i
 
 ## Anti-patterns to avoid
 
-- ❌ **Prohibition without an alternative.** "Never paste customer data" with no sanctioned path moves the work to a personal account and removes your visibility entirely.
-- ❌ **Naming models and versions in the rules.** They change quarterly; consequence-based rules survive. Keep tool names in the approved-list appendix where they're cheap to update.
-- ❌ **Five or more tiers.** Nobody classifies correctly against a scheme they can't recall at the moment of pasting.
-- ❌ **Writing for auditors.** A policy in control language gets filed, not followed. Plain rules for a working day.
-- ❌ **No exception route.** Guarantees either shadow usage or a queue of blocked work — and you find out about neither.
-- ❌ **Requiring review of everything.** A gate on low-consequence drafting trains people to ignore gates that matter.
-
-**Non-interactive:** with no user to ask, assume no sector-specific regime beyond general data-protection practice and tag it `[assumption]`, listing what to confirm. If the input names no organisation type or data context, emit `BLOCKED: need the population covered and the kinds of data they handle` — a fabricated policy is worse than none, because it will be circulated as if it were reviewed.
+- ❌ **Prohibition without an alternative.** It moves the work out of sight.
+- ❌ **Repeating the vendor.** "The tool never stores your data" because a sales sheet said so.
+- ❌ **Invented machinery.** An owner, a five-day exception turnaround, a quarterly review, a
+  tier scheme the organisation never asked for.
+- ❌ **The full framework on a short note.** Tier tables and review matrices for a twelve-person
+  team that asked for half a page.
+- ❌ **Bracketed notes in the policy.** `[confirm with counsel]` in a document about to be
+  attached for a client.
+- ❌ **Naming laws the user didn't name.** Say what to check, in the note after the policy.
+- ❌ **Requiring review of everything.** A gate on low-risk drafting trains people to ignore the
+  gates that matter.

package/packs/ai-engineering/skills/ai-usage-policy/evals/evals.json

@@ -74,6 +74,34 @@
         "It does not state as fact that a specific law applies or that the studio owns the copyright in AI-generated material; any such point is marked as something to check",
         "The policy itself fits on about one page (roughly 500 words or fewer)"
       ]
+    },
+    {
+      "id": 6,
+      "held_out": "2026-10-17",
+      "prompt": "I'm the operations director at Harrowmere Veterinary Group (11 clinics, about 230 staff). The board wants a staff policy on using AI tools at its next meeting. Everything I know is in three files: `ops-notes.md`, `vendor-sheet-murmurly.txt` and `board-meeting-extract.md`. Draft the policy for all staff: reception, vets, nurses, marketing and our two developers. Plain English, no more than two pages (about 900 words), and skip any intro about how AI is changing the world. Separately, give me a short list of the questions I need the Managing Director or the board to settle; keep those out of the staff policy itself.",
+      "assertions": [
+        "It says Murmurly transcription may be used only in the pilot at Northgate and Fernhill clinics (with the client told and able to object) and that other clinics must not start using it yet; it does not describe Murmurly as approved across the group",
+        "It does not repeat Murmurly's data-handling claims (zero retention, never used for training, compliant with every law, certified secure) as established fact; any it mentions are attributed to the vendor or marked unverified pending the unsigned contract",
+        "Every use the policy rules out comes with an alternative staff can use (such as the Dosewell formulary for doses, or a Tallowby Business seat) or a statement that there is no approved way yet and that the Managing Director decides; no prohibition is left without one",
+        "It tells staff what to do if client, payment or staff details have already been put into an AI tool, including reporting it to the Practice Compliance Lead under the existing data incident procedure, and it does not treat the receptionist's incident as already resolved",
+        "It does not say every member of staff has or can get a Tallowby Business account; it reflects that there are 40 seats and that who gets them is undecided",
+        "It does not invent a policy owner, review date or cycle, training programme, tool, licence count, or regulation not in the files; the claim about the veterinary regulator's rules on AI in clinical records is marked as unchecked, not stated as a rule",
+        "The staff policy is about 900 words or fewer, and the questions for the Managing Director or board are given separately from it rather than inside it"
+      ]
+    },
+    {
+      "id": 7,
+      "held_out": "2026-10-17",
+      "prompt": "hi, we run Millbrook Lane Bakery, 3 shops and about 18 staff. a few of the team have started using Wordnook (the free chat app) on their phones to write our instagram posts, and one shift lead used it to sort out the staff rota. I'm the owner and I'm a bit worried about people putting customer stuff in there, like the custom cake orders which have names, phone numbers and allergy notes on them. can you write me something short I can pin up in the back room? half a page max, no jargon please",
+      "assertions": [
+        "It delivers the notice in this reply rather than asking questions first; any gaps are noted briefly without holding up the notice",
+        "The notice is about half a page (roughly 250 words or fewer) and written in plain everyday words, without terms like 'data controller', 'LLM' or 'personal data processing'",
+        "It says customer names, phone numbers and allergy or order details from cake orders must not be typed into Wordnook, and says what to do instead (for example, write the post without them, or ask the owner)",
+        "It covers staff information such as the rota (names, hours) as well as customer information",
+        "Every 'don't' on the notice is paired with what to do instead or with 'ask the owner'",
+        "It says what to do if someone has already typed customer or staff details into Wordnook, at least telling the owner",
+        "It does not invent a paid plan, app settings, a law, a named person other than the owner, training, a review date, or other tools, and does not state as fact what Wordnook does or does not do with what is typed into it"
+      ]
     }
   ]
 }

package/packs/ai-engineering/skills/ai-usage-policy/evals/files/6/board-meeting-extract.md

@@ -0,0 +1,13 @@
+# Board meeting, 2 October: extract, item 6 (AI tools)
+
+- Murmurly: agreed as a PILOT only, at Northgate and Fernhill clinics, until the contract
+  and data processing terms are signed and the pilot is reviewed. Other clinics are not to
+  start using it. Pilot vets must tell the client a consult is being transcribed and stop
+  if the client objects.
+- Glimmerpress: no client pet photos until the marketing team has a way to get the
+  owner's permission. No decision yet on how that will work.
+- Policy ownership: two names were put forward (Head of Clinical Services, IT Manager).
+  Not agreed. The Managing Director will decide who owns the policy, and until then any
+  "can I use AI for this?" question not covered by the policy goes to the Managing Director.
+- Codewren: decision on buying deferred until the trial ends.
+- Ops director to draft a staff policy for the next meeting.

package/packs/ai-engineering/skills/ai-usage-policy/evals/files/6/ops-notes.md

@@ -0,0 +1,42 @@
+# AI tools: where we are (ops director's notes, October)
+
+Harrowmere Veterinary Group: 11 clinics, about 230 staff. Reception and client care, vets,
+vet nurses, a small marketing team (3), and two in-house developers who look after the
+booking site and the practice-management integrations.
+
+## What people are using
+
+- **Tallowby Chat** (general chat assistant). We bought 40 seats on the Tallowby Business
+  plan in the spring, mostly for clinic managers and marketing. Nobody has decided who gets
+  the other seats or whether we buy more. Plenty of staff are using the free Tallowby app on
+  their own phones and personal accounts instead, including reception.
+- **Murmurly** (consult transcription). Vets love it. See the board extract for what was
+  actually agreed. The vendor sheet is in `vendor-sheet-murmurly.txt`. Contract and data
+  processing terms are with our solicitor and have NOT been signed yet.
+- **Codewren** (coding assistant). The two developers are on a free 60-day trial that ends
+  next month. No decision on buying it. They have mentioned pasting chunks of the booking
+  site code and, once, a config file to debug a payment issue.
+- **Glimmerpress** (image generator). Marketing uses it for social posts. Worry: someone
+  suggested uploading photos clients send us of their pets to "make them look festive" for
+  the Christmas campaign. We have never asked clients whether we can use those photos.
+
+## What's already gone wrong
+
+- Two weeks ago a receptionist pasted a whole client complaint into her personal Tallowby
+  account to help write a reply. It had the client's full name, phone number, home address,
+  the pet's treatment history and the last four digits of their card. She told her manager
+  afterwards. Nothing else has been done about it yet.
+- A locum vet asked Tallowby for a dosage for a cat and used it. It turned out fine, but
+  that should have come from the Dosewell formulary, which every clinic already subscribes to.
+
+## Things that already exist
+
+- Data incidents go to the Practice Compliance Lead under the existing data incident
+  procedure. Staff mostly don't know that.
+- Client photos and records live in the practice-management system.
+
+## Things I don't know
+
+- Someone at the board said the veterinary regulator "has rules about AI in clinical
+  records". Nobody has checked whether that's true.
+- Who owns this policy going forward. See board extract.

package/packs/ai-engineering/skills/ai-usage-policy/evals/files/6/vendor-sheet-murmurly.txt

@@ -0,0 +1,10 @@
+MURMURLY FOR VETERINARY PRACTICES - WHY TEAMS TRUST US
+
+* Zero data retention: recordings are deleted the moment your note is ready.
+* Your data is NEVER used to train our models.
+* Fully compliant with every data protection law in every market we serve.
+* Bank-grade encryption, end to end.
+* Certified secure by independent auditors.
+* Clinical-grade accuracy: 99.4% of notes need no correction.
+
+Start your free practice-wide rollout today.

package/packs/ai-engineering/skills/ai-usage-policy/manifest.json

@@ -1,7 +1,7 @@
 {
   "name": "ai-usage-policy",
-  "version": "0.1.1",
-  "description": "Draft an organisation's AI acceptable-use policy — three data-sensitivity tiers with what may be put into a tool at each, permitted and prohibited uses stated as behaviours, a human-review matrix keyed to consequence, an approved-tool list with an exception route, and a named owner per rule. Use when a team needs rules for what people may put into AI tools, or asks for an AI acceptable-use or governance policy. Do NOT use to write a repo's agent-tooling policy (that's agents-md-generator) or to analyse one agent's capability surface (that's agent-threat-model).",
+  "version": "0.2.0",
+  "description": "Draft an organisation's AI use policy or staff guidance from what it has told you about its people, tools, data and worries — every \"don't\" paired with what to do instead (or who decides, when no approved way exists yet), what to do if data has already gone into a tool, and no claim about a tool, licence, owner, regulation or commitment the input didn't give. Written in the length, labels and voice the audience needs. Use when a team needs rules for what people may put into AI tools, or asks for an AI acceptable-use or governance policy. Do NOT use to write a repo's agent-tooling policy (that's agents-md-generator) or to analyse one agent's capability surface (that's agent-threat-model).",
   "entrypoint": "SKILL.md",
   "deps": {
     "npm": [],
@@ -28,6 +28,6 @@
   ],
   "model": {
     "tier": "standard",
-    "rationale": "Drafts a policy document against a fixed structure (tiers, behaviours, review matrix, exception route). Bounded generation; escalate via ambiguous-input where a regulatory regime is named or contested."
+    "rationale": "Drafts a policy that pairs every restriction with an alternative and claims nothing unsupplied. Bounded generation; escalate via ambiguous-input where a regulatory regime is named or contested."
   }
 }

package/packs/solution-architect/skills/design-doc/evals/evals.json

@@ -70,6 +70,34 @@
         "The rollout includes a step that observes or logs would-be limiting before requests are actually blocked, or a stated way to switch enforcement off quickly",
         "It is about one page: roughly 700 words or fewer"
       ]
+    },
+    {
+      "id": 6,
+      "held_out": "2026-10-17",
+      "prompt": "Can you write the nurse rostering proposal for the Digital Programme Board on 23 October? Notes from the pre-meet are in premeet-notes.md, the requirements we agreed are in requirements.md, and the quotes and other numbers are in figures.csv. It goes into the board pack, so two pages at most, call it 1,000 words, and the board needs a recommendation it can vote on. Save it as rostering-proposal.md.",
+      "assertions": [
+        "Within its first few paragraphs it says what is proposed and which option it recommends (a recommendation that depends on a stated condition counts), framed as a decision for this board to take; it does not say the board already approved Corvane in March",
+        "ShiftLattice is not recommended as it stands, because its Canadian hosting fails the UK data requirement (IG-07), and the document says so even though ward managers prefer it; making it conditional on UK hosting becoming available is fine",
+        "The recommended option's weaknesses are stated as well as its strengths (for example Corvane's payroll interface being only in beta, or the in-house route being uncosted and needing a developer for most of a year)",
+        "The two agency spend figures (£4.2m from the finance ledger and £3.1m from the nursing workforce report) are not merged or silently reduced to one: it reports the discrepancy, or uses one with the other noted, and says it needs reconciling",
+        "The ward-manager time saved is stated as not measured, with a way to measure it (for example timing rota work on some wards); no hours-per-week or money saving is presented as fact, and Priya's 'a day a week' is not used as a measured figure",
+        "It does not invent facts the inputs do not give: no named owners for actions, no go-live or milestone dates, no author name, and no cost for the in-house option or other figures absent from figures.csv",
+        "It respects the board pack limit: roughly 1,100 words or fewer"
+      ]
+    },
+    {
+      "id": 7,
+      "held_out": "2026-10-17",
+      "prompt": "hey can you write me a one-pager to get our two partners to sign off on this. we're a small vet practice, Linthorpe Vets, 3 vets and 6 support staff. reception spends most mornings ringing clients to confirm the next day's appointments and we still get no-shows, nobody's counted how many. we want to switch to text reminders. our practice software VetLedger has a texting add-on for £45 a month, or Jo found a standalone texting service that's cheaper per message but we'd have to export the appointment list to it every day. some of the older clients only have landlines on file. a page max please",
+      "assertions": [
+        "It delivers the one-pager rather than stopping to ask questions; any open questions appear inside the document, not instead of it",
+        "Near the top it says what is proposed and which of the two options it recommends, or the specific fact that would decide between them",
+        "The trade-off between the options is stated honestly: the add-on costs a fixed £45 a month, while the standalone service needs a daily manual export that can be forgotten or go out of date",
+        "It says clients with only a landline on file will not get texts and need another route (such as a phone call), so morning calls do not disappear entirely",
+        "The no-show rate is recorded as not yet counted, with a way to find out (for example counting no-shows for a few weeks before and after the switch); no no-show rate or time saving is presented as fact",
+        "It does not invent facts the user did not give: no per-message price for the standalone service, no message volumes, no money saved, no named owners beyond Jo's stated role, no go-live dates and no author name",
+        "It fits on one page: roughly 550 words or fewer"
+      ]
     }
   ]
 }

package/packs/solution-architect/skills/design-doc/evals/files/6/figures.csv

@@ -0,0 +1,11 @@
+item,value,source
+Wards in scope,14,Nursing directorate
+Nursing staff on rotas (registered nurses and healthcare assistants),620,Nursing directorate
+Corvane rostering module - implementation,£185000,Corvane quote September 2026
+Corvane rostering module - annual licence,£62000,Corvane quote September 2026
+ShiftLattice - implementation,£20000,ShiftLattice quote September 2026
+ShiftLattice - annual subscription,£48000,ShiftLattice quote September 2026
+In-house extension of Access rota tool,not costed,Digital
+Agency nursing spend 2025/26,£4.2m,Finance ledger (Tomasz Lee)
+Agency nursing spend 2025/26,£3.1m,Nursing workforce report (Helen Marsh)
+Rota publication lead time today,4 weeks,Nursing directorate

package/packs/solution-architect/skills/design-doc/evals/files/6/premeet-notes.md

@@ -0,0 +1,25 @@
+# Nurse rostering - pre-meet for Digital Programme Board
+
+Wrenfield District Hospital, 2 October 2026
+
+Present: Helen Marsh (Deputy Chief Nurse), Tomasz Lee (Finance Business Partner), Ade Okafor (Head of Digital), Priya Raman (Ward Manager, Elm Ward), Gary Fenn (Information Governance Lead)
+
+**Where we are**
+- Helen: every ward still builds its rota in its own spreadsheet and keeps the live version on the office whiteboard. Gaps get spotted a few days out, which is when we end up ringing agencies.
+- Helen: the board will want to know how many hours this gives back to ward managers. "Put a number on it." Nobody has ever timed how long rota work takes. Priya: "feels like a day a week, for me anyway."
+
+**Money**
+- Tomasz: agency nursing spend for 2025/26 was £4.2m, from the finance ledger.
+- Helen: her figure from the nursing workforce report is £3.1m for the same year.
+- Not resolved which is right or why they differ.
+
+**Options**
+- ShiftLattice: Priya and two other ward managers sat through the demo and loved it - self-rostering on the phone, very easy to use. Priya: "it's the obvious choice."
+- Gary: ShiftLattice told us their data is hosted in Canada and they have no date for UK hosting. Policy IG-07 says staff personal data stays in the UK. Gary can't sign it off as it stands.
+- Corvane rostering module: Corvane already runs our patient record system. Ade has the quote. Their interface to Pellbridge (our payroll) is in beta; two other hospitals are piloting it.
+- In-house: Ade says we could extend the old Access rota tool, but it would need a developer for most of a year. Not costed.
+
+**Other**
+- Priya: "Didn't the board already approve Corvane back in March?" Tomasz: the March board noted the outline case; it did not approve anything.
+- Helen would like it live before winter. No date agreed.
+- Proposal to go to the Digital Programme Board on 23 October.

package/packs/solution-architect/skills/design-doc/evals/files/6/requirements.md

@@ -0,0 +1,8 @@
+# Rostering requirements (agreed at pre-meet)
+
+1. Staff can request shifts and leave from their phone.
+2. Rotas published at least 6 weeks ahead (today: 4 weeks).
+3. Shows each ward's minimum safe staffing per shift and flags gaps as soon as they appear.
+4. Hours worked go to Pellbridge payroll without being typed in again.
+5. Staff personal data is held in the UK (policy IG-07).
+6. Ward managers can use it after a short training session.

package/packs/solution-architect/skills/design-doc/manifest.json

@@ -1,6 +1,6 @@
 {
   "name": "design-doc",
-  "version": "0.1.1",
+  "version": "0.1.2",
   "description": "Generate a Google-style engineering design doc (problem, goals/non-goals, options considered, recommended approach, risks, rollout) from a feature brief or short description. Use when the user wants to draft a design doc, technical proposal, or one-pager for an engineering review.",
   "entrypoint": "SKILL.md",
   "deps": { "npm": [], "pip": [] },

package/packs/sre-oncall/pack.json

@@ -45,7 +45,7 @@
       {
         "skill": "postmortem-generator",
         "you_do": "Paste the incident thread, pager timeline and notes once it is over.",
-        "you_get": "A blameless postmortem with quantified impact, a UTC timeline showing detection and mitigation gaps, contributing factors, up to eight action items, and runbook deltas phrased as edits.",
+        "you_get": "A blameless postmortem at the length you ask for: the cause as the change and the missing check, never a person; who or what noticed first and how late; checkable follow-ups; and the runbook edits the incident showed were needed.",
         "decide": "Gate G4, a human call: PROCEED closes it, PROCEED WITH CONDITIONS closes it with named follow-ups, REVISE sends the deltas back to the runbook."
       },
       {

package/packs/sre-oncall/skills/postmortem-generator/SKILL.md

@@ -1,74 +1,99 @@
 ---
 name: postmortem-generator
-description: Generate a blameless incident postmortem from raw material (Slack thread, pager timeline, notes) — quantified impact, UTC timeline with detection/mitigation gaps, contributing factors instead of a single root cause, and ≤8 verifiable action items. Use after an incident or outage when the user needs a postmortem, RCA, incident review, or "lessons learned" doc.
+description: Write a blameless incident postmortem from the raw material (chat scrollback, alert history, timeline, notes) for the audience and length the user names — the cause stated as the change and the gap that let it through, never a person even when the notes name one; who or what noticed first and how late; known kept apart from still-unknown; and follow-up actions that close the gap. Invents no times, figures, owners or severities. Use after an incident or outage when the user needs a postmortem, RCA, incident review, a plain explanation for a non-technical reader, or "lessons learned" doc.
 ---
 
 # postmortem-generator
 
-Turns the debris of an incident — Slack scrollback, pager entries, half-remembered timestamps — into a postmortem the next on-caller learns from. Blameless is structural here, not a tone: the doc names systems and gaps, never people and mistakes. The operate-phase counterpart to `runbook-generator`, which consumes this skill's runbook-delta output.
+**The rule: name the change and the missing check, never the person.** Incident notes are
+written in the heat of it: "Dana's deploy broke it", "Sam forgot the flag". The agent's habit
+is to carry that framing straight into the document, and a postmortem that names someone as
+the cause teaches everyone to hide the next mistake. The cause is always a condition: what
+made the error easy to make, hard to catch and quick to spread. People appear only doing
+response work, by role ("the on-call engineer rolled back at 14:32"), and that holds even when
+the user's own message points at someone.
 
-## How to respond
-
-**Four rules come before the steps and outrank them:**
-
-- **Answer what was asked, first.** Open with the answer, the decision or the artifact, in plain words. Scores, matrices, frameworks and tags come after it, and anything that doesn't change the answer is cut.
-- **Use only what you were given.** Don't add facts, names, numbers, incidents, history, steps or sections the input doesn't contain. What you need and don't have is left out of the artifact and listed once at the end under "To confirm".
-- **Deliver from what you have.** When the request gives you something to work on, state your assumptions in a line and produce the result. When it gives you nothing to work on, ask for it in one or two plain sentences and say what you will do once you have it.
-- **Write for someone who has never heard of this skill.** No skill names, no paths or scripts from this folder, no internal terms, and nothing about how the run was set up. A next step is one plain sentence at the end that describes the work.
-- **For this skill:** With no timeline, logs or notes to work from, ask for them in two sentences and name the three things you most need. Don't describe your working directory or your template.
-
-1. **Ingest the raw material.** Slack threads, pager/alert timelines, deploy logs, prose recollections — all valid. Ask at most 2 questions, and spend them on impact quantification ("how many users / requests / minutes?") — it's the data people forget fastest and the section read first. Everything else unknown gets a visible `[missing]` tag, never a vague sentence papering over it.
-
-2. **Strip blame structurally while drafting.** People appear only as roles performing response actions ("on-call engineer rolled back at 14:32"). Errors are attributed to the system that allowed them. ✅ *"A malformed config value passed review and deploy; no validation step checks this field"* — ❌ *"Dave pushed a bad config"*. If the source material is finger-pointy, translate it; the postmortem is the cleaned record.
-
-3. **Build the timeline in UTC** with one row per event (timestamp, what happened, source). Then compute and state the two gaps that matter:
-   - **Detection gap** — impact start → first human aware. If users noticed before monitoring did, say so in those words.
-   - **Mitigation gap** — detection → impact ended.
-   The timeline ends at "impact over", not "everyone went to bed"; cleanup goes under follow-ups.
+A second rule sits beside it: **say plainly who or what noticed first, and how late.** If a
+customer, a support ticket or a member of staff found the problem before any alert did, that
+is the most useful sentence in the document: ✅ *"Two teachers reported the gradebook down 40
+minutes before any alert fired."* Don't write "alerting worked" when it didn't.
 
-4. **Write contributing factors, not a root cause.** Minimum 2, typically 3–5, using "why was that possible?" chains. **"Human error" is banned as a factor** — it is always the start of a question, never the answer: what made the error easy to make, hard to catch, and fast to propagate? Each factor states the condition, not the act.
-
-5. **Force the three honesty lists**: what went well (so it gets repeated), what went poorly (response-side, not cause-side), and **where we got lucky** — the near-misses that would have made this worse. The lucky list is mandatory; an incident with no luck involved hasn't been examined closely.
-
-6. **Cap action items at 8**, each with: owner (role, not name), class (**prevent** recurrence / **detect** faster / **mitigate** faster), and a verifiable done-condition. ✅ *"Config deploys reject values failing schema validation — verified by a test deploy of a malformed value"* — ❌ *"Improve config safety"*. If the analysis surfaces 15 candidates, pick the 8 with the best leverage and list the rest as "considered, not taken" with one line each on why.
-
-7. **End with runbook deltas** — the specific sections of the service runbook this incident proves wrong or missing, phrased as edits ready for `runbook-generator` or a human to apply.
-
-8. **Emit with [`templates/postmortem.md`](templates/postmortem.md)** in one message, summary first: severity, duration, quantified impact, and the one-sentence cause a director can repeat.
-
-## Useful references in this skill
+## How to respond
 
-- [`templates/postmortem.md`](templates/postmortem.md) — the full doc skeleton with the gap calculations and action-item table
+1. **Fit the audience and length they asked for.** "Half a page for the board", "a note for
+   customers", "two pages max", "the full incident review": that is the format. A
+   short version is what happened, why it was possible, how it was found, and what changes.
+   The full form in [`templates/postmortem.md`](templates/postmortem.md) is for when they ask
+   for a full review or an incident-review meeting doc.
+
+2. **Build the timeline from the material.** Use the events that changed what users saw:
+   impact starts, first noticed, mitigation, impact ends. Use the timezone the material uses
+   unless asked otherwise, and state it. Compute the gaps that matter (start to noticed,
+   noticed to fixed) only from times you have.
+
+3. **Keep what is known apart from what is still being investigated.** Write the cause the
+   evidence supports, and name anything not yet confirmed as open.
+
+4. **Write the causes as conditions, more than one where the material shows more than one.**
+   For each: the condition, and why it made the incident possible or worse. ✅ *"A config value
+   passed review and deploy; nothing validates that field."* ❌ *"Human error"*, ❌ *"should
+   have been more careful"*. Don't invent extra causes to make up a number.
+
+5. **Follow-ups that close the gap.** Each action says what changes and how anyone could tell
+   it's done: ✅ *"Config deploys reject values that fail the schema, checked by a test deploy
+   of a bad value."* ❌ *"Improve config safety."* Give an owner or date only if the material
+   gives one; otherwise write "no owner yet". A few strong actions beat a long list.
+
+6. **Runbook changes, when the incident proved a procedure wrong or missing.** Phrase each as
+   a concrete edit to the runbook section it affects, ready for someone to apply. Leave them
+   out of a short version for a non-technical audience unless asked.
+
+7. **Say only what the material supports.** No affected-customer count, revenue or SLA-credit
+   figure, severity level, owner or time that isn't in it, even when a stakeholder asked for
+   one. Where a number was asked for and the material can't give it, say what it does show
+   ("12 customers have written in so far") and what would settle it. Never leave
+   `[missing]` or blank fields in the document; list what is still unknown once, briefly,
+   after it.
+
+8. **Deliver from what you have.** With notes to work from, write it and state any assumption
+   in one line. With nothing to work from, ask in two sentences for the timeline, how it was
+   noticed, and what was done.
 
 ## Quality bar
 
-- **Impact is numbers or `[missing]`.** Duration, users/requests affected, SLO burn, revenue if known. "Significant impact" is not a measurement.
-- **No person is named in a causal sentence.** Roles appear in response actions only. One named-blame sentence fails the doc.
-- **Detection and mitigation gaps are computed and stated.** They are the two numbers the next incident will be judged against.
-- **At least 2 contributing factors, zero of them "human error".** A single root cause means the chain of "why was that possible?" stopped one question early.
-- **Every action item is verifiable and owned.** A reader can check it's done without asking anyone's opinion; an item without a done-condition is a wish.
-- **"Where we got lucky" is non-empty.** Naming the near-miss is how it gets fixed before it's the next incident's headline.
+- **No person is named as a cause.** Roles appear in response actions only, including when
+  the user's notes name someone.
+- **Who or what noticed first is stated,** with the gap to the first alert when the material
+  gives both times.
+- **Known and still-open are kept apart.**
+- **Causes are conditions, not "human error",** and come only from the material.
+- **Every action is checkable,** and has an owner only if the material named one.
+- **Nothing is invented:** no figures, times, severities, owners or counts beyond the input.
+- **The length and format are the ones asked for,** and the document has no placeholders.
 
 ## When to use this skill
 
-- ✅ After an incident/outage, turning the response scrollback into the postmortem doc
+- ✅ After an incident or outage, turning the response scrollback into the postmortem
 - ✅ "Write the RCA for yesterday's outage"
+- ✅ A short explanation of what went wrong for a non-technical reader
 - ✅ Preparing the incident-review meeting doc
-- ✅ Retroactively documenting an old incident before the details evaporate
 
 ## When NOT to use this skill
 
-- ❌ During the incident — mitigate first; the postmortem starts when impact ends
-- ❌ A performance-management record — the doc is structurally blameless; misusing it kills honest reporting
-- ❌ Project retrospectives with no production incident — different ritual, different doc
-- ❌ Writing the runbook itself — emit the deltas and hand to `runbook-generator`
+- ❌ During the incident — mitigate first; live updates to stakeholders are `incident-comms`
+- ❌ A performance-management record — the document is blameless by design; using it to blame kills honest reporting
+- ❌ A project retrospective with no production incident
+- ❌ Writing the runbook itself — hand the runbook changes to `runbook-generator`
 
 ## Anti-patterns to avoid
 
-- ❌ **Single root cause.** "The config was wrong" explains nothing about review, validation, deploy gates, or blast radius — the four places to actually fix.
-- ❌ **"Human error" / "should have been more careful".** Careful is not a control. Name the missing guardrail instead.
-- ❌ **The 20-item action list.** It signals diligence and delivers nothing; nobody finishes it and the P1s drown.
-- ❌ **Timeline theater.** Forty rows of who-said-what-in-Slack instead of the ten events that changed system state.
-- ❌ **Quiet heroics as a fix.** "An engineer noticed by luck at 2am" is a detection gap wearing a cape — the action item is monitoring, not gratitude.
-- ❌ **Skipping the postmortem because impact was "minor".** Near-misses are the cheapest lessons; severity gates the meeting, not the doc.
-- ❌ **Showing the machinery.** The reply and the artifact are for the person who asked. Don't mention this skill, its files, templates, caps or internal terms, or that the run is non-interactive. Name another skill once, at the end, as a suggested next step, never inside the artifact.
+- ❌ **Copying the blame from the notes.** "The outage was caused by X's change" — rewrite as
+  the change and the missing check.
+- ❌ **"Alerting worked" when a customer found it first.** The detection gap is the finding.
+- ❌ **Filling the template.** Severity rows, SLO burn, "where we got lucky" and owner columns
+  on a half-page note for a head teacher.
+- ❌ **Placeholders in a document meant to ship.** `Severity: [missing]` goes nowhere; list
+  unknowns after the document.
+- ❌ **Invented owners, dates and numbers** to make actions look tracked or impact look
+  measured.
+- ❌ **The 20-item action list.** Nobody finishes it and the important ones drown.

package/packs/sre-oncall/skills/postmortem-generator/evals/evals.json

@@ -72,6 +72,33 @@
         "It says the problem was noticed through helpdesk calls about 15 minutes after the change went live, and does not invent a monitoring alert or page",
         "At least one follow-up action addresses checking a DNS change right after it is made, lowering the TTL before a change, or avoiding changes around registration, written so someone can tell whether it was done"
       ]
+    },
+    {
+      "id": 6,
+      "held_out": "2026-10-17",
+      "prompt": "I was incident lead for INC-0412 at Quillmere (we make invoicing software for small businesses). Everything I have is in timeline.md (my notes), incident-channel.txt (the chat export) and alerts.csv. Write the incident review for the leadership team's Monday meeting. They are not engineers, so plain English, and keep it under 450 words. Ade has asked for the exact number of customers affected and the £ value of the stuck invoices to be in it, so please include those. Save it as incident-review.md.",
+      "assertions": [
+        "No named person (Tomasz or anyone else) is described as the cause of the incident or as at fault; the cause is put in terms of the configuration change and the checks that did not catch it",
+        "It says the problem was first noticed by customers through support tickets (from about 14:31), before any alert fired at 14:58, and does not describe the incident as detected by monitoring",
+        "It does not state 15:35 as the time service was restored without qualification; it uses the deploy and monitoring record (rollback finished 15:47, processing back to normal around 15:52) or says the sources disagree",
+        "The database failover is not presented as a cause (it may appear only as an early theory that was ruled out); the drop in workers from the configuration change is given as the established trigger, and the open questions (whether dead-lettered payment updates were lost, how many already-paid clients got an overdue reminder) are labelled as still being investigated rather than stated as settled",
+        "It does not state a number of affected customers or a pound figure for stuck invoices, and does not invent any other time, figure, owner or incident severity level absent from the material; it tells leadership those numbers are not yet known rather than estimating them",
+        "Follow-up actions address the gaps the material shows: a check on consumer configuration values before or during deploy, and an alert on payment processing delay that would fire before customers notice; each is concrete enough that someone could later tell whether it was done",
+        "incident-review.md exists, is under 450 words, reads in plain language for a non-engineering leadership audience, and the reply delivers it without stopping to ask questions first"
+      ]
+    },
+    {
+      "id": 7,
+      "held_out": "2026-10-17",
+      "prompt": "ugh ok. run a small online yarn shop (Wrenmoor Yarn Co, me + 2 staff). checkout on the site was broken over the weekend. last order came in sat about 9am, then nothing. didnt notice till a customer messaged us on instagram sunday around 11 saying she couldnt pay. think it was the shipping plugin, it auto updated friday night maybe? rolled it back sun afternoon and orders started coming through again. jamie says she clicked update on something friday but not sure what. probably lost a few orders. need a short email to jamie and priya explaining what happened and what we do now so it doesnt happen again. keep it short",
+      "assertions": [
+        "It does not blame Jamie or anyone else for the outage; if the update she clicked is mentioned, it is framed as how updates are handled in the shop, not as her fault",
+        "It says plainly that the problem was found because a customer messaged on Instagram on Sunday around 11, not by any check or alert",
+        "It keeps what is known (checkout stopped working some time after the last order around 9am Saturday; rolling back the shipping plugin brought orders back) apart from what is not (which update caused it and when, exactly when checkout broke, how many orders were missed)",
+        "It does not invent a start or fix time, a number of lost orders, a money figure, or plugin details that are not in the message",
+        "Follow-up actions are small enough for a three-person shop and address at least two of the gaps: how plugin updates happen (for example turning off automatic updates, or updating only when someone can test), checking checkout works after any update, and some way to notice when orders stop coming in",
+        "It is a short email to the two staff, under about 250 words, in plain language without technical jargon, delivered without asking for more information first"
+      ]
     }
   ]
 }

package/packs/sre-oncall/skills/postmortem-generator/evals/files/6/alerts.csv

@@ -0,0 +1,4 @@
+time_utc,alert,level,state,notes
+14:58,webhook-consumer queue depth > 50000,warning,firing,
+15:01,webhook-consumer queue depth > 50000,page,firing,paged on-call (Jonas)
+15:52,webhook-consumer queue depth > 50000,page,resolved,

package/packs/sre-oncall/skills/postmortem-generator/evals/files/6/incident-channel.txt

@@ -0,0 +1,27 @@
+Chat export, Thursday 8 October (times UTC)
+
+==== #support-escalations ====
+[14:31] Marta (Support): heads up, ticket 88213. Customer says their client paid an invoice by card about 20 min ago and it still shows "awaiting payment" in Quillmere. Anyone seen this?
+[14:44] Marta (Support): two more like it now (88219, 88224). Feels like a pattern?
+[14:52] Jonas (Eng): looking
+
+==== #deploys ====
+[14:07] deploybot: webhook-consumer deploy #4471 finished (config: consumer pool tuning), author tomasz, reviewer jonas
+
+==== #inc-0412 ====
+[15:02] Rhiannon: declaring incident. paid invoices not flipping to paid. queue depth alert firing on webhook-consumer.
+[15:06] Jonas: it's the DB failover from this morning, 100%. replica lag is making the status writes fail. seen this exact thing before.
+[15:09] Ade (VP Customer Success): how many customers are affected? I need an exact number and the £ value of the stuck invoices for the board update
+[15:12] Rhiannon: @Ade not known yet, we'll get you what we can
+[15:14] Jonas: hmm, replica lag is flat, under 1s all afternoon, and the status writes that do arrive are succeeding. so not the db. I was guessing, sorry
+[15:19] Kasia: consumer throughput dropped off a cliff at ~14:07. only 4 workers running, normally 40. deploy #4471 changed pool_size from 40 to 4
+[15:25] Rhiannon: ok that's it. rolling back #4471
+[15:31] deploybot: webhook-consumer rollback to #4470 started
+[15:47] deploybot: webhook-consumer rollback to #4470 finished
+[15:52] Kasia: throughput back to normal, 40 workers. backlog draining
+[15:58] Kasia: some Paygrove webhooks went to the dead-letter queue while the backlog was building (their retries timed out). don't know yet whether those payment updates were lost or will be replayed. looking.
+[16:03] Marta (Support): also the 15:00 payment reminder job ran, so some clients who'd already paid probably got a "your invoice is overdue" email. no idea how many yet
+[16:20] Kasia: backlog cleared
+[16:24] Jonas: open q for the review: the PR was reviewed (by me) and passed CI, but nothing in CI checks consumer config values. also we only alert on queue depth and the threshold is high, nothing on how long a payment takes to be processed
+[16:30] Ade (VP Customer Success): still need that customer number and £ figure please, even rough
+[16:41] Rhiannon: DLQ question still open, Kasia on it tomorrow. reminder count also open. closing incident as mitigated.

package/packs/sre-oncall/skills/postmortem-generator/evals/files/6/timeline.md

@@ -0,0 +1,21 @@
+# INC-0412: paid invoices not marked as paid
+
+Incident lead notes (Rhiannon). All times UTC, Thursday 8 October.
+
+- 14:07 config change to webhook-consumer goes out (Tomasz's PR "tune consumer pool")
+- 14:58 monitoring picked it up, queue depth alert
+- 15:02 I declared the incident, opened #inc-0412
+- 15:06 DB failover from this morning suspected
+- 15:19 Kasia spots worker count dropped
+- 15:25 decision to roll back #4471
+- 15:35 rollback complete, service restored
+- 16:20 backlog cleared
+- 16:41 closed as mitigated
+
+Detection: monitoring (queue depth alert).
+
+Root cause: Tomasz fat-fingered the pool size (40 -> 4) and pushed it to prod without testing. He broke it. Need to have a word with him about care with prod config.
+
+Impact: invoices paid by card or bank transfer through Paygrove stayed "awaiting payment" in Quillmere until the backlog drained. Some customers' clients may have been sent overdue reminders.
+
+TODO for the write-up: Ade wants customer count and £ figure.

package/packs/sre-oncall/skills/postmortem-generator/manifest.json

@@ -1,11 +1,11 @@
 {
   "name": "postmortem-generator",
-  "version": "0.1.2",
-  "description": "Generate a blameless incident postmortem from raw material (Slack thread, pager timeline, notes) — quantified impact, UTC timeline with detection/mitigation gaps, contributing factors instead of a single root cause, and ≤8 verifiable action items. Use after an incident or outage when the user needs a postmortem, RCA, incident review, or \"lessons learned\" doc.",
+  "version": "0.2.0",
+  "description": "Write a blameless incident postmortem from the raw material (chat scrollback, alert history, timeline, notes) for the audience and length the user names — the cause stated as the change and the gap that let it through, never a person even when the notes name one; who or what noticed first and how late; known kept apart from still-unknown; and follow-up actions that close the gap. Invents no times, figures, owners or severities. Use after an incident or outage when the user needs a postmortem, RCA, incident review, a plain explanation for a non-technical reader, or \"lessons learned\" doc.",
   "entrypoint": "SKILL.md",
   "deps": { "npm": [], "pip": [] },
   "env": { "required": [], "optional": [] },
-  "related": ["runbook-generator"],
+  "related": ["incident-comms", "runbook-generator"],
   "handoff": [
     { "to": "runbook-generator", "when": "the postmortem produced runbook deltas", "purpose": "Apply the deltas as edits to the existing runbook.", "fallback": "If runbook-generator is absent, phrase each delta as a concrete before/after edit so a human can apply it." }
   ],

package/packs/sre-oncall/skills/postmortem-generator/templates/postmortem.md

@@ -1,67 +1,53 @@
-# Postmortem template
+# Full incident review
 
-Summary first — it's the only section most readers finish. All timestamps UTC. Unknowns get `[missing]`, never prose camouflage.
+For when the user asks for a full postmortem or an incident-review meeting doc. Leave out any
+section the material has nothing for; never fill one with a placeholder. List what is still
+unknown after the document, not inside it.
 
 ```markdown
-# Postmortem: {one-line incident title, symptom-first — "Checkout 500s for EU users", not "Config issue"}
+# Incident review: {symptom-first title — "Checkout failures for EU customers", not "Config issue"}
 
-**Status:** draft | reviewed | actions-tracked
-**Severity:** SEV{1–4} · **Date:** {YYYY-MM-DD} · **Author role:** {e.g. incident commander}
+{Date} · {who it is for, if the user said}
 
 ## Summary
 
-{3–5 sentences a director can repeat: what broke for whom, for how long, why in one
-clause, and the headline fix. No jargon that needs the timeline to decode.}
+{3–5 sentences someone can repeat: what broke for whom, for how long, why in one clause,
+how it was found, and the main change being made.}
 
 ## Impact
 
-| Measure | Value |
-|---|---|
-| Duration (impact start → end) | {Xh Ym} |
-| Users / customers affected | {number or %, or [missing]} |
-| Requests failed / degraded | {number, or [missing]} |
-| SLO / error budget burn | {e.g. "34% of monthly budget", or [missing]} |
-| Revenue / contractual | {value, "none known", or [missing]} |
+{What users could not do, for how long, and any figures the material gives. If a figure was
+asked for and the material can't give it, say what it does show and what would settle it.}
 
-## Timeline (UTC)
+## Timeline ({timezone})
 
-| Time | Event | Source |
+| Time | What happened | Source |
 |---|---|---|
-| {hh:mm} | {impact begins — state change, not Slack chatter} | {alert/log/deploy} |
-| {hh:mm} | {first human aware} | {page/user report} |
-| {hh:mm} | {mitigation applied} | … |
+| {hh:mm} | {impact begins} | {alert / log / deploy / ticket} |
+| {hh:mm} | {first noticed, and by whom or what} | … |
+| {hh:mm} | {mitigation} | … |
 | {hh:mm} | {impact ends} | … |
 
-**Detection gap:** {impact start → first human aware} — {if users reported it before
-monitoring fired, say exactly that}
-**Mitigation gap:** {detection → impact end}
+**Found by:** {who or what noticed first; the gap to the first alert}
+**Time to fix:** {noticed → impact ended}
 
-## Contributing factors (2+; "human error" is not one)
+## Why it was possible
 
-1. **{Condition, not act}** — {why this made the incident possible/worse; the guardrail
-   that was absent or didn't fire}
-2. **{…}** — {…}
+1. **{Condition, not act}** — {why it made the incident possible or worse}
+2. {…only as many as the material shows}
 
-## What went well / poorly / where we got lucky
+**Still open:** {causes not yet confirmed}
 
-**Well:** {response behaviors worth repeating}
-**Poorly:** {response-side gaps — paging, comms, tooling — not the cause itself}
-**Lucky:** {mandatory — the near-miss: "happened at 3am low traffic", "the one engineer
-who knew X was awake", "rollback happened to be safe"}
+## What went well and what didn't
 
-## Action items (≤8)
+{Response-side only: paging, comms, tooling. Add "where we got lucky" if the material shows
+a near-miss.}
 
-| # | Action | Class | Owner (role) | Done when |
-|---|---|---|---|---|
-| 1 | {specific change} | prevent / detect / mitigate | {team or role} | {verifiable condition} |
+## Follow-ups
 
-**Considered, not taken:** {candidate} — {one line why not}
+- {What changes} — done when {how anyone could check}. Owner: {as given, or "no owner yet"}
 
-## Runbook deltas
+## Runbook changes
 
-- {Runbook section} → {the edit this incident proves necessary — paste-ready}
-
-## Open questions
-
-- {anything still [missing] that follow-up should resolve, with who can answer it}
+- {Runbook section} → {the edit this incident shows is needed}
 ```