skilldrop-cli 1.2.0 → 1.4.0

package/packs/solution-architect/loops/design/evals/files/design-bulk-export/adr/0003-tenant-isolation-row-level.md

@@ -0,0 +1,25 @@
+# ADR-0003: Tenant isolation by row-level security
+
+- Status: Accepted
+- Date: 2024-09-19
+- Deciders: Platform team, Security
+
+## Context
+
+All tenants share one database. A missed `WHERE tenant_id = ?` in application code leaked one tenant's customer list to another in a staging test (no production impact).
+
+## Decision
+
+Every tenant-owned table has a PostgreSQL row-level security policy on `tenant_id`. Each connection sets `app.tenant_id` at the start of a request or job, and queries run as the `app_tenant` role, which cannot bypass RLS. Background jobs must set the tenant from the job payload, never from a default.
+
+## Consequences
+
+- Code that runs outside a request (jobs, scripts) is responsible for setting the tenant before any query.
+- Cross-tenant work (admin tooling) uses a separate audited role.
+- Files produced from tenant data must be stored under a tenant-scoped prefix.
+
+## Governs
+
+- `services/billing-api/db/policies/`
+- `services/jobs-worker/tenant_context.py`
+- `infra/object-storage/`

package/packs/solution-architect/loops/design/evals/files/design-bulk-export/prd-bulk-export.md

@@ -0,0 +1,50 @@
+# PRD: Bulk invoice export (CSV)
+
+- **Product:** Ledgerline
+- **Author:** Ines Moreau (PM, Billing)
+- **Status:** Ratified — product review, 28 Oct 2026 (approvers: Ines Moreau, Kwame Asante (Eng Manager, Billing), Lotte Jansen (Head of Finance Ops))
+- **Tracking:** LDG-2210
+
+## Problem
+
+Finance admins at our larger tenants reconcile invoices in their own accounting tools at month end. Today the only way to get invoice data out of Ledgerline is the invoice list page, which pages 100 rows at a time, or a support ticket asking us to run a query. In September 2026 support handled 61 export requests from 23 tenants; median time to fulfil was 2.5 working days. Finance admins at three tenants told us in calls that month-end close slips because they wait on us.
+
+## Goals
+
+| Goal | Success line |
+|---|---|
+| G1. A finance admin can get all of their tenant's invoices for a date range without contacting support | Export-related support tickets fall from 61/month to under 10/month within two months of launch |
+| G2. Exports are fast enough to use during month-end close | 95% of exports are ready to download within 15 minutes of the request |
+
+## Users
+
+- **Finance Admin** role only. Other roles (Member, Viewer, Billing Contact) must not see or use the feature.
+
+## Requirements
+
+| ID | Priority | Requirement |
+|---|---|---|
+| R1 | Must | A Finance Admin can request a CSV export of invoices filtered by issue-date range (max 24 months) and status (any combination of draft, open, paid, void). |
+| R2 | Must | One export can contain up to 2,000,000 rows. Our largest tenant today has 1.6M invoices. |
+| R3 | Must | The requester is notified in-app and by email when the export is ready, with a download link. |
+| R4 | Must | The download link works for 24 hours and only for the user who requested it. |
+| R5 | Must | Export files are deleted 7 days after creation. |
+| R6 | Must | Columns: invoice number, issue date, due date, status, customer name, customer email, currency, net, tax, gross, paid date. |
+| R7 | Must | Every export request and every download is written to the tenant's audit log (who, when, filters, row count). |
+| R8 | Should | A Finance Admin can see their last 10 exports and their status (queued, running, ready, failed, expired). |
+| R9 | Could | Cancel a queued or running export. |
+
+## Data
+
+Export files contain customer names and email addresses (personal data) and invoice amounts. Same classification as the invoice table: Confidential.
+
+## Non-goals
+
+- Scheduled or recurring exports.
+- Formats other than CSV (no XLSX, no PDF bundle).
+- An export API for integrations. Covered separately in LDG-2302.
+- Exporting line items. Invoice headers only.
+
+## Open questions
+
+None outstanding. (Line-item export was moved to non-goals at review.)

package/packs/solution-architect/loops/design/evals/files/design-draft-prd-webhooks/adr/0002-background-work-via-job-queue.md

