skilldrop-cli 0.16.3__py3-none-any.whl

skilldrop_cli/data/packs/dev-team/skills/launch-readiness/SKILL.md

@@ -0,0 +1,95 @@
+---
+name: launch-readiness
+description: Produce a go/no-go launch readiness report for a merged change before it goes live — one row per check (rollback path, alert and runbook per new failure mode, NFR targets measured, comms drafted, data/privacy sign-off), each with an owner, evidence link, and met / not met / n/a-because status, ending in a PROCEED / PROCEED WITH CONDITIONS / REVISE / BLOCKED verdict. Use when the user asks "are we ready to launch", "go/no-go", "production readiness review", "launch checklist", or "can we ship this to users".
+---
+
+# launch-readiness
+
+You judge whether a change that is already merged *can* go live, using evidence rather than
+reassurance. The output is a readiness report a release owner can act on in five minutes.
+Whether it *should* go live now (timing, freeze windows, who is on call) is a separate human
+decision. That belongs to `council-review` or the release owner, not to this report.
+
+## How to respond
+
+1. **Pin down what is launching.** You need: the change (a PR, a release tag, or a feature
+   name), who it reaches (internal, a percentage, everyone), and the release owner. If the
+   change itself is unknown, ask. You may ask at most 2 questions. A missing reach or owner
+   becomes an `[assumption]` to confirm. Everything else becomes a row that is `not met`
+   because evidence is missing.
+
+2. **List the new failure modes first.** Before any checklist, write 3–5 ways this specific
+   change could hurt users or data once it is live. Read them from the diff, the design doc or
+   the migration plan. Each later check is judged against this list. A generic checklist with
+   no failure modes is a ritual.
+
+3. **Fill [`templates/readiness-report.md`](templates/readiness-report.md).** It has one row
+   per check, and every row carries:
+   - **Status:** `met`, `not met`, or `n/a — <reason>`. `n/a` without a reason counts as `not met`.
+   - **Evidence:** a link, a command output, or a file path. A row with no evidence counts as
+     `not met`, however confident the user sounds. Evidence must cover the path the failure
+     mode touches; if it is unclear what it covered (which endpoint a load test hit), tag it
+     `[assumption]`.
+   - **Owner:** a role, not a person's name.
+
+4. **Apply the checks in this order.** The order matters: the first ones are the costliest to
+   discover after launch.
+   1. **Rollback.** It must be a tested path back, with its data story stated. If a data or
+      schema change is involved and no plan exists, hand off to `migration-plan`.
+   2. **Detection.** Each new failure mode needs an alert that fires before users complain. If
+      one is missing, hand off to `observability-plan`.
+   3. **Response.** Each such alert needs a runbook entry. If one is missing, hand off to
+      `runbook-generator`.
+   4. **Quality targets.** Every target in `nfr-spec` (latency, availability, scale) must be
+      *measured*, for example by a load test or canary result. A target that is only asserted
+      does not count.
+   5. **Data and privacy.** New personal data, retention changes or new processors need a
+      named sign-off, or `n/a — <reason>`.
+   6. **Comms.** User-facing notes are drafted (see `release-notes`), support is briefed, and
+      the status page owner is known if the launch is risky.
+   7. **Exposure.** The first exposure is staged (flag, percentage or cohort), or there is a
+      stated reason why all-at-once is safe.
+
+5. **Give the verdict.** It is the last line, with exactly one reason:
+   - `PROCEED`: every row is `met` or `n/a — <reason>`.
+   - `PROCEED WITH CONDITIONS`: only rows 6–7 are open, and each open row has an owner and a
+     date. The open rows travel with the release.
+   - `REVISE`: any row 2–5 is `not met`. Name the row and the hand-off that fixes it.
+   - `BLOCKED`: rollback is `not met`, or the change or its reach is unknown. A missing
+     rollback blocks on its own, whatever else passes.
+
+**Non-interactive runs** (CI, subagent, headless): never invent evidence such as test results,
+dashboards or sign-offs. Tag a guessed fact `[assumption]` and list it first. If the change
+being launched cannot be identified, emit `BLOCKED: need <the PR, tag, or feature name>`.
+
+## Useful references in this skill
+
+- [`templates/readiness-report.md`](templates/readiness-report.md) — the report skeleton, one row per check.
+- [`examples/schema-change-revise.md`](examples/schema-change-revise.md) — a worked report for a schema change that comes out `REVISE`.
+
+## Quality bar
+
+- **Every row has evidence or is `not met`.** Readiness asserted is not readiness.
+- **The failure modes are specific to this change.** "The service could go down" is true of everything and checks nothing.
+- **Rollback is judged first and can block alone.** Every other gap can be fixed while live; an irreversible launch with no way back cannot.
+- **The verdict follows mechanically from the rows.** Two reviewers given the same rows reach the same verdict.
+- **Owners are roles.** "Payments on-call", not a person who will change teams.
+
+## When to use this skill
+
+- ✅ A merged change is about to reach users and someone asks "are we ready?"
+- ✅ A production readiness review needs a written go/no-go record.
+- ✅ The `ready` stage of the `release` loop.
+
+## When NOT to use this skill
+
+- ❌ Deciding whether to *merge*. That is `pre-merge-review`'s gate, which happens earlier.
+- ❌ Planning the rollout phases themselves. That is `migration-plan`; this skill checks that the plan exists and has been rehearsed.
+- ❌ Choosing *when* to launch. Timing and freeze windows are the release owner's call, or `council-review`'s if they are contested.
+
+## Anti-patterns to avoid
+
+- ❌ **A generic checklist with every box ticked.** If no row is `not met` on a non-trivial launch, the evidence was not checked.
+- ❌ **`n/a` as a way out.** Data and privacy marked `n/a` with no reason is the most common way a launch skips a review it needed.
+- ❌ **Letting a strong row offset a missing rollback.** Great dashboards do not make an irreversible launch safe.
+- ❌ **Writing the runbook or the alert inside this report.** Name the gap and hand it off; a readiness report that also drafts fixes becomes too long to read.

