skilldrop-cli 0.16.3__py3-none-any.whl

skilldrop_cli/data/packs/sre-oncall/skills/incident-comms/evals/eval_queries.json

@@ -0,0 +1,34 @@
+[
+  {
+    "query": "Draft a status page update for this ongoing incident",
+    "should_trigger": true
+  },
+  {
+    "query": "We're live in an incident — I need customer, internal, and exec updates",
+    "should_trigger": true
+  },
+  {
+    "query": "Write the customer-facing comms while we investigate",
+    "should_trigger": true
+  },
+  {
+    "query": "How do I tell stakeholders about this outage right now?",
+    "should_trigger": true
+  },
+  {
+    "query": "Write the blameless postmortem now that it's resolved",
+    "should_trigger": false
+  },
+  {
+    "query": "Generate the runbook for this service",
+    "should_trigger": false
+  },
+  {
+    "query": "Summarize this technical doc for executives",
+    "should_trigger": false
+  },
+  {
+    "query": "Extract decisions and action items from the incident channel",
+    "should_trigger": false
+  }
+]

skilldrop_cli/data/packs/sre-oncall/skills/incident-comms/evals/evals.json

@@ -0,0 +1,16 @@
+{
+  "skill_name": "incident-comms",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "We're 20 minutes into a live incident — checkout is failing for about 30% of users, cause not yet confirmed. Draft the customer, internal, and exec updates.",
+      "assertions": [
+        "Each message's first sentence is reader-facing impact, not an internal symptom or architecture detail",
+        "Every message names the next-update time, or marks it [set HH:MM] when unknown",
+        "No unconfirmed cause is stated and no commitment is made that might need retracting",
+        "The three audiences (customer status page, internal stakeholders, exec) get genuinely different messages rather than one text reused",
+        "Nothing is asserted beyond what the operator supplied"
+      ]
+    }
+  ]
+}

skilldrop_cli/data/packs/sre-oncall/skills/incident-comms/manifest.json

@@ -0,0 +1,14 @@
+{
+  "name": "incident-comms",
+  "version": "0.1.0",
+  "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": [] },
+  "env": { "required": [], "optional": [] },
+  "related": ["postmortem-generator", "runbook-generator"],
+  "handoff": [
+    { "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." }
+}

skilldrop_cli/data/packs/sre-oncall/skills/incident-comms/reference.md

@@ -0,0 +1,43 @@
+# incident-comms reference — audience altitude, status vocabulary, cadence
+
+## The three audiences (same facts, three altitudes)
+
+| | Customer (status page / in-app / email) | Internal stakeholder (support, sales, CS) | Exec |
+|---|---|---|---|
+| **Leads with** | what you can't do right now | what to tell your customers | business impact + the ask |
+| **Cause** | none until confirmed, and only if it helps them | confirmed-vs-suspected, plainly | one clause, only if it changes a decision |
+| **Length** | 2–4 sentences | short + a "what to say" block | 3 sentences, max |
+| **Includes** | impact, status, workaround if any, next update | all that + comms guidance (pause? relay? hold?) | revenue/SLA/customer exposure, decision needed, what you need from them |
+| **Excludes** | jargon, internal names, blame, speculative ETA | raw engineering detail they can't use | technical narrative, play-by-play |
+| **Forward risk** | assume it's screenshotted to social media | assume it reaches a customer verbatim | assume it's quoted in a board update |
+
+## Status vocabulary (use precisely — these words mean specific things)
+
+- **Investigating** — aware of impact, cause not yet identified. Don't guess the cause to fill space.
+- **Identified** — cause confirmed, fix not yet applied or not yet effective.
+- **Monitoring** — fix applied, watching to confirm it holds. NOT resolved.
+- **Resolved** — restored and verified across all affected paths. Only after verification.
+
+Never skip "monitoring" straight to "resolved" on a SEV1/2 — the watch window is what catches the relapse.
+
+## Cadence by severity (the promise you must keep)
+
+| Severity | Customer-facing impact | Update cadence | First ack target |
+|---|---|---|---|
+| SEV1 | full outage / data risk / payments down | every 30 min, even with no change | ≤ 15 min |
+| SEV2 | major feature down, no workaround | every 60 min | ≤ 30 min |
+| SEV3 | degraded, workaround exists | at identified + at resolved | ≤ 2 h |
+| SEV4 | minor / cosmetic | resolved note only, or none | n/a |
+
+The cadence is set when you send the first ack ("next update at HH:MM") and is then a commitment. If the window arrives with nothing new, send the no-change update — silence is read as loss of control.
+
+## What's in your control vs not
+
+- **In your control — commit to these:** the next-update time, the fact that you're on it, the current confirmed impact.
+- **Not in your control — never commit to these:** the fix ETA, the root cause before confirmation, the all-clear before verification.
+
+When someone demands "when will it be fixed?", the honest, defensible answer is the next-update time: *"We don't have a confirmed restore time yet. Our next update will be at 14:30 with progress."*
+
+## The forward test
+
+Before sending any message, ask: if this were screenshotted and posted publicly with our logo on it, would we stand behind it? If no — remove the speculation, the blame, or the jargon until yes.