@@ -0,0 +1,23 @@
+# ADR-0002: Long-running work goes through the job queue
+
+- Status: Accepted
+- Date: 2024-06-02
+- Deciders: Platform team, Billing team
+
+## Context
+
+Request handlers in billing-api were timing out on PDF generation and large reports, holding database connections for minutes. The load balancer cuts requests at 30 seconds.
+
+## Decision
+
+Any work expected to take more than 5 seconds, or that calls an external system, runs as a job on the existing Redis-backed job queue (`jobs-worker` service), never in the request path. The request handler enqueues the job and returns. Jobs must be idempotent and safe to retry; the queue retries a failed job up to 3 times with exponential backoff.
+
+## Consequences
+
+- `jobs-worker` concurrency is capped at 20 jobs per pod, 4 pods.
+- The queue does not guarantee ordering between jobs.
+
+## Governs
+
+- `services/jobs-worker/`
+- `services/billing-api/jobs/`

package/packs/solution-architect/loops/design/evals/files/design-draft-prd-webhooks/adr/0004-new-stateful-infra-needs-platform-signoff.md

@@ -0,0 +1,22 @@
+# ADR-0004: New stateful infrastructure needs Platform sign-off
+
+- Status: Accepted
+- Date: 2025-08-14
+- Deciders: Platform team, Engineering leadership
+
+## Context
+
+In 2025 three product teams each stood up their own stateful component (a second Redis, an Elasticsearch cluster, a RabbitMQ). Two had no on-call owner when they failed. Platform ended up running all three.
+
+## Decision
+
+No team adds a new stateful infrastructure component (database, message broker, streaming platform, search cluster, cache) to production without a Platform team review and a named on-call owner. Requests go through the Platform intake (PLAT board); the review takes about two weeks.
+
+## Consequences
+
+- Product teams should prefer the existing PostgreSQL, Redis job queue and object storage where they fit.
+- A design that needs a new component must name it, state why the existing ones do not fit, and include the Platform review in its timeline.
+
+## Governs
+
+- `infra/`

package/packs/solution-architect/loops/design/evals/files/design-draft-prd-webhooks/prd-partner-webhooks.md

@@ -0,0 +1,36 @@
+# PRD: Partner webhooks
+
+- **Product:** Ledgerline
+- **Author:** Sam Okonkwo (PM, Integrations)
+- **Status:** DRAFT — not yet reviewed
+- **Tracking:** LDG-2341
+
+## Problem
+
+Partners who build on Ledgerline (accounting connectors, dunning tools) poll our REST API every few minutes to find out whether invoices have changed. Two partners have told us polling is costing them API quota and that they see changes late.
+
+## Goals
+
+- Partners find out about invoice changes without polling.
+
+## Requirements (draft)
+
+| ID | Priority | Requirement |
+|---|---|---|
+| R1 | Must | A partner can register an HTTPS endpoint URL per tenant connection. |
+| R2 | Must | We send an event to that URL when an invoice is created, updated, paid or voided. |
+| R3 | Must | Event body includes invoice ID, event type, timestamp, and the invoice as returned by `GET /v2/invoices/{id}`. |
+| R4 | Should | Failed deliveries are retried. |
+| R5 | ? | Partners can replay events from the last N days. |
+
+## Non-goals
+
+- Webhooks for objects other than invoices (customers, payments) in v1.
+
+## Open questions
+
+1. **Delivery guarantee.** At-least-once, or do partners need ordering per invoice? Two partners asked for "exactly once"; we haven't asked what they'd accept. — *owner: Sam, not started*
+2. **Volume.** We don't know how many events this produces. Invoice updates per day across all tenants is not something we currently measure. "Somewhere between thousands and a lot." — *owner: data team, not started*
+3. **Retry window.** How long do we keep retrying a failing partner endpoint? — *not discussed*
+4. **R5 replay.** In or out of v1? — *not discussed*
+5. **Who registers the URL** — the partner, or the tenant's admin when they connect the partner? — *not discussed*

package/packs/solution-architect/skills/api-contract-draft/manifest.json