skilldrop_cli/data/packs/dev-team/skills/launch-readiness/evals/eval_queries.json

@@ -0,0 +1,10 @@
+[
+  { "query": "Are we ready to launch this to users on Monday?", "should_trigger": true },
+  { "query": "Run a go/no-go check on the checkout redesign before we turn it on", "should_trigger": true },
+  { "query": "Do a production readiness review for the new search service", "should_trigger": true },
+  { "query": "Give me a launch checklist for this release and tell me what's missing", "should_trigger": true },
+  { "query": "Is this PR safe to merge?", "should_trigger": false },
+  { "query": "Plan the phased rollout and backfill for moving users to the new auth provider", "should_trigger": false },
+  { "query": "Write the release notes for everything since v2.3", "should_trigger": false },
+  { "query": "Write the runbook for the payments service", "should_trigger": false }
+]

skilldrop_cli/data/packs/dev-team/skills/launch-readiness/evals/evals.json

@@ -0,0 +1,19 @@
+{
+  "skill_name": "launch-readiness",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "Are we ready to launch? PR #412 adds a `loyalty_points` column to `customers`, backfills it from order history, and shows points on the checkout page. Going to 100% of users Thursday. Load test hit p99 180ms against a 250ms target (link: grafana/d/lt-412). We have a dashboard but haven't added alerts yet. Support hasn't been told.",
+      "assertions": [
+        "Lists 3-5 failure modes specific to this change (e.g. backfill load on customers, wrong point totals shown at checkout) before the checklist",
+        "Every check row has a status of met, not met, or n/a with a reason, plus an evidence column and an owner expressed as a role",
+        "Rollback is the first row and is not met, because no tested rollback or data story was supplied",
+        "Detection is not met because no alerts exist, and the report hands off to observability-plan rather than drafting the alert inline",
+        "The quality-targets row is met and cites the supplied load-test link as evidence",
+        "Exposure is flagged because a 100% launch is not staged and no reason is given for why all-at-once is safe",
+        "The verdict is BLOCKED, and the reason given is the missing rollback",
+        "No dashboards, test results, or sign-offs are invented beyond what the prompt supplied"
+      ]
+    }
+  ]
+}

skilldrop_cli/data/packs/dev-team/skills/launch-readiness/examples/schema-change-revise.md

@@ -0,0 +1,54 @@
+# Worked example — schema change that comes out REVISE
+
+## Input given to the skill
+
+> Go/no-go for release `orders-v4.2`. It splits `orders.address` into `shipping_address_id`
+> pointing at a new `addresses` table. We followed the migration plan
+> (docs/migrations/orders-address.md): expand and backfill are done in staging, and dual-write
+> is behind the flag `orders.address_split`. Rollback is "turn the flag off". It was rehearsed
+> in staging on 2026-09-28 (log: ci/run/88213). The p99 target for order reads is 120ms, and
+> the canary at 5% shows 96ms (grafana/d/orders-canary). The existing `orders-5xx` alert
+> covers this. Release notes are drafted in PR #977. Plan is 5% → 50% → 100% over three days.
+
+---
+
+# Launch readiness — orders-v4.2 (address split)
+
+**Change:** release `orders-v4.2` · **Reach:** 5% → 50% → 100% over 3 days · **Release owner:** Orders tech lead
+**Assessed:** 2026-10-01 · **Inputs:** migration plan, staging rollback log, canary dashboard, PR #977
+
+## New failure modes
+
+| # | Failure mode | Who is hurt | Reversible? |
+|---|---|---|---|
+| F1 | Dual-write diverges: an order is saved with an `addresses` row that doesn't match `orders.address` | Customers shipped to the wrong address | Partly. Data can be fixed, parcels already sent cannot |
+| F2 | The read path picks the new column before the backfill is complete for that tenant | Customers who see a blank address at checkout | Yes, by turning the flag off |
+| F3 | The extra join pushes order reads past p99 under full load | All checkout users | Yes, by turning the flag off |
+
+## Checks
+
+| # | Check | Covers | Status | Evidence | Owner |
+|---|---|---|---|---|---|
+| 1 | Rollback | all | met | Flag-off rehearsed in staging, ci/run/88213. While the old column is still written, flag-off loses no data | Orders on-call |
+| 2 | Detection | F1–F3 | **not met** | `orders-5xx` catches F3 errors only. Nothing detects F1 divergence or F2 blank reads, because both return 200 | Orders on-call |
+| 3 | Response | F1–F3 | **not met** | There is no runbook entry for divergence. `orders-5xx` has a runbook entry, but it does not mention the flag | Orders on-call |
+| 4 | Quality targets | F3 | met | Canary p99 96ms against a 120ms target at 5%, grafana/d/orders-canary | Orders tech lead |
+| 5 | Data & privacy | — | n/a — no new personal data. Address data moves between tables, and retention and processors are unchanged | Migration plan §2 | Data protection lead |
+| 6 | Comms | — | met | Release notes drafted in PR #977. No customer-visible change | Orders tech lead |
+| 7 | Exposure | — | met | Staged 5% → 50% → 100% behind `orders.address_split` | Release owner |
+
+## Open items
+
+- Row 2: add a reconciliation metric for dual-write divergence, and an alert on any non-zero count, plus an alert on blank-address reads. Orders on-call, before the 5% → 50% step. Hand off to `observability-plan`.
+- Row 3: add a runbook entry for "divergence alert fires" (flag off, then run the reconciler), and add the flag to the `orders-5xx` entry. Orders on-call, same deadline. Hand off to `runbook-generator`.
+
+## Verdict
+
+**REVISE.** Row 2 is not met: the two failure modes that do lasting damage (F1, F2) return 200, so nothing would detect them. Fix rows 2 and 3, then run readiness again.
+
+---
+
+**Why this is a good output:** the rollback is genuinely in place, so the verdict is REVISE and
+not BLOCKED. The report notices that an existing alert covering the change only catches the
+failure that is easiest to undo. It does not draft the alert or runbook itself; it names the
+gap, the owner and the hand-off.

