skilldrop-cli 0.16.35 → 0.16.37

package/packs/solution-architect/skills/event-contract-draft/templates/asyncapi-skeleton.json

@@ -0,0 +1,144 @@
+{
+  "asyncapi": "3.0.0",
+  "info": {
+    "title": "Billing events",
+    "version": "1.0.0",
+    "description": "Events the billing service publishes about invoices.\n\nConsumers must: (1) deduplicate on eventId, because delivery is at-least-once; (2) ignore fields they do not recognise; (3) drop an event whose invoiceRevision is lower than the last one applied for that invoice; (4) never depend on order across different invoices.\n\nVersioning: within a version only optional fields are added. A breaking change (rename, removal, type or meaning change, a new required field) ships as a new event version on a new channel, published alongside the old one until the old one's x-sunset date."
+  },
+  "defaultContentType": "application/json",
+  "servers": {
+    "production": {
+      "host": "kafka.example.internal:9092",
+      "protocol": "kafka",
+      "description": "Placeholder host; replace with the real bootstrap servers."
+    }
+  },
+  "channels": {
+    "invoiceLifecycleV1": {
+      "address": "billing.invoice-lifecycle.v1",
+      "description": "Every state change of an invoice, in the order it happened for that invoice.",
+      "x-partition-key": "invoiceId",
+      "x-ordering": "Ordered per invoiceId: all events for one invoice arrive in the order billing published them. No order across invoices and no global order. Retries can redeliver an earlier event; consumers compare invoiceRevision.",
+      "x-delivery": "at-least-once; duplicates happen on producer retry and consumer rebalance",
+      "x-retention": "7 days",
+      "x-replay": "Consumers can reset their offset to any point inside the retention window.",
+      "x-dead-letter": "A consumer moves a message it cannot process after 5 attempts to <consumer>.billing.invoice-lifecycle.v1.dlq; the consuming team owns and watches its own DLQ.",
+      "messages": {
+        "InvoiceIssued": { "$ref": "#/components/messages/InvoiceIssued" },
+        "InvoicePaid": { "$ref": "#/components/messages/InvoicePaid" }
+      }
+    }
+  },
+  "operations": {
+    "publishInvoiceLifecycle": {
+      "action": "send",
+      "channel": { "$ref": "#/channels/invoiceLifecycleV1" },
+      "messages": [
+        { "$ref": "#/channels/invoiceLifecycleV1/messages/InvoiceIssued" },
+        { "$ref": "#/channels/invoiceLifecycleV1/messages/InvoicePaid" }
+      ]
+    }
+  },
+  "components": {
+    "messages": {
+      "InvoiceIssued": {
+        "name": "InvoiceIssued",
+        "title": "Invoice issued",
+        "summary": "An invoice was issued to a customer.",
+        "description": "Event-carried state: the full invoice as issued, so consumers need no call back to billing.",
+        "x-event-style": "event-carried-state",
+        "bindings": { "kafka": { "key": { "type": "string", "description": "invoiceId" } } },
+        "payload": {
+          "allOf": [
+            { "$ref": "#/components/schemas/Envelope" },
+            {
+              "type": "object",
+              "required": ["data"],
+              "properties": {
+                "eventType": { "type": "string", "const": "InvoiceIssued" },
+                "data": { "$ref": "#/components/schemas/InvoiceIssuedData" }
+              }
+            }
+          ]
+        },
+        "examples": [
+          {
+            "name": "issued",
+            "payload": {
+              "eventId": "5b0c6f4e-2a91-4f3e-9d7c-1e8a2b3c4d5e",
+              "eventType": "InvoiceIssued",
+              "eventVersion": 1,
+              "occurredAt": "2026-10-19T14:03:11Z",
+              "producer": "billing-service",
+              "correlationId": "c2f1a9d0-7b3e-4c55-8a10-2d9e6f7a8b90",
+              "causationId": "0d4e8f12-6a7b-4c3d-9e2f-1a0b9c8d7e6f",
+              "data": {
+                "invoiceId": "inv_4T7Q",
+                "invoiceRevision": 1,
+                "customerId": "cus_31F8",
+                "totalMinor": 4250,
+                "currency": "GBP"
+              }
+            }
+          }
+        ]
+      },
+      "InvoicePaid": {
+        "name": "InvoicePaid",
+        "title": "Invoice paid",
+        "summary": "An invoice was paid in full.",
+        "description": "Notification: ids and the amount paid only; fetch the invoice from the billing API for anything else.",
+        "x-event-style": "notification",
+        "bindings": { "kafka": { "key": { "type": "string", "description": "invoiceId" } } },
+        "payload": {
+          "allOf": [
+            { "$ref": "#/components/schemas/Envelope" },
+            {
+              "type": "object",
+              "required": ["data"],
+              "properties": {
+                "eventType": { "type": "string", "const": "InvoicePaid" },
+                "data": {
+                  "type": "object",
+                  "required": ["invoiceId", "invoiceRevision", "paidMinor", "currency"],
+                  "properties": {
+                    "invoiceId": { "type": "string" },
+                    "invoiceRevision": { "type": "integer", "minimum": 1, "description": "Increases by 1 on every change to this invoice." },
+                    "paidMinor": { "type": "integer", "minimum": 0, "description": "Amount paid in minor units (pence)." },
+                    "currency": { "type": "string", "pattern": "^[A-Z]{3}$" }
+                  }
+                }
+              }
+            }
+          ]
+        }
+      }
+    },
+    "schemas": {
+      "Envelope": {
+        "type": "object",
+        "required": ["eventId", "eventType", "eventVersion", "occurredAt", "producer", "correlationId"],
+        "properties": {
+          "eventId": { "type": "string", "format": "uuid", "description": "Unique per event; the same on every redelivery. Consumers deduplicate on it." },
+          "eventType": { "type": "string", "description": "Past-tense event name; one per message schema." },
+          "eventVersion": { "type": "integer", "minimum": 1, "description": "Major version of this event type's schema." },
+          "occurredAt": { "type": "string", "format": "date-time", "description": "When the fact happened, UTC, RFC 3339 with Z." },
+          "producer": { "type": "string", "description": "The service that owns the fact." },
+          "correlationId": { "type": "string", "description": "Shared by every event and request in one business flow." },
+          "causationId": { "type": "string", "description": "eventId (or request id) of what directly caused this event." }
+        }
+      },
+      "InvoiceIssuedData": {
+        "type": "object",
+        "required": ["invoiceId", "invoiceRevision", "customerId", "totalMinor", "currency"],
+        "properties": {
+          "invoiceId": { "type": "string" },
+          "invoiceRevision": { "type": "integer", "minimum": 1, "description": "Increases by 1 on every change to this invoice." },
+          "customerId": { "type": "string", "description": "Opaque id; no name or contact details on the event." },
+          "totalMinor": { "type": "integer", "minimum": 0, "description": "Invoice total in minor units (pence)." },
+          "currency": { "type": "string", "pattern": "^[A-Z]{3}$" }
+        }
+      }
+    }
+  }
+}

