skilldrop-cli 1.4.0 → 1.6.0

package/packs/civil-architect/skills/floor-plan-layout/templates/plan.json

@@ -0,0 +1,38 @@
+{
+  "title": "Ground floor, house on Plot 14",
+  "units": "m",
+  "north": 15,
+  "wall": 0.23,
+  "min_door_width": 0.8,
+  "outline": [[0, 0], [10, 0], [10, 9], [0, 9]],
+  "rooms": [
+    {"name": "Foyer", "rect": [0, 0, 2.5, 2.4], "target_area": 6},
+    {"name": "Stair", "rect": [0, 2.4, 2.5, 2.4]},
+    {"name": "Living", "rect": [2.5, 0, 5.4, 4.8], "target_area": 25.9, "min_width": 3.6, "habitable": true},
+    {"name": "Prayer room", "rect": [7.9, 0, 2.1, 2.2], "target_area": 4.5, "habitable": true},
+    {"name": "Dining", "rect": [0, 4.8, 3.4, 4.2], "target_area": 14, "habitable": true},
+    {"name": "Kitchen", "rect": [3.4, 4.8, 3.0, 4.2], "target_area": 12.6, "habitable": true},
+    {"name": "Utility", "rect": [6.4, 4.8, 1.6, 2.3], "target_area": 4},
+    {"name": "Toilet", "rect": [6.4, 7.1, 1.6, 1.9], "target_area": 3.2},
+    {"name": "Hall", "rects": [[7.9, 2.2, 2.1, 2.6], [8.0, 4.8, 2.0, 4.2]]}
+  ],
+  "doors": [
+    {"between": ["outside", "Foyer"], "at": [1.25, 0], "width": 1.0},
+    {"between": ["Foyer", "Living"], "at": [2.5, 1.2], "width": 0.9},
+    {"between": ["Foyer", "Stair"], "at": [1.25, 2.4], "width": 0.9},
+    {"between": ["Living", "Dining"], "at": [2.95, 4.8], "width": 0.9},
+    {"between": ["Living", "Prayer room"], "at": [7.9, 1.1], "width": 0.8},
+    {"between": ["Living", "Hall"], "at": [7.9, 3.5], "width": 0.9},
+    {"between": ["Dining", "Kitchen"], "at": [3.4, 6.9], "width": 0.9},
+    {"between": ["Kitchen", "Utility"], "at": [6.4, 6.0], "width": 0.8},
+    {"between": ["Hall", "Toilet"], "at": [8.0, 8.0], "width": 0.8},
+    {"between": ["Hall", "outside"], "at": [9.0, 9], "width": 0.9}
+  ],
+  "windows": [
+    {"room": "Living", "at": [5.2, 0], "width": 2.4},
+    {"room": "Dining", "at": [0, 6.9], "width": 1.5},
+    {"room": "Kitchen", "at": [4.9, 9], "width": 1.2},
+    {"room": "Prayer room", "at": [10, 1.1], "width": 0.9},
+    {"room": "Toilet", "at": [7.2, 9], "width": 0.6}
+  ]
+}

package/packs/dev-team/loops/release/LOOP.md

@@ -5,7 +5,7 @@ description: Take merged code to live users through a planned, reversible rollou
 
 # release
 
-This loop covers the step between `build`, which ends when a human merges, and `operate`,
+This loop covers the step between `build`, which ends when a human merges, and running the service,
 which assumes the service is already live. A merge can be undone with a revert. A launch that
 has touched users or data often cannot be undone, so this loop gets its own gates instead of
 being folded into either neighbour.
@@ -39,8 +39,8 @@ being folded into either neighbour.
    `council-review`. `RECONSIDER` means it is ready but this is the wrong time, and the work
    waits instead of going back to `plan`.
 
-After `PROCEED`, the change is live and the work moves to `operate`. Gaps that G3 sent to
-`observability-plan` or `runbook-generator` are the first things `operate` picks up.
+After `PROCEED`, the change is live and the work moves to running it. Gaps that G3 sent to
+`observability-plan` or `runbook-generator` are the first things to pick up there.
 
 ## Verdicts
 
@@ -83,7 +83,7 @@ which end in `BLOCKED`.
 - **Rollback exists before readiness is judged.** A plan with no way back is the one thing that cannot be fixed after launch.
 - **Readiness rests on evidence.** Every check links to something; "we're good" is `not met`.
 - **Can and should are separate gates.** G3 says whether it can ship; G3.1 says whether it should ship now.
-- **Detection gaps leave this loop as hand-offs.** `operate` picks them up first, rather than discovering them during the first incident.
+- **Detection gaps leave this loop as hand-offs.** Running the service starts with them, rather than discovering them during the first incident.
 
 ## Anti-patterns to avoid
 

package/packs/dev-team/loops/release/loop.json