skilldrop_cli/data/packs/dev-team/skills/launch-readiness/manifest.json

@@ -0,0 +1,24 @@
+{
+  "name": "launch-readiness",
+  "version": "0.1.0",
+  "description": "Produce a go/no-go launch readiness report for a merged change before it goes live — one row per check (rollback path, alert and runbook per new failure mode, NFR targets measured, comms drafted, data/privacy sign-off), each with an owner, evidence link, and met / not met / n/a-because status, ending in a PROCEED / PROCEED WITH CONDITIONS / REVISE / BLOCKED verdict. Use when the user asks \"are we ready to launch\", \"go/no-go\", \"production readiness review\", \"launch checklist\", or \"can we ship this to users\".",
+  "entrypoint": "SKILL.md",
+  "deps": { "npm": [], "pip": [] },
+  "env": { "required": [], "optional": [] },
+  "related": [
+    "migration-plan",
+    "observability-plan",
+    "runbook-generator",
+    "nfr-spec",
+    "release-notes",
+    "council-review",
+    "pre-merge-review"
+  ],
+  "handoff": [
+    { "to": "migration-plan", "when": "the change has no tested rollback path", "purpose": "Plan the phases and the rollback, and name the point of no return, before readiness is judged again.", "fallback": "If migration-plan is absent, write the rollback as numbered steps with its data story inline, and mark the row not met until someone has rehearsed it." },
+    { "to": "observability-plan", "when": "a new failure mode has no alert", "purpose": "Define the SLI and the burn-rate alert that would detect it.", "fallback": "If observability-plan is absent, name the symptom, the metric that shows it, and a threshold inline, tagged [assumption] for the owner to confirm." },
+    { "to": "runbook-generator", "when": "an alert exists but has no runbook entry", "purpose": "Write the procedure the on-call follows when that alert fires.", "fallback": "If runbook-generator is absent, write recognise / mitigate / escalate as three lines under the row, and keep the row not met until the on-call owner has reviewed them." }
+  ],
+  "tags": ["launch", "release", "readiness", "go-no-go", "production-readiness"],
+  "model": { "tier": "standard", "rationale": "Checks evidence against a fixed checklist. Bounded synthesis, not adversarial review." }
+}

skilldrop_cli/data/packs/dev-team/skills/launch-readiness/templates/readiness-report.md

@@ -0,0 +1,41 @@
+# Launch readiness — {change name}
+
+**Change:** {PR / tag / feature} · **Reach:** {internal / N% / cohort / everyone} · **Release owner:** {role}
+**Assessed:** {YYYY-MM-DD} · **Inputs:** {what was read — diff, design doc, migration plan, dashboards}
+
+> **Assumptions to confirm first** (omit if none)
+> - `[assumption]` {fact guessed rather than given}
+
+## New failure modes
+
+What this change, specifically, could do to users or data once live.
+
+| # | Failure mode | Who is hurt | Reversible? |
+|---|---|---|---|
+| F1 | {e.g. backfill locks `orders` table under peak write load} | {checkout users} | {yes / no / partly} |
+| F2 | | | |
+| F3 | | | |
+
+## Checks
+
+Status is `met`, `not met`, or `n/a — <reason>`. No evidence means `not met`.
+
+| # | Check | Covers | Status | Evidence | Owner |
+|---|---|---|---|---|---|
+| 1 | **Rollback** — tested path back, data story stated | all | | {link / command output} | {role} |
+| 2 | **Detection** — an alert per failure mode, fires before users complain | F1–F3 | | | |
+| 3 | **Response** — a runbook entry per alert in row 2 | F1–F3 | | | |
+| 4 | **Quality targets** — each NFR target measured, not asserted | | | | |
+| 5 | **Data & privacy** — sign-off for new personal data, retention, or processors | | | | |
+| 6 | **Comms** — release notes drafted, support briefed, status-page owner known | | | | |
+| 7 | **Exposure** — first exposure staged, or why all-at-once is safe | | | | |
+
+## Open items
+
+One line per `not met` row: what closes it, who, by when, and the hand-off if any.
+
+- Row {n}: {what closes it} — {owner role}, {date} → {`migration-plan` / `observability-plan` / `runbook-generator` / none}
+
+## Verdict
+
+**{PROCEED | PROCEED WITH CONDITIONS | REVISE | BLOCKED}** — {the one reason, naming the row}.

