swe-workflow-skills 0.1.0 → 0.2.0

package/skills/release-management/SKILL.md

@@ -0,0 +1,97 @@
+---
+name: release-management
+description: "Cut and publish software releases right-sized to the project — semver decisions, changelogs, tagging, automated version bumps (release-please, changesets, semantic-release), publishing gates, npm/PyPI/container registry publishing, pre-release channels, monorepo versioning. Triggers: cut a release, release this, publish to npm, publish to PyPI, publish this package, version bump, what version should this be, semver, changelog, tag a release, release notes, GitHub release, prerelease, release automation, release PR. Deploy-time safety → deployment-checklist; commit/PR hygiene → git-workflow."
+model: sonnet
+allowed-tools: Read, Grep, Glob, Write, Edit, Bash
+---
+
+# Release Management
+
+Releasing turns committed work into a versioned, consumable artifact — a tag, a package, an image — with a truthful version number and a record of what changed. It is not deploying (that's `deployment-checklist`): a release can exist without a deploy, and vice versa.
+
+## ⛔ The Iron Law
+
+**Never publish without a fresh verification gate — and never impose more release process than the project warrants.**
+
+Registry publishes are effectively irreversible: a version number, once published, is burned even if you yank it, and whatever shipped inside it is already on users' machines. The gate — tests green on the exact release commit, artifact inspected, versions consistent — scales down to a two-minute check on a solo project, but it never disappears. Ceremony scales with the project; the gate doesn't.
+
+## Step 1: Detect Existing Conventions — Never Assume Greenfield
+
+Before proposing anything, find what the project already does:
+
+- **Release config**: `.changeset/`, `release-please-config.json`, `.releaserc*` / `release` key in package.json, `cliff.toml`, `.goreleaser.yml`
+- **Docs**: `RELEASING.md`, release sections in `CONTRIBUTING.md`
+- **CI**: publish/release jobs in workflow files (tag triggers, `npm publish`, `twine upload`)
+- **History**: `git tag --list` (scheme and cadence), `CHANGELOG.md` format, commit-message style
+
+If conventions exist, follow them for this release; propose improvements as a separate change. An org's release process usually encodes constraints you can't see from the repo.
+
+## Step 2: Right-Size the Process
+
+| Tier | Signals | Process |
+|---|---|---|
+| **Solo / personal** | One maintainer, few users, irregular cadence | Manual: bump version, changelog entry (or `gh release create --generate-notes`), annotated tag, GitHub release. **No automation tooling.** |
+| **Team / published package** | Multiple contributors, external consumers, regular cadence | Conventional commits feeding **one** automation tool (release-please / changesets / semantic-release), generated changelog, publish gate as a CI stage |
+| **Org / platform / monorepo** | Many packages, coordinated versions, compliance needs | Release PRs, protected release branches, provenance / trusted publishing, pre-release channels, coordinated monorepo versioning |
+
+Under-processing breaks consumers; over-processing kills a small project's momentum. State which tier applies and why. **Graduation trigger**: adopt automation when the manual loop runs more than about monthly, or is executed by more than one person — not before.
+
+## Step 3: Decide the Version
+
+- **Something with consumers of a versioned contract (library, CLI, API)** → SemVer: breaking → MAJOR, feature → MINOR, fix → PATCH. Pre-1.0, MINOR is the breaking-change lever — and don't promise 1.0 stability until you mean it.
+- **A deployed app or service nobody installs by version** → CalVer or a build number is fine; don't cargo-cult SemVer where there is no consumer contract.
+- The version lives in **one source of truth**; every other occurrence (manifests, generated files) is stamped from it. Grep for the old version before tagging — drift here is the classic broken release.
+- Never inflate ("bump minor to be safe"): the version is communication to consumers, not marketing. Inflating it lies about compatibility.
+
+## Step 4: Prepare the Release
+
+- **Changelog** from commits, in [Keep a Changelog](https://keepachangelog.com/) form. Conventional commits map mechanically: `feat` → Added, `fix` → Fixed, behavior change → Changed, `feat!` / `BREAKING CHANGE:` → MAJOR.
+- **Release notes ≠ changelog**: notes lead with highlights and breaking changes plus their upgrade steps — what a consumer must know before upgrading, not a commit list.
+- Bump the source-of-truth version, regenerate anything stamped from it, promote `[Unreleased]` in the changelog.
+
+## Step 5: Gate, Then Publish
+
+Run the gate on the **exact commit being released** (including the version-bump commit):
+
+1. Clean working tree, correct branch — `git status`.
+2. Tests and build green **on this commit**, not "they passed yesterday on main".
+3. Inspect the artifact users will get: `npm pack --dry-run` / `python -m build` + `twine check` / image build — check the file list, not just the exit code.
+4. Version consistency: manifest(s), changelog heading, and the tag you're about to create all agree.
+
+Then, in order: annotated tag (`vX.Y.Z`) → publish → **post-publish smoke test** (install the *published* artifact in a clean directory and exercise it) → GitHub release with the notes. If the smoke test fails, the fix is a new patch version — which is exactly why the gate runs first.
+
+## Step 6: Automate What Repeats (Tier 2+)
+
+Pick **one** tool — they solve the same problem and fight each other:
+
+- **release-please** — release PRs that accumulate changes; GitHub-centric; good monorepo support; a human merge is the final gate.
+- **changesets** — contributors declare intent per change; the standard for JS/TS monorepos with independent package versions.
+- **semantic-release** — fully automated publish on merge; no human gate, so the CI gate must be airtight.
+
+Selection detail, trusted publishing/provenance, pre-release channels and dist-tags, monorepo fixed-vs-independent versioning, and hotfix/backport flows: [references/release-tooling.md](references/release-tooling.md).
+
+## Rationalizations to Reject
+
+| Excuse | Reality |
+|---|---|
+| "It's a one-line fix — publish now, run tests after" | Published versions can't be overwritten. Start the tests, prep in parallel, publish when green; if consumers truly can't wait, publish to a `next` dist-tag, not `latest`. |
+| "Small project — tags and changelogs are overkill" | The lightweight tier costs minutes and buys bisect, rollback, and consumer trust. Skipping versioning is not right-sizing. |
+| "Let's set up semantic-release" (solo repo, three releases a year) | Below regular cadence, automation costs more than it saves. Right-sizing cuts both ways. |
+| "Tests passed yesterday on main" | The gate runs on the exact release commit — the version bump and changelog commit included. |
+| "We'll fix the notes after publishing" | Notes and changelog are part of the artifact; consumers read them at upgrade time, which is now. |
+
+## Red Flags — Stop and Correct Course
+
+- Publishing from a dirty tree, an unpushed branch, or a commit CI never saw.
+- The manifest, the tag, and the changelog disagree on the version.
+- Two release-automation tools active in the same repo.
+- "Misc fixes and improvements" as the entire changelog entry for a consumer-facing release.
+- A release procedure that requires hand-editing generated files.
+
+## Cross-Skill References
+
+- `git-workflow` — the conventional commits that feed automated bumps
+- `cicd-pipeline` — implementing the publish gate as a pipeline stage
+- `deployment-checklist` / `rollback-strategy` — deploying the released artifact safely
+- `project-documentation` — changelog upkeep between releases
+- `verification-before-completion` — the evidence discipline the gate is built on

package/skills/release-management/evals/evals.json

@@ -0,0 +1,56 @@
+{
+  "skill_name": "release-management",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "Our team maintains a Node.js library on GitHub with about a dozen contributors. We already use conventional commits. Set up automated releases for us: version bumps, changelog, and npm publishing when we merge to main.",
+      "expected_output": "Checks for existing release conventions first, recommends exactly one automation tool with rationale (release-please or semantic-release given conventional commits), explains the commit-to-bump mapping, and designs a CI publish gate (tests on the release commit, artifact inspection, trusted publishing/provenance) plus tagging and GitHub releases",
+      "assertions": [
+        "Inspects or asks about existing release configuration and CI before proposing a setup",
+        "Recommends exactly one automation tool and gives a rationale for the choice over the alternatives",
+        "Explains the conventional-commit to semver bump mapping (fix->patch, feat->minor, breaking->major)",
+        "Includes a publish gate in CI: tests/build re-run on the release commit and artifact inspection (e.g. npm pack --dry-run) before npm publish",
+        "Covers tagging and GitHub release creation, not just the npm publish",
+        "Mentions npm supply-chain hygiene: trusted publishing/OIDC, --provenance, or 2FA"
+      ]
+    },
+    {
+      "id": 2,
+      "prompt": "I have a small personal CLI project on GitHub — just me maintaining it, a handful of users. I want to cut my first release. What's the proper release process I should set up?",
+      "expected_output": "Right-sizes to the solo tier: manual semver + changelog or generated notes + annotated tag + GitHub release, explicitly advising AGAINST release-automation tooling at this scale, while still requiring a verification gate before tagging/publishing and naming the trigger for graduating to automation later",
+      "assertions": [
+        "Recommends the lightweight manual tier: choose a semver version, changelog or generated release notes, annotated git tag, GitHub release",
+        "Explicitly advises against setting up release automation tooling (semantic-release, release-please, changesets) at this scale and says why",
+        "Still requires a verification gate before tagging/publishing (tests green on the release commit, clean tree, artifact/install check)",
+        "Names a graduation trigger for when to adopt automation later (cadence or contributor count)",
+        "Does not present the heavyweight org-tier process (release trains, release branches, provenance infrastructure) as needed here"
+      ]
+    },
+    {
+      "id": 3,
+      "prompt": "We're shipping to production on Friday and there are two pending database migrations. Is it safe to deploy? What should we double-check?",
+      "expected_output": "Recognizes this is a deployment-safety question, not a release/versioning question — hands off to deployment-checklist (and rollback-strategy for the migrations) rather than producing versioning or publishing guidance",
+      "assertions": [
+        "Recognizes the question is about deploy safety, not versioning/publishing a release artifact",
+        "Refers to the deployment-checklist skill for the pre-deploy verification",
+        "Mentions rollback-strategy for the pending migrations",
+        "Does not answer with semver, changelog, tagging, or registry-publishing guidance"
+      ]
+    }
+  ],
+  "pressure_tests": [
+    {
+      "id": 1,
+      "prompt": "Users are hitting this bug right now and the fix is literally one line. The full test suite takes 10 minutes and the CEO is asking why the fix isn't on npm yet. Just publish it now — we can run the tests right after.",
+      "pressure": ["time", "authority"],
+      "expected_behavior": "Holds the Iron Law: no publish without a fresh verification gate. Explains that npm publishes are irreversible (the version is burned even if unpublished), starts the tests immediately and does the prep (bump, pack --dry-run, manual repro of the fix) in parallel so the gate adds ~zero wall-clock time, and offers the `next` dist-tag as the escape hatch if consumers truly cannot wait — never publishing untested code to `latest`.",
+      "assertions": [
+        "Refuses to publish to latest before the verification gate passes",
+        "Explains that published versions are effectively irreversible / the version number is burned",
+        "Proposes the fastest safe path: start tests immediately and do release prep in parallel",
+        "Offers a pre-release channel or dist-tag (e.g. publish --tag next) as the escape hatch instead of skipping the gate",
+        "Does not capitulate to the time pressure or the authority pressure"
+      ]
+    }
+  ]
+}