@@ -1,7 +1,7 @@
 {
   "$comment": "RFC-0031. Covers the step between build (ends at merge, G2.1) and operate (starts at instrument). Its gates are G3 and G3.1: the whole number places the loop in the lifecycle (discover G0 through operate G4), and a decimal is a second gate inside the same loop (RFC-0044).",
   "name": "release",
-  "version": "0.4.0",
+  "version": "0.4.1",
   "description": "Take merged code to live users through a planned, reversible rollout — plan the phases and the rollback, judge readiness on evidence, draft the release notes, then a human makes the go/no-go call. Use when the user has merged a change and asks how to roll it out, whether they are ready to launch, or for a go/no-go decision.",
   "entrypoint": "LOOP.md",
   "kind": "loop",

package/packs/dev-team/skills/bug-triage/SKILL.md

@@ -33,6 +33,7 @@ Converts the bug report someone *sent* into the ticket an engineer can *start*
 ## Useful references in this skill
 
 - [`templates/bug-ticket.md`](templates/bug-ticket.md) — the ticket skeleton with the severity/priority matrix and the no-repro diagnostics list
+- [`examples/export-row-limit-escalation.md`](examples/export-row-limit-escalation.md) — worked example: a VP's S1/P1 for "exports losing data" that the log shows is a 10,000-row CSV cap, filed S3/P2
 
 ## Quality bar
 

package/packs/dev-team/skills/bug-triage/examples/export-row-limit-escalation.md

@@ -0,0 +1,126 @@
+# Worked example: an escalated "exports are losing data" report
+
+Input → output oracle for `bug-triage`. Shows severity judged from the evidence rather than
+the escalation, a paraphrased error replaced by the verbatim string, and a three-symptom
+thread split into one bug, one more bug and one feature request.
+
+## Input
+
+> Can you turn this into a ticket for the Reports squad? Our VP of Customer Success wants it
+> filed as S1/P1 today. Tallow & Finch renew next month and they're furious.
+>
+> **#cs-escalations (pasted):**
+>
+> **Dana (CSM), 09:12:** Tallow & Finch say exports are losing data. Their ops lead exported
+> the Shipment Activity report for October and "half the shipments are gone". Got some random
+> error when it finished. Started after last week's release I think.
+>
+> **Dana, 09:14:** Also their dates come out as MM/DD in the CSV even though their account is
+> set to DD/MM. And they asked again for scheduled exports to SFTP.
+>
+> **Dana, 09:20:** Screenshot text from their ops lead: "Export ready. Some rows may not be
+> included. (EXPORT_ROW_LIMIT_REACHED)"
+>
+> **Marco (support engineer), 09:41:** Pulled the job log:
+>
+> ```
+> 2026-11-04T08:57:31Z export_job id=exp_88213 tenant=tallow-finch.example
+>   report=shipment_activity range=2026-10-01..2026-10-31 format=csv status=completed
+>   rows_matched=14212 rows_written=10000 warning=EXPORT_ROW_LIMIT_REACHED app=5.18.2
+> ```
+>
+> **Marco, 09:43:** The shipments are all there in the app, btw. The report shows 14,212 rows
+> on screen.
+
+## Output
+
+Filed as **S3/P2, not S1/P1.** Nothing stored was lost: the app still shows all 14,212 rows.
+The export file stops at 10,000. That is a real bug with a likely workaround. The VP can raise
+the priority to P1 for the renewal, but that changes priority only. The severity stays S3.
+The thread also held two other items, split out at the bottom.
+
+```markdown
+# CSV export of Shipment Activity stops at 10,000 rows (EXPORT_ROW_LIMIT_REACHED); remaining rows missing from file
+
+**Severity:** S3 — the export file is incomplete, stored data is intact, and splitting the date range likely works around it
+**Priority:** P2 — one tenant confirmed, renewal next month; a workaround CS can hand over today removes the need to drop current work
+**Blast radius:** any export over 10,000 rows, on any tenant `[assumption]`; one tenant confirmed `[verified]`
+**Component (best guess):** report export job `[assumption]`
+
+## Summary
+
+A customer ops lead exported October's Shipment Activity report as CSV. The file holds 10,000
+of the 14,212 matching rows `[verified: job log exp_88213]`. The dialog warned that rows "may
+not be included" `[reported: screenshot text]`. All 14,212 rows still show in the app
+`[verified: Marco, on screen]`.
+
+## Environment
+
+| Field | Value | Tag |
+|---|---|---|
+| App version | 5.18.2 | `[verified]` |
+| Tenant | tallow-finch.example | `[verified]` |
+| Report / range / format | shipment_activity, 2026-10-01..2026-10-31, CSV | `[verified]` |
+| Time | 2026-11-04 08:57:31 UTC | `[verified]` |
+| First seen / last worked | "after last week's release" | `[reported]` |
+
+## Reproduction
+
+**No repro yet.** One occurrence is confirmed in the log and nobody has reproduced it. Collect:
+- An export of any report with more than 10,000 matching rows on a test tenant, run on 5.18.2.
+  Record rows_matched and rows_written from the job log.
+- The downloaded file from exp_88213, to count its rows and check whether it ends cleanly at
+  row 10,000 or mid-row
+- Export job logs from the 30 days before last week's release, filtered on
+  `rows_written=10000`
+- A screenshot of the full export dialog, to check whether it states the limit or only "may
+  not be included"
+
+## Expected vs actual
+
+**Expected:** the CSV contains all 14,212 rows the report shows, or the export refuses and names the limit
+**Actual:** the CSV contains 10,000 rows, the job status is `completed`, and the dialog shows a vague warning
+**Error (verbatim):** `Export ready. Some rows may not be included. (EXPORT_ROW_LIMIT_REACHED)`
+
+## Hypotheses (≤3 — each with a 5-minute check; none of these is a conclusion)
+
+| # | Hypothesis | Quick check |
+|---|---|---|
+| H1 | 10,000 is a deliberate cap that was never documented | Search the export service config and docs for `10000` or `EXPORT_ROW_LIMIT` |
+| H2 | The cap or its warning arrived in a recent release | Filter export logs before last week's release for `rows_written=10000` |
+| H3 | Pagination stops after a fixed number of pages rather than a fixed row count | Export 10,001 rows and then 25,000 rows on a test tenant and compare rows_written |
+
+## Questions for reporter (≤3, ranked by diagnostic value)
+
+1. Has the ops lead had a complete export of more than 10,000 rows before? When was the last one?
+2. Do two half-month exports (Oct 1–15 and Oct 16–31) each come out complete?
+3. What does the file feed: a person reading it, or another system that will treat it as complete?
+
+## Duplicate-search hints
+
+`EXPORT_ROW_LIMIT_REACHED` · `export missing rows` · `csv export 10000`
+
+## Split out (if the report contained more than one issue)
+
+- CSV export writes dates as MM/DD when the account date format is DD/MM → to be filed as its own bug
+- Scheduled exports to SFTP → feature request, not a bug; route to the product backlog
+```
+
+## Why this is the oracle
+
+- **Severity is judged on worst plausible impact, and priority is judged separately.** The
+  reporter's words ("losing data", "half gone") and the VP's pressure both point at S1. The
+  evidence shows an incomplete file over intact data with a likely workaround, so the ticket
+  says S3. The VP's urgency is a legitimate input to priority, so the reply leaves that lever
+  with the VP and does not let it move severity.
+- **Tags separate reported from verified.** "Half the shipments are gone" is `[reported]`. The
+  log shows 10,000 of 14,212, about 70%, written. "After last week's release" stays a
+  hypothesis with a check (H2), not a stated cause.
+- **The verbatim error replaces the paraphrase, and one bug gets one ticket.** The "random
+  error" is quoted as the exact string, which is also the best duplicate-search term. The date
+  bug and the SFTP request get split out.
+
+A cheaper pass titles it "Exports losing data", files S1/P1 as asked, writes "Cause: 10k row
+limit introduced in 5.18" as fact, invents repro steps nobody ran, and puts the date bug in
+the same ticket. That ticket gets fixed in a rush on a guessed cause, and the date bug goes
+nowhere.

package/packs/dev-team/skills/bug-triage/manifest.json

@@ -1,6 +1,6 @@
 {
   "name": "bug-triage",
-  "version": "0.1.0",
+  "version": "0.1.1",
   "description": "Turn a vague bug report (Slack message, support ticket, \"it's broken on mobile sometimes\") into an actionable ticket — searchable symptom title, numbered repro steps from a clean state, expected vs actual, severity separated from priority, evidence tagged reported-vs-verified, and labeled hypotheses instead of root-cause guesses. Use when the user wants to triage a bug, write up a bug report, turn a complaint into a ticket, or make a flaky issue actionable.",
   "entrypoint": "SKILL.md",
   "deps": { "npm": [], "pip": [] },
@@ -10,5 +10,5 @@
     { "to": "feature-implement-loop", "when": "the defect is reproduced and scoped", "purpose": "Fix the triaged defect through the same capped loop a story gets.", "fallback": "If feature-implement-loop is absent, fix inline with a regression test that fails before the fix." }
   ],
   "tags": ["bug-triage", "bug-report", "ticket", "qa", "repro", "severity"],
-  "model": { "tier": "standard", "rationale": "Extraction plus judgment calls (severity vs priority, hypothesis ranking) — same shape as brief-intake: above light, below heavy." }
+  "model": { "tier": "heavy", "rationale": "Measured (RFC-0073): on its held-out evals the heavy tier met 92% and 92% of checks in two tier trials, against standard's 76% and light's 70% and 86%, more than 5 points ahead both times; moved once its examples/ oracle shipped (RFC-0074)." }
 }

package/packs/product-manager/skills/prd-draft/SKILL.md

@@ -28,6 +28,7 @@ Turns "the business wants X" into the document that aligns everyone on **what pr
 ## Useful references in this skill
 
 - [`templates/prd.md`](templates/prd.md) — the PRD skeleton with the solution-language test and MoSCoW table
+- [`examples/approver-delay-not-slack.md`](examples/approver-delay-not-slack.md) — worked example: a brief that blames a missing Slack integration when the data says approvers sit on requests
 
 ## Quality bar
 

package/packs/product-manager/skills/prd-draft/examples/approver-delay-not-slack.md

@@ -0,0 +1,142 @@
+# Worked example: a "Slack approvals" brief whose data describes a different problem
+
+Input → output oracle for `prd-draft`. Shows a solution-shaped brief rewritten as the problem
+its own data describes, an unsupported goal replaced by one the data can measure, and a policy
+constraint that the brief's "one click" pitch would have broken.
+
+## Input
+
+> Write the PRD for Slack approvals so eng can start next sprint. Sales says it's the #1 ask.
+> Two pages max. Everything I have is below.
+>
+> **brief.md (Head of Sales):**
+> Problem: we don't have a Slack integration and competitors do. Customers ask for it
+> constantly. Solution: Slack approvals, so managers approve expenses with one click right in
+> Slack. Seamless. Must use Slack Block Kit interactive messages. Goal: cut churn by 15%. Has
+> to ship before the Ledgerline Summit on 2027-03-09.
+>
+> **crm-summary.md:**
+> - Feature requests tagged "slack": 14 requests from 9 accounts in the last 12 months, out of
+>   1,340 paying accounts.
+> - Requests tagged "approval reminders" or "approve from phone": 31 requests from 22 accounts.
+>
+> **product-analytics.md:**
+> - Median time an expense waits at the approver step: 4.6 days. Median time in all other
+>   steps combined: 0.8 days.
+> - Of reimbursements paid late (more than 10 days after submission, the SLA in our customer
+>   contracts), 58% waited on an approver for more than 5 days.
+> - Chat tool connected, by account: Slack 38%, Microsoft Teams 27%, none 35%.
+> - Approvers who open the email notification approve a median of 1.1 days after it is sent.
+>
+> **policy.md (Finance and Security):**
+> - Approving an expense over $2,500 requires the approver to be signed in with MFA.
+> - Approvers cannot edit amounts. They can approve, reject with a reason, or return for changes.
+
+## Output
+
+```markdown
+# PRD: Faster approver decisions on submitted expenses
+
+**Status:** draft · **Owner:** Product Manager, Approvals · **Date:** 2026-11-05
+**Binding constraint:** fixed deadline, ship before 2027-03-09 `[reported by Head of Sales]`
+
+## Problem
+
+Employees wait for reimbursement mainly because expenses sit with their approver. The median
+wait at the approver step is 4.6 days, against 0.8 days for every other step combined
+`[data: product analytics]`. Of the reimbursements that miss the 10-day contractual SLA, 58%
+waited on an approver for more than 5 days `[data: product analytics]`. Approvers who open the
+notification email act in a median of 1.1 days `[data: product analytics]`, which suggests the
+delay is in noticing and getting to the request rather than in deciding `[assumption]`.
+Customers ask about this in several forms: 31 requests from 22 accounts for reminders or
+approving from a phone, and 14 requests from 9 accounts for Slack `[data: CRM]`.
+
+## Users
+
+**Primary:** a manager who approves their team's expenses, works mostly outside the expense
+app, and gets to approvals in batches. Job-to-be-done: clear the pending requests without
+setting time aside to log in.
+**Secondary (explicitly deprioritized):** employees who submit expenses. They feel the delay
+but cannot shorten it. Finance admins, who chase late approvals today, benefit indirectly.
+
+## Goals
+
+| # | Goal | We'll know it worked when |
+|---|---|---|
+| G1 | Approvers decide sooner | Median approver-step time drops from 4.6 to ≤ 2.0 days within 90 days of GA `[target: assumption]` |
+| G2 | Fewer reimbursements miss the contractual SLA | The share of reimbursements paid after 10 days falls by a third within 90 days of GA `[baseline needed]` |
+
+Full measurement design (instrumentation, guardrails, decision rule): hand to `success-metrics`.
+
+## Requirements
+
+| ID | Requirement (testable, solution-free) | MoSCoW | Maps to goal |
+|---|---|---|---|
+| R1 | An approver can approve, reject with a reason, or return for changes on an expense of $2,500 or less, from the notification itself, without signing in to the web app | M | G1 |
+| R2 | For an expense over $2,500, the same notification takes the approver to a signed-in, MFA-verified screen to decide | M | G1 |
+| R3 | The notification shows employee, amount, category, date and receipt thumbnail, enough to decide without opening the expense | M | G1 |
+| R4 | An approver with any pending request older than 2 days gets one reminder per day, listing all of them | S | G1, G2 |
+| R5 | The approver can act from at least one channel that reaches accounts with no chat tool connected | S | G2 |
+| R6 | A decision made from a notification shows in the expense's audit history with time and channel | M | G1 |
+| R7 | An approver can approve several pending requests in one action | C | G1 |
+
+**Won't have (this version):**
+- Editing amounts from a notification: policy forbids approvers editing amounts at all
+- Decisions on expenses over $2,500 without MFA, however the notification is delivered
+
+## Non-goals (minimum 3 — the scope-creep firewall)
+
+- **Submitting expenses from chat:** the delay is at approval, not submission. Revisit if
+  submission time becomes the bottleneck.
+- **Every chat tool in v1:** Slack reaches 38% of accounts and Teams 27% `[data]`. Which
+  channels ship first is a design decision, made against those numbers and the deadline.
+- **Finance-admin bulk overrides:** a different user with a different authorization surface.
+- **Churn reduction as a v1 target:** nothing in the inputs links approval time to churn. The
+  brief's "−15% churn" is out until someone produces that link.
+
+## Quality targets
+
+A decision taken from a notification shows in the web app within 10 seconds `[assumption]`.
+MFA rule as in policy. Full treatment → `nfr-spec`.
+
+## Open questions
+
+| Question | Owner | Needed by |
+|---|---|---|
+| Which channel(s) ship first given the 38% / 27% / 35% split and the 2027-03-09 date? | Eng lead + PM | 2026-11-19 |
+| What is the current share of reimbursements paid after 10 days (G2 baseline)? | Data analyst | 2026-11-12 |
+| Is there any evidence linking approval delay to churn? | Head of Sales | 2026-11-26 |
+| Can a decision from a notification count as "signed in" for the audit trail Finance needs? | Security lead | 2026-11-19 |
+
+## Assumptions log
+
+- [assumption] The delay is in noticing requests, not deciding them. Challenge by checking time-to-open versus time-to-decide by 2026-11-19.
+- [assumption] The G1 target of ≤ 2.0 days. Challenge in requirements review.
+
+## Handoffs
+
+- Stories & slicing → `user-story-splitter`
+- Quality targets → `nfr-spec`
+- Measurement → `success-metrics`
+- Technical approach (including the Block Kit question in the brief) → `design-doc`
+```
+
+## Why this is the oracle
+
+- **The problem statement passes the alternative-solution test.** The brief's problem, "we
+  don't have a Slack integration", is the absence of a solution. The data describes approvers
+  sitting on requests. Daily reminders, email actions, Teams, mobile push and Slack could each
+  follow from the rewritten paragraph. That matters here because Slack alone reaches 38% of
+  accounts.
+- **Every claim is tagged to its source and every goal can be measured.** "Customers ask
+  constantly" becomes 14 requests from 9 of 1,340 accounts, set beside the 31 requests from 22
+  accounts for reminders. The −15% churn goal has no support in the inputs, so it moves to the
+  non-goals with the reason, and G1 measures something the analytics already track.
+- **Requirements are testable and free of implementation.** "Must use Block Kit" goes to
+  design. "One click, seamless" becomes R1, which a tester can pass or fail. R2 carries the
+  $2,500 MFA rule, which the brief's pitch would have broken.
+
+A cheaper pass writes "Problem: competitors have Slack approvals and we don't", makes every
+line in the brief a Must, keeps "cut churn 15%" as G1 and "use Block Kit" as R1, and specifies
+one-click approval for every amount. That PRD ships a feature that 62% of accounts cannot
+use, measures it against a number nothing supports, and fails a security review in sprint 4.

package/packs/product-manager/skills/prd-draft/manifest.json

@@ -1,6 +1,6 @@
 {
   "name": "prd-draft",
-  "version": "0.1.0",
+  "version": "0.1.1",
   "description": "Draft a Product Requirements Document from a feature idea or brief — evidence-backed problem statement with zero solution language, testable MoSCoW-prioritized requirements, mandatory non-goals, and a success line per goal. Use when the user needs a PRD, wants to capture business requirements for a feature, or asks to turn an idea, pitch, or brief into a requirements doc.",
   "entrypoint": "SKILL.md",
   "deps": { "npm": [], "pip": [] },
@@ -12,5 +12,5 @@
     { "to": "design-doc", "when": "the what is agreed and the how is open", "purpose": "Design the system that satisfies these requirements.", "fallback": "If design-doc is absent, write the approach, the alternatives, and the trade-offs inline." }
   ],
   "tags": ["prd", "requirements", "product", "discovery", "moscow", "non-goals"],
-  "model": { "tier": "standard", "rationale": "Synthesizes a structured requirements doc from a brief. The solution-language discipline needs care; bounded by the template. Escalate via ambiguous-input on contested scope." }
+  "model": { "tier": "heavy", "rationale": "Measured (RFC-0073): on its held-out evals the heavy tier met 85% and 76% of checks in two tier trials, against standard's 68% and light's 68% and 68%, more than 5 points ahead both times; moved once its examples/ oracle shipped (RFC-0074)." }
 }

package/profiles.json

@@ -18,7 +18,7 @@
       "description": "The complete catalogue: every pack, every reviewer agent, every loop.",
       "packs": ["core", "solution-architect", "product-manager", "dev-team", "sre-oncall", "stakeholder-comms", "design", "ai-engineering", "api-builder", "converters", "experience-design", "research", "trackers", "data-analytics", "grc", "infra-as-code", "skill-engineering", "career"],
       "agents": ["devils-advocate", "security-reviewer", "code-quality"],
-      "loops": ["discover", "design", "build", "release", "operate", "ship-a-draft", "apply"]
+      "loops": ["design", "build", "release", "ship-a-draft", "research", "comply", "measure", "modernize", "ship-agent", "provision", "clarify"]
     }
   }
 }

package/packs/ai-engineering/loops/adopt/LOOP.md

@@ -1,120 +0,0 @@
----
-name: adopt
-description: Take an organisation from a pile of AI ideas to a first rollout wave its sponsor approved: the use cases ranked with a first slice, readiness scored against that slice, a usage policy covering the data the slice touches, and a cohort rollout whose first wave is the slice's users, with a gate that sends the slice back when a blocking gap stands in its way. Use when the user says "help us start using AI", "roll out AI across the team", "run the adopt loop", or has AI ideas, no policy and no rollout plan.
----
-
-# adopt
-
-One first slice, from a list of ideas to a wave of people using it. The four skills each work
-alone; in order, each one narrows the next. Triage picks one use case, so readiness is scored
-against what that use case needs instead of against the whole organisation. Readiness names the
-gaps, so the policy covers the data the slice really touches. The rollout's pilot is the slice's
-own users, and its adoption gate is the observable triage said would prove or kill the slice.
-
-## Stages
-
-| # | Stage | Type | Skills | Gate |
-|---|---|---|---|---|
-| 1 | `triage` | generate | [`ai-use-case-triage`](../../skills/ai-use-case-triage/SKILL.md) | — |
-| 2 | `readiness` | verify | [`ai-readiness-assessment`](../../skills/ai-readiness-assessment/SKILL.md) | **G11** review |
-| 3 | `policy` | generate | [`ai-usage-policy`](../../skills/ai-usage-policy/SKILL.md) | — |
-| 4 | `rollout` | generate | [`ai-adoption-rollout`](../../skills/ai-adoption-rollout/SKILL.md) | — |
-| 5 | `sign-off` | gate | [`doc-critique`](../../../core/skills/doc-critique/SKILL.md) | **G11.1** human |
-
-## How to run this loop
-
-1. **Triage the ideas.** Run `ai-use-case-triage` on whatever the person brought: a brainstorm,
-   a backlog, interview notes. Save it as `triage.md`. Carry three things from it into every
-   later stage: the first slice (one workflow and the people who do it), the observable that
-   proves or kills it, and the time box.
-2. **Score readiness for the slice.** Run `ai-readiness-assessment` scoped to the slice's team
-   and the decision "can this slice start". Each dimension is read against what the slice
-   needs: Data is the data the slice reads, Tooling is the tool the slice uses, Process is the
-   review step the slice's output passes through. Save it as `readiness.md`.
-3. **Judge the slice at G11.** Ask three questions, then choose the verdict below:
-   - Does any gap the assessment ranks as blocking sit on something the slice needs?
-   - Can each remaining gap be closed inside the slice's time box, with an owner role named?
-   - Is there a review step where a person checks the slice's output before anyone acts on it?
-4. **On `REVISE`, change the slice, not the scores.** Return to `triage` with the blocking gap
-   as a constraint, and pick the highest-ranked candidate that does not need what is missing.
-   The not-yet list's promotion conditions say which one. Each return counts against the cap.
-5. **Write the policy for the slice's data.** Run `ai-usage-policy` for the slice's people,
-   naming every kind of data the slice puts into a tool (from triage and the Data line of
-   readiness). Every kind of data the slice touches gets a rule; a rule for data the slice
-   never touches stays out of this version. Save it as `policy.md`.
-6. **Plan the rollout from the slice.** Run `ai-adoption-rollout` with the slice's users as the
-   pilot cohort and triage's observable as the pilot's adoption gate. G11's conditions become
-   preconditions the pilot cannot open without. Save it as `rollout.md`.
-7. **Ask the sponsor at G11.1.** Run `doc-critique` over the policy and the rollout together,
-   then put the first wave, the conditions and the critique's open findings to the person who
-   sponsors the slice. Only they choose the verdict. In a non-interactive run, stop here and
-   write the decision they need to make; never record their verdict for them.
-8. **Hand over the plan, then the verdict.** Lead with the slice, who starts using it and when,
-   and what would end it. The scorecard, the policy and the cohort plan go underneath. Close
-   with each gate on its own line, `G11: <VERDICT>` and `G11.1: <VERDICT>` (or
-   `G11.1: awaiting <role>`), and one sentence of reasons.
-
-## Verdicts
-
-Defined in [`contracts/terminals.json`](../../../../contracts/terminals.json). G11 emits:
-
-- `PROCEED`: no blocking gap sits on what the slice needs, and its output has a review step.
-- `PROCEED WITH CONDITIONS`: a gap sits on the slice but can close inside the time box, with
-  an owner role. Each condition travels into the rollout as a precondition for the pilot.
-- `REVISE`: a blocking gap sits on the slice and won't close inside the time box. Return to
-  `triage` with that gap as a constraint.
-- `RECONSIDER`: the gap blocks every candidate, such as no rule for what may go into any tool
-  or no tool access at all. Fixing it is the work, so the loop ends here with that gap's first
-  action and owner role.
-- `BLOCKED`: no candidates to triage, or no team the slice belongs to.
-
-G11.1 emits `PROCEED`, `PROCEED WITH CONDITIONS`, `REVISE` (back to `policy`, when the sponsor
-rejects a rule or a cohort) or `BLOCKED` (no sponsor named).
-
-On the cap-th `REVISE` at G11, emit `RECONSIDER`: three slices in a row hit blocking gaps, so
-the gaps are the work.
-
-## Non-interactive runs
-
-With no candidates, `ai-use-case-triage` emits `BLOCKED`; carry it through as the loop's
-verdict and run no further stages. Missing weights and readiness evidence degrade to the
-skills' own `[assumption]` and `[insufficient evidence]` tags. G11.1 always stops at the
-sponsor: write `G11.1: awaiting <role>` with the decision they face, never a verdict.
-
-## When a stage's skill is not installed
-
-Name the missing skill and skilldrop as its source, do the minimal inline version of that
-stage, and record that it ran degraded. A degraded `readiness` still scores Data, Tooling,
-Governance and Process against the slice with an evidence line each, because G11 can't be
-judged without them. Never skip G11 or G11.1.
-
-## 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-11-03T10:15:00Z","loop":"adopt","stage":"readiness","gate":"G11","verdict":"REVISE","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).
-The log holds verdicts only: never the use cases, the scores or the policy.
-`skilldrop loop-stats` summarises the file.
-
-## Quality bar
-
-- **Readiness is scored against the slice.** An organisation-wide score hides the one gap that stops the slice and flags gaps that stop nothing yet.
-- **A `REVISE` changes the slice.** It never re-scores a dimension upward to let the same slice through.
-- **The policy covers every kind of data the slice touches,** each restriction with what to do instead.
-- **The pilot is the slice's users, and its adoption gate is triage's observable.** A pilot of volunteers from elsewhere proves nothing about the slice.
-- **G11.1 is the sponsor's call.** The loop writes the decision they face; it never records their verdict.
-
-## Anti-patterns to avoid
-
-- ❌ **Scoring the whole company's readiness first.** The assessment then ranks gaps by how bad they look, not by what they block.
-- ❌ **Writing a policy for every tool and every kind of data before anything ships.** It is long, it is late, and nobody reads the part that matters to the pilot.
-- ❌ **Passing G11 with a blocking gap and a promise.** A gap that won't close inside the time box is a `REVISE`, however good the slice looks.
-- ❌ **A pilot gate that is "the pilot went well".** The gate is triage's observable, with its threshold and time box.
-- ❌ **Running all four skills before the first gate.** A policy and a rollout written for a slice that then fails G11 are thrown away.

package/packs/ai-engineering/loops/adopt/evals/eval_queries.json

@@ -1,10 +0,0 @@
-[
-  {"query": "help us start using AI in the finance team, we have ideas but no rules and no plan", "should_trigger": true},
-  {"query": "run the adopt loop on these AI use cases from the workshop", "should_trigger": true},
-  {"query": "we want to roll out AI across the support team: pick where to start, check we're ready, write the rules and plan the waves", "should_trigger": true},
-  {"query": "take this list of AI ideas to a first pilot our VP can sign off", "should_trigger": true},
-  {"query": "rank these twelve AI use cases by value and risk", "should_trigger": false},
-  {"query": "write an AI acceptable-use policy for our staff", "should_trigger": false},
-  {"query": "how far along is our engineering team with coding agents?", "should_trigger": false},
-  {"query": "design an eval harness for our support chatbot", "should_trigger": false}
-]

package/packs/ai-engineering/loops/adopt/evals/evals.json

@@ -1,69 +0,0 @@
-{
-  "loop_name": "adopt",
-  "evals": [
-    {
-      "id": "slice-first-then-readiness",
-      "prompt": "Run the adopt loop for our 40-person customer operations team at Larkspur Freight. Ideas from last week's workshop: (1) draft first replies to shipment-delay emails, (2) summarise call recordings for QA, (3) auto-approve refund claims under 50 GBP, (4) translate customs paperwork. We have Microsoft 365 with Copilot licences for 12 people; nobody has written any rules about what can go into it. Delay emails include customer names and tracking numbers; call recordings include card details read out loud. QA reviews 5% of calls today. The head of customer operations, Priya Anand, is the sponsor. Non-interactive: no follow-up questions.",
-      "assertions": [
-        "Runs ai-use-case-triage first and names one first slice with an observable that proves or kills it and a time box",
-        "Does not pick auto-approving refunds as the first slice, because its output reaches money without a review step",
-        "Scores readiness against the slice's needs (its data, the Copilot licences, its review step), not the whole company in general",
-        "Reaches a G11 verdict from PROCEED, PROCEED WITH CONDITIONS, REVISE, RECONSIDER or BLOCKED with the reasons",
-        "The policy has a rule for every kind of data the slice puts into a tool, each with what to do instead",
-        "The rollout's pilot is the slice's users and its adoption gate is triage's observable",
-        "Stops at G11.1 for the sponsor and writes the decision she faces, without recording a verdict for her",
-        "Does not invent tools, owners, regulations or figures the prompt did not give"
-      ]
-    },
-    {
-      "id": "blocking-gap-sends-the-slice-back",
-      "prompt": "Continuing the adopt loop. The readiness assessment for our first slice (summarising call recordings for QA) found that recordings contain card numbers read aloud, the recording system has no redaction, and the vendor says redaction ships in Q3 next year. Our time box for the slice was 6 weeks. The not-yet list from triage said: draft first replies to delay emails — promote when a reviewer can check the draft before it's sent (they can: agents already approve every outbound email). What now?",
-      "assertions": [
-        "Treats the redaction gap as blocking the slice and gives G11 REVISE, not PROCEED WITH CONDITIONS",
-        "Returns to triage rather than re-scoring readiness upward",
-        "Picks the delay-email drafting slice because its promotion condition is met",
-        "Re-scores readiness for the new slice before writing any policy",
-        "Counts the new slice's readiness check as round 2 under the cap of 3",
-        "Does not write a policy or rollout for the call-summary slice"
-      ]
-    },
-    {
-      "id": "blocked-without-candidates",
-      "prompt": "Run the adopt loop. We want to use more AI. Non-interactive, no follow-up questions.",
-      "assertions": [
-        "Emits BLOCKED and names what is missing: the candidate use cases and the team they belong to",
-        "Does not invent use cases, a team, or a sponsor",
-        "Does not run the readiness, policy or rollout stages",
-        "Says in plain words what it will produce once it has the candidates"
-      ]
-    },
-    {
-      "id": "adopt-first-wave-to-sign-off",
-      "held_out": "2026-11-03",
-      "prompt": "We want to start using AI at Pellmore but honestly it's a pile of ideas and nobody's written any rules. The ideas are in ai-ideas.md, company background is in org-context.md and last month's staff survey is staff-survey.csv. Can you run the adopt loop and get us to a first wave Ruth can sign off?",
-      "assertions": [
-        "Runs the stages in order (use-case triage, then readiness, then usage policy, then rollout, then sign-off), and each stage uses the previous one's output: readiness is scored against the named first slice, not the company in general",
-        "Triage ranks all seven ideas on value, feasibility and risk with the weights shown, names one first slice, and gives a not-yet list with the condition that would promote each",
-        "Gate G11 gives a verdict of PROCEED or PROCEED WITH CONDITIONS with an evidence line from the inputs per readiness score, and any conditions it sets show up in the policy or rollout",
-        "The usage policy covers the data the chosen slice touches (for delivery-date replies: customer names, addresses, phone numbers and order details from KitchenTrack), pairs every 'don't' with what to do instead, says what to do if data has already gone into a personal account, and addresses the personal-account use the survey found",
-        "The rollout's first wave is the chosen slice's users (the 14-person customer service team if the slice is delivery-date replies), fits within the 25 licensed seats, and has an adoption gate before the next wave opens; the comms plan answers the union rep's jobs question by saying what will not change",
-        "Stops at G11.1 with the doc-critique findings and asks Ruth Calloway to sign off; it does not record her approval itself or declare the wave approved",
-        "Does not invent tools, licences, owners, regulations or figures not in the inputs, such as a second AI vendor, a CRM, or headcounts that differ from org-context.md"
-      ]
-    },
-    {
-      "id": "adopt-sponsor-slice-blocked-by-client-data",
-      "held_out": "2026-11-03",
-      "prompt": "Margaret (our managing partner, she's sponsoring this) wants AI drafting replies to client tax queries to be the first thing we do. She's decided, so rank the rest of the ideas around it. Ideas are in ai-ideas.md, background is in firm-context.md. Run the adopt loop please, we'd like a rollout plan in front of her by the end of the month.",
-      "assertions": [
-        "Triage ranks all six ideas with the weights shown, records client tax-query replies as the first slice as the sponsor decided, and gives a not-yet list",
-        "Readiness is scored against the tax-query slice and names as blocking gaps that engagement-letter clause 9.2 and Schedule B allow no AI service without each client's prior written consent, and that no AI tool is licensed or approved, quoting or citing firm-context.md",
-        "Gate G11 does not pass: the verdict is REVISE, RECONSIDER or BLOCKED, not PROCEED, and it sends the slice back naming what would clear it (client consent or updated engagement letters and Schedule B, plus a contracted tool) or a slice that touches no client data, such as procedures-manual Q&A or the weekly guidance briefing",
-        "States the conflict with Margaret's decision plainly rather than silently swapping in a different slice",
-        "Does not write a usage policy or cohort rollout that treats client tax-query replies as cleared to go; if it reruns with a different slice, it scores readiness against that slice before writing the policy and rollout",
-        "Does not claim Margaret's approval or reach the G11.1 sign-off for the blocked slice",
-        "Does not invent an approved AI tool, a vendor agreement, client consent, or a regulation the inputs do not give"
-      ]
-    }
-  ]
-}