skilldrop-cli 0.16.3__py3-none-any.whl

skilldrop_cli/data/packs/solution-architect/skills/threat-model/examples/document-upload.md

@@ -0,0 +1,56 @@
+# Worked example — document-upload feature → 6 ranked findings
+
+## Input (design-doc excerpt, verbatim)
+
+> New feature: customers upload contract PDFs for e-signing. Browser gets a presigned S3 URL from `upload-api` (authenticated), uploads directly to the `contracts` bucket, then `upload-api` enqueues a message; `doc-processor` consumes it, runs OCR via a third-party API, and writes extracted text to Postgres. Support staff can view any customer's documents in the admin panel to help with signing issues. Multi-tenant SaaS, tenant ID in the JWT.
+
+## Output
+
+### System summary
+
+**Assets (ranked):** customer contracts (legal PII — top asset), extracted contract text in Postgres, S3 credentials / presigned-URL minting capability, OCR API key.
+**Entry points:** `upload-api` (authn'd HTTP), direct browser→S3 upload, SQS queue into `doc-processor`, third-party OCR API responses, admin panel.
+**Trust boundaries:** internet→upload-api, internet→S3 (presigned), upload-api→queue→doc-processor, doc-processor→OCR vendor (data leaves our trust domain), doc-processor→Postgres, support-staff→admin panel, tenant→tenant throughout.
+[assumption] Presigned URLs are PUT-only. [assumption] OCR vendor is contractually approved for PII.
+
+### Findings
+
+**🟥 TM-1 — Cross-tenant document read via unscoped presigned URLs** (boundary: internet→S3; STRIDE: I, E)
+Scenario: a tenant inspects their presigned URL, finds object keys are `contracts/{uuid}.pdf` with no tenant prefix; any later GET-capable URL or a key-guessing bug exposes other tenants' contracts — compromise of the top asset.
+Existing mitigation: none stated in the design. Recommended: keys become `contracts/{tenant_id}/{uuid}.pdf`, minted only from the JWT's tenant claim, GET URLs scoped to prefix and ≤5 min. **Verify:** CI test fetches tenant B's key with tenant A's session — must 403.
+
+**🟥 TM-2 — Malicious file detonates in doc-processor** (boundary: queue→doc-processor; STRIDE: T, E)
+Scenario: attacker uploads a crafted PDF (parser exploit, zip bomb, SSRF-triggering embedded URL); doc-processor parses it with vendor-library defaults and processor credentials. RCE here reaches Postgres and the OCR key.
+Existing mitigation: none stated. Recommended: validate content-type + size at presign and on consume; parse inside a sandboxed, least-privilege worker (no Postgres write role until post-parse); pin and patch the parser. **Verify:** corpus of hostile PDFs in CI lands in DLQ, not crash-loop or exec.
+
+**🟧 TM-3 — Support staff can browse any tenant's contracts with no audit trail** (boundary: human→system; STRIDE: I, R; insider pass)
+Scenario: a support login (insider or phished) bulk-reads contracts across tenants; the design grants "view any customer's documents" with no purpose-binding or logging — undetectable until external disclosure.
+Existing mitigation: admin panel is authenticated. Recommended: case-bound access (support sees a document only via an open ticket reference), immutable audit log of every view, MFA on support accounts. **Verify:** admin-action integration test asserts the audit row; access without ticket reference → denied.
+
+**🟧 TM-4 — Queue accepts unauthenticated/poisoned messages** (boundary: upload-api→queue; STRIDE: S, T)
+Scenario: any internal workload (or attacker post-TM-2) enqueues `{tenant_id: victim, s3_key: attacker_file}`; doc-processor trusts the message and writes attacker text into the victim tenant's Postgres rows.
+Existing mitigation: queue is network-internal `[assumption: flat internal trust]`. Recommended: doc-processor re-derives tenant from the S3 key prefix (post-TM-1) instead of trusting the message field; schema-validate on consume; producer allow-list via IAM. **Verify:** message with mismatched tenant/key → rejected with alert.
+
+**🟨 TM-5 — Contract PII leaves trust domain to OCR vendor unminimized** (boundary: doc-processor→vendor; STRIDE: I)
+Scenario: full contracts ship to the vendor; a vendor breach exposes the top asset with no detection on our side. Requires the vendor's failure, hence 🟨 not 🟧.
+Existing mitigation: `[assumption]` contractual DPA. Recommended: confirm the DPA covers this data class; disable vendor-side retention; log per-document egress so exposure is enumerable after a vendor incident. **Verify:** vendor account settings reviewed + egress log row asserted in tests.
+
+**🟨 TM-6 — Unbounded uploads as cost/availability attack** (boundary: internet→S3; STRIDE: D)
+Scenario: a scripted tenant requests thousands of presigned URLs and uploads max-size files; S3 cost spike and OCR-queue saturation delay every tenant's processing (noisy-neighbor DoS).
+Existing mitigation: authn required. Recommended: per-tenant presign rate limit + size cap at presign time; queue depth alarm with per-tenant fairness. **Verify:** load test on the presign endpoint shows throttling before queue saturation.
+
+### n/a ledger
+Repudiation at internet→S3: n/a beyond TM-3's audit log — S3 access logging assumed on. DoS at admin panel: internal user base, marginal.
+
+### Authz / insider pass
+Authz: TM-1, TM-4 (tenant→tenant). Insider: TM-3. Sweeps produced findings — no all-clear claimed.
+
+### Questions for the team
+1. Are presigned URLs PUT-only, and is there any GET path today? (confirms or escalates TM-1)
+2. Does the OCR vendor contract cover contract PII, and is vendor-side retention off? (resolves TM-5's assumptions)
+
+### Out of scope
+E-signing flow itself (separate design); S3 bucket-policy review (assumed account-standard); browser-side threats (XSS) — covered by the web app's existing model.
+
+### Revisit trigger
+New entry point (e.g. email-in ingestion), new document consumer, or any change to support-access rules.

skilldrop_cli/data/packs/solution-architect/skills/threat-model/manifest.json

@@ -0,0 +1,11 @@
+{
+  "name": "threat-model",
+  "version": "0.1.0",
+  "description": "Produce a STRIDE threat model from a design doc, architecture description, or feature spec — assets and trust boundaries first, threats anchored to boundary crossings with concrete attack scenarios, severity-ranked with verifiable mitigations. Use when the user asks to threat-model a design, run a security review of an architecture, ask \"how could this be attacked\", or needs security sign-off input before build.",
+  "entrypoint": "SKILL.md",
+  "deps": { "npm": [], "pip": [] },
+  "env": { "required": [], "optional": [] },
+  "related": ["design-doc", "devils-advocate", "postmortem-generator", "reverse-architecture", "sonar-review"],
+  "tags": ["threat-model", "security", "stride", "architecture", "design-review", "trust-boundaries"],
+  "model": { "tier": "heavy", "rationale": "Adversarial reasoning over a design — cheaper models emit checklist residue, miss authz/insider paths, and inflate severity. Never downgrade." }
+}

skilldrop_cli/data/packs/solution-architect/skills/threat-model/reference.md

@@ -0,0 +1,69 @@
+# threat-model reference — STRIDE question banks + mitigation table
+
+Questions are prompts for the analysis, not a checklist to transcribe. A question only becomes a finding when it can be narrated as actor → path → result against a named boundary in the system under review.
+
+## STRIDE by boundary type
+
+### Internet → edge (public API, web app, webhook receiver)
+
+- **S** — Can a caller forge identity? Token audience/issuer validated? Webhook signatures checked, or just a "secret" URL? API keys distinguishable from user auth?
+- **T** — Are request bodies/headers trusted downstream (forwarded `X-User-Id`)? Can query params alter server-side behavior beyond their contract (mass assignment, prototype pollution)?
+- **R** — Are authentication failures and privileged calls logged with caller identity? Could a caller plausibly deny an action?
+- **I** — Do error responses leak stack traces, internal hostnames, versions? Do list endpoints leak other users' resource IDs? Timing differences on auth (user enumeration)?
+- **D** — Unauthenticated endpoints with expensive work (search, export, PDF render)? Rate limits per-IP only (trivially rotated) or per-principal? Payload size caps?
+- **E** — Do any endpoints trust client-supplied role/scope claims? Hidden admin routes guarded by obscurity?
+
+### Service → service (internal APIs, queues, RPC)
+
+- **S** — Does service B verify *which* service is calling, or accept anything inside the network ("flat trust")? mTLS / workload identity, or shared static secrets?
+- **T** — Are queue messages signed or schema-validated, or does the consumer trust whatever's enqueued? Can a compromised producer poison downstream state?
+- **R** — Can an action be traced through the chain (correlation IDs), or does attribution die at the first hop?
+- **I** — Do internal payloads carry more data than the consumer needs (full user record where an ID would do)?
+- **D** — Can one service exhaust another (no backpressure, unbounded fan-out, retry storms)?
+- **E** — Does a low-privilege service hold credentials that grant more than it uses (over-scoped IAM)?
+
+### App → datastore (DB, object storage, cache)
+
+- **S** — Shared DB credentials across services, or per-service identity?
+- **T** — String-built queries anywhere? Can the app write rows/objects outside its tenant scope (key-prefix discipline)?
+- **I** — Tenant isolation by `WHERE` clause convention only? Backups/replicas/cache covered by the same access controls as primaries? Presigned URLs scoped and short-lived?
+- **D** — Unbounded queries reachable from user input (no LIMIT, full scans)? Cache stampede paths?
+- **E** — Does the app account hold DDL/admin rights it never uses?
+
+### Human → system (admin panels, support tooling, CI/CD)
+
+- **S** — Admin auth at the same strength as user auth, or stronger (MFA, hardware keys)? Sessions revocable?
+- **T** — Can CI run arbitrary code with deploy credentials on a PR from a fork? Are build artifacts verifiable (signed, pinned digests)?
+- **R** — Are support/admin actions on user data logged immutably with operator identity?
+- **I** — Can support staff browse data beyond the case at hand (no purpose-binding)?
+- **E** — Path from "support role" to "admin role"? Long-lived personal tokens with org-wide scope?
+
+### Tenant → tenant (multi-tenant SaaS) — run with the authz pass
+
+- IDs guessable/enumerable across tenants (sequential integers, predictable UUIDs in URLs)?
+- Every query path tenant-scoped by construction (middleware/RLS), or by developer discipline?
+- Shared compute side-channels: can one tenant's load degrade another's (noisy neighbor as DoS)?
+- Export/report/search features — the classic cross-tenant leak surfaces.
+
+## Insider / compromised-credential pass
+
+Assume one legitimate credential is attacker-held: a user account, a support login, a CI token, one service's IAM role. For each, what's the blast radius before detection? Findings here are usually 🟧 — they need position, but position is bought cheaply (phishing, leaked token).
+
+## Common mitigations (with the verification that makes them real)
+
+| Threat shape | Mitigation | Verified by |
+|---|---|---|
+| Forged inbound identity | Token validation incl. audience+issuer+expiry; webhook HMAC | Negative test: tampered/expired token rejected in CI |
+| Cross-tenant access | Tenant scoping by construction (RLS, scoped prefixes), not per-query discipline | Cross-tenant fetch test as a permanent CI case |
+| Trusted internal headers | Strip/rewrite identity headers at the edge; sign internal assertions | Request with spoofed header from outside → rejected |
+| Queue poisoning | Schema validation on consume; producer allow-list | Malformed message → DLQ with alert, not crash-loop |
+| Resource exhaustion | Per-principal rate limits, payload caps, timeouts, bounded queries | Load test on the most expensive unauthenticated path |
+| Over-scoped credentials | Per-service identity, least-privilege IAM, short-lived tokens | Periodic automated diff of granted vs used permissions |
+| Silent admin abuse | Immutable audit log, purpose-bound support access | Audit-log entry asserted in admin-action integration tests |
+
+## Severity calibration
+
+- 🟥 **critical** — unauthenticated attacker, or any cross-tenant data compromise, against a top-ranked asset. Halt-the-build territory.
+- 🟧 **high** — authenticated user bypasses authz; single-tenant data exposure; insider blast radius covering a top asset.
+- 🟨 **medium** — requires chaining 2+ weaknesses or unusual position; degraded availability short of outage.
+- ⚪ **low / accepted** — real but marginal; document the acceptance so it's a decision, not an oversight.

skilldrop_cli/data/packs/sre-oncall/loops/operate/LOOP.md

@@ -0,0 +1,84 @@
+---
+name: operate
+description: Take a shipped service through detection, response, and learning — instrument it, write the runbook, communicate the incident, then feed the postmortem's deltas back into the runbook. Use when the user is preparing to run a service, is in an incident, or is writing a postmortem.
+---
+
+# operate
+
+The only loop whose failures are **irreversible and live**. The other four can be re-run at
+the cost of time; this one runs while real users are affected. Its feedback edge is the point:
+`postmortem-generator` emits runbook deltas phrased as edits, and those go straight back into
+`document`. An incident that changes no procedure has not been learned from.
+
+## Stages
+
+| # | Stage | Type | Skills | Gate |
+|---|---|---|---|---|
+| 1 | `instrument` | generate | [`observability-plan`](../../skills/observability-plan/SKILL.md) | — |
+| 2 | `document` | generate | [`runbook-generator`](../../skills/runbook-generator/SKILL.md) | — |
+| 3 | `respond` | generate | [`incident-comms`](../../skills/incident-comms/SKILL.md) | — |
+| 4 | `learn` | verify | [`postmortem-generator`](../../skills/postmortem-generator/SKILL.md) | **G3** human |
+
+## How to run this loop
+
+1. **Instrument first.** `observability-plan` decides what is measured and what pages a human.
+   You cannot respond to what you never detected, and you cannot write a runbook entry for an
+   alert that does not exist.
+2. **Write the runbook per alert.** Each alert the previous stage defined maps to a
+   `runbook-generator` entry. An alert with no procedure wakes someone who then has to think.
+3. **Respond to the audience the incident actually has.** `incident-comms` is staged —
+   detect, mitigate, resolve — and the stage determines the message. Writing a resolution
+   update during mitigation is the most common error here.
+4. **Learn at G3.** `postmortem-generator` analyses blamelessly and ends with runbook deltas.
+   A human signs off that the incident is closed. `REVISE` returns to `document`: the deltas
+   are the loop's output, and applying them is what closes it.
+
+Entering mid-loop is normal and expected. An incident starts at `respond`; a new service
+starts at `instrument`. Do not replay earlier stages for their own sake.
+
+## Verdicts
+
+Defined in [`contracts/terminals.json`](../../../../contracts/terminals.json). G3 emits `PROCEED`,
+`PROCEED WITH CONDITIONS`, `REVISE`, or `BLOCKED`. `PROCEED WITH CONDITIONS` means the
+incident is closed but named follow-ups are outstanding — they travel with the postmortem.
+
+## Non-interactive runs
+
+Never fabricate incident facts — timings, impact, customer counts, root cause. When the
+timeline is incomplete, emit `BLOCKED: need <the missing facts>` and name them. A confident
+postmortem built on guessed impact is worse than no postmortem.
+
+## When a stage's skill is not installed
+
+Name the missing skill and skilldrop as its source, do the minimal inline version, and record
+the stage as degraded. During a live incident, prefer the degraded inline version over
+stopping to install anything.
+
+## Run log (opt-in)
+
+Only when the environment variable `SKILLDROP_LOOP_LOG` is set to a file path: after each
+gate's verdict, append one JSON line to that file. Nothing else is recorded, and nothing is
+sent anywhere. When the variable isn't set, or you can't read it, skip this section.
+
+```bash
+printf '%s\n' '{"ts":"2026-10-01T14:03:00Z","loop":"operate","stage":"learn","gate":"G3","verdict":"PROCEED","round":1}' >> "$SKILLDROP_LOOP_LOG"
+```
+
+Fields: `ts` (UTC), `loop`, `stage`, `gate` (`null` for a stage without one), `verdict` (the
+gate's exact word), and `round` (1 for the first attempt, counting returns under the cap).
+`skilldrop loop-stats` summarises the file: which gates pass first time, which loop back, and
+which end in `BLOCKED`.
+
+## Quality bar
+
+- **Every alert has a runbook entry.** An alert that pages someone with no procedure is an interruption, not a signal.
+- **The postmortem ends in runbook deltas.** Analysis with no procedural change is a story about an outage.
+- **Comms match the incident's actual stage.** Detect, mitigate, and resolve have different audiences and different truths.
+- **Blameless means blameless.** Naming a person is a defect in the postmortem; naming a missing guardrail is the point.
+
+## Anti-patterns to avoid
+
+- ❌ **Writing the runbook before the observability plan.** Procedures for alerts that do not exist, and none for the alerts that do.
+- ❌ **Skipping `learn` because the incident was small.** Small incidents are where the cheap runbook deltas are.
+- ❌ **Guessing impact numbers to finish the postmortem.** State the gap; a postmortem's value is entirely in its accuracy.
+- ❌ **Replaying `instrument` during a live incident.** Enter at `respond`; the loop is not a checklist to complete in order.

skilldrop_cli/data/packs/sre-oncall/loops/operate/evals/eval_queries.json

@@ -0,0 +1,30 @@
+[
+  {
+    "query": "write the postmortem for last night's incident",
+    "should_trigger": true
+  },
+  {
+    "query": "run the operate loop on this service",
+    "should_trigger": true
+  },
+  {
+    "query": "what should we alert on and what's the runbook?",
+    "should_trigger": true
+  },
+  {
+    "query": "we're in an incident — what do I tell customers?",
+    "should_trigger": true
+  },
+  {
+    "query": "implement the fix for this bug",
+    "should_trigger": false
+  },
+  {
+    "query": "design the retry architecture",
+    "should_trigger": false
+  },
+  {
+    "query": "draft the PRD for this feature",
+    "should_trigger": false
+  }
+]

skilldrop_cli/data/packs/sre-oncall/loops/operate/evals/evals.json

@@ -0,0 +1,25 @@
+{
+  "loop_name": "operate",
+  "evals": [
+    {
+      "id": "postmortem-must-produce-runbook-deltas",
+      "prompt": "Run the operate loop. Our rate limiter alert fired last night — a customer's retry loop hammered the API for 40 minutes.",
+      "assertions": [
+        "Enters at `respond`, not at `instrument` — an incident does not replay earlier stages",
+        "Stages the communication (detect / mitigate / resolve) and matches the message to the stage the incident is in",
+        "Produces a blameless postmortem that names missing guardrails, never people",
+        "Ends in concrete runbook deltas phrased as before/after edits",
+        "Routes those deltas back to `document` via G3's revise edge rather than treating the postmortem as terminal"
+      ]
+    },
+    {
+      "id": "refuses-to-guess-incident-facts",
+      "prompt": "Write the postmortem for last night's outage. I don't have the exact timeline or customer impact numbers yet.",
+      "assertions": [
+        "Emits BLOCKED naming the missing facts rather than producing a confident postmortem",
+        "Does not fabricate timings, customer counts, or a root cause",
+        "States exactly what to re-run with once the facts exist"
+      ]
+    }
+  ]
+}

skilldrop_cli/data/packs/sre-oncall/loops/operate/loop.json

@@ -0,0 +1,41 @@
+{
+  "$comment": "RFC-0028. The only loop whose failures are irreversible and live. Its feedback edge is real and already documented in the repo: postmortem-generator emits runbook deltas phrased as edits for runbook-generator.",
+  "name": "operate",
+  "version": "0.2.0",
+  "description": "Take a shipped service through detection, response, and learning — instrument it, write the runbook, communicate the incident, then feed the postmortem's deltas back into the runbook. Use when the user is preparing to run a service, is in an incident, or is writing a postmortem.",
+  "entrypoint": "LOOP.md",
+  "kind": "loop",
+  "cap": 3,
+  "stages": [
+    {
+      "id": "instrument",
+      "type": "generate",
+      "intent": "Decide what is measured and what pages a human. You cannot respond to what you never detected.",
+      "skills": ["observability-plan"]
+    },
+    {
+      "id": "document",
+      "type": "generate",
+      "intent": "Write the procedure the on-call follows at 3am, per alert the previous stage defined.",
+      "skills": ["runbook-generator"]
+    },
+    {
+      "id": "respond",
+      "type": "generate",
+      "intent": "Communicate during the incident, to the audience that needs it, at the stage the incident is actually in.",
+      "skills": ["incident-comms"]
+    },
+    {
+      "id": "learn",
+      "type": "verify",
+      "intent": "Analyse blamelessly and emit runbook deltas. An incident that changes no procedure has not been learned from.",
+      "skills": ["postmortem-generator"],
+      "gate": {
+        "id": "G3",
+        "kind": "human",
+        "verdicts": ["PROCEED", "PROCEED WITH CONDITIONS", "REVISE", "BLOCKED"],
+        "revise_to": "document"
+      }
+    }
+  ]
+}

skilldrop_cli/data/packs/sre-oncall/pack.json

@@ -0,0 +1,59 @@
+{
+  "description": "Operate the service: runbooks, observability design, incident communications, postmortems, and capacity/cost models.",
+  "display_name": "SRE / on-call",
+  "keywords": ["runbook", "incident", "postmortem", "observability", "slo"],
+  "links": {
+    "documentation": "https://sananthanarayan.github.io/skilldrop/packs/sre-oncall/"
+  },
+  "maintainers": [
+    {
+      "name": "sananthanarayan"
+    }
+  ],
+  "first-value": {
+    "audience-posture": "technical",
+    "prerequisites": [],
+    "starter-task": "Write the runbook an on-call engineer can follow at 3am",
+    "starter-prompt": "Write a runbook for our payments-api service: it runs in the Kubernetes namespace payments, depends on Postgres and Stripe, and pages the payments on-call rotation.",
+    "verification": "runbook-generator returns a runbook with rollback commands, the common incidents and what to do for each, and an escalation path. Facts you did not give it are marked missing, not invented.",
+    "recovery": "If runbook-generator does not activate, ask for it by name (\"use runbook-generator\") and check that its folder exists in your skills folder (`~/.claude/skills/` by default)."
+  },
+  "requires": ["core"],
+  "journey": {
+    "when": "You are getting a service ready to run, handling an incident, or writing it up afterwards; you can join at whichever stage you are in.",
+    "you_bring": [
+      "the service: what it does, where it runs, what it depends on, who gets paged",
+      "during or after an incident: the timeline, the Slack thread or pager log, and the known impact",
+      "facts only; the skills mark anything you leave out as missing rather than guessing it"
+    ],
+    "steps": [
+      {
+        "skill": "observability-plan",
+        "you_do": "Describe the service and its main user journeys.",
+        "you_get": "SLIs and SLOs with error budgets, burn-rate alerts split into page and ticket, and a metrics, logs and traces plan with a cardinality and cost budget."
+      },
+      {
+        "skill": "runbook-generator",
+        "you_do": "Give it the service details and the alerts from the plan.",
+        "you_get": "A runbook with deploy and rollback steps, what to do for each common incident, escalation, SLOs, dashboards and dependencies, with unknown facts marked missing."
+      },
+      {
+        "skill": "incident-comms",
+        "you_do": "During an incident, say what users are seeing and what stage you are in (detect, mitigate or resolve).",
+        "you_get": "Separate updates for the status page, internal stakeholders and execs, each leading with user impact and naming the next update time, with no guessed cause or ETA."
+      },
+      {
+        "skill": "postmortem-generator",
+        "you_do": "Paste the incident thread, pager timeline and notes once it is over.",
+        "you_get": "A blameless postmortem with quantified impact, a UTC timeline showing detection and mitigation gaps, contributing factors, up to eight action items, and runbook deltas phrased as edits.",
+        "decide": "Gate G3, a human call: PROCEED closes it, PROCEED WITH CONDITIONS closes it with named follow-ups, REVISE sends the deltas back to the runbook."
+      },
+      {
+        "skill": "delivery-metrics-report",
+        "you_do": "A few weeks later, export deployments and incidents as CSV and ask whether the postmortem's actions moved anything.",
+        "you_get": "Change fail rate, failed deployment recovery time, lead time and deployment frequency computed from the exports, with the weekly trend and the rows it had to skip."
+      }
+    ],
+    "you_end_with": "An observability plan, a runbook tied to its alerts, the incident updates you sent, and a postmortem whose deltas go back into the runbook."
+  }
+}

skilldrop_cli/data/packs/sre-oncall/skills/capacity-cost-model/SKILL.md

@@ -0,0 +1,65 @@
+---
+name: capacity-cost-model
+description: Build a capacity and cost model for a service or feature — sized from a demand driver and its growth curve, not from instance types; unit economics (cost per request/tenant/GB); peak-vs-average and headroom as explicit decisions; cost at 1×/3×/10× with scaling cliffs named; and the forgotten line items (egress, logging, NAT, non-prod) checklisted. Use when the user needs to estimate cloud/infra cost, size capacity for launch or growth, project the bill at scale. For reviewing a bill you already have, use cloud-cost-review.
+---
+
+# capacity-cost-model
+
+Turns "how much will this cost to run?" into a model a reviewer can re-run and finance can trust — sized from **demand**, expressed in **cost per unit**, and honest about the line items everyone forgets until the invoice. Distinct from `business-case` (which decides *whether* to invest, across options) and `nfr-spec` (which *sets* the throughput/availability targets); this models the resources and dollars to *meet* a target you've already chosen.
+
+## How to respond
+
+1. **Start from the demand model, never from instance types.** The first question is "how much of what?" — the **driver** (requests/sec, tenants, GB stored, events/day, concurrent users), its **current value**, its **growth curve**, and the **peak-to-average ratio**. Ask at most 2 questions, spent on the driver's current volume + source and the peak ratio (the spikiness that decides static-vs-autoscale). Sizing to a round instance count instead of to demand is how clusters end up 80% idle or 200% over.
+
+2. **Express everything as unit economics.** Cost per request / per tenant / per 1k events / per GB-month — because that's what scales predictably, what finance budgets in, and what reveals whether the architecture gets cheaper or more expensive per unit as it grows. ✅ *"$0.012 per active tenant per day, dominated by the per-tenant search index"* — ❌ *"about $4k/month"* (a number with no denominator can't be reasoned about at 10×).
+
+3. **Model the components against the cost catalog** ([`reference.md`](reference.md)) — compute, storage, **network egress** (the forgotten heavyweight), managed-service tiers, **logging/observability** (routinely a top-3 surprise), backups/DR, data transfer cross-AZ/region, and **non-production environments** (dev/staging/idle often 30–50% of the bill). Each line: the quantity from the demand model × the unit price, with the price's source/date tagged. Missing the egress and observability lines is the single most common way a model lands 40% low.
+
+4. **Make peak-vs-average and headroom explicit decisions, not defaults.** State both the average load (what you bill for) and the peak (what you must serve), and the chosen **target utilization + buffer** with its reasoning: ✅ *"size to peak × 1.3 for failover + spike; accept ~55% average utilization because the spike is revenue-critical"*. Over-provisioning burns money; under-provisioning is an incident — the headroom number is where that tradeoff is decided, so it's named, not buried in a rounded-up instance count.
+
+5. **Project at 1× / 3× / 10× and find the scaling cliffs.** Cost rarely scales linearly — name where it jumps: the next instance/managed-service tier, cross-AZ egress kicking in, a license seat band, single-node → sharded, a free-tier ceiling. ✅ *"linear to ~5×, then the search tier forces a sharded cluster (+$3k/mo step) at ~6×"*. A model that's a single multiplication hides the cliff that wrecks the budget.
+
+6. **Rank the cost drivers and use ranges.** The 2–3 line items that dominate get named (optimization targets them, not the rounding error). Outputs are **ranges with a stated lean** (low/expected/high), never false precision — three estimated inputs don't produce "$4,271/mo". Tag input confidence like `business-case` does.
+
+7. **Set the cost guardrails.** Budget alert thresholds, and the **unit-cost regression check**: cost-per-unit should hold flat or fall as volume grows; if the model shows it *rising* with scale, that's a flagged architectural problem, not a footnote. (Mirrors `success-metrics`' guardrail discipline; the alerting itself is an `nfr-spec` cost target.)
+
+8. **Emit with [`templates/cost-model.md`](templates/cost-model.md)** in one message: demand model, component table with unit prices, unit economics, total at average + peak, growth scenarios with cliffs, cost-driver ranking, the forgotten-costs checklist (each ticked present or n/a), and guardrails. State the assumptions that most move the total at the top.
+
+## Useful references in this skill
+
+- [`reference.md`](reference.md) — the cost-component catalog, the forgotten-costs checklist, headroom guidance, and common scaling cliffs
+- [`templates/cost-model.md`](templates/cost-model.md) — the model skeleton with demand, component, and growth-scenario tables
+
+## Quality bar
+
+- **Sized from a demand driver with a growth curve**, not a chosen instance count. The driver and its source are stated.
+- **Every cost is a unit cost × a quantity**, with the unit price's source and date tagged. A bare monthly total fails.
+- **Egress, observability, and non-prod lines are present** (or explicitly n/a). Their absence is the signature of a model that's 40% low.
+- **Headroom and peak-vs-average are explicit decisions** with reasoning, not absorbed into a rounded number.
+- **Scaling cliffs are named in the 1×/3×/10× projection.** A linear extrapolation that hides a tier jump is a budget trap.
+- **Outputs are ranges with a lean; the unit-cost-at-scale trend is checked.** Rising per-unit cost with growth is flagged as an architecture issue.
+
+## When to use this skill
+
+- ✅ Estimating run cost for a new service/feature before launch
+- ✅ Sizing capacity for a launch or a known growth event
+- ✅ "What will this cost at 10× / when we hit N tenants?"
+- ✅ Finding where the next scaling cliff is as demand grows
+
+## When NOT to use this skill
+
+- ❌ Deciding whether to build/buy/invest at all — that's `business-case` (this can feed its run-cost line)
+- ❌ Setting the performance/availability targets — that's `nfr-spec` (this sizes to meet them)
+- ❌ The migration/rollout sequence — that's `migration-plan`
+- ❌ Finding waste in a bill you already pay — that's `cloud-cost-review`, which works from the cost export
+- ❌ A fixed-price SaaS seat with no scaling math — just read the price sheet
+
+## Anti-patterns to avoid
+
+- ❌ **Sizing from instance types.** "Let's run 3 large nodes" before knowing the load — that's a guess wearing a SKU, idle or overwhelmed by luck.
+- ❌ **The denominator-free total.** "$4k/month" with no per-unit cost can't be projected, compared, or optimized.
+- ❌ **Forgetting egress and observability.** The two line items that turn a tidy estimate into a 40%-low one; the checklist exists because they're forgotten every time.
+- ❌ **Ignoring non-prod.** Three idle staging environments and a never-scaled-down dev cluster are real money the model pretends doesn't exist.
+- ❌ **Linear extrapolation past a cliff.** "10× the load, 10× the cost" right up until the sharded-cluster step doubles it. Name the cliff.
+- ❌ **False precision.** "$4,271.40/mo" from estimated inputs reads as certainty the model doesn't have. Ranges with a lean.
+- ❌ **Missing the rising-unit-cost flag.** A model where cost-per-tenant climbs with scale is describing an architecture that gets worse the more it succeeds — that's the headline, not a row.

skilldrop_cli/data/packs/sre-oncall/skills/capacity-cost-model/evals/eval_queries.json

@@ -0,0 +1,34 @@
+[
+  {
+    "query": "What will this service cost to run at 10x our current tenants?",
+    "should_trigger": true
+  },
+  {
+    "query": "Size capacity and estimate the AWS bill for our launch next quarter",
+    "should_trigger": true
+  },
+  {
+    "query": "We expect 5x traffic next year — model where the next cost cliff is",
+    "should_trigger": true
+  },
+  {
+    "query": "Build a cost-per-request model for the new ingestion pipeline",
+    "should_trigger": true
+  },
+  {
+    "query": "Should we build or buy a search platform? Write the business case",
+    "should_trigger": false
+  },
+  {
+    "query": "Set the latency and availability targets for the search service",
+    "should_trigger": false
+  },
+  {
+    "query": "Plan the cutover sequence for moving search from Elasticsearch to OpenSearch",
+    "should_trigger": false
+  },
+  {
+    "query": "Our AWS bill jumped 24% last month — find the waste in this cost export",
+    "should_trigger": false
+  }
+]

skilldrop_cli/data/packs/sre-oncall/skills/capacity-cost-model/evals/evals.json

@@ -0,0 +1,19 @@
+{
+  "skill_name": "capacity-cost-model",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "Model the run cost for our new document-search service at Northwind on AWS. Demand: 1,200 active tenants today, growing about 8% a month; average 15 searches/sec, peak 60/sec weekday mornings. Each tenant indexes about 2 GB. We'll use OpenSearch, ECS Fargate for the API, and CloudWatch for logs. There are dev and staging environments too. What will it cost now and at 3x and 10x?",
+      "assertions": [
+        "Sizes from the demand driver (tenants and searches/sec, with the 8%/month growth curve), not from a chosen instance count",
+        "Every cost line is a unit price x quantity, with the unit price's source and date tagged",
+        "Expresses unit economics (e.g. cost per active tenant per month), not just a bare monthly total",
+        "Egress, observability (CloudWatch logs), and non-prod (dev and staging) lines are present or explicitly marked n/a",
+        "States average and peak load separately and makes the headroom/target-utilization choice explicit with reasoning",
+        "Projects 1x/3x/10x and names at least one scaling cliff (e.g. an OpenSearch tier or shard step) rather than extrapolating linearly",
+        "Outputs are low/expected/high ranges with a lean, and the cost-per-tenant trend at scale is checked and flagged if it rises",
+        "Does not invent demand figures or services beyond those in the prompt; unknown inputs are stated as assumptions"
+      ]
+    }
+  ]
+}