package/packs/sre-oncall/skills/slo-spec/SKILL.md

@@ -0,0 +1,161 @@
+---
+name: slo-spec
+description: Define service level objectives for a service from its critical user journeys — each SLI a good-events / valid-events ratio with both sides defined and measured where the user feels it, a target set from user need and history (checked against dependency SLOs), the error budget computed in minutes and bad requests at current traffic, multi-window burn-rate alerts with the budget consumed when each fires, low-traffic handling, and an error-budget policy with owners. Use when the user asks to "define SLOs", "write our SLIs", "how much error budget do we have", "what burn-rate alerts should page", "is 99.99% realistic", or "write an error-budget policy".
+---
+
+# slo-spec
+
+Turns a service's user journeys into SLOs a team can defend: what counts as a good and a valid
+event, the target and window, the budget in real units, the alerts that fire on it, and what
+the team does when it's spent. This is the reliability contract. The wider set of
+non-functional targets for a design is `nfr-spec`; what to instrument, log and trace and which
+dashboards to build is `observability-plan`; the procedure on-call follows when an alert fires
+is `runbook-generator`; DORA delivery metrics are `delivery-metrics-report`.
+
+## 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:** Every budget, threshold and alert number is computed, never estimated, and shown in real units (minutes, bad requests). A target that can't be met — above a dependency's SLO, or measured where it can't see the user's wait — is said in the first lines, not in a footnote.
+
+1. **Start from 2–4 critical user journeys, not from the metrics that exist.** A journey is
+   something a user does and would complain about losing: ✅ *"place an order and see it
+   confirmed"* — ❌ *"order-worker latency"*, ❌ *"CPU < 80%"*. Rank by what an outage costs the
+   user. Everything past four is a dashboard, not an SLO. An internal or staff-only journey
+   still counts if people depend on it, but gets its own target and alerting (step 6).
+
+2. **Write each SLI as good events / valid events, with both sides defined.** Name the
+   request set, what makes one *valid*, and what makes one *good*:
+   - ✅ *"Valid: `POST /bookings` from customers, excluding 4xx validation errors and synthetic
+     test bookings. Good: reaches 'confirmed' or 'declined by bank' within 20 s of the request
+     arriving at the load balancer."*
+   - ❌ *"Checkout availability: 99.9%"* — of what? A card decline is a correct outcome, not a
+     failure; a 429 we caused is a failure, not an exclusion.
+   Latency SLIs are a threshold count (✅ *"% of searches answered in < 800 ms"*), never an
+   average or "p99 = X". An asynchronous journey is good only when the user sees the outcome,
+   so the SLI spans submit → result, not the accepting `202`.
+
+3. **Measure as close to the user as possible.** Prefer, in order: client / real-user beacon,
+   load balancer or edge, then the app. Reject a timer that can't see queueing:
+   ✅ *"from LB request timestamp to the confirmation event"* — ❌ *"worker process time"* when
+   orders wait in a queue first (the worker shows 200 ms while customers wait 90 s). If
+   the input shows a measured SLI disagreeing with what users reported, that is the finding:
+   lead with it. Name what the chosen point still misses (client-side failures for an LB SLI).
+
+4. **Set targets from what users need and from history — never 100%, never five nines by
+   default.** Start at or slightly below what the journey achieved over the last 1–3 months
+   when users weren't complaining; tighten only with a reason. History measured at the wrong
+   point (the accepting response, not the outcome) overstates the journey: say so and mark the
+   target provisional until a month of the new SLI exists. Check every hard dependency the journey calls
+   synchronously: a target above the product of their SLOs is **not achievable without
+   redundancy** (a second provider, a cache, a queue-and-retry fallback) — say so and name the
+   redundancy it would take. ✅ *"99.99% isn't reachable while every booking needs the card
+   processor at 99.9%; the processor alone would spend 10× the budget."* — ❌ quietly writing
+   99.99%. A target equal to a dependency's SLO leaves nothing for the service's own failures; flag that too.
+   Default window: 30 days rolling `[assumption]` unless the team reviews on another cadence.
+
+5. **Compute the error budget in real units — run the script, don't estimate.**
+
+   ```bash
+   # Claude Code
+   python3 "${CLAUDE_SKILL_DIR}/scripts/slo_math.py" --target 99.9 --window 30 --rpd 1000000 --dep 99.95
+   # Other IDEs (from the skill folder)
+   python3 scripts/slo_math.py --target 99.9 --window 30 --rpd 1000000 --dep 99.95
+   # Price a past outage against the budget: --outage 40 (minutes, repeatable)
+   # Several SLOs at once: a JSON list (shape in the script header), or - for stdin
+   python3 scripts/slo_math.py --batch slos.json --json
+   ```
+
+   It prints the budget as minutes of full outage and as bad requests per window at the given
+   traffic, the alert table, the dependency ceiling, the share a given outage spends, and
+   flags. ✅ *"99.9% over 30 days = 43.2
+   minutes, or 30,000 failed requests at 1,000,000 a day."* — ❌ *"about 40 minutes a month."* Use
+   average traffic and say so; peak hours burn budget faster than the minutes suggest. If no
+   script can run, do the arithmetic in the reply and show it (formulas in
+   [`reference.md`](reference.md)).
+
+6. **Alert on burn rate, not on raw error rate.** Default to the multi-window, multi-burn-rate
+   set: 14.4× over 1 h with a 5 m short window → page (2% of a 30-day budget gone); 6× over 6 h
+   with 30 m → page (5%); 1× over 3 d with 6 h → ticket (10%). Both windows must breach. Every
+   row states the error rate that trips it, the budget consumed when it fires and the time to
+   exhaustion, from the script. ❌ *"Page if error rate > 1% for 5 minutes"* — it pages on a blip
+   that costs 0.1% of the budget and stays quiet through a slow burn that spends all of it.
+   If the window isn't 30 days, keep the burn rates and report the consumed share the script
+   gives; don't pretend 14.4× still means exactly 2%.
+
+7. **Low-traffic journeys: say the ratio is noisy, then change the method.** When the script
+   flags a window with fewer than ~10 expected bad events, an alert there fires on two
+   failures. Pick one and say why: a longer SLO window (90 days), longer alert windows, a
+   synthetic probe at a fixed rate that sets the event count, or ticket-only alerting in the
+   hours people use it. ✅ *"Back-office API: 800 requests/day gives 0.48 bad requests in the 1 h
+   window — a page would fire on one error. Ticket on 3 failures in 6 h during office hours
+   and add a probe every minute."* — ❌ copying the paging set from the busy journeys.
+
+8. **Write the error-budget policy with owners, agreed in advance.** It says what changes at
+   each budget level and who decides: ✅ *"Budget spent: release freeze except fixes and
+   security patches; the next sprint's top item is the largest budget consumer; owner — the
+   team's engineering lead; exception — the head of engineering signs a written exception."*
+   Include: thresholds (e.g. 50% spent in the first half of the window → reliability work
+   jumps the queue; 100% → freeze), what's exempt, what happens when a dependency spent the
+   budget (escalate to its owner; the freeze still covers risky changes), and when it's
+   reviewed. Owners are roles or names from the input; never invent a person.
+
+9. **Write it up with [`templates/slo-spec.md`](templates/slo-spec.md)** — the findings first
+   (unachievable targets, wrong measurement point, noisy journeys), then per journey: SLI
+   with good/valid definitions and measurement point, target and window, budget in minutes
+   and requests, alert table, then the policy. For a chat question ("how much budget is
+   99.95%?") answer in a few lines with the numbers and one alert table; no document.
+
+**Non-interactive runs** (subagent, CI, headless): a missing window becomes 30 days rolling,
+a missing target becomes one set from the stated history, and missing traffic leaves the
+budget in minutes only — each tagged `[assumption]` and listed first. If the input names no
+service, journey or user-facing behaviour at all, emit `BLOCKED: need the service and what its
+users do with it`, because SLIs invented without journeys measure nothing.
+
+## Useful references in this skill
+
+- [`reference.md`](reference.md) — SLI menu by journey type, measurement points and what each misses, valid-event exclusions, budget and burn-rate formulas, dependency ceilings, low-traffic options, and a policy skeleton
+- [`templates/slo-spec.md`](templates/slo-spec.md) — the write-up skeleton
+- [`scripts/slo_math.py`](scripts/slo_math.py) — budget in minutes and requests, burn-rate alert table, noise and dependency flags (stdlib only, `--json`)
+- [`examples/ticket-booking.md`](examples/ticket-booking.md) — worked example with real script output
+
+## Quality bar
+
+- **2–4 journeys, each with an SLI written as good / valid events,** both sides defined, including what's excluded from valid.
+- **The measurement point is named and can see what the user waits for** — including queue time on async paths.
+- **No target is 100%, none is five nines without a reason in the input,** and none sits above the hard dependencies' combined SLO without naming the redundancy it needs.
+- **Every budget is in minutes and bad requests at stated traffic,** matching the script output.
+- **Alerts are burn-rate rows with long and short windows,** each with the trip rate, the budget consumed at fire and the time to exhaustion.
+- **Low-traffic journeys are flagged with the count that makes them noisy** and get a different method, with the reason.
+- **The policy names owners, thresholds, the freeze rule, the exception route and the dependency case.**
+- **Nothing in it is invented:** traffic, history, dependency SLOs and people all come from the input or are tagged `[assumption]`.
+
+## When to use this skill
+
+- ✅ "Define SLOs / SLIs for this service" from a description of what users do
+- ✅ "How much error budget is 99.9% over 28 days at our traffic?"
+- ✅ "What burn-rate alerts should page us?" or "is our error-rate alert right?"
+- ✅ "Is 99.99% realistic for checkout?" — target pushback against history and dependencies
+- ✅ "Write our error-budget policy"
+
+## When NOT to use this skill
+
+- ❌ The full set of non-functional targets for a design — latency, durability, privacy, cost — that's `nfr-spec`
+- ❌ What to instrument, metrics/logs/traces split, cardinality, dashboards — that's `observability-plan`
+- ❌ The step-by-step procedure when an alert fires — that's `runbook-generator`
+- ❌ Deployment frequency, change fail rate, lead time — that's `delivery-metrics-report`
+
+## Anti-patterns to avoid
+
+- ❌ **Metrics-first SLIs.** Starting from what Prometheus already has and calling CPU, pod restarts or worker time an SLO.
+- ❌ **The SLI behind the queue.** An app or worker timer that starts after the request waited, so the SLO stays green while users stare at a spinner.
+- ❌ **Undefined "valid".** Counting card declines and bot traffic as failures, or dropping our own 429s and timeouts from the denominator.
+- ❌ **Nines by ambition.** 99.99% because "it's revenue", on top of a provider at 99.9%.
+- ❌ **"About 40 minutes".** A budget guessed, rounded, or given only as a percentage.
+- ❌ **Raw error-rate paging.** "Error rate > 1% for 5 m" instead of burn rate over two windows.
+- ❌ **One alert set for every journey.** Paging rules copied onto an 800-request/day API, where one failure is an incident.
+- ❌ **A policy with no owner or exception route** — so the first time the budget runs out, the freeze is argued from scratch and dropped.

package/packs/sre-oncall/skills/slo-spec/evals/eval_queries.json

@@ -0,0 +1,38 @@
+[
+  {
+    "query": "Define SLOs for our checkout service: which SLIs, what targets, and the error budget",
+    "should_trigger": true
+  },
+  {
+    "query": "How much error budget is 99.9% over 28 days if we do 3 million requests a day?",
+    "should_trigger": true
+  },
+  {
+    "query": "What burn-rate alerts should page us for a 99.95% availability SLO?",
+    "should_trigger": true
+  },
+  {
+    "query": "Product wants 99.99% for the payments API. Is that realistic when our card processor only promises 99.9%?",
+    "should_trigger": true
+  },
+  {
+    "query": "Write an error-budget policy: what happens when our SLO budget runs out",
+    "should_trigger": true
+  },
+  {
+    "query": "List the non-functional requirements for the new booking feature: latency, availability, data retention, accessibility",
+    "should_trigger": false
+  },
+  {
+    "query": "What should we instrument in the order service, and which dashboards and log fields do we need?",
+    "should_trigger": false
+  },
+  {
+    "query": "Write the on-call runbook for the payments service, including rollback and escalation",
+    "should_trigger": false
+  },
+  {
+    "query": "Compute our change failure rate and deployment frequency from this deploy log",
+    "should_trigger": false
+  }
+]

package/packs/sre-oncall/skills/slo-spec/evals/evals.json

@@ -0,0 +1,75 @@
+{
+  "skill_name": "slo-spec",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "We need SLOs for our order service before the reliability review next week. Everything I know about it is in order-service.md: the journeys, traffic, what we measure today and the last 90 days. Give us SLIs, targets, error budgets, the alerts that should page, and an error-budget policy.",
+      "assertions": [
+        "Opens with the decisions and blockers in the first lines: that 99.99% for checkout is not achievable while every order depends on PayRail at 99.9%, and that the proposed worker timer cannot be the checkout SLI",
+        "Rejects order_worker_process_seconds as the checkout SLI because it starts after the queue wait, cites the 14 September backlog (about 3 minutes of queue wait while p99 stayed 400 ms) as the evidence, and measures checkout end to end from the load balancer request to the confirmation the customer sees",
+        "Defines every SLI as good events over valid events with both sides spelled out, including what is excluded from valid (for example card declines or 4xx validation errors), and does not use CPU, pod restarts or queue depth as an SLI",
+        "Sets a checkout target at or below 99.9% with the reason (PayRail's 99.9% SLO and the history), and says what redundancy or fallback a higher target would need",
+        "Gives each error budget in minutes and in bad requests at the stated traffic, and the numbers match the formulas (for example 99.9% over 30 days is 43.2 minutes, or 144,000 bad requests at 4,800,000 search requests a day)",
+        "Alerts use burn rate over a long and a short window (such as 14.4x over 1 h with 5 m, 6x over 6 h with 30 m, 1x over 3 d ticketing), each with the budget consumed when it fires, and none is a raw error-rate threshold",
+        "Treats the admin API as low traffic: shows that about 600 requests a day gives well under one expected bad request per alert window, and does not copy the customer paging set onto it (uses a longer window, a synthetic probe, or office-hours tickets, with the reason)",
+        "The error-budget policy names owners from the input (Priya Raman, Tom Okafor, Dana Whitlock) or roles, a release freeze except fixes when the budget is spent, and an exception route; it does not invent people, traffic figures, history or dependency SLOs that are not in the file"
+      ]
+    },
+    {
+      "id": 2,
+      "prompt": "Quick one: our API's SLO is 99.95% over 28 days and we do about 2 million requests a day. How much error budget is that, and what burn-rate alerts should page us? Right now we page whenever the error rate goes above 0.05% for 5 minutes.",
+      "assertions": [
+        "Answers in the first lines with the budget: 20.16 minutes of full outage and 28,000 bad requests per 28 days",
+        "Says the current rule (above 0.05% for 5 minutes) is a 1x burn over 5 minutes that pages on about 3–4 failed requests and a negligible share of the budget, and recommends replacing it",
+        "Recommends multi-window burn-rate alerts with long and short windows, two paging and one ticketing (for example 14.4x over 1 h with 5 m, 6x over 6 h with 30 m, 1x over 3 d with 6 h)",
+        "States for each alert the error rate that trips it (for example 0.72% for 14.4x) and the budget consumed when it fires, adjusted for the 28-day window (about 2.14%, 5.36% and 10.71%) rather than the 30-day 2/5/10%",
+        "Numbers are computed, not rounded guesses: no 'about 20 minutes' or 'roughly 30k'",
+        "Stays a short chat answer: no full SLO document, no error-budget policy section, no sections the question did not ask for",
+        "Does not invent journeys, dependencies, team names or traffic patterns not in the prompt"
+      ]
+    },
+    {
+      "id": 3,
+      "prompt": "Can you write our error-budget policy for catalogue-search? The status page is in search-slo-status.md. Our VP also wants to bump the target to 99.99% so the team takes it seriously; I'd like your view on that too.",
+      "assertions": [
+        "Opens by advising against 99.99% in plain words: the service missed 99.5% in both windows (about 99.3% and 99.43% achieved), and 99.99% shrinks the budget from 201.6 minutes / 168,000 bad requests to about 4 minutes / 3,360 bad requests per 28 days",
+        "Says the problem is that nothing changed when the budget was spent (releases continued at 3–4 a week), which a policy fixes and a tighter target does not",
+        "The policy has thresholds tied to budget states, with what changes at each: reliability work prioritised before the budget is gone, and a release freeze except fixes and security patches when it is spent",
+        "Names owners from the input (Marta Lindqvist, Owen Achterberg, Helen Varga) or their roles, and says the policy is agreed in advance by engineering and product",
+        "Includes an exception route: who can approve a release during a freeze, in writing, and how it is recorded",
+        "Handles budget spent by a dependency: the shared Postgres cluster accounted for about 62% and 30% of the two windows, so the policy escalates to its owner (Kofi Mensah, Data Platform) with the numbers rather than only freezing search releases, while noting that search's own releases also overspent the budget",
+        "Does not invent incidents, people, dependency SLOs or numbers not in the file"
+      ]
+    },
+    {
+      "id": 4,
+      "held_out": "2026-10-20",
+      "prompt": "I'm the tech lead on payments-api at Larkspur Pay. Our only alert is the one in alerts/payments-api.rules.yaml and it paged on-call 31 times in the last 90 days, mostly for nothing. Leadership wants proper SLOs for the charges API before Q1. Can you define SLOs for POST /v1/charges and GET /v1/charges/{id}, work out the error budget, and give me burn-rate alerts to replace the current rule (what pages vs what's a ticket)? 90-day numbers are in metrics/summary-90d.md and our dependencies are in docs/dependencies.md. Also, our VP of product wants 99.99% on charges. Is that realistic?",
+      "assertions": [
+        "Answers the 99.99% question directly with a no (or 'not today'), and grounds it in the inputs: the Halberd gateway's 99.95% SLA alone allows 0.05% failures, five times a 0.01% budget, and there is no secondary acquirer until Corvid in Q2 2027; it may also note that Halberd and the Ledger DB in series (99.95% x 99.95%) come to about 99.90%.",
+        "Spots that the current rule counts 402 card_declined as errors, and that the 26 card-testing decline spikes caused most of the 31 pages. Its availability SLI treats a correct decline (and other 4xx such as 400/422/409/429) as not-bad, and leaves /healthz probe traffic out of valid events.",
+        "Measures the availability SLI from the ingress LB metric (lb_requests_total), not the app metric http_server_requests_total, and says why: the LB-only 502s during pod restarts, worth about 0.02% (LB 0.06% vs app 0.04% 5xx on POST /v1/charges).",
+        "Picks a POST /v1/charges availability target near 99.9% (anything from 99.9% to 99.95% is fine if justified against the ~99.91-99.96% monthly history and the dependency SLAs), and states the 30-day budget correctly. At 99.9% that is 43.2 minutes and about 93,312 bad requests at 36 req/s average (93.3M requests); at 99.95% it is 21.6 minutes and about 46,656.",
+        "Gives multi-window burn-rate alerts with a page/ticket split, and states for each one the burn rate, the windows, and the share of the 30-day budget used when it fires (e.g. 14.4x over 1h with a 5m short window is 2%, 6x over 6h/30m is 5%, and 1x over 3d as a ticket is 10%). It converts at least the fast-burn threshold into an error rate for the chosen target (14.4x at 99.9% is a 1.44% error ratio).",
+        "Defines a separate latency SLI for POST /v1/charges, with a threshold taken from the given distribution (e.g. under 2,000 ms, met by 99.12% today, or under 3,000 ms at 99.71%), not an arbitrary p99. It treats GET /v1/charges/{id} as its own SLO with its own budget (about 57,024 bad requests per 30 days at 99.9% and 22 req/s).",
+        "Flags at least one dependency risk that is not obvious: the idempotency Redis has no SLO and fails closed (503), or the fraud-scoring 99.9% SLO does not cap the charge SLO because it fails open.",
+        "Invents nothing that isn't in the inputs: no metric names other than lb_requests_total / lb_request_duration_seconds_bucket / http_server_requests_total / http_server_request_duration_seconds_bucket, no traffic figures, dependency SLAs or incident counts beyond those given. Any replacement rule YAML it writes uses those metric names and labels."
+      ]
+    },
+    {
+      "id": 5,
+      "held_out": "2026-10-20",
+      "prompt": "hey, Dana (my manager) wants 'four nines' for Tally (our internal expense approval app) so it can go in the quarterly ops review. im the only dev on it. can you write up the SLO + whatever alerting makes sense? my notes are in ops-notes.md. we dont have prometheus, app logs go to Loki and theres an uptime checker pinging /health every minute",
+      "assertions": [
+        "Tells the user plainly, near the top, that 99.99% is not a realistic or useful target for Tally, with numbers: at ~41,800 requests/month (1,900 x 22) it allows only about 4 failed requests a month (or 4.32 minutes per 30 days), and PeopleCore's 99.5% SLA alone allows up to 0.5% (about 216 minutes a month) with no cache or fallback.",
+        "Proposes a target based on the history in the notes: about 99.85% in July (61/40,300), 99.94% in August (23/37,900) and 99.67% in September (140/42,600), with the PeopleCore outage driving September. The target lands somewhere around 99.5% to 99.9%, not 99.99%.",
+        "Catches that PingDeck's 99.95% says almost nothing about users: /health is a static {\"ok\": true} that doesn't touch Postgres or PeopleCore, and checks are paused during the Sunday reboot. It bases the SLI on nginx access logs in Loki (good = non-5xx over valid requests), or on a deep synthetic check, not on the current /health.",
+        "Says outright whether the SLI counts requests or minutes, and why that matters here: the weekly 02:00-02:20 Sunday reboot (~87 minutes a month) affects almost no requests under a request-based SLI, but under a time-based one it would use up more than a 99.9% budget (43.2 min) by itself.",
+        "Handles low traffic explicitly, for example a minimum request count before an alert can fire, long windows (hours/days instead of 5 minutes), or alerting on absolute counts of failed submissions. It notes that with ~16 requests per 5 minutes in business hours, one error looks like a huge burn rate.",
+        "Fits the alerting to a single developer with no on-call: nothing pages 24/7. Alerts go to Jonah during business hours as notifications or tickets, with month-end (Marisol Teague's close) as the time that matters most.",
+        "Includes a short error-budget policy that names real owners from the notes (Jonah Okafor, Dana Whitfield, optionally Marisol Teague as stakeholder) and concrete actions such as pausing feature work, or adding an approver cache or fallback for PeopleCore. It stays short and doesn't invent a team, rota or process the notes don't support.",
+        "Invents nothing that isn't in the inputs: no Prometheus metrics (the user said they don't have Prometheus), no traffic, error or SLA figures beyond those in ops-notes.md, and no additional people or systems. Any Loki/LogQL queries reference only the nginx access-log fields the notes mention (status, path, request_time)."
+      ]
+    }
+  ]
+}

package/packs/sre-oncall/skills/slo-spec/evals/files/1/order-service.md

@@ -0,0 +1,51 @@
+# Tidewater Grocers — order service (reliability review input)
+
+Owner: Order team (engineering lead: Priya Raman). Product owner: Tom Okafor.
+Head of Engineering: Dana Whitlock.
+
+## What customers do with it
+
+1. **Search and browse products** — web and app call `GET /products` and `GET /search`.
+   About 4,800,000 requests a day. Customers abandon if results take more than about a second.
+2. **Place an order (checkout)** — the customer presses "Place order". The app calls
+   `POST /orders`, which validates the basket and puts the order on the `orders` queue
+   (RabbitMQ), then returns `202 Accepted`. An `order-worker` takes it off the queue, charges
+   the card through PayRail (our only payment provider, called synchronously from the worker)
+   and writes the confirmation. The app polls `GET /orders/{id}` until it shows "confirmed"
+   or "declined". About 240,000 `POST /orders` calls a day, including retries.
+3. **Book a delivery slot** — `GET /slots` and `POST /slots/{id}/hold`. About 360,000 requests
+   a day. If it fails the customer can usually try again a minute later.
+4. **Store-ops admin API** — staff in 40 stores adjust stock and mark items unavailable.
+   About 600 requests a day, nearly all between 08:00 and 16:00 on weekdays.
+
+## What we measure today
+
+- Load balancer access logs for every public endpoint: status code and total request time.
+- `order_worker_process_seconds` histogram, timed inside the worker from the moment it takes an
+  order off the queue until it writes the confirmation. The team proposes this as the checkout
+  latency SLI ("p99 is 400 ms, we're in great shape").
+- RabbitMQ `orders` queue depth.
+- CPU, memory and pod restarts for every deployment.
+- A browser beacon (real-user monitoring) on the search results page only.
+
+## History (last 90 days, from load balancer logs)
+
+| Journey | Success rate at the load balancer |
+|---|---|
+| Search and browse | 99.95% |
+| `POST /orders` accepted | 99.97% |
+| Delivery slots | 99.7% |
+| Admin API | 99.6% (about 2 failed requests a week) |
+
+On 14 September (a promotion day) the `orders` queue backed up for about 50 minutes. Queue wait
+reached roughly 3 minutes and support logged 212 complaints about orders "stuck on processing".
+`order_worker_process_seconds` p99 stayed at 400 ms throughout.
+
+PayRail's published SLO is 99.9% monthly availability. PayRail had two incidents this quarter,
+each around 40 minutes long.
+
+## What we've been asked for
+
+Tom wants checkout at **99.99%** "because checkout is revenue". Dana wants an error-budget
+policy written down before the next quarter's planning. The admin API should have "the same
+paging as everything else".

package/packs/sre-oncall/skills/slo-spec/evals/files/3/search-slo-status.md

@@ -0,0 +1,30 @@
+# catalogue-search — SLO status (Bramblecote Travel)
+
+Service: `catalogue-search`, the holiday search behind the website and app.
+Traffic: about 1,200,000 search requests a day.
+
+People:
+- Search team engineering lead: Marta Lindqvist
+- Product manager, search: Owen Achterberg
+- VP Engineering: Helen Varga
+- Data Platform team lead (owns the shared Postgres cluster): Kofi Mensah
+
+## Current SLO
+
+- SLI: share of valid search requests answered with a non-5xx response in under 800 ms,
+  measured at the load balancer. Valid excludes health checks and the partner scraper.
+- Target: 99.5% over a rolling 28 days.
+
+## The last two windows
+
+| Window | Budget used | Biggest consumers |
+|---|---|---|
+| 4 Aug – 31 Aug | 140% | Shared Postgres cluster failover, 21 Aug: about 62% of the window's budget. Two search releases with a slow ranking query: about 55%. Remaining: scattered timeouts. |
+| 1 Sep – 28 Sep | 115% | Search release 4.18 (index rebuild during peak): about 70%. Postgres replica lag, 12 Sep: about 30%. Remaining: scattered timeouts. |
+
+Nothing changed after either window. Releases continued at 3–4 a week.
+
+## The ask
+
+Helen wants a written error-budget policy before Q4 planning, and has suggested raising the
+target to 99.99% "so the team takes it seriously".

package/packs/sre-oncall/skills/slo-spec/evals/files/4/alerts/payments-api.rules.yaml

@@ -0,0 +1,16 @@
+groups:
+  - name: payments-api
+    rules:
+      # Added 2025-11 after the Halberd outage. 402 included because a burst of
+      # declines "can mean the gateway is broken".
+      - alert: PaymentsApiHighErrorRate
+        expr: |
+          sum(rate(http_server_requests_total{service="payments-api", status=~"5..|402"}[5m]))
+            /
+          sum(rate(http_server_requests_total{service="payments-api"}[5m]))
+          > 0.01
+        for: 5m
+        labels:
+          severity: page
+        annotations:
+          summary: "payments-api error rate above 1%"

package/packs/sre-oncall/skills/slo-spec/evals/files/4/docs/dependencies.md

@@ -0,0 +1,8 @@
+# payments-api dependencies
+
+| Dependency | Used by | Commitment | Behaviour when it fails |
+|---|---|---|---|
+| Halberd Payments Gateway (acquirer) | POST /v1/charges (synchronous, every request) | Contractual SLA 99.95% monthly uptime; we measured 99.97% over the last 90 days | Request fails with 502/504. No secondary acquirer today — Corvid Acquiring integration is on the Q2 2027 roadmap. |
+| Ledger DB (managed Postgres, multi-AZ) | POST and GET | Provider SLA 99.95% monthly | Request fails with 503. |
+| Fraud scoring (internal, team Sentinel) | POST /v1/charges | Internal SLO 99.9% availability, p99 180 ms | Called with a 250 ms timeout. On timeout or error we fall back to rules-based scoring and proceed (fail-open); logged as `fraud_fallback=true`. |
+| Idempotency cache (self-hosted Redis, single primary + replica) | POST /v1/charges | No SLO | Fail-closed: request returns 503. |

package/packs/sre-oncall/skills/slo-spec/evals/files/4/metrics/summary-90d.md

@@ -0,0 +1,51 @@
+# payments-api — 90-day summary (2026-07-22 to 2026-10-19)
+
+Two metric sources exist:
+
+- **App:** `http_server_requests_total{service="payments-api", route, status}` and
+  `http_server_request_duration_seconds_bucket{service="payments-api", route, le}` — emitted by the pods.
+- **Ingress LB:** `lb_requests_total{backend="payments-api", route, code}` and
+  `lb_request_duration_seconds_bucket{backend="payments-api", route, le}` — emitted by the ingress load balancer.
+
+The LB sees ~0.02% more 5xx on POST /v1/charges than the app does: 502s returned by the LB while pods
+restart during deploys (about 4 deploys/week) never reach the app, so the app metric doesn't count them.
+
+## Traffic
+
+| Route | Avg req/s | Daily peak req/s | Notes |
+|---|---|---|---|
+| POST /v1/charges | 36 | 95 (12:00–13:00 UTC); 210 during merchant batch runs | |
+| GET /v1/charges/{id} | 22 | 60 | |
+| GET /healthz | 30 | 30 | LB probes + kubelet; always 200 |
+
+## POST /v1/charges — status breakdown (LB-measured, 90d)
+
+| Status | Share |
+|---|---|
+| 201 created | 98.52% |
+| 402 card_declined | 0.71% baseline; 1.5–4% during card-testing attacks on a single merchant (26 such spikes, 10–40 min each) |
+| 400 / 422 validation | 0.55% |
+| 409 idempotency conflict | 0.08% |
+| 429 rate limited | 0.08% |
+| 5xx | 0.06% (502: 0.02%, 503: 0.01%, 504: 0.03%) |
+
+App-measured 5xx on the same route: 0.04%.
+
+Monthly non-5xx share, LB-measured: Aug 99.95%, Sep 99.91%, Oct (1–19) 99.96%.
+
+## POST /v1/charges — latency (LB-measured, 90d)
+
+p50 310 ms · p90 640 ms · p95 820 ms · p99 1,850 ms · p99.9 4,200 ms
+
+Share of requests completing under: 1,000 ms → 96.4% · 2,000 ms → 99.12% · 3,000 ms → 99.71%
+
+## GET /v1/charges/{id} (LB-measured, 90d)
+
+5xx 0.02% · p99 120 ms · share under 250 ms → 99.93%
+
+## Pages from PaymentsApiHighErrorRate (90d)
+
+31 pages total:
+- 26 — card-testing decline spikes (402s), no service fault
+- 3 — 502 bursts during deploys (resolved on their own within 6 min)
+- 2 — Halberd gateway incidents (Sep 9: 504s on ~9% of POST /v1/charges for 22 min; Oct 2: 7 min)

package/packs/sre-oncall/skills/slo-spec/evals/files/5/ops-notes.md

@@ -0,0 +1,34 @@
+# Tally — ops notes (Jonah)
+
+Tally = internal expense approval app. Employees submit expenses, their approver approves, finance pays.
+
+## Setup
+- Django + gunicorn behind nginx, single VM `tally-vm-01`. Postgres runs on the same VM.
+- I deploy by hand, ~2x/month. gunicorn restart takes ~30s; nginx returns 502 for anything that comes in meanwhile.
+- IT auto-patches and reboots the VM every Sunday 02:00–02:20. PingDeck checks are paused during that window.
+
+## Users / traffic
+- ~300 employees submit, ~40 approvers, finance team of 6 (lead: Marisol Teague — month-end close is when she cares most).
+- ~1,900 requests per working day on average, almost all 08:00–18:00 Mon–Fri, ~22 working days a month.
+  Last 3 working days of the month are roughly 3x busier. Nights and weekends: under 20 requests total.
+- Monthly requests (nginx access logs in Loki): Jul 40,300 · Aug 37,900 · Sep 42,600
+- ~350 403s a month — people clicking approval links for reports they aren't the approver on.
+
+## Errors (nginx 5xx, from Loki)
+- Jul 61 · Aug 23 · Sep 140
+- Sep 16: PeopleCore outage, ~2.5h. Every submit/approve failed with 500 because approver lookup failed.
+
+## Monitoring
+- Loki has nginx access logs (status, path, request_time) and Django app logs.
+- PingDeck hits `GET /health` every minute. Reports 99.95% uptime over the last 90 days.
+  `/health` just returns `{"ok": true}` from Django — doesn't touch Postgres or PeopleCore.
+- Alerts: none right now apart from PingDeck emailing me.
+
+## Dependencies
+- Corp SSO (IT Identity team) — published SLO 99.9%. Needed to log in.
+- PeopleCore HR API (vendor) — SLA 99.5% monthly. Approver lookup on every submit and every approval. No cache.
+- Corporate SMTP relay — notification emails, async with retries; failures don't fail the request.
+
+## People
+- Me (Jonah Okafor) — only dev. Reachable business hours, no on-call rota.
+- Dana Whitfield — my manager.