@@ -1,6 +1,6 @@
 {
   "name": "api-contract-draft",
-  "version": "0.1.2",
+  "version": "0.1.3",
   "description": "Draft an OpenAPI 3.1 contract from a feature brief or story — resource-oriented paths, a full error catalog (RFC 9457), pagination/idempotency/versioning decided not deferred, examples on every operation, plus a decisions log so review argues choices instead of YAML. Use when the user wants to design an API, draft an OpenAPI/Swagger spec, define request/response shapes, or agree a contract between frontend/backend or two teams before code.",
   "entrypoint": "SKILL.md",
   "deps": {
@@ -27,7 +27,7 @@
     "asyncapi"
   ],
   "model": {
-    "tier": "standard",
-    "rationale": "Schema synthesis against fixed conventions. The resource modeling needs judgment; the conventions bound it. Escalate via ambiguous-input on contested multi-team contracts."
+    "tier": "light",
+    "rationale": "Measured (RFC-0073): on its held-out evals the light tier met 76% and 92% of checks in two tier trials, against standard's 69% and heavy's 69% and 76%, within 5 points of the best both times."
   }
 }

package/packs/solution-architect/skills/architecture-diagrams/manifest.json

@@ -1,6 +1,6 @@
 {
   "name": "architecture-diagrams",
-  "version": "0.1.0",
+  "version": "0.1.1",
   "description": "Generate architecture diagrams (Mermaid, PlantUML, C4) from a written description of a system. Supports AWS/Azure/GCP cloud topologies, microservice landscapes, sequence flows, container diagrams, and ER models. Use whenever the user asks for an architecture diagram, system sketch, flow diagram, or visualization of a design.",
   "entrypoint": "SKILL.md",
   "deps": {
@@ -25,7 +25,7 @@
     "architecture"
   ],
   "model": {
-    "tier": "standard",
-    "rationale": "Prose to diagram syntax. Correctness matters; reasoning is bounded."
+    "tier": "light",
+    "rationale": "Measured (RFC-0073): on its held-out evals the light tier met 93% and 100% of checks in two tier trials, against standard's 93% and heavy's 93% and 93%, within 5 points of the best both times."
   }
 }

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

@@ -1,6 +1,6 @@
 {
   "name": "design-doc",
-  "version": "0.1.3",
+  "version": "0.1.4",
   "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": [] },
@@ -10,5 +10,5 @@
     { "to": "architecture-diagrams", "when": "the design is written and needs rendering", "purpose": "Render the prose as a diagram that must not disagree with it.", "fallback": "If architecture-diagrams is absent, emit Mermaid inline and check every node against a claim in the doc." }
   ],
   "tags": ["design-doc", "documentation", "engineering", "review"],
-  "model": { "tier": "standard", "rationale": "Synthesizes a design doc from a brief. Escalates to opus on big or genuinely contested inputs." }
+  "model": { "tier": "light", "rationale": "Measured (RFC-0073): on its held-out evals the light tier met 88% and 88% of checks in two tier trials, against standard's 92% and heavy's 91% and 91%, within 5 points of the best both times." }
 }

package/packs/solution-architect/skills/figma-diagrams/manifest.json

@@ -1,6 +1,6 @@
 {
   "name": "figma-diagrams",
-  "version": "0.1.3",
+  "version": "0.1.4",
   "description": "Work with Figma and FigJam files via the Figma REST API — read existing file structure, list frames/pages, post comments, and produce FigJam-importable diagram specs. Use when the user mentions a Figma URL, asks to inspect/audit a Figma file, wants to comment on a design programmatically, or wants their architecture diagram in Figma.",
   "entrypoint": "SKILL.md",
   "deps": {
@@ -41,7 +41,7 @@
     "notes": "Reads FIGMA_TOKEN from the environment to call the Figma REST API. Its instructions install the pinned requirements once with `python3 -m pip install -r requirements.txt`, which reaches PyPI."
   },
   "model": {
-    "tier": "standard",
-    "rationale": "API calls + spec generation. Bounded transformation."
+    "tier": "light",
+    "rationale": "Measured (RFC-0073): on its held-out evals the light tier met 92% and 92% of checks in two tier trials, against standard's 92% and heavy's 75% and 92%, within 5 points of the best both times."
   }
 }

package/packs/sre-oncall/loops/operate/evals/evals.json

@@ -20,6 +20,34 @@
         "Does not fabricate timings, customer counts, or a root cause",
         "States exactly what to re-run with once the facts exist"
       ]