skilldrop_cli/data/packs/sre-oncall/skills/capacity-cost-model/manifest.json

@@ -0,0 +1,11 @@
+{
+  "name": "capacity-cost-model",
+  "version": "0.2.0",
+  "description": "Build a capacity and cost model for a service or feature — sized from a demand driver and its growth curve, not from instance types; unit economics (cost per request/tenant/GB); peak-vs-average and headroom as explicit decisions; cost at 1×/3×/10× with scaling cliffs named; and the forgotten line items (egress, logging, NAT, non-prod) checklisted. Use when the user needs to estimate cloud/infra cost, size capacity for launch or growth, project the bill at scale. For reviewing a bill you already have, use cloud-cost-review.",
+  "entrypoint": "SKILL.md",
+  "deps": { "npm": [], "pip": [] },
+  "env": { "required": [], "optional": [] },
+  "related": ["business-case", "cloud-cost-review", "migration-plan", "nfr-spec", "success-metrics"],
+  "tags": ["capacity-planning", "cost", "cloud", "finops", "sizing", "unit-economics"],
+  "model": { "tier": "standard", "rationale": "Quantitative projection from a demand model against a fixed cost catalog. Headroom and scaling-cliff judgment is bounded by the reference; escalate via ambiguous-input on novel architectures." }
+}