skilldrop_cli/data/packs/dev-team/skills/migration-plan/SKILL.md

@@ -0,0 +1,68 @@
+---
+name: migration-plan
+description: Generate a phased migration or rollout plan (schema change, API version, datastore swap, platform move, auth-provider switch) — expand→migrate→contract by default, every phase reversible or its point of no return named, observable gates between phases, idempotent backfill with parity checks. Use when the user needs a migration plan, cutover plan, rollout strategy, or asks "how do we get from X to Y without downtime".
+---
+
+# migration-plan
+
+Plans the road from current state to target state so that at every moment the system is in a stable, *reversible* position — until the one explicitly named point of no return. The default shape is the parallel-change pattern: **expand** (add the new path alongside the old), **migrate** (move traffic/data with verification), **contract** (remove the old path — actually scheduled, not "later").
+
+## How to respond
+
+1. **Pin both ends.** Current state and target state, stated concretely enough that "done" is checkable ("all reads served by the v2 endpoint and v1 returns 410", not "migrated to v2"). Ask at most 2 questions; spend them on the constraints that shape the plan — downtime tolerance and data volume. Everything else gets `[assumption]`.
+
+2. **Cut phases by the one-change rule.** Each phase changes one thing: schema *or* code path *or* traffic share — never two in the same step, because a failed phase must implicate exactly one change. ✅ *"Phase 2: deploy dual-write code (schema already expanded in phase 1)"* — ❌ *"Phase 2: add the new column and start writing to it"*.
+
+3. **Give every phase the four mandatory fields** (skeleton in [`templates/migration-plan.md`](templates/migration-plan.md)):
+   - **Action** — what changes
+   - **Gate** — observable criteria to pass before the next phase (error rates, data parity, shadow-diff results), plus **bake time**; a zero-bake gate is a gate in name only
+   - **Rollback** — the tested way back, ✅ *"flip flag `orders_v2_read` off; old path still receives dual writes, no data loss"* — ❌ *"redeploy previous version"* when data has already moved
+   - **Blast radius** — who/what is affected if this phase fails
+   If a phase has no real rollback, it is the **point of no return**: name it in bold, schedule it as late as possible, and list what must be verified immediately before crossing it. A plan may have one; a plan with three has its phases cut wrong.
+
+4. **Specify the backfill like an engineer will run it at 2am.** Idempotent (safe to re-run), resumable (checkpointed, not restart-from-zero), rate-limited (with the limit and the metric that triggers slowdown), and verified by **parity checks at three depths**: row/object counts, checksums or aggregates per partition, and a sampled deep-compare. Dual-write without a reconciliation job is drift with a delay timer — if the plan dual-writes, it names the reconciler and its alert.
+
+5. **Cut traffic over incrementally by default** — flag-gated percentage ramp or canary cohort, with the ramp schedule and the abort threshold at each step. Big-bang cutover is allowed only when the user states why incremental is impossible (e.g. protocol can't run dual), and the plan then compensates with a rehearsal in staging and a widened rollback window.
+
+6. **Schedule the contract phase with a date and an owner.** Removing the old path, the flag, the dual-write, the legacy table — this is a real phase with its own gate ("zero reads on old path for 14 days, verified by metric"), not a footnote. The two-paths-forever system is the most common migration failure and it happens by omission.
+
+7. **Add the comms row per phase**: who needs to know (on-call, support, dependent teams, customers if visible), and what the message is. One line each; silence is a decision, mark it as one.
+
+8. **Emit the plan in one message**: state summary, phase table (overview), per-phase detail, backfill spec, ramp schedule, point of no return, contract phase, and open `[assumption]`s. For the risk analysis itself, point the user at `test-plan-generator` (verification depth) or `council-review` (contested decisions) rather than duplicating them.
+
+## Useful references in this skill
+
+- [`templates/migration-plan.md`](templates/migration-plan.md) — phase skeleton with the four mandatory fields, backfill spec, and ramp table
+
+## Quality bar
+
+- **Every phase is reversible, or is *the* named point of no return.** A reader can answer "how do we get back from here?" for any row in the plan.
+- **Every gate is observable with a bake time.** "Looks good" is not a gate; "error rate ≤ baseline +0.1% for 48h and parity job green" is.
+- **One change per phase.** A failed phase implicates exactly one change — that's what makes rollback decisions fast.
+- **Backfill is idempotent, resumable, rate-limited, parity-checked** — all four stated, none implied.
+- **The contract phase has a date, an owner, and a gate.** Plans that end at "100% on new path" are unfinished.
+- **Rollback steps are tested, not asserted.** Each rollback names when it was (or will be) rehearsed; an unrehearsed rollback is a hypothesis.
+
+## When to use this skill
+
+- ✅ Schema changes that need backfill on a live system
+- ✅ API or service version migrations with consumers to move
+- ✅ Datastore, queue, auth-provider, or platform swaps
+- ✅ "How do we roll this out without downtime?" for any risky change
+
+## When NOT to use this skill
+
+- ❌ A change deployable in one reversible step — normal deploy, no plan needed
+- ❌ Choosing the target ("should we move to DynamoDB?") — that's `tech-comparison-matrix`; this skill starts after the decision
+- ❌ The test depth itself — emit gates here, hand verification design to `test-plan-generator`
+- ❌ Organizational/process migrations with no system state — different problem
+
+## Anti-patterns to avoid
+
+- ❌ **Big-bang cutover as the default.** It's the plan you get by not planning; incremental is the default and exceptions must argue.
+- ❌ **"Rollback: redeploy the previous version"** after data has migrated. Code rolls back in minutes; data doesn't. State the data story or the rollback is fiction.
+- ❌ **Dual-write without reconciliation.** The two stores *will* drift — name the reconciler, its schedule, and its alert, or don't dual-write.
+- ❌ **Schema and code in one phase.** When it fails, you won't know which to revert, so you'll freeze instead.
+- ❌ **Zero bake time.** Phases passed in the same hour they started are phases nobody watched.
+- ❌ **The unscheduled contract phase.** "We'll remove the old path later" — later has no owner, so dual paths become the architecture.
+- ❌ **Migrating and improving simultaneously.** "While we're at it" scope is how a 3-week migration becomes a 6-month one; improvements go in the backlog, the migration moves like-for-like.

skilldrop_cli/data/packs/dev-team/skills/migration-plan/evals/eval_queries.json

@@ -0,0 +1,34 @@
+[
+  {
+    "query": "Plan the migration for this schema change",
+    "should_trigger": true
+  },
+  {
+    "query": "How do we roll this datastore swap out safely with no downtime?",
+    "should_trigger": true
+  },
+  {
+    "query": "Give me a phased expand-migrate-contract plan for this API version",
+    "should_trigger": true
+  },
+  {
+    "query": "We're switching auth providers — plan the cutover and rollback",
+    "should_trigger": true
+  },
+  {
+    "query": "Design the new database schema and its indexes",
+    "should_trigger": false
+  },
+  {
+    "query": "Split this migration work into user stories",
+    "should_trigger": false
+  },
+  {
+    "query": "Write the runbook for the on-call team",
+    "should_trigger": false
+  },
+  {
+    "query": "Write an ADR recording why we chose this datastore",
+    "should_trigger": false
+  }
+]

skilldrop_cli/data/packs/dev-team/skills/migration-plan/evals/evals.json

@@ -0,0 +1,16 @@
+{
+  "skill_name": "migration-plan",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "Plan the migration from our single-tenant Postgres schema to a multi-tenant one, with no downtime.",
+      "assertions": [
+        "The plan is phased expand-migrate-contract by default",
+        "Every phase is reversible, or is explicitly named as the point of no return — a reader can answer 'how do we get back from here?' for every phase",
+        "Every gate is observable with a bake time and a threshold, not 'looks good'",
+        "Each phase carries exactly one change, so a failed phase implicates one thing",
+        "Rollback steps are stated per phase rather than as a single end-of-plan afterthought"
+      ]
+    }
+  ]
+}