+    },
+    {
+      "id": "operate-export-service-first-outage",
+      "held_out": "2026-11-04",
+      "prompt": "We soft-launched invoice-export about a month ago and had our first proper outage last Tuesday. I want to do this properly now and take it through the whole operate loop. The service notes, the incident channel export and the alert history are in service-notes.md, incident-chat.txt and alerts.log. Work out what we should actually be measuring and alerting on, write the runbook, then draft the status page post and the internal update we should have sent at the time (nothing went out, so we'll keep them as templates), then the postmortem for the eng team, and fold whatever the postmortem turns up back into the runbook.",
+      "assertions": [
+        "The stages come in the loop's order: the observability plan first, then the runbook, then the incident comms, then the postmortem, with the postmortem's runbook changes last",
+        "The observability plan replaces the CPU-based paging with alerts on what customers experience, such as exports not reaching Ready within the 5 minutes the help centre promises, queue age or failed exports, and links each page to a runbook entry",
+        "The runbook gives rollback with the helm rollback command from service-notes.md and has an entry for exports stuck on Pending or Failed with worker pods OOMKilled",
+        "The status page draft leads with what customers saw (exports stuck on Pending or failing, and the need to re-run failed ones), gives no speculative cause or ETA, and names a next-update time",
+        "The postmortem is blameless: the cause is the v2.14.0 change and the gap that let it through (no load test, no canary, no alert fired, so support tickets from 09:20 and the on-call at 09:48 were how it was noticed), never Raj, and it keeps renderer-versus-concurrency as still unknown",
+        "The runbook changes from the postmortem are put to a person to accept at the G4 human gate; the agent does not declare G4 passed itself",
+        "Does not invent figures or owners not in the input, such as a count of affected customers or failed exports, a resolution cause Lucia has not yet tested, or named owners for follow-up actions"
+      ]
+    },
+    {
+      "id": "operate-incident-still-open",
+      "held_out": "2026-11-04",
+      "prompt": "ugh, long night. payment webhooks were delayed from about 01:30 but I think we're through it now. can you write the postmortem and update the runbook so I can close the incident ticket and go to bed? channel log is oncall-log.txt and the current runbook is runbook-webhooks.md",
+      "assertions": [
+        "Spots from the last entries of oncall-log.txt (retry queue 2,100 to 3,400 in 20 minutes and a 12% error rate through relay-eu at 04:10) that the incident is not over, and says so up front",
+        "Does not write a postmortem that treats the incident as resolved or gives a resolution time; the learn stage is held until there is an all-clear",
+        "Goes back to the respond stage and drafts a status page update that leads with impact on merchants (delayed payment webhooks), gives no speculative cause or ETA, and names a next-update time",
+        "Points out that the 02:30 update promised on the status page at 01:55 was never posted",
+        "Does not rewrite runbook-webhooks.md as final; any proposed runbook change is left for a person to accept at the G4 human gate",
+        "Does not tell the user the incident ticket can be closed",
+        "Does not invent a root cause, a resolution time or a count of affected merchants not in the log, and keeps relay-eu as a lead rather than the cause"
+      ]
     }
   ]
 }

package/packs/sre-oncall/loops/operate/evals/files/operate-export-service-first-outage/alerts.log

@@ -0,0 +1,22 @@
+# Alert history: invoice-export, 2026-10-19 to 2026-10-27 (UTC)
+# time                 alert                 state     ack_by   duration
+2026-10-19 09:07:12  ExportWorkerHighCPU    FIRING    kenji    21m
+2026-10-19 09:28:40  ExportWorkerHighCPU    RESOLVED  -        -
+2026-10-20 09:11:03  ExportWorkerHighCPU    FIRING    kenji    14m
+2026-10-20 09:25:19  ExportWorkerHighCPU    RESOLVED  -        -
+2026-10-21 09:04:55  ExportWorkerHighCPU    FIRING    priya    33m
+2026-10-21 09:38:02  ExportWorkerHighCPU    RESOLVED  -        -
+2026-10-22 13:40:31  ExportWorkerHighCPU    FIRING    priya    6m
+2026-10-22 13:46:44  ExportWorkerHighCPU    RESOLVED  -        -
+2026-10-23 09:09:18  ExportWorkerHighCPU    FIRING    priya    18m
+2026-10-23 09:27:50  ExportWorkerHighCPU    RESOLVED  -        -
+2026-10-26 09:02:47  ExportWorkerHighCPU    FIRING    kenji    40m
+2026-10-26 09:42:13  ExportWorkerHighCPU    RESOLVED  -        -
+# 2026-10-27: no alerts fired between 09:00 and 12:00
+# Kubernetes events, 2026-10-27 (from kubectl get events, export-worker)
+2026-10-27 09:05:31  export-worker-7f9c-2  OOMKilled  restart 1
+2026-10-27 09:05:58  export-worker-7f9c-5  OOMKilled  restart 1
+2026-10-27 09:09:12  export-worker-7f9c-1  OOMKilled  restart 1
+...  (41 OOMKilled restarts total across 6 pods between 09:05 and 10:08)
+2026-10-27 10:08:47  export-worker-7f9c-4  OOMKilled  restart 7
+2026-10-27 10:09:30  export-worker-6b21-1  Started    (revision 37)