skilldrop_cli/data/packs/sre-oncall/skills/capacity-cost-model/reference.md

@@ -0,0 +1,54 @@
+# capacity-cost-model reference — component catalog, forgotten costs, cliffs
+
+All unit prices are illustrative placeholders — the skill tags each with its real source and date. Cloud pricing changes; never hard-code a number without a date.
+
+## Cost-component catalog (model every applicable line)
+
+| Component | Demand quantity | Typical unit price shape | Notes |
+|---|---|---|---|
+| **Compute** | peak concurrent work / rps | $/vCPU-hr, $/instance-hr, $/request (serverless) | size to peak or autoscale; state which |
+| **Storage** | GB stored × growth | $/GB-month, tiered (hot/warm/cold) | growth is cumulative — model the curve, not a point |
+| **Network egress** | GB out to internet / cross-region | $/GB, often tiered, free inbound | THE forgotten heavyweight; cross-AZ counts too |
+| **Managed services** (DB, cache, queue, search) | IOPS, nodes, throughput units | per-node / per-RU / per-throughput-tier | tier jumps are the classic cliff |
+| **Logging / observability** | GB ingested, metrics cardinality, traces | $/GB ingested, $/metric series | routinely top-3; high-cardinality labels explode it |
+| **Backups / DR** | snapshot GB, replica count, cross-region copy | $/GB-month × retention × copies | retention × copies multiplies fast |
+| **Data transfer** | inter-service, cross-AZ, cross-region | $/GB | "internal" traffic is not always free |
+| **Non-production** | dev + staging + preview envs | fraction of prod, often 30–50% | idle/never-scaled-down is pure waste — model it |
+| **Support / licenses** | seats, support plan %, per-seat tools | $/seat, % of spend | seat bands are a cliff |
+| **Idle / always-on** | min instances, provisioned capacity, NAT gateways | $/hr regardless of load | NAT gateways and provisioned concurrency bill 24/7 |
+
+## Forgotten-costs checklist (tick each: present / n/a-with-reason)
+
+- [ ] Network egress to internet
+- [ ] Cross-AZ / cross-region data transfer
+- [ ] Logging & observability ingestion (and metric cardinality)
+- [ ] Backups × retention × replica copies
+- [ ] Non-prod environments (dev/staging/preview), incl. idle
+- [ ] NAT gateway / load balancer / always-on networking
+- [ ] Provisioned-but-idle capacity (min autoscale floor, reserved-but-unused)
+- [ ] Support plan (% of spend) and per-seat tooling
+- [ ] Data egress on delete/migration (one-time but real)
+- [ ] Free-tier expiry (the bill that appears in month 13)
+
+A model that hasn't consciously cleared this list is presumed 30–40% low.
+
+## Headroom guidance (state the decision)
+
+- **Target utilization:** the average you design for. 50–70% is common for spiky interactive workloads; 80%+ only for smooth, predictable, non-critical load.
+- **Buffer:** peak × (failover redundancy + spike margin). N+1 across AZs is a multiplier, not a rounding.
+- **Autoscale vs static:** if peak-to-average > ~2–3×, autoscaling usually beats provisioning for peak. State the floor (min capacity bills 24/7) and the scale-up latency (cold starts during a spike are an availability risk, an `nfr-spec` concern).
+- The headroom number is a money-vs-incident tradeoff — write the reasoning, not just the multiplier.
+
+## Common scaling cliffs (name the one that bites first)
+
+- **Managed-service tier jump** — DB/cache/search moves to the next node size or shard count; cost steps, not slopes.
+- **Single-node → distributed** — replication, coordination, and cross-node transfer appear all at once.
+- **Cross-AZ egress threshold** — multi-AZ for HA turns "internal" traffic into a metered line.
+- **Free-tier / committed-use ceiling** — the discount or free allowance runs out; effective unit price jumps.
+- **License/seat band** — per-seat tools and support plans step at user-count thresholds.
+- **Observability cardinality wall** — a new label dimension multiplies metric series and the bill with them.
+- **Connection/throughput limits** — hitting a managed service's connection cap forces a proxy/pooler tier.
+
+## Unit-cost-at-scale check
+
+Compute cost-per-unit at 1×, 3×, 10×. The healthy shape is flat or declining (economies of scale). If per-unit cost **rises** with volume, the model has found an architectural anti-pattern (per-tenant fixed overhead, N² chatter, cardinality explosion) — surface it as the headline finding, because it means success makes the economics worse.