skilldrop_cli/data/packs/sre-oncall/skills/incident-comms/templates/messages.md

@@ -0,0 +1,82 @@
+# incident-comms message templates
+
+Paste-ready. Every message carries a next-update time — fill it or leave `[set HH:MM]`. Times in the customer's expected timezone (state it).
+
+---
+
+## ACKNOWLEDGE
+
+### Customer (status page / in-app)
+```
+[Investigating] {Plain impact — what users can't do.} We're aware of the issue
+and actively investigating. Next update by {HH:MM TZ}.
+```
+Example: *"[Investigating] Some users are unable to log in. We're aware and actively investigating. Next update by 14:15 ET."*
+
+### Internal (support / sales / CS)
+```
+🔴 {SEV} — {one-line impact}. Status: investigating, cause not yet identified.
+What to tell customers: {the approved customer line above — nothing beyond it}.
+Workaround: {one if it exists, else "none yet"}.
+Do NOT: speculate on cause or give a fix ETA.
+Next update: {HH:MM}.
+```
+
+### Exec
+```
+{SEV} incident, started {HH:MM}. Impact: {who/how many/what business function}.
+Exposure: {revenue / SLA / key accounts if known, else "assessing"}.
+We need: {nothing right now / a decision on X / comms approval}. Next update {HH:MM}.
+```
+
+---
+
+## UPDATE (send on cadence — even with no change)
+
+### Customer
+```
+[{Investigating|Identified|Monitoring}] {What changed, or "We're continuing to
+investigate."} {If identified: "We've identified the cause and are working on a fix."}
+Next update by {HH:MM TZ}.
+```
+No-change variant: *"[Investigating] We're still working to identify the cause. No customer-facing change yet. Next update by {HH:MM}."*
+
+### Internal
+```
+🟠 {SEV} update — {what changed since last}. Current status: {vocabulary word}.
+What to tell customers now: {updated line}.
+Workaround: {current}.
+Next update: {HH:MM}.
+```
+
+### Exec
+```
+Update on {SEV}: {one sentence on progress}. Impact now {growing/stable/shrinking}.
+{Decision needed / still no action required}. Next update {HH:MM}.
+```
+
+---
+
+## RESOLVE (only after verification across all affected paths)
+
+### Customer
+```
+[Resolved] {What's restored} has been restored as of {HH:MM TZ}. The issue affected
+{who} between {start} and {end}. {If anyone might still be affected: "If you continue
+to experience problems, {action}."} We apologize for the disruption.
+{SEV1/2 only: "A full post-incident review will follow."}
+```
+
+### Internal
+```
+🟢 Resolved {HH:MM}. Root cause: {one line if confirmed, else "under review"}.
+Customer-facing window: {start–end}. If a customer still reports issues: {action/route}.
+Postmortem owner: {role}, due {date}.
+```
+
+### Exec
+```
+{SEV} resolved at {HH:MM}, total customer-facing window {duration}. Impact: {final
+quantified impact}. {SLA/credit implications if any}. Postmortem to follow by {date}.
+```
+Handoff: feed the timeline and impact into `postmortem-generator`.

skilldrop_cli/data/packs/sre-oncall/skills/observability-plan/SKILL.md

@@ -0,0 +1,70 @@
+---
+name: observability-plan
+description: Design an observability plan for a service — user-journey SLIs, SLOs with error budgets, symptom-based burn-rate alerting (page vs ticket, every page actionable and runbook-linked), and a deliberate metrics/logs/traces split with a cardinality and cost budget. Use when the user needs SLOs, alerting design, a monitoring/observability strategy, dashboards, or wants to fix alert fatigue and know what to measure.
+---
+
+# observability-plan
+
+Designs the telemetry that makes a service *debuggable at 3am and detectable before users complain* — SLOs measured from the user's experience, alerts that fire only when a human must act, and the three pillars each used for what they're good at. Expands the one-line observability requirement from `nfr-spec` into a full operating plan; upstream of `incident-comms` and `postmortem-generator` (you can't communicate or analyze an incident you couldn't detect). Distinct from `success-metrics` (business outcomes) — this is operational health.
+
+## How to respond
+
+1. **Start from user journeys, not from the resource dashboard.** The first artifact is the list of critical journeys ("log in", "place order", "load feed") — because an SLI measures *what the user experiences*, and CPU graphs measure what's easy. Ask at most 2 questions, spent on the most critical journey and what "down" means to a user there. Resource metrics (the golden signals) still get covered — but as saturation/cause signals, never as the SLO.
+
+2. **Define SLIs as good-events / valid-events from the user's side** (catalog in [`reference.md`](reference.md)) — availability (success rate), latency (a threshold, measured at a percentile: "% of requests < 300ms"), and where relevant freshness, correctness, throughput. ✅ *"SLI: proportion of checkout requests returning 2xx within 1s, measured at the load balancer"* — ❌ *"SLI: average CPU"* (the user never feels your CPU). Latency SLIs are a *threshold count*, not an average — averages hide the tail that hurts.
+
+3. **Set SLOs with an explicit error budget and window.** Each SLI gets a target over a rolling window: "99.9% over 28 days." That target *is* the error budget (0.1% = ~40 min/28d) — the quantity that governs both alerting and how aggressively you ship. State the budget in human terms (minutes/month) and name the **error-budget policy**: what happens when it's spent (freeze risky releases, redirect to reliability) — an SLO with no policy is a number nobody defends. Pick targets honestly (99.9% is not free; see `nfr-spec`'s down-for-an-hour calibration) — more nines is exponentially more cost.
+
+4. **Alert on symptoms, page only on what's actionable now.** The hard rule that kills alert fatigue: **a page means a human must act immediately; everything else is a ticket or a dashboard.** Alert on SLO burn (the user is being hurt), not on every cause (a single CPU spike that auto-recovered). Cause-based signals inform diagnosis once you're paged — they don't page. Use **multi-window, multi-burn-rate alerts** ([`reference.md`](reference.md)): a fast burn (budget being consumed quickly) pages; a slow burn opens a ticket. Every page is actionable, deduplicated, severity-tiered, and **maps to a runbook entry** (→ `runbook-generator`) — a page with no runbook is a 3am puzzle, not an alert.
+
+5. **Split the three pillars deliberately — each for what it's good at:**
+   - **Metrics** — cheap, aggregatable, the basis of SLOs and alerts. Low-cardinality. Answer "is it broken and how much?"
+   - **Logs** — expensive, high-detail, for debugging the specific failure. **Structured** (not string soup), sampled on the hot path, with a retention/cost budget. Answer "what exactly happened to this request?"
+   - **Traces** — request flow across services, for "where in the chain did the latency/error come from?" Sample intelligently (tail-based on errors/slow); propagate context across every hop.
+   Don't put in logs what should be a metric (cardinality and cost explode), and don't try to metric what needs a trace (you'll never reconstruct the path from counters).
+
+6. **Set a cardinality and cost budget.** High-cardinality labels (user_id, request_id, full URL) on metrics multiply time series and the bill without bound — name which labels are allowed on metrics (bounded sets: region, status_class, endpoint-template) and push the high-cardinality identifiers to logs/traces where they belong. State the log-volume and metric-series budget (ties to `capacity-cost-model`); observability is routinely a top-3 cloud line item.
+
+7. **Specify dashboards by the question each answers**, not by graph count. A service dashboard shows the golden signals + SLO/budget status at a glance (the at-a-glance health check); a debugging dashboard supports drill-down. The 3am questions from `nfr-spec` become concrete panels. A wall of 100 graphs is where signal goes to hide.
+
+8. **Emit with [`templates/observability-plan.md`](templates/observability-plan.md)** in one message: critical journeys, SLI/SLO table with error budgets, the error-budget policy, the alert table (condition / window / burn-rate / page-or-ticket / runbook link), the metrics-logs-traces split, the cardinality+cost budget, and dashboards-by-question. Instrumentation naming conventions and trace-context propagation noted.
+
+## Useful references in this skill
+
+- [`reference.md`](reference.md) — golden signals, SLI types by component, SLO/error-budget math, the multi-window burn-rate alert table, the metrics-vs-logs-vs-traces decision guide, and alert-quality rules
+- [`templates/observability-plan.md`](templates/observability-plan.md) — the plan skeleton with SLO, alert, and pillar tables
+
+## Quality bar
+
+- **SLIs measure user experience** (good/valid events), not resource utilization. Latency SLIs are threshold counts at a percentile, never averages.
+- **Every SLO has an error budget in human terms and a policy** for when it's spent. A target with no budget consequence is decoration.
+- **Pages are actionable, symptom-based, and runbook-linked.** If a page doesn't require an immediate human action, it's a ticket — the plan re-tiers it.
+- **Burn-rate alerting is used**, not static "CPU > 80%" thresholds, for SLO-backed surfaces.
+- **The three pillars are split by purpose**, with high-cardinality identifiers kept off metrics. Logs are structured and budgeted.
+- **A cardinality/cost budget exists.** Observability without a cost ceiling becomes the surprise invoice.
+- **Dashboards are defined by the question they answer**, not by quantity.
+
+## When to use this skill
+
+- ✅ Standing up monitoring/SLOs for a new or existing service
+- ✅ "What should we measure / alert on?" / designing an alerting strategy
+- ✅ Fixing alert fatigue — too many pages, most non-actionable
+- ✅ Turning `nfr-spec`'s observability requirement into an implementable plan
+
+## When NOT to use this skill
+
+- ❌ Business/product success metrics — that's `success-metrics`
+- ❌ Customer/stakeholder comms during an outage — that's `incident-comms`
+- ❌ The post-incident analysis — that's `postmortem-generator`
+- ❌ The one-line observability *requirement* in a spec — that's `nfr-spec`; this is the full design beneath it
+
+## Anti-patterns to avoid
+
+- ❌ **Resource metrics as SLOs.** Alerting on CPU/memory/disk as if they were user pain — they auto-recover, they spike harmlessly, and they page you at 3am for nothing while the actual user-facing error goes unnoticed.
+- ❌ **Averages for latency.** "Average response 120ms" with a p99 of 4s means a lot of users are suffering invisibly. Measure the percentile and the threshold.
+- ❌ **Cause-based paging.** A page for every component hiccup. Page on the symptom (users hurt / budget burning fast); let causes inform diagnosis, not wake people.
+- ❌ **The alert with no runbook.** Firing a page that says "high error rate" with no "here's what to check" — that's a puzzle handed to someone half-asleep.
+- ❌ **Unbounded metric cardinality.** `user_id` or `request_id` as a metric label — millions of time series, a five-figure bill, and a dashboard that times out. Those belong in logs/traces.
+- ❌ **String-soup logs.** Unstructured `printf` logs you can't query or aggregate, retained forever at full volume. Structure them, sample the hot path, budget the retention.
+- ❌ **The 100-graph dashboard.** Built to look thorough, used by no one, because no panel answers a question anyone asks under pressure.
+- ❌ **99.99% by reflex.** Copying a target off a blog instead of from the down-for-an-hour cost calibration; every nine multiplies the engineering and on-call burden.

skilldrop_cli/data/packs/sre-oncall/skills/observability-plan/evals/eval_queries.json

@@ -0,0 +1,34 @@
+[
+  {
+    "query": "Design an observability plan for this service",
+    "should_trigger": true
+  },
+  {
+    "query": "What SLIs and SLOs should we define, and what should page us?",
+    "should_trigger": true
+  },
+  {
+    "query": "Set up burn-rate alerting with error budgets",
+    "should_trigger": true
+  },
+  {
+    "query": "We alert on CPU and it's useless — design symptom-based alerting",
+    "should_trigger": true
+  },
+  {
+    "query": "Sweep the full non-functional requirements catalog",
+    "should_trigger": false
+  },
+  {
+    "query": "Write the operational runbook for the on-call team",
+    "should_trigger": false
+  },
+  {
+    "query": "Model our capacity and infrastructure cost",
+    "should_trigger": false
+  },
+  {
+    "query": "Write the postmortem for last week's outage",
+    "should_trigger": false
+  }
+]

skilldrop_cli/data/packs/sre-oncall/skills/observability-plan/evals/evals.json

@@ -0,0 +1,16 @@
+{
+  "skill_name": "observability-plan",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "Design the observability plan for our checkout service — what should we measure, alert on, and page for?",
+      "assertions": [
+        "SLIs measure user experience as good-over-valid events, not resource utilization",
+        "Latency SLIs are threshold counts at a percentile, never averages",
+        "Every SLO carries an error budget stated in human terms plus a policy for when it is spent",
+        "Pages are symptom-based, actionable, and runbook-linked; anything not actionable is a ticket, not a page",
+        "The plan makes a deliberate metrics-vs-logs-vs-traces choice rather than proposing everything"
+      ]
+    }
+  ]
+}

skilldrop_cli/data/packs/sre-oncall/skills/observability-plan/manifest.json

@@ -0,0 +1,15 @@
+{
+  "name": "observability-plan",
+  "version": "0.1.0",
+  "description": "Design an observability plan for a service — user-journey SLIs, SLOs with error budgets, symptom-based burn-rate alerting (page vs ticket, every page actionable and runbook-linked), and a deliberate metrics/logs/traces split with a cardinality and cost budget. Use when the user needs SLOs, alerting design, a monitoring/observability strategy, dashboards, or wants to fix alert fatigue and know what to measure.",
+  "entrypoint": "SKILL.md",
+  "deps": { "npm": [], "pip": [] },
+  "env": { "required": [], "optional": [] },
+  "related": ["capacity-cost-model", "incident-comms", "nfr-spec", "postmortem-generator", "runbook-generator", "success-metrics"],
+  "handoff": [
+    { "to": "runbook-generator", "when": "the alerts are defined and each needs a procedure", "purpose": "Write the procedure the on-call follows per alert.", "fallback": "If runbook-generator is absent, write one numbered procedure per alert inline." },
+    { "to": "incident-comms", "when": "detection fired and an audience needs telling", "purpose": "Communicate at the stage the incident is actually in.", "fallback": "If incident-comms is absent, state the stage, the impact, and the next update time inline." }
+  ],
+  "tags": ["observability", "slo", "sli", "alerting", "monitoring", "sre"],
+  "model": { "tier": "standard", "rationale": "Methodology synthesis against fixed SRE practices (golden signals, burn-rate alerting, pillar split). SLO calibration needs judgment but is bounded; escalate via ambiguous-input on contested reliability targets." }
+}

skilldrop_cli/data/packs/sre-oncall/skills/observability-plan/reference.md

@@ -0,0 +1,67 @@
+# observability-plan reference — signals, SLO math, burn-rate alerts, pillar split
+
+## The golden signals (cover all four; they're cause/saturation signals, not SLOs by default)
+
+| Signal | Question | Typical measure |
+|---|---|---|
+| **Latency** | how slow? (split success vs error latency) | p50/p95/p99 against a threshold |
+| **Traffic** | how much demand? | rps, requests/min, active connections |
+| **Errors** | how often failing? | error rate, by class (5xx vs 4xx) |
+| **Saturation** | how full? | CPU/mem/queue depth/connection-pool % — the leading indicator of trouble |
+
+User-facing **latency + errors** usually become SLIs; **saturation** is the early-warning/cause signal that informs diagnosis, not the page.
+
+## SLI types (good events / valid events, from the user's side)
+
+| SLI | Definition | Measured where |
+|---|---|---|
+| Availability | successful responses / valid requests | LB / gateway / client |
+| Latency | requests faster than threshold / valid requests | same vantage as the user |
+| Freshness | data served within max staleness / reads | for caches, pipelines, replicas |
+| Correctness | correct outputs / total (where checkable) | post-processing validation |
+| Throughput | jobs completed within deadline / scheduled | batch/streaming |
+
+Measure as close to the user as practical. An SLI measured server-side misses the failures that never reached the server.
+
+## SLO targets, windows, error budgets
+
+- Target over a **rolling window** (28 or 30 days is common). 99.9%/28d ≈ **40 min** of budget; 99.95% ≈ 20 min; 99.99% ≈ 4 min.
+- The **error budget** = (1 − SLO) × window. It is the allowed unreliability — spend it on releases and risk.
+- **Error-budget policy** (write it): e.g. "budget >50% remaining → ship freely; <25% → freeze risky changes, prioritize reliability; exhausted → release freeze until recovered." Without a policy, the SLO doesn't change any behavior.
+- Calibrate targets to cost (see `nfr-spec` down-for-an-hour). Internal tools rarely need >99.5%; payment paths may justify 99.95%+. Each nine is ~10× the effort.
+
+## Multi-window, multi-burn-rate alerting (page on fast burn, ticket on slow)
+
+"Burn rate" = how fast you're consuming the error budget relative to even consumption (1× burn would exactly exhaust it at window end). Alert on high burn over a short window AND confirm over a longer one to avoid flapping.
+
+| Burn rate | Budget consumed | Long/short windows | Severity |
+|---|---|---|---|
+| 14.4× | 2% in 1h | 1h and 5m both breaching | 🔴 page — fast burn, acute |
+| 6× | 5% in 6h | 6h and 30m | 🟠 page — sustained |
+| 3× | 10% in 1d | 1d and 2h | 🟡 ticket — slow burn |
+| 1× | tracking only | — | dashboard, no alert |
+
+Require both the long and short window to breach before firing — the short window confirms it's still happening, the long window confirms it's significant. This is what replaces brittle "errors > N" static thresholds.
+
+## Alert-quality rules
+
+1. **Every page is actionable now** — there is a thing a human does on receipt. If not, it's a ticket.
+2. **Every page maps to a runbook entry** (→ `runbook-generator`). No runbook = not ready to page.
+3. **Page on symptoms** (SLO burn, user-facing errors), not causes (a pod restarted). Causes are diagnostic context.
+4. **Deduplicate and group** — one incident, one page, not 200 per-host alerts.
+5. **Tier severity:** page (wake someone) / ticket (next business day) / log (queryable, no notification). Most "alerts" should be tickets or logs.
+6. **Review noisy/non-actionable pages** monthly; a page that's been ignored 5× is either re-tiered or fixed. Alert fatigue is a reliability risk in itself.
+
+## Metrics vs logs vs traces (use each for its strength)
+
+| | Metrics | Logs | Traces |
+|---|---|---|---|
+| Good at | aggregate state, alerting, SLOs | per-event detail, debugging one request | request flow across services |
+| Cost driver | **cardinality** (label combinations) | **volume** (GB ingested) | sampling rate × span count |
+| Cardinality | keep LOW — bounded labels only | high-cardinality lives here | high-cardinality lives here |
+| Retention | long (cheap, downsampled) | short, sampled on hot path | short, tail-sampled on errors/slow |
+| Don't | put user_id/request_id as a label | use as a metric (count via logs = $$$) | sample blindly and miss the error traces |
+
+**Cardinality budget:** allowed metric labels are bounded sets — `region`, `status_class`, `endpoint_template`, `tenant_tier`. Forbidden as metric labels — `user_id`, `request_id`, raw `url`, `email`. Those identifiers belong in logs/traces, linked from metrics via **exemplars**. One unbounded label can create millions of series and a five-figure monthly bill.
+
+**Structured logs:** key-value/JSON, consistent field names, a trace/correlation ID on every line so logs join to traces. Sample the hot path (keep all errors, sample successes). Set a retention budget (ties to `capacity-cost-model`).

skilldrop_cli/data/packs/sre-oncall/skills/observability-plan/templates/observability-plan.md

@@ -0,0 +1,62 @@
+# Observability-plan template
+
+SLIs from the user's side, SLOs with budgets and a policy, pages that are actionable and runbook-linked, pillars split by purpose with a cost ceiling.
+
+```markdown
+# Observability plan: {service}
+
+**Date:** {YYYY-MM-DD} · **On-call team:** {role}
+
+## Critical user journeys (SLIs measure these)
+
+| Journey | "Down" means to a user | SLI |
+|---|---|---|
+| {log in} | {can't authenticate} | success rate of auth requests |
+| {place order} | {checkout errors / hangs} | % checkout req 2xx within 1s |
+
+## SLIs / SLOs / error budgets
+
+| SLI | Definition (good/valid) | SLO (target / window) | Error budget | Measured at |
+|---|---|---|---|---|
+| checkout availability | 2xx / valid checkout req | 99.9% / 28d | ~40 min/28d | load balancer |
+| checkout latency | < 1s / valid checkout req | 99% < 1s / 28d | 1% of checkout req/28d may exceed 1s | load balancer |
+
+**Error-budget policy:** {>50% remaining → ship freely; <25% → freeze risky releases; exhausted → release freeze + reliability focus until recovered}.
+
+## Alerts (symptom-based, burn-rate, every page runbook-linked)
+
+| Alert | Condition | Windows | Burn | Page / Ticket | Runbook |
+|---|---|---|---|---|---|
+| checkout fast burn | budget burn ≥ 14.4× | 1h & 5m | acute | 🔴 page | runbook#checkout-errors |
+| checkout slow burn | budget burn ≥ 3× | 1d & 2h | slow | 🟡 ticket | runbook#checkout-degraded |
+| saturation early-warn | pool util > 85% | 15m | — | 🟡 ticket | runbook#scale-checkout |
+
+{No page without a runbook link. Cause/resource signals are tickets or dashboards, not pages.}
+
+## Three-pillar strategy
+
+| Pillar | Used for | Key rules |
+|---|---|---|
+| Metrics | SLOs, alerts, golden signals | bounded labels only (region, status_class, endpoint_template) |
+| Logs | per-request debugging | structured JSON, trace-id on every line, sample successes, keep errors, retention {N}d |
+| Traces | cross-service latency/error attribution | propagate context all hops, tail-sample errors/slow, {x}% baseline |
+
+## Cardinality & cost budget
+
+- **Allowed metric labels:** {region, status_class, endpoint_template, tenant_tier}
+- **Forbidden as metric labels (→ logs/traces):** user_id, request_id, raw url, email
+- **Budgets:** metric series ≤ {N}; log ingest ≤ {GB/day}; trace sampling {x}%. Alert at 80% of each. (→ `capacity-cost-model`)
+
+## Dashboards (by the question each answers)
+
+| Dashboard | Question it answers | Panels |
+|---|---|---|
+| Service health | "is checkout healthy right now?" | golden signals + SLO/budget status |
+| Checkout drill-down | "where is the latency/error coming from?" | per-dependency latency, error breakdown, trace exemplars |
+
+## Instrumentation conventions
+
+- Metric naming: {namespace.subsystem.unit} (e.g. `checkout.request.duration_ms`)
+- Trace context propagated on every hop ({W3C traceparent}); exemplars link metrics → traces.
+- Every new feature ships its SLI instrumentation with it (not as a fast-follow).
+```

skilldrop_cli/data/packs/sre-oncall/skills/postmortem-generator/SKILL.md

@@ -0,0 +1,66 @@
+---
+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.
+---
+
+# 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.
+
+## How to respond
+
+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.
+
+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
+
+- [`templates/postmortem.md`](templates/postmortem.md) — the full doc skeleton with the gap calculations and action-item table
+
+## 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.
+
+## When to use this skill
+
+- ✅ After an incident/outage, turning the response scrollback into the postmortem doc
+- ✅ "Write the RCA for yesterday's outage"
+- ✅ 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`
+
+## 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.

skilldrop_cli/data/packs/sre-oncall/skills/postmortem-generator/evals/eval_queries.json

@@ -0,0 +1,34 @@
+[
+  {
+    "query": "Write a blameless postmortem for this incident",
+    "should_trigger": true
+  },
+  {
+    "query": "Turn this pager timeline and Slack thread into a postmortem",
+    "should_trigger": true
+  },
+  {
+    "query": "We resolved the outage — document what happened and why",
+    "should_trigger": true
+  },
+  {
+    "query": "Generate the incident review doc with impact and action items",
+    "should_trigger": true
+  },
+  {
+    "query": "We're still in the incident — draft the customer update",
+    "should_trigger": false
+  },
+  {
+    "query": "Extract the decisions and owners from this thread",
+    "should_trigger": false
+  },
+  {
+    "query": "Write the runbook so this is handled better next time",
+    "should_trigger": false
+  },
+  {
+    "query": "Summarize the incident for the executive team",
+    "should_trigger": false
+  }
+]

skilldrop_cli/data/packs/sre-oncall/skills/postmortem-generator/evals/evals.json

@@ -0,0 +1,17 @@
+{
+  "skill_name": "postmortem-generator",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "Write the postmortem from this pager timeline and Slack thread for last Tuesday's checkout outage.",
+      "assertions": [
+        "Impact is quantified — duration, users or requests affected, SLO burn, revenue where known — or explicitly marked [missing]; 'significant impact' is rejected",
+        "No person is named in a causal sentence; roles appear only in response actions",
+        "Detection and mitigation gaps are computed and stated as numbers",
+        "The timeline is in UTC",
+        "Contributing factors are listed rather than a single root cause",
+        "Action items carry owners as roles and are derived from the contributing factors"
+      ]
+    }
+  ]
+}

skilldrop_cli/data/packs/sre-oncall/skills/postmortem-generator/manifest.json

@@ -0,0 +1,14 @@
+{
+  "name": "postmortem-generator",
+  "version": "0.1.1",
+  "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.",
+  "entrypoint": "SKILL.md",
+  "deps": { "npm": [], "pip": [] },
+  "env": { "required": [], "optional": [] },
+  "related": ["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." }
+  ],
+  "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." }
+}