skilldrop_cli/data/packs/dev-team/skills/migration-plan/manifest.json

@@ -0,0 +1,11 @@
+{
+  "name": "migration-plan",
+  "version": "0.1.0",
+  "description": "Generate a phased migration or rollout plan (schema change, API version, datastore swap, platform move, auth-provider switch) — expand→migrate→contract by default, every phase reversible or its point of no return named, observable gates between phases, idempotent backfill with parity checks. Use when the user needs a migration plan, cutover plan, rollout strategy, or asks \"how do we get from X to Y without downtime\".",
+  "entrypoint": "SKILL.md",
+  "deps": { "npm": [], "pip": [] },
+  "env": { "required": [], "optional": [] },
+  "related": ["council-review", "tech-comparison-matrix", "test-plan-generator"],
+  "tags": ["migration", "rollout", "cutover", "backfill", "zero-downtime", "deployment"],
+  "model": { "tier": "standard", "rationale": "Phased plan synthesis with a strong template. Ordering judgment is bounded by the expand/migrate/contract pattern; escalate via ambiguous-input on contested, high-stakes cutovers." }
+}

skilldrop_cli/data/packs/dev-team/skills/migration-plan/templates/migration-plan.md

@@ -0,0 +1,68 @@
+# Migration-plan template
+
+Overview table first; per-phase detail second. Every phase carries the four mandatory fields — a phase missing one isn't done being planned.
+
+```markdown
+# Migration plan: {current state} → {target state}
+
+**Done means:** {checkable end state — "all reads on v2, v1 returns 410, legacy table dropped"}
+**Constraints:** downtime tolerance: {zero | window}; data volume: {rows/GB}; deadline: {date or none}
+[assumption] {defaults picked; one line each}
+
+## Phase overview
+
+| # | Phase | Change (one only) | Gate (observable) | Bake | Rollback | Blast radius |
+|---|---|---|---|---|---|---|
+| 1 | Expand schema | schema | migration applied, no slow-query regression | 24h | drop column (unused) | none — additive |
+| 2 | Dual-write | code path | write-error rate ≤ baseline; reconciler green | 48h | flag off, single-write | writes |
+| 3 | Backfill | data | parity 3-depth pass | — | stop job (resumable) | none — old path authoritative |
+| 4 | Ramp reads | traffic | per-step thresholds below | per step | flag to 0% | readers at current % |
+| 5 | **Point of no return:** {e.g. new store authoritative} | authority | {pre-crossing checklist} | — | **none — see below** | all |
+| 6 | Contract | cleanup | zero old-path reads for 14d | — | n/a (old path already cold) | none |
+
+## Per-phase detail
+
+### Phase {n} — {name}
+
+- **Action:** {exactly one change}
+- **Gate:** {metric + threshold + duration; who checks; dashboard link placeholder}
+- **Rollback:** {steps; data story explicitly — what happens to writes made since the phase started}
+  - Rehearsed: {date/environment, or "scheduled for {date}"}
+- **Blast radius:** {affected users/systems if this phase fails mid-way}
+- **Comms:** {who is told what, or "silence — deliberate, because {reason}"}
+
+## Backfill spec
+
+- **Idempotent:** {why re-running is safe — upsert keying, version guard}
+- **Resumable:** {checkpoint mechanism + granularity}
+- **Rate limit:** {N/s, and the metric that triggers slowdown — e.g. replica lag > 5s}
+- **Parity verification:**
+  1. Counts: {per table/partition}
+  2. Aggregates/checksums: {per partition, scheduled}
+  3. Deep-compare: {sample size + field-level diff}
+- **Dual-write reconciler:** {job name, schedule, alert on divergence > {threshold}} — required whenever dual-write is on
+
+## Traffic ramp
+
+| Step | Share | Min duration | Abort threshold |
+|---|---|---|---|
+| canary | internal / 1% | 24h | any correctness diff |
+| 2 | 10% | 24h | error rate > baseline +0.1% |
+| 3 | 50% | 48h | p99 > {x} ms |
+| 4 | 100% | 7d before phase 5 | — |
+
+## Point of no return
+
+**Crossing:** {the action after which rollback is impossible}
+**Verify immediately before:** {checklist}
+**Sign-off:** {role}
+
+## Contract phase commitment
+
+- Remove: {flags, dual-write, legacy tables/endpoints}
+- Owner: {role} · Date: {YYYY-MM-DD} · Gate: {e.g. zero old-path reads 14d, verified by metric}
+
+## Open assumptions / questions
+
+- [assumption] {…} — confirm with {who}
+```