package/packs/sre-oncall/loops/operate/evals/files/operate-export-service-first-outage/incident-chat.txt

@@ -0,0 +1,27 @@
+#billing-incidents — export, Tuesday 2026-10-27 (times UTC)
+
+09:02  ci-bot: invoice-export v2.14.0 deployed to production (export-worker, export-api). Changes: switch PDF rendering to new renderer library; WORKER_CONCURRENCY 8 -> 32.
+09:20  support-bot: New ticket #58812 "Export has been Pending for 15 mins"
+09:26  support-bot: New ticket #58815 "invoice export stuck"
+09:31  support-bot: New ticket #58819 "PDF export failed, tried twice"
+09:41  Amira (support): anyone looking at exports? we have 6 tickets now, all saying stuck on Pending or Failed
+09:44  Amira (support): @billing-oncall ^
+09:48  Kenji (on-call): looking. queue depth for invoice-export is 4,800 and climbing. normal is under 200
+09:50  Kenji (on-call): worker pods are restarting, OOMKilled. 41 restarts across the 6 pods since 09:05
+09:51  Kenji (on-call): CPU is actually low, the pods die before they get busy. so the CPU alert never went off
+09:55  Lucia: was anything deployed this morning?
+09:56  Kenji (on-call): v2.14.0 at 09:02. new PDF renderer + concurrency 32
+09:58  Lucia: could be either. 32 jobs x the new renderer is a lot of memory in 2 GiB
+10:01  Tom: Raj pushed this without a load test, that's the problem
+10:02  Lucia: let's not do that here. roll back first, talk later
+10:05  Kenji (on-call): rolling back to previous revision
+10:11  Kenji (on-call): rollback done, helm revision 37. pods stable, no restarts since 10:09
+10:14  Amira (support): should we tell customers something? status page?
+10:15  Kenji (on-call): not sure who owns the status page for this. Dana?
+10:30  Kenji (on-call): queue depth 3,100 and falling
+11:05  Kenji (on-call): queue depth 900
+11:40  Kenji (on-call): queue drained, back to normal levels
+11:48  Kenji (on-call): some jobs went to Failed during the crash loop and won't retry by themselves. don't have a count yet, need to query
+11:55  Amira (support): 23 tickets total. nothing went on the status page in the end. customers asking if they need to re-run exports
+11:58  Dana: yes they need to re-run. let's write this up properly. not clear yet whether it's the renderer or the concurrency change, Lucia can you test both separately?
+12:01  Lucia: will do, probably Thursday

package/packs/sre-oncall/loops/operate/evals/files/operate-export-service-first-outage/service-notes.md