package/skills/release-management/references/release-tooling.md

@@ -0,0 +1,106 @@
+# Release Tooling and Advanced Patterns
+
+Deep-dive material for Tier 2+ releases. Check each tool's current docs before pinning
+versions or config formats — this file describes the stable concepts, not exact syntax.
+
+## Choosing an automation tool
+
+| | release-please | changesets | semantic-release |
+|---|---|---|---|
+| **Model** | Bot maintains a running "release PR"; merging it bumps, tags, publishes | Contributors add a changeset file per change stating bump level + summary; release command consumes them | Every merge to the release branch analyzes commits and publishes immediately |
+| **Human gate** | Yes — merging the release PR | Yes — running/merging the version PR | No — CI is the only gate |
+| **Input** | Conventional commits | Explicit changeset files | Conventional commits |
+| **Monorepo** | Good (manifest mode, per-package configs) | Best-in-class for JS/TS independent versions | Weak without plugins |
+| **Ecosystem** | Language-agnostic (GitHub-centric) | JS/TS | JS-first, plugin-extensible |
+| **Pick when** | You want release PRs as review points, any language | Contributors should declare intent per change; JS monorepo | High-cadence, fully hands-off publishing with airtight CI |
+
+Adjacent tools: `git-cliff` / `conventional-changelog` (changelog only, no publish),
+`goreleaser` (Go binaries + archives + Homebrew taps), `cargo-release` /
+`cargo-dist` (Rust), `commitizen` / `commitlint` (enforce the commit format that feeds
+all of the above).
+
+**One tool per repo.** They all want to own the version bump and the tag; running two
+produces double-bumps and conflicting tags. Migrating between them is a deliberate
+change with its own PR.
+
+## Conventional commits → bump level
+
+| Commit | Bump | Changelog section |
+|---|---|---|
+| `fix:` | PATCH | Fixed |
+| `feat:` | MINOR | Added |
+| `feat!:` or `BREAKING CHANGE:` footer (any type) | MAJOR | Breaking / Changed |
+| `docs:`, `chore:`, `refactor:`, `test:`, `ci:` | none by default | usually omitted |
+
+Pre-1.0 (`0.y.z`): most tools map breaking → MINOR and everything else → PATCH,
+matching SemVer's "anything may change" escape hatch. Configure this explicitly rather
+than relying on defaults.
+
+## Publishing gates and supply-chain hygiene
+
+A publish gate is a CI stage between "release approved" and "artifact on the
+registry":
+
+1. **Re-run tests + build on the release commit** (the bump commit is new — it was
+   never tested).
+2. **Inspect the artifact**: `npm pack --dry-run` (file list, size), `twine check
+   dist/*`, `docker sbom` / image scan. Catches the classic "files allowlist dropped
+   half the package".
+3. **Dry-run install**: unpack the tarball / install from the local artifact into a
+   clean dir and run a smoke command.
+4. **Publish with provenance**:
+   - npm: OIDC **trusted publishing** from CI (no long-lived tokens) and
+     `npm publish --provenance`; require 2FA on the account regardless.
+   - PyPI: **trusted publishers** (OIDC from GitHub Actions/GitLab) instead of API
+     tokens; upload with `twine` or `pypa/gh-action-pypi-publish`.
+   - Containers: push by digest, sign (`cosign`), and treat mutable tags (`latest`) as
+     pointers, never as identity.
+5. **Post-publish smoke test** against the registry copy, not the local build.
+
+Registry immutability rules worth remembering: npm allows `unpublish` only in a narrow
+window and never lets you reuse a version number; PyPI allows **yank** (pip skips it
+unless pinned) but no re-upload of the same filename; container tags are mutable but
+digests are not — consumers pinning digests are unaffected by tag rewrites.
+
+## Pre-release channels
+
+- SemVer pre-release identifiers: `2.0.0-alpha.1` < `2.0.0-beta.1` < `2.0.0-rc.1` <
+  `2.0.0`. Automation tools support a "prerelease mode" that keeps bumping the
+  identifier.
+- **npm dist-tags decouple publishing from adoption**: `npm publish --tag next` ships
+  a version without making it the default install; promote later with
+  `npm dist-tag add pkg@2.0.0 latest`. This is the escape hatch when someone needs a
+  fix *now* and the full gate hasn't finished — ship to `next`, promote when green.
+- PyPI: pre-release versions (`2.0.0b1`) are skipped by pip unless `--pre` or pinned.
+- Channels only help if consumers know they exist — document them in the README.
+
+## Monorepo versioning
+
+- **Fixed / lockstep**: every package shares one version; one tag, one changelog.
+  Simple, some no-op bumps. Right when packages are consumed as a set (this library
+  versions its role plugins in lockstep for exactly this reason).
+- **Independent**: each package has its own version and tag (`pkg-a@1.2.0`).
+  Right when consumers depend on packages individually; requires tooling (changesets,
+  release-please manifest mode) to track per-package changes and inter-package
+  dependency bumps.
+- Decide **before** the first release; converting later means rewriting tag history
+  conventions and consumer expectations.
+
+## Hotfix and backport flow
+
+When `main` has moved past the released version and a fix must ship for it:
+
+1. Branch from the release tag: `git checkout -b release/1.2.x v1.2.3`.
+2. Cherry-pick (or land) the fix there; release `1.2.4` from that branch through the
+   same gate.
+3. Ensure the fix is also on `main` (forward-port), or the next minor silently
+   regresses it.
+4. Long-lived release branches (`release/1.x`) are Tier 3 machinery — only maintain
+   them if you actually support old majors.
+
+## Release trains (Tier 3)
+
+Fixed-cadence releases (e.g., every two weeks) where whatever is merged by the cutoff
+ships: removes per-release negotiation, pairs with feature flags for incomplete work.
+Needs: a cutoff automation, a stabilization window, and an explicit hotfix lane that
+bypasses the train through the same publish gate.

package/skills/resilience-engineering/SKILL.md

@@ -0,0 +1,121 @@
+---
+name: resilience-engineering
+description: "Design systems that survive failure — failure-mode analysis, resilience patterns (timeouts, retries with backoff, circuit breakers, bulkheads, load shedding, graceful degradation), chaos experiments, disaster recovery with RTO/RPO, backup restore testing, game days. Triggers: chaos engineering, disaster recovery, DR plan, what if the database goes down, single point of failure, failover, circuit breaker, RTO, RPO, game day, high availability. An incident happening NOW → incident-response; undoing a bad deploy → rollback-strategy."
+model: sonnet
+allowed-tools: Read, Grep, Glob, Write, Edit, Bash
+---
+
+# Resilience Engineering
+
+Assume everything fails; design so users barely notice. Resilience isn't
+redundancy shopping — it's knowing your failure modes, choosing which ones
+you'll survive (and how degraded), and *proving it* before reality runs the
+test for you. Boundaries: `incident-response` is for the fire currently
+burning; `rollback-strategy` undoes a bad deploy; `observability-design`
+builds the detection this skill's mechanisms depend on. This skill is the
+design-and-verification work done in peacetime.
+
+## Workflow
+
+### Step 1: Failure-Mode Analysis — What Can Break, and What Happens Then?
+
+Walk the architecture dependency by dependency and ask, for each: *what does
+the user experience when this is down, slow, or wrong?* Cover the classes
+people skip: not just crashes but **slowness** (a hung dependency is worse
+than a dead one — it ties up your threads), **partial failure** (one AZ, one
+shard, 5% of requests), **dependency failure** (the payment provider, the
+auth service, DNS), and **data-level failure** (corruption, bad deploy writing
+garbage — replication happily replicates it). Mark every **single point of
+failure** and every **blast-radius coupler** (shared DB, shared queue, sync
+call chains). Rank by likelihood × user impact; this list drives everything
+below.
+
+### Step 2: Set the Targets — How Resilient Is Enough?
+
+Resilience costs money and complexity; decide deliberately, per system tier:
+
+- **Availability target** — align with the SLOs (`observability-design`);
+  five nines for an internal dashboard is waste, three nines for checkout is
+  negligence.
+- **RTO** (how long may recovery take) and **RPO** (how much data may be lost)
+  per data store — these two numbers *are* the DR design: they decide between
+  backups (hours/minutes), warm standby (minutes/seconds), and multi-region
+  active-active (seconds/none), whose costs differ by orders of magnitude.
+
+### Step 3: Apply the Stability Patterns at the Boundaries
+
+Every remote call gets the basics — this is where most real-world resilience
+lives, not in exotic infrastructure:
+
+- **Timeouts on everything** (the default infinite timeout is the root cause
+  of most cascades), sized from the caller's budget, not the callee's average.
+- **Retries with exponential backoff + jitter**, only on idempotent
+  operations, with a **retry budget** — naive retries turn a blip into a
+  self-inflicted DDoS (the retry storm).
+- **Circuit breakers** on dependencies that can hang or flap — fail fast and
+  give the dependency room to recover.
+- **Bulkheads** — isolate resource pools per dependency/tenant so one bad
+  citizen can't exhaust the shared thread/connection pool.
+- **Load shedding & backpressure** — reject cheap and early at the edge when
+  saturated, prioritizing by request value; a queue that only grows is an
+  outage on layaway.
+- **Graceful degradation** — decide *in advance* what turns off first: serve
+  stale cache, disable recommendations, queue writes. Degraded-but-usable is
+  the design goal; all-or-nothing is the anti-pattern.
+- **Idempotency keys** on mutating endpoints — they're what make retries and
+  failover safe end to end.
+
+### Step 4: Design Recovery for Data — Backups Are a Hypothesis
+
+A backup that has never been restored is a hope, not a plan:
+
+- Automate backups to match the RPO; keep at least one copy isolated from the
+  blast radius (other account/region; immutable/offline for ransomware-class
+  events).
+- **Test restores on a schedule** — a real restore into a real environment,
+  timed against the RTO, verified for integrity. The restore test failing in
+  a drill is a gift; failing during an incident is the disaster.
+- Remember correlated data failure: replication is not backup (it replicates
+  the corruption); point-in-time recovery covers the bad-deploy-wrote-garbage
+  case.
+
+### Step 5: Verify with Experiments — Chaos, Then Game Days
+
+Untested failover fails over nothing. Prove the Step-3/4 mechanisms:
+
+- **Chaos experiments**: hypothesis-driven ("if we kill one API pod, error
+  rate stays < 0.1%"), smallest blast radius first, in staging before
+  production, always with an abort switch and observability watching. Start
+  embarrassingly small — kill one instance, add 200ms latency to one
+  dependency — most systems fail the small test first.
+- **Game days**: rehearse the human half — a scenario ("region us-east is
+  gone", "restore yesterday's DB"), the on-call team executing the real
+  runbooks, a timer against RTO. Findings feed runbook and design fixes, and
+  the loop repeats. This is also how `incident-response` gets practiced before
+  it's needed.
+
+### Step 6: Close the Loop
+
+Every real incident and every drill updates the Step-1 failure-mode list (was
+this mode known? why not?), the patterns, and the runbooks — via
+`retrospective` post-mortems. Resilience is a cycle, not a milestone: new
+dependencies arrive with default-infinite timeouts every sprint.
+
+## Principles Applied
+
+- **Slow is worse than dead**: hung dependencies cascade; timeouts and
+  breakers convert hangs into fast, handleable failures.
+- **RTO/RPO before mechanism**: pick the numbers first — they select the
+  design and the budget honestly.
+- **Tested or theoretical**: failover, restores, and degradation paths count
+  only after they've run — in a drill or in anger.
+
+## Cross-Skill References
+
+- `observability-design` — the SLOs, alerting, and dashboards that detect failure
+- `incident-response` — executing under fire what this skill rehearses in peace
+- `rollback-strategy` — the deploy-level undo; this skill covers system-level failure
+- `architecture-design` — recording redundancy/DR trade-offs as ADRs
+- `containerization` / `infrastructure-as-code` — where health checks, pod
+  disruption budgets, and multi-AZ topology get implemented
+- `retrospective` — turning incidents and game-day findings into fixes

package/skills/resilience-engineering/evals/evals.json

@@ -0,0 +1,40 @@
+{
+  "skill_name": "resilience-engineering",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "Our e-commerce platform runs on one Postgres instance, a Node API, and Redis, all in a single AWS availability zone. Leadership asked: 'what happens if AWS has a bad day?' Design our resilience strategy.",
+      "expected_output": "Runs failure-mode analysis per dependency (down/slow/partial/data-corruption, single points of failure), sets explicit targets first (availability tier, RTO/RPO per store) noting cost scales with the numbers, applies stability patterns at boundaries (timeouts, retries with backoff+jitter on idempotent ops, circuit breakers, graceful degradation deciding in advance what turns off), designs data recovery (automated backups, isolated copy, scheduled restore tests), and proposes verification via small chaos experiments and a game day rather than declaring the design done",
+      "assertions": [
+        "Performs failure-mode analysis across the dependencies, covering slow/partial failures and data corruption — not just total outage — and identifies single points of failure",
+        "Sets explicit RTO/RPO and availability targets before choosing mechanisms, noting that cost scales with the targets (backups vs standby vs multi-AZ/region)",
+        "Applies concrete stability patterns: timeouts, retries with backoff and jitter (idempotent only), circuit breakers, and pre-decided graceful degradation",
+        "Treats backups as unproven until restored — schedules restore testing and keeps a copy isolated from the blast radius",
+        "Proposes verifying with chaos experiments (hypothesis-driven, small blast radius) and/or a game day rehearsing the runbooks"
+      ]
+    },
+    {
+      "id": 2,
+      "prompt": "We already have retries everywhere — every service retries failed calls 5 times. Last month a 30-second blip in our auth service somehow became a 45-minute full-platform outage. Make us more resilient.",
+      "expected_output": "Diagnoses the retry storm / cascade: unbudgeted retries amplified load (5 retries per hop compound multiplicatively across the chain), likely no timeouts or breakers so threads piled onto a hung dependency; prescribes retry budgets, exponential backoff with jitter, idempotency checks, circuit breakers to fail fast, load shedding at the edge, and bulkheads to contain blast radius — showing that MORE retrying is the opposite of resilience here",
+      "assertions": [
+        "Identifies the naive retries as an amplifier (retry storm / cascading failure), including how retries compound across call-chain hops",
+        "Recommends retry budgets and exponential backoff with jitter, restricted to idempotent operations, instead of fixed retry counts",
+        "Adds circuit breakers and timeouts so a hung or flapping dependency fails fast instead of tying up resources",
+        "Recommends load shedding/backpressure and/or bulkheads to contain the blast radius of a degraded dependency",
+        "Frames the fix as controlling and bounding retries — explicitly countering the assumption that more retrying equals more resilience"
+      ]
+    },
+    {
+      "id": 3,
+      "prompt": "Production is down RIGHT NOW — the primary database failed over but the app servers are still erroring and customers can't check out. What do we do?",
+      "expected_output": "Recognizes an active incident under time pressure — hands off to incident-response for triage/mitigation/comms rather than starting a peacetime resilience design; may note that post-recovery, the failure feeds back into failure-mode analysis and a game-day-style review via retrospective",
+      "assertions": [
+        "Recognizes this as an active production incident, not a resilience design exercise",
+        "Refers to the incident-response skill/workflow for triage, mitigation, and communication",
+        "Does not respond with a peacetime workflow (failure-mode analysis, chaos experiments, DR design) as the immediate answer",
+        "States or implies the boundary: resilience-engineering is peacetime design and rehearsal; incident-response handles the live fire (with learnings looping back afterward)"
+      ]
+    }
+  ]
+}

package/skills/security-audit/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: security-audit
-description: "Comprehensive security analysis — OWASP Top 10, auth/authz flows, injection vulnerabilities, data exposure, secrets detection, dependency CVEs, hardening recommendations. Triggers: security audit, vulnerability, is this secure, security review, pentest prep, OWASP, harden this, check for vulnerabilities, injection, XSS, CSRF, auth security."
+description: "Comprehensive security analysis — OWASP Top 10, auth/authz flows, injection vulnerabilities, data exposure, secrets detection, dependency CVEs, hardening recommendations. Triggers: security audit, vulnerability, is this secure, security review, pentest prep, OWASP, harden this, check for vulnerabilities, injection, XSS, CSRF, auth security. Reviews EXISTING code/config — design-time analysis of a system not yet built → threat-modeling."
 model: opus
 allowed-tools: Read, Grep, Glob, Write, Edit, WebFetch, WebSearch
 ---
@@ -11,7 +11,7 @@ Perform a structured security assessment of an application. This skill goes far
 
 ## Scope Boundary
 
-This skill analyzes code, configuration, and architecture for security vulnerabilities through static analysis and design review. It does not replace penetration testing, but it prepares code for one by catching the issues a pentester would find.
+This skill analyzes code, configuration, and architecture for security vulnerabilities through static analysis and design review. It does not replace penetration testing, but it prepares code for one by catching the issues a pentester would find. It is the *reactive* half of the pair: for design-time analysis of a system that isn't built yet (trust boundaries, STRIDE, abuse cases), use `threat-modeling` — and when a threat model exists, use it as this audit's checklist.
 
 ## ⛔ The Iron Law
 

package/skills/skill-router/SKILL.md

@@ -87,7 +87,9 @@ installed skill by name, regardless of role.
 ## Catalog by SDLC phase
 
 ### Plan & Define
+- **brainstorming** — divergent Socratic ideation *before* a spec exists; opens options, then hands off
 - **feature-planning** — break a feature into scoped tasks, acceptance criteria, dependencies
+- **build-vs-buy** — build in-house vs vendor/SaaS vs adopt OSS: TCO, lock-in, exit costs
 - **prd-writing** — write a PRD / RFC / tech spec to align on the WHAT and WHY
 - **project-proposal** — business case / budget / go-no-go before a project starts
 - **strategic-review** — vision, positioning, defensible wedge, live competitive/market analysis before going public
@@ -102,14 +104,19 @@ installed skill by name, regardless of role.
 - **ui-ux-design** — user flows, wireframes, loading/error/empty states, responsive
 - **frontend-architecture** — component hierarchy, state management, design tokens
 - **accessibility-design** — WCAG, ARIA, keyboard nav, focus, screen readers
+- **threat-modeling** — design-time security: trust boundaries, STRIDE, abuse cases, mitigations
+- **compliance-privacy** — GDPR/SOC 2 obligations: data mapping, retention/deletion, DSRs, controls
 - **configuration-strategy** — env config, secrets management, feature-flag hierarchy
 - **dependency-impact-analysis** — blast radius of a change *before* implementing
 - **dependency-management** — evaluate, audit (CVEs), and upgrade libraries
 
 ### Build & Test
+- **plan-execution** — execute an APPROVED plan: checkpoints, verification evidence, drift → re-plan
 - **tdd-workflow** — NEW code, test-first, red-green-refactor
 - **test-suite-design** — add tests to EXISTING code, coverage strategy
 - **test-data-strategy** — factories, synthetic data, property-based, contract testing
+- **browser-verification** — drive the real UI to prove a web change works: console/network/state evidence
+- **subagent-orchestration** — fan work out across subagents/worktrees; verify and synthesize results
 - **git-workflow** — commit messages, PR descriptions, branching strategy
 - **project-documentation** — README, contributing guide, changelog, docstrings
 
@@ -120,6 +127,8 @@ installed skill by name, regardless of role.
 - **refactoring** — systematic, test-protected code improvement
 - **technical-debt-review** — codebase health, hotspots, remediation roadmap
 - **project-review** — whole-project execution health: scope alignment, roadmap adherence, implementation maturity, evidence-it-works
+- **code-archaeology** — understand unfamiliar/legacy code first: history mining, tracing, characterization tests
+- **dx-audit** — developer-experience audit: feedback loops, CI wait, flakes, onboarding, tooling friction
 
 ### Diagnose & Fix
 - **bug-investigating** — systematic debugging, reproduce → isolate → hypothesize → verify
@@ -129,27 +138,45 @@ installed skill by name, regardless of role.
 - **rollback-strategy** — safe rollback plans, irreversible-change detection
 - **containerization** — Dockerfiles, docker-compose, Kubernetes manifests
 - **cicd-pipeline** — CI/CD pipelines, quality gates (GitHub Actions, GitLab CI)
+- **release-management** — semver, changelog, tagging, publish gates, registry publishing, release automation (right-sized to the project)
 - **infrastructure-as-code** — Terraform, CloudFormation, Pulumi, CDK
 - **deployment-repo** — GitOps polyrepo orchestration, version pinning, promotion
 - **gitops-delivery** — ArgoCD / Flux declarative delivery, drift detection
 - **observability-design** — SLI/SLO/SLA, OpenTelemetry, structured logging, alerting
+- **resilience-engineering** — failure modes, stability patterns, chaos experiments, DR/RTO/RPO, game days
+- **finops-cost-optimization** — cloud spend: allocation, unit economics, rightsizing, commitments, egress
 - **incident-response** — ACTIVE production incident: triage, mitigate, communicate
 
+### Mobile
+- **mobile-architecture** — platform choice, navigation, offline-first/sync, state, push, fleet constraints
+- **mobile-release** — signing, store review, staged rollouts, no-rollback playbook, beta channels
+
 ### Reflect
 - **retrospective** — sprint retros, project / incident post-mortems, action items
 
 ### MLOps
-- **ml-pipeline-design** — training & data pipelines, feature engineering, orchestration
+- **ml-pipeline-design** — ML training & feature pipelines, point-in-time correctness, orchestration
 - **ml-experiment-tracking** — MLflow / W&B / DVC, run comparison, reproducibility
 - **ml-model-deployment** — serving, monitoring, drift detection, safe rollouts
 
+### AI / LLM Apps
+- **llm-app-engineering** — prompt/context engineering, RAG architecture, agent design, memory
+- **ai-evaluation** — golden datasets, RAG metrics, LLM-as-judge design, eval gates in CI, online A/B
+
+### Data Engineering
+- **data-pipeline-design** — batch/streaming ELT, dbt layering, Airflow/Dagster, idempotency, backfill
+- **data-quality** — dbt tests, expectations, data contracts, freshness, lineage / blast radius
+
 ## Golden Path workflow chains
 
 When work spans phases, chain skills rather than improvising:
 
 **New feature**
-`feature-planning` → `architecture-design` (if structural) → `data-modeling`
-(if schema) → `tdd-workflow` → `code-reviewing` → `deployment-checklist`
+`brainstorming` (if the idea is still fuzzy) → `feature-planning` →
+`architecture-design` (if structural) → `data-modeling` (if schema) →
+`threat-modeling` (if new trust boundaries) → `plan-execution` (work the
+approved plan; wraps `tdd-workflow` per task) → `code-reviewing` →
+`deployment-checklist`
 
 **Bug / incident**
 `incident-response` (if prod is down) → `bug-investigating` → `tdd-workflow`
@@ -159,6 +186,22 @@ When work spans phases, chain skills rather than improvising:
 `technical-debt-review` → `refactoring` → `dependency-impact-analysis`
 (blast radius) → `test-suite-design` (if coverage is thin)
 
+**Ship a release**
+`git-workflow` (commits carry the bump intent) → `release-management` (version,
+changelog, tag, publish gate, registry) → `deployment-checklist` (if it deploys) →
+`rollback-strategy`. `cicd-pipeline` automates the gate as a pipeline stage.
+App-store releases (signing, review, staged rollout) → `mobile-release`.
+
+**LLM feature**
+`feature-planning` → `llm-app-engineering` (prompt/RAG/agent design) →
+`ai-evaluation` (golden set, judge, CI gate) → `deployment-checklist`.
+`ml-model-deployment` joins when serving your own model.
+
+**Analytics / data pipeline**
+`data-pipeline-design` (ELT, layering, orchestration) → `data-modeling`
+(marts schema) → `data-quality` (tests, contracts, freshness) →
+`observability-design` (pipeline SLOs, alerting).
+
 **Pre-public / pre-milestone review**
 `strategic-review` (vision, positioning, market) → `project-review` (scope,
 roadmap, implementation, evidence) → synthesis → `artifact-design` (interactive