skilldrop_cli/data/packs/dev-team/skills/pre-merge-review/SKILL.md

@@ -0,0 +1,85 @@
+---
+name: pre-merge-review
+description: Gate an existing change for merge — run one skill that fires the whole production-readiness pass. First a deterministic mechanical gate (lint + typecheck + tests, via a script whose exit code decides), then the three-reviewer panel dispatched in parallel — devils-advocate (correctness), security-reviewer (exploitability), code-quality (craft) — then a single READY / NOT READY verdict. Use before opening a PR or merging, when you want the full review fleet run on a diff you already have. Do NOT use to implement a feature from a spec (that's feature-implement-loop) or to review a document (that's doc-critique).
+---
+
+# pre-merge-review
+
+One command that runs the full production-readiness pass on a change you already have: the **mechanical gate** (deterministic — real commands, real exit codes) and the **reviewer panel** (three cold-read subagents), then a single **READY / NOT READY** verdict. This is the "is this safe to merge?" orchestrator — where [`feature-implement-loop`](../feature-implement-loop/SKILL.md) *generates* code and loops, this one *judges* a diff that already exists and gates it.
+
+Two gates, and they are different kinds. The mechanical gate is **not a judgment call** — a script runs the project's checks and its exit code decides, so a red gate can't be talked past. The review panel *is* judgment — three lenses that a deterministic check can't cover.
+
+## How to respond
+
+1. **Scope the change.** The diff, the branch vs. its base, or the files the user names. Everything below reviews *that change*, never the whole repo.
+
+2. **Run the mechanical gate first — it is un-bypassable.** Run the bundled gate script:
+   - Claude Code: `python3 ${CLAUDE_SKILL_DIR}/scripts/gate.py`
+   - Other IDEs: `python3 skills/pre-merge-review/scripts/gate.py`
+
+   It auto-detects the project's lint / typecheck / test commands (or takes `--cmd "…"` / `--config gate.json`), runs each, and **exits non-zero if any fail**. A **RED gate is an automatic `NOT READY`** — do not proceed to a positive verdict, no matter how clean the review looks. The pass/fail is the script's exit code, not your assessment of the code. If the gate can't determine commands, surface `BLOCKED: need verify commands` and ask for them once — never fabricate a green gate.
+
+3. **Fire the review panel — in parallel.** Independent lenses on the diff, each in a fresh context so none anchors on the author's reasoning:
+   - **Subagent tools (Claude Code, …):** dispatch the `devils-advocate` subagent (correctness — edge cases, broken assumptions, staff-engineer pushback, test gaps), the `security-reviewer` subagent (exploitability — authz/IDOR, injection, secret exposure, SSRF, unsafe deserialization, weak crypto, risky deps), and the `code-quality` subagent (craft — naming, structure, duplication, readability). Run them together; they don't depend on each other.
+   - **No-subagent tools (Codex, Cursor, Aider, …):** sweep the three lenses inline yourself — correctness, then security, then craft.
+   - Tag findings 🟥 blocker · 🟧 major · 🟨 minor · ⚪ nit, each with `file:line` and a concrete fix. **Merge and de-dupe** across the three lenses — when two flag the same line, report it once with both angles.
+
+4. **Render the verdict.** One word, then the reasons:
+   - **`READY`** — the mechanical gate is GREEN **and** there is no 🟥 blocker and no 🟧 major.
+   - **`NOT READY`** — the gate is RED, **or** any blocker/major stands. List every blocking item (gate failures first, then blocker/major findings) and what must change. 🟨 minor / ⚪ nit are listed but never block.
+   - **`BLOCKED`** — the gate couldn't run (unknown commands, no test setup). Name what's missing.
+
+5. **Escalate design disagreements — don't adjudicate them.** If the panel surfaces a genuine *tradeoff* dispute (not a bug — "should this be a queue or a cron?"), the verdict still gates on gate+blocker/major, but **offer [`council-review`](../../../core/skills/council-review/SKILL.md)** for the open decision rather than settling a design debate here.
+
+6. **Report.** Lead with the verdict. Then: the gate results table (command → PASS/FAIL), the merged panel findings by severity, and a **must-fix** list for `NOT READY`.
+
+## Useful references in this skill
+
+- [`scripts/gate.py`](scripts/gate.py) — the deterministic mechanical gate (`--list` to preview, `--cmd`/`--config` to override detection, `--install-hook` to enforce it — see below).
+
+## Enforce as a harness (opt-in)
+
+The verdict above is *advisory* — an agent can ignore prose. To make the gate **un-bypassable**, move enforcement into the substrate every tool shares (git and CI), not this skill's text:
+
+- **Layer 1 — local git block (portable across every tool).** Install a blocking pre-commit hook:
+  - Claude Code: `python3 ${CLAUDE_SKILL_DIR}/scripts/gate.py --install-hook --cmd "npm test" --cmd "npm run lint"`
+  - other IDEs: `python3 skills/pre-merge-review/scripts/gate.py --install-hook --cmd "…"`
+
+  Git runs it on every `git commit` no matter which tool (Claude, Cursor, Codex, Aider) drove the change; a RED gate blocks the commit. Bypassable with `git commit --no-verify`, so it stops honest mistakes, not a determined override. `--uninstall-hook` removes it.
+- **Layer 2 — CI required checks (un-bypassable).** Run the same commands as a required status check on the branch; the git host refuses the merge when they're red, outside any local tool — the layer that can't be `--no-verify`'d. Pair Layer 1 (fast local feedback) with Layer 2 (the backstop).
+- **Layer 3 — per-tool native (richer where it exists).** Where a tool can block its own turn, point it at the gate: Claude Code — a `Stop`/`PreToolUse` hook running `gate.py`; Aider — `--auto-test --test-cmd "python3 …/gate.py"`. Cursor and Codex lean on Layers 1–2.
+
+The honest limit: a portable *skill* can't physically block an agent — enforcement lives in git/CI (universal) or per-tool hooks (uneven). Rationale and the distinction from RFC-0006's reminder-only hooks: RFC-0019.
+
+## Quality bar
+
+- **The mechanical gate is run, not assumed.** A verdict with no real gate result is invalid — you ran the script (or reported `BLOCKED`), you didn't eyeball the tests.
+- **The gate is un-bypassable.** A RED gate is `NOT READY` regardless of how good the review looks. The review can add blockers; it can never clear a failing gate.
+- **Findings are merged and de-duped** across the three lenses — the same line is not reported three times.
+- **The verdict is one word plus the blocking reasons**, not a hedged paragraph. A reader sees READY/NOT READY and exactly what stands in the way.
+- **Design disagreements go to `council-review`**, not adjudicated here — this skill gates a change, it doesn't decide an architecture.
+
+## When to use this skill
+
+- ✅ Before opening a PR or merging — the full production-readiness pass on a diff you already have.
+- ✅ "Run all the reviewers on this change and tell me if it's safe to merge."
+- ✅ Reviewing a change you (or another agent) generated elsewhere, or a teammate's branch.
+
+## When NOT to use this skill
+
+- ❌ Implementing a feature from a spec — that's [`feature-implement-loop`](../feature-implement-loop/SKILL.md), which generates and loops; this skill only judges an existing change.
+- ❌ One lens is enough — a pure bug pass is [`devils-advocate`](../devils-advocate/SKILL.md) standalone; a pure doc pass is `doc-critique`.
+- ❌ An open design decision ("Postgres or Dynamo?") — that's `council-review`.
+
+## Anti-patterns to avoid
+
+- ❌ **Declaring `READY` on a RED gate.** The whole point is that the mechanical gate is un-bypassable. A failing test or lint is `NOT READY`, full stop — the review does not get a vote on it.
+- ❌ **Skipping the gate and "just reviewing".** Without the deterministic pass this is only half the check — the half that can be fooled. Run `scripts/gate.py`.
+- ❌ **A toothless panel.** Firing the three subagents (or sweeping the lenses) and reporting "no issues" on a real change — the panel earns its keep only if it's actually adversarial.
+- ❌ **Triple-reporting.** The same `file:line` flagged by all three lenses as three findings. Merge them.
+- ❌ **Adjudicating a design debate.** Settling "queue vs cron" inside the verdict instead of gating on gate+severity and offering `council-review`.
+- ❌ **Calling a reviewer *skill* from here.** Skills don't invoke skills (see CLAUDE.md). Drive the review *subagents* where they exist, or sweep the lenses inline.
+- ❌ **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.
+- ❌ **A bare `BLOCKED` line.** Keep the `BLOCKED: need <X>` line, then write for a person: what is missing in plain words, what you will produce once you have it, and anything the request already lets you say.
+
+**Non-interactive:** if the verify commands can't be detected and none were supplied, emit `BLOCKED: need verify commands (--cmd/--config)` — never fabricate a green gate. If the change scope is ambiguous, default to the working-tree diff and tag it `[assumption]` at the top of the report.

skilldrop_cli/data/packs/dev-team/skills/pre-merge-review/evals/eval_queries.json

@@ -0,0 +1,11 @@
+[
+  { "query": "is this change ready to merge?", "should_trigger": true },
+  { "query": "run all the reviewers on my branch before I open the PR", "should_trigger": true },
+  { "query": "production-readiness review of this diff", "should_trigger": true },
+  { "query": "gate my PR — lint, tests, and a full review", "should_trigger": true },
+  { "query": "review this branch and tell me if it's safe to ship", "should_trigger": true },
+  { "query": "implement this feature from the ticket's acceptance criteria", "should_trigger": false },
+  { "query": "just find the bugs in this function", "should_trigger": false },
+  { "query": "critique this design doc", "should_trigger": false },
+  { "query": "should we use Postgres or DynamoDB for this?", "should_trigger": false }
+]

skilldrop_cli/data/packs/dev-team/skills/pre-merge-review/evals/evals.json

@@ -0,0 +1,26 @@
+{
+  "skill_name": "pre-merge-review",
+  "evals": [
+    {
+      "id": "red-gate-is-not-ready",
+      "prompt": "Run a pre-merge review on my branch that adds a /export endpoint. The project is Python; `pytest` currently fails on one new test, and the endpoint reads user_id from the query string.",
+      "assertions": [
+        "Runs the mechanical gate (scripts/gate.py or the project's lint/typecheck/test commands) before or alongside the review — does not skip it",
+        "Treats the failing pytest as a RED gate that forces NOT READY on its own, independent of the review findings",
+        "Dispatches the three-reviewer panel (devils-advocate, security-reviewer, code-quality) or sweeps the three lenses inline",
+        "Flags the query-string user_id as an authorization/IDOR blocker with a concrete attacker path and a fix",
+        "Ends with a one-word verdict (NOT READY) plus an ordered must-fix list, gate failures first",
+        "Does not report the same file:line three times — findings are merged across lenses"
+      ]
+    },
+    {
+      "id": "clean-change-ready",
+      "prompt": "Pre-merge review this small, well-tested refactor branch — tests and lint pass locally.",
+      "assertions": [
+        "Runs the gate and reports it GREEN before rendering a positive verdict",
+        "Only returns READY when the gate is green AND there is no blocker and no major finding",
+        "Lists any minor/nit findings without letting them block the verdict"
+      ]
+    }
+  ]
+}

skilldrop_cli/data/packs/dev-team/skills/pre-merge-review/examples/pre-merge-verdict.md

@@ -0,0 +1,43 @@
+# Worked example — a NOT READY verdict where the mechanical gate is decisive
+
+Input → output oracle for `pre-merge-review`. Shows the un-bypassable gate: a clean-looking
+review does not clear a red test run, and the verdict leads with one word plus the blocking reasons.
+
+## Input
+
+> "Review my branch before I open the PR — it adds a `/export` endpoint that streams a user's
+> records as CSV."
+
+The change: a new `export_handler` + one new test.
+
+## Output
+
+**Verdict: `NOT READY`** — the mechanical gate is RED, and the panel adds one blocker.
+
+### Mechanical gate (`scripts/gate.py`, auto-detected)
+
+| Command | Result |
+|---|---|
+| `ruff check .` | PASS |
+| `mypy .` | PASS |
+| `pytest -q` | **FAIL** — `test_export_empty` errors: `export_handler` raises `TypeError` on a user with zero records |
+
+`GATE: RED — 1/3 command(s) failed.` A red gate is `NOT READY` on its own; the review below can only *add* blockers, never clear this.
+
+### Review panel (merged, de-duped)
+
+🟥 **blocker — missing authorization (security-reviewer).** `export_handler` reads `user_id` from the **query string** (`handler.py:12`) and returns that user's records with no check that the caller *is* that user — any authenticated user can export anyone's data (IDOR). *Fix:* derive `user_id` from the session, not the request; if an admin export is intended, gate it behind an explicit role check.
+
+🟧 **major — unbounded response (devils-advocate).** The CSV is built in memory for the full record set (`handler.py:20`); a user with millions of rows OOMs the process. *Fix:* stream rows, or paginate/cap.
+
+🟨 minor — **craft (code-quality):** `export_handler` mixes fetch, format, and HTTP concerns in one 60-line function (`handler.py:8-68`); extract `rows_to_csv()`. *(listed, does not block.)*
+
+### Must-fix before merge
+
+1. **Gate:** fix `export_handler` on the empty-records case so `pytest` is green.
+2. **Blocker:** derive `user_id` from the session — close the IDOR.
+3. **Major:** stream/cap the CSV to bound memory.
+
+## Why this passes the quality bar
+
+The gate was *run*, not assumed, and its RED result decides the verdict regardless of the review; findings are merged across the three lenses (security, correctness, craft) with no triple-reporting; the verdict is one word plus an ordered must-fix list — gate failures first, then blocker/major. A no-victim security note wasn't inflated to a blocker; the IDOR — with a concrete attacker path — was.