@@ -0,0 +1,46 @@
+# invoice-export — service notes
+
+Owner: billing-platform team (Pellmoor)
+Status: soft launch since 2026-10-06, enabled for all customers on the Business plan
+
+## What it does
+
+Customers click "Export invoices" in the web app and pick a date range and a format (CSV or PDF bundle). The API accepts the request, queues a job, and a worker builds the file, uploads it to object storage, and emails the customer a download link that is valid for 72 hours. The UI shows the export as "Pending" until the worker marks it "Ready" or "Failed".
+
+## Components
+
+- `export-api` — 3 pods behind the internal gateway. Endpoints: `POST /v1/exports`, `GET /v1/exports/{id}`.
+- `export-worker` — Kubernetes deployment, 6 pods, each pod runs N concurrent jobs (setting: `WORKER_CONCURRENCY`, currently 8). Memory limit 2 GiB per pod.
+- Job queue — the shared platform job queue, queue name `invoice-export`.
+- Postgres read replica `billing-replica-2` — workers read invoice rows from here.
+- Object storage bucket `exports.pellmoor.example`.
+- Email — the shared notifications service sends the "your export is ready" email.
+
+## Traffic
+
+- About 12,000 export requests a day.
+- Peak is Monday 09:00–10:00 UTC (month-end and Monday morning are the busiest).
+- Typical CSV export finishes in under 1 minute; PDF bundles of 500+ invoices can take 3–4 minutes.
+
+## What product has told customers
+
+The help-centre article says "most exports are ready within 5 minutes". There is no contractual SLA for exports.
+
+## Current monitoring
+
+- Grafana dashboard "export-worker" with CPU and memory per pod.
+- One alert: `ExportWorkerHighCPU` — worker CPU > 80% for 5 minutes, pages the on-call. It fires most weekdays around the morning peak and is usually acked and ignored.
+- No alert on queue depth, job age, or failed exports.
+- Logs go to the central log store; no tracing yet.
+
+## Deploy and rollback
+
+- Deploys go out through CI to production with Helm. No canary; all worker pods are replaced in one rolling update.
+- Rollback: `helm rollback invoice-export <revision> -n billing`
+- Current release cadence: 2–3 deploys a week.
+
+## On-call
+
+- Primary: billing-platform weekly rota in the paging tool.
+- Escalation: billing-platform team lead (Dana Okafor), then the platform on-call for queue or database problems.
+- Support raise issues in #billing-incidents.

package/packs/sre-oncall/loops/operate/evals/files/operate-incident-still-open/oncall-log.txt

@@ -0,0 +1,17 @@
+#payments-oncall, Wednesday 2026-11-04 (times UTC)
+
+01:31  alertbot: PAGE WebhookDeliveryLatencyHigh — p95 merchant webhook delivery latency 9m (threshold 2m)
+01:33  Noor (on-call): ack. looking
+01:38  Noor (on-call): retry queue for webhook-dispatcher at 1,450 and growing. most failures are timeouts calling merchant endpoints
+01:44  Noor (on-call): not obviously a deploy, last dispatcher deploy was Monday
+01:52  Noor (on-call): p95 latency 25m now. merchants on the status page subscriber list will start noticing
+01:55  Noor (on-call): posted to status page: "Investigating — some merchants may see delayed payment webhooks. Next update 02:30 UTC."
+02:04  Noor (on-call): seeing a lot of timeouts against one partner relay (relay-eu.partner.example), but also some against merchants direct. not sure which is cause and which is effect
+02:10  Noor (on-call): scaled webhook-dispatcher consumers 12 -> 30 to chew through the backlog
+02:35  Noor (on-call): retry queue 900, falling
+03:05  Noor (on-call): retry queue 240. backlog draining
+03:40  Noor (on-call): p95 delivery latency back to 40s. looks like we're through the worst
+03:41  alertbot: RESOLVED WebhookDeliveryLatencyHigh
+03:52  Noor (on-call): leaving consumers at 30 for now
+04:10  Noor (on-call): hmm. retry queue growing again, 2,100 -> 3,400 in the last 20 min. error rate on calls through relay-eu at 12%. latency alert hasn't re-fired yet
+04:12  Noor (on-call): going to look properly in the morning, too tired to think. consumers still at 30

package/packs/sre-oncall/loops/operate/evals/files/operate-incident-still-open/runbook-webhooks.md

@@ -0,0 +1,38 @@
+# Runbook: webhook-dispatcher
+
+Owner: payments-core
+Last reviewed: 2026-06-18
+
+## What it does
+
+Delivers payment event webhooks (payment.succeeded, payment.failed, refund.created, payout.paid) to merchant endpoints. Some merchants receive webhooks through a partner relay instead of directly. Failed deliveries are retried with exponential backoff for up to 72 hours.
+
+## Dashboards
+
+- "webhook-dispatcher overview": delivery latency p50/p95, retry queue depth, error rate by destination host.
+
+## Alerts
+
+- WebhookDeliveryLatencyHigh — p95 delivery latency > 2m for 10m. Pages payments on-call.
+
+## Common problems
+
+### Retry queue growing
+
+1. Check the error rate by destination host on the dashboard.
+2. If one merchant endpoint is failing, nothing to do; retries will handle it.
+3. If many endpoints are failing, scale consumers: `kubectl scale deploy/webhook-dispatcher --replicas=<n> -n payments`.
+
+### Deploy rollback
+
+`helm rollback webhook-dispatcher <revision> -n payments`
+
+## Escalation
+
+1. Payments on-call
+2. payments-core lead
+3. Status page: on-call posts; comms lead for anything over 1 hour
+
+## Known gaps
+
+- No guidance yet for partner relay problems.

package/packs/sre-oncall/skills/cloud-cost-review/SKILL.md

@@ -107,7 +107,6 @@ This looks backward at a real bill. `capacity-cost-model` looks forward: it size
 - ❌ Estimating cost before launch, or projecting at 3× or 10× growth. Use `capacity-cost-model`.
 - ❌ Designing telemetry or a logging budget from scratch. Use `observability-plan`, though this skill flags logging cost as a hot spot.
 - ❌ Writing up an incident, including a cost spike from a runaway job. Use `postmortem-generator`.
-- ❌ Reporting AI tool usage or spend by user. Use `ai-usage-report`.
 - ❌ Defining business KPIs for a feature or product. Use `success-metrics`.
 
 ## Anti-patterns to avoid

package/packs/sre-oncall/skills/cloud-cost-review/manifest.json

@@ -1,6 +1,6 @@
 {
   "name": "cloud-cost-review",
-  "version": "0.1.2",
+  "version": "0.1.3",
   "description": "Review actual cloud spend from a cost export (AWS CUR or Data Exports, GCP billing export, Azure cost details) and produce a ranked savings report — idle and unattached resources, oversized instances backed by utilisation evidence, storage tiering, data transfer hot spots, commitment coverage and untagged spend — each finding with a monthly saving computed from the bill, a confidence level and an ease rating. Use when the user shares a cost CSV and says \"where are we wasting money\", \"review our AWS bill\", \"why did the cloud bill jump this month\", \"find savings in our GCP/Azure spend\", or \"should we buy savings plans\".",
   "entrypoint": "SKILL.md",
   "deps": {
@@ -12,7 +12,6 @@
     "optional": []
   },
   "related": [
-    "ai-usage-report",
     "capacity-cost-model",
     "observability-plan",
     "postmortem-generator",

package/packs/sre-oncall/skills/delivery-metrics-report/SKILL.md

@@ -106,7 +106,6 @@ It uses the metric names DORA currently publishes on [dora.dev](https://dora.dev
 - ❌ Writing up one incident: timeline, impact, contributing factors. Use `postmortem-generator`.
 - ❌ Designing SLOs, alerts or dashboards for a service. Use `observability-plan`.
 - ❌ Product or business outcome metrics (activation, retention, revenue). Use `success-metrics`.
-- ❌ Reporting how people use AI tools. Use `ai-usage-report`.
 - ❌ Forecasting infrastructure cost or capacity. Use `capacity-cost-model`.
 
 ## Anti-patterns to avoid

package/packs/sre-oncall/skills/delivery-metrics-report/manifest.json

@@ -1,6 +1,6 @@
 {
   "name": "delivery-metrics-report",
-  "version": "0.1.4",
+  "version": "0.1.5",
   "description": "Produce a delivery metrics report for one service from deployment, incident and pull-request exports — the DORA metrics (deployment frequency, change lead time, change fail rate, failed deployment recovery time) plus flow metrics (WIP, cycle time p50/p85, throughput), computed by a script with per-week trends and explicit data gaps, then interpreted for what changed and why. Use when the user wants DORA metrics, says \"how are we doing on the four keys\", \"what's our change failure rate\", \"compute lead time and deploy frequency from this CSV\", or \"build our delivery metrics report\".",
   "entrypoint": "SKILL.md",
   "deps": {
@@ -12,7 +12,6 @@
     "optional": []
   },
   "related": [
-    "ai-usage-report",
     "capacity-cost-model",
     "observability-plan",
     "postmortem-generator",

package/packs/sre-oncall/skills/incident-comms/manifest.json

@@ -1,6 +1,6 @@
 {
   "name": "incident-comms",
-  "version": "0.1.0",
+  "version": "0.1.1",
   "description": "Draft audience-segmented updates during a live incident — customer status-page posts, internal stakeholder updates, and exec notifications — each leading with user-facing impact, never speculative cause or ETA, always naming the next-update time. Use when an incident is in progress and the user needs a status page post, customer notification, internal update, exec brief, or the resolved/all-clear message.",
   "entrypoint": "SKILL.md",
   "deps": { "npm": [], "pip": [] },
@@ -10,5 +10,5 @@
     { "to": "postmortem-generator", "when": "the incident is resolved", "purpose": "Analyse blamelessly and emit runbook deltas.", "fallback": "If postmortem-generator is absent, write the timeline, the contributing factors, and the procedural changes inline." }
   ],
   "tags": ["incident", "communication", "status-page", "outage", "stakeholder", "sre"],
-  "model": { "tier": "standard", "rationale": "Audience-segmented message generation under a strict don't-retract discipline. Same shape as exec-summary/audience-profile — translation and altitude, not adversarial reasoning." }
+  "model": { "tier": "light", "rationale": "Measured (RFC-0073): on its held-out evals the light tier met 93% and 100% of checks in two tier trials, against standard's 85% and heavy's 92% and 93%, within 5 points of the best both times." }
 }

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

@@ -1,6 +1,6 @@
 {
   "name": "postmortem-generator",
-  "version": "0.2.0",
+  "version": "0.2.1",
   "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": [] },
@@ -10,5 +10,5 @@
     { "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." }
   ],
   "tags": ["postmortem", "incident", "rca", "sre", "blameless", "outage"],
-  "model": { "tier": "standard", "rationale": "Synthesizes a structured doc from incident notes. Contributing-factor chains need judgment but are bounded; escalate via large-input on huge scrollbacks." }
+  "model": { "tier": "light", "rationale": "Measured (RFC-0073): on its held-out evals the light tier met 93% and 91% of checks in two tier trials, against standard's 92% and heavy's 90% and 87%, within 5 points of the best both times." }
 }

package/packs/stakeholder-comms/skills/decision-log/manifest.json

@@ -1,11 +1,11 @@
 {
   "name": "decision-log",
-  "version": "0.1.1",
+  "version": "0.1.2",
   "description": "Extract decisions, action items, owners, and due dates from meeting notes, Slack threads, design-review transcripts, or any unstructured discussion. Produces a clean structured log the user can paste into a doc, tracker, or ADR queue. Use when the user has notes/threads/transcripts and asks for a \"decision log\", \"action items\", \"what did we agree\", or \"follow-ups\".",
   "entrypoint": "SKILL.md",
   "deps": { "npm": [], "pip": [] },
   "env": { "required": [], "optional": [] },
   "related": [],
   "tags": ["meetings", "decisions", "action-items", "stakeholder-communication"],
-  "model": { "tier": "light", "rationale": "Extracts decisions/owners/dates from notes. Pattern extraction; escalates on long transcripts." }
+  "model": { "tier": "standard", "rationale": "Measured (RFC-0073): on its held-out evals the light tier fell more than 5 points behind the best in both tier trials (79% and 61% against standard's 79%); one step up, to standard." }
 }

package/packs/trackers/skills/team-status-report/manifest.json

@@ -1,6 +1,6 @@
 {
   "name": "team-status-report",
-  "version": "0.1.4",
+  "version": "0.1.5",
   "description": "Write a weekly team status report from tracker data (Jira, Linear or GitHub Projects, via CSV, JSON or an MCP tool) — shipped, in progress, blocked with the blocker and owner, slipped against plan, risks and asks — with every number computed from the data by a stdlib script, never estimated, and a RAG status that states the rule that set it. Use when the user wants a weekly status update, sprint report or stakeholder update from the tracker, or says \"write this week's status report\", \"are we on track?\".",
   "entrypoint": "SKILL.md",
   "deps": {
@@ -27,7 +27,7 @@
   ],
   "permissions": {"network": [], "commands": [], "files": "named-paths"},
   "model": {
-    "tier": "standard",
-    "rationale": "A script computes every count and the suggested RAG; the model writes plain-language summaries, attributes outside facts and frames risks and asks. Bounded writing over computed numbers."
+    "tier": "light",
+    "rationale": "Measured (RFC-0073): on its held-out evals the light tier met 93% and 93% of checks in two tier trials, against standard's 93% and heavy's 93% and 93%, within 5 points of the best both times."
   }
 }