skilldrop-cli 1.3.0 → 1.5.0

package/packs/solution-architect/loops/design/evals/evals.json

@@ -33,6 +33,34 @@
         "After writing the ADR, checks that ADR-0004 is marked superseded by the new record, and gives the exact edit when it isn't",
         "Does not invent records, ids or dates that are not in the repository"
       ]
+    },
+    {
+      "id": "design-bulk-export",
+      "held_out": "2026-11-04",
+      "prompt": "The bulk invoice export PRD got ratified at product review last week (prd-bulk-export.md). Our existing ADRs are in adr/. Can you work out how we should build it and write up the decision?",
+      "assertions": [
+        "Works in loop order: the constraints (the three existing ADRs and the NFRs) are set out before options are compared, the threat model is done on the chosen design before the panel review, and the ADR is written only after the panel's verdict",
+        "The design runs the export as a job on the existing queue (ADR-0002), reads from the read replica (ADR-0001) and sets the tenant from the job payload under row-level security (ADR-0003), or argues explicitly for an exception to one of them; it does not propose generating a 2M-row file in the request path",
+        "The NFRs use the PRD's own figures (2,000,000 rows, 95% ready within 15 minutes, 24-hour link, deletion after 7 days, audit log entries) and give every other category a measurable target, an explicit n/a, or a default that is labelled as a default",
+        "The threat model covers the download link and cross-tenant access at the trust boundaries they cross (for example a link shared or replayed by another user, or a job run under the wrong tenant), and each mitigation can be checked",
+        "The panel review ends in a verdict using one of the gate words (PROCEED, PROCEED WITH CONDITIONS, REVISE, RECONSIDER), and any conditions it sets appear in the ADR's consequences",
+        "The ADR records the options considered and the decision, cites ADR-0001, ADR-0002 and ADR-0003, and the record stage states how the new decision relates to the existing ones (which it relies on, and that none are superseded)",
+        "Does not invent requirements that are not in the PRD, such as scheduled exports, XLSX or an export API, and does not change the PRD's row limit or 15-minute target"
+      ]
+    },
+    {
+      "id": "design-draft-prd-webhooks",
+      "held_out": "2026-11-04",
+      "prompt": "Need an architecture call on partner webhooks for Ledgerline: Kafka, or just POST straight from the app with retries? PRD is prd-partner-webhooks.md, ADRs in adr/. Skip the threat model, it's internal-ish. Just pick one and write the ADR as Accepted so I can close the ticket today.",
+      "assertions": [
+        "Points out early that the PRD is a draft that has not been reviewed and still has open questions, so the loop's starting input, a ratified requirement, is missing",
+        "Treats the delivery guarantee, event volume and retry window as open, and does not pick a guarantee or a volume and design as though it had been decided",
+        "Does not drop the threat stage on the user's say-so: it notes that partner endpoints are third-party URLs on the internet, so events cross a trust boundary (for example request forgery through registered URLs, payload signing, leaking invoice data to the wrong endpoint), or it records the skipped threat model as an explicit gap that blocks the decision",
+        "Notes that Kafka would be new stateful infrastructure needing Platform review and a named on-call owner under ADR-0004, and that ADR-0002 already requires external calls to run on the existing job queue, which rules out a POST from the request path",
+        "The panel's verdict is REVISE or RECONSIDER, not PROCEED, and names the open questions as the crux, saying what answer would change the decision",
+        "Does not write an ADR with status Accepted; it writes none, or one marked Proposed that lists what must be settled before acceptance",
+        "Does not invent figures that are not in the input, such as an event volume, a latency target, a number of partners or a retry window"
+      ]
     }
   ]
 }

package/packs/solution-architect/loops/design/evals/files/design-bulk-export/adr/0001-postgres-system-of-record.md

@@ -0,0 +1,23 @@
+# ADR-0001: PostgreSQL is the system of record
+
+- Status: Accepted
+- Date: 2024-03-11
+- Deciders: Platform team
+
+## Context
+
+Ledgerline needs one transactional store for tenants, customers, invoices and payments. We considered PostgreSQL, MySQL and a document store.
+
+## Decision
+
+PostgreSQL 15 (managed) is the single system of record for all billing data. Read replicas may be used for reporting and other read-heavy workloads; nothing writes to a replica.
+
+## Consequences
+
+- Heavy reads (reports, exports) should go to the read replica, not the primary.
+- Replica lag is normally under 2 seconds; features that read from the replica must tolerate that.
+
+## Governs
+
+- `services/billing-api/db/`
+- `infra/postgres/`

package/packs/solution-architect/loops/design/evals/files/design-bulk-export/adr/0002-background-work-via-job-queue.md

@@ -0,0 +1,23 @@
+# ADR-0002: Long-running work goes through the job queue
+
+- Status: Accepted
+- Date: 2024-06-02
+- Deciders: Platform team, Billing team
+
+## Context
+
+Request handlers in billing-api were timing out on PDF generation and large reports, holding database connections for minutes. The load balancer cuts requests at 30 seconds.
+
+## Decision
+
+Any work expected to take more than 5 seconds runs as a job on the existing Redis-backed job queue (`jobs-worker` service), never in the request path. The request handler enqueues the job and returns a job ID. Jobs must be idempotent and safe to retry; the queue retries a failed job up to 3 times.
+
+## Consequences
+
+- Features with long-running work need a job status model and a way to tell the user when the job is done.
+- `jobs-worker` concurrency is capped at 20 jobs per pod, 4 pods. Heavy jobs must not starve PDF generation.
+
+## Governs
+
+- `services/jobs-worker/`
+- `services/billing-api/jobs/`

package/packs/solution-architect/loops/design/evals/files/design-bulk-export/adr/0003-tenant-isolation-row-level.md

@@ -0,0 +1,25 @@
+# ADR-0003: Tenant isolation by row-level security
+
+- Status: Accepted
+- Date: 2024-09-19
+- Deciders: Platform team, Security
+
+## Context
+
+All tenants share one database. A missed `WHERE tenant_id = ?` in application code leaked one tenant's customer list to another in a staging test (no production impact).
+
+## Decision
+
+Every tenant-owned table has a PostgreSQL row-level security policy on `tenant_id`. Each connection sets `app.tenant_id` at the start of a request or job, and queries run as the `app_tenant` role, which cannot bypass RLS. Background jobs must set the tenant from the job payload, never from a default.
+
+## Consequences
+
+- Code that runs outside a request (jobs, scripts) is responsible for setting the tenant before any query.
+- Cross-tenant work (admin tooling) uses a separate audited role.
+- Files produced from tenant data must be stored under a tenant-scoped prefix.
+
+## Governs
+
+- `services/billing-api/db/policies/`
+- `services/jobs-worker/tenant_context.py`
+- `infra/object-storage/`

package/packs/solution-architect/loops/design/evals/files/design-bulk-export/prd-bulk-export.md

@@ -0,0 +1,50 @@
+# PRD: Bulk invoice export (CSV)
+
+- **Product:** Ledgerline
+- **Author:** Ines Moreau (PM, Billing)
+- **Status:** Ratified — product review, 28 Oct 2026 (approvers: Ines Moreau, Kwame Asante (Eng Manager, Billing), Lotte Jansen (Head of Finance Ops))
+- **Tracking:** LDG-2210
+
+## Problem
+
+Finance admins at our larger tenants reconcile invoices in their own accounting tools at month end. Today the only way to get invoice data out of Ledgerline is the invoice list page, which pages 100 rows at a time, or a support ticket asking us to run a query. In September 2026 support handled 61 export requests from 23 tenants; median time to fulfil was 2.5 working days. Finance admins at three tenants told us in calls that month-end close slips because they wait on us.
+
+## Goals
+
+| Goal | Success line |
+|---|---|
+| G1. A finance admin can get all of their tenant's invoices for a date range without contacting support | Export-related support tickets fall from 61/month to under 10/month within two months of launch |
+| G2. Exports are fast enough to use during month-end close | 95% of exports are ready to download within 15 minutes of the request |
+
+## Users
+
+- **Finance Admin** role only. Other roles (Member, Viewer, Billing Contact) must not see or use the feature.
+
+## Requirements
+
+| ID | Priority | Requirement |
+|---|---|---|
+| R1 | Must | A Finance Admin can request a CSV export of invoices filtered by issue-date range (max 24 months) and status (any combination of draft, open, paid, void). |
+| R2 | Must | One export can contain up to 2,000,000 rows. Our largest tenant today has 1.6M invoices. |
+| R3 | Must | The requester is notified in-app and by email when the export is ready, with a download link. |
+| R4 | Must | The download link works for 24 hours and only for the user who requested it. |
+| R5 | Must | Export files are deleted 7 days after creation. |
+| R6 | Must | Columns: invoice number, issue date, due date, status, customer name, customer email, currency, net, tax, gross, paid date. |
+| R7 | Must | Every export request and every download is written to the tenant's audit log (who, when, filters, row count). |
+| R8 | Should | A Finance Admin can see their last 10 exports and their status (queued, running, ready, failed, expired). |
+| R9 | Could | Cancel a queued or running export. |
+
+## Data
+
+Export files contain customer names and email addresses (personal data) and invoice amounts. Same classification as the invoice table: Confidential.
+
+## Non-goals
+
+- Scheduled or recurring exports.
+- Formats other than CSV (no XLSX, no PDF bundle).
+- An export API for integrations. Covered separately in LDG-2302.
+- Exporting line items. Invoice headers only.
+
+## Open questions
+
+None outstanding. (Line-item export was moved to non-goals at review.)

package/packs/solution-architect/loops/design/evals/files/design-draft-prd-webhooks/adr/0002-background-work-via-job-queue.md

@@ -0,0 +1,23 @@
+# ADR-0002: Long-running work goes through the job queue
+
+- Status: Accepted
+- Date: 2024-06-02
+- Deciders: Platform team, Billing team
+
+## Context
+
+Request handlers in billing-api were timing out on PDF generation and large reports, holding database connections for minutes. The load balancer cuts requests at 30 seconds.
+
+## Decision
+
+Any work expected to take more than 5 seconds, or that calls an external system, runs as a job on the existing Redis-backed job queue (`jobs-worker` service), never in the request path. The request handler enqueues the job and returns. Jobs must be idempotent and safe to retry; the queue retries a failed job up to 3 times with exponential backoff.
+
+## Consequences
+
+- `jobs-worker` concurrency is capped at 20 jobs per pod, 4 pods.
+- The queue does not guarantee ordering between jobs.
+
+## Governs
+
+- `services/jobs-worker/`
+- `services/billing-api/jobs/`

package/packs/solution-architect/loops/design/evals/files/design-draft-prd-webhooks/adr/0004-new-stateful-infra-needs-platform-signoff.md

@@ -0,0 +1,22 @@
+# ADR-0004: New stateful infrastructure needs Platform sign-off
+
+- Status: Accepted
+- Date: 2025-08-14
+- Deciders: Platform team, Engineering leadership
+
+## Context
+
+In 2025 three product teams each stood up their own stateful component (a second Redis, an Elasticsearch cluster, a RabbitMQ). Two had no on-call owner when they failed. Platform ended up running all three.
+
+## Decision
+
+No team adds a new stateful infrastructure component (database, message broker, streaming platform, search cluster, cache) to production without a Platform team review and a named on-call owner. Requests go through the Platform intake (PLAT board); the review takes about two weeks.
+
+## Consequences
+
+- Product teams should prefer the existing PostgreSQL, Redis job queue and object storage where they fit.
+- A design that needs a new component must name it, state why the existing ones do not fit, and include the Platform review in its timeline.
+
+## Governs
+
+- `infra/`

package/packs/solution-architect/loops/design/evals/files/design-draft-prd-webhooks/prd-partner-webhooks.md

@@ -0,0 +1,36 @@
+# PRD: Partner webhooks
+
+- **Product:** Ledgerline
+- **Author:** Sam Okonkwo (PM, Integrations)
+- **Status:** DRAFT — not yet reviewed
+- **Tracking:** LDG-2341
+
+## Problem
+
+Partners who build on Ledgerline (accounting connectors, dunning tools) poll our REST API every few minutes to find out whether invoices have changed. Two partners have told us polling is costing them API quota and that they see changes late.
+
+## Goals
+
+- Partners find out about invoice changes without polling.
+
+## Requirements (draft)
+
+| ID | Priority | Requirement |
+|---|---|---|
+| R1 | Must | A partner can register an HTTPS endpoint URL per tenant connection. |
+| R2 | Must | We send an event to that URL when an invoice is created, updated, paid or voided. |
+| R3 | Must | Event body includes invoice ID, event type, timestamp, and the invoice as returned by `GET /v2/invoices/{id}`. |
+| R4 | Should | Failed deliveries are retried. |
+| R5 | ? | Partners can replay events from the last N days. |
+
+## Non-goals
+
+- Webhooks for objects other than invoices (customers, payments) in v1.
+
+## Open questions
+
+1. **Delivery guarantee.** At-least-once, or do partners need ordering per invoice? Two partners asked for "exactly once"; we haven't asked what they'd accept. — *owner: Sam, not started*
+2. **Volume.** We don't know how many events this produces. Invoice updates per day across all tenants is not something we currently measure. "Somewhere between thousands and a lot." — *owner: data team, not started*
+3. **Retry window.** How long do we keep retrying a failing partner endpoint? — *not discussed*
+4. **R5 replay.** In or out of v1? — *not discussed*
+5. **Who registers the URL** — the partner, or the tenant's admin when they connect the partner? — *not discussed*

package/packs/solution-architect/skills/api-contract-draft/manifest.json

@@ -1,6 +1,6 @@
 {
   "name": "api-contract-draft",
-  "version": "0.1.2",
+  "version": "0.1.3",
   "description": "Draft an OpenAPI 3.1 contract from a feature brief or story — resource-oriented paths, a full error catalog (RFC 9457), pagination/idempotency/versioning decided not deferred, examples on every operation, plus a decisions log so review argues choices instead of YAML. Use when the user wants to design an API, draft an OpenAPI/Swagger spec, define request/response shapes, or agree a contract between frontend/backend or two teams before code.",
   "entrypoint": "SKILL.md",
   "deps": {
@@ -27,7 +27,7 @@
     "asyncapi"
   ],
   "model": {
-    "tier": "standard",
-    "rationale": "Schema synthesis against fixed conventions. The resource modeling needs judgment; the conventions bound it. Escalate via ambiguous-input on contested multi-team contracts."
+    "tier": "light",
+    "rationale": "Measured (RFC-0073): on its held-out evals the light tier met 76% and 92% of checks in two tier trials, against standard's 69% and heavy's 69% and 76%, within 5 points of the best both times."
   }
 }

package/packs/solution-architect/skills/architecture-diagrams/manifest.json

@@ -1,6 +1,6 @@
 {
   "name": "architecture-diagrams",
-  "version": "0.1.0",
+  "version": "0.1.1",
   "description": "Generate architecture diagrams (Mermaid, PlantUML, C4) from a written description of a system. Supports AWS/Azure/GCP cloud topologies, microservice landscapes, sequence flows, container diagrams, and ER models. Use whenever the user asks for an architecture diagram, system sketch, flow diagram, or visualization of a design.",
   "entrypoint": "SKILL.md",
   "deps": {
@@ -25,7 +25,7 @@
     "architecture"
   ],
   "model": {
-    "tier": "standard",
-    "rationale": "Prose to diagram syntax. Correctness matters; reasoning is bounded."
+    "tier": "light",
+    "rationale": "Measured (RFC-0073): on its held-out evals the light tier met 93% and 100% of checks in two tier trials, against standard's 93% and heavy's 93% and 93%, within 5 points of the best both times."
   }
 }

package/packs/solution-architect/skills/design-doc/manifest.json

@@ -1,6 +1,6 @@
 {
   "name": "design-doc",
-  "version": "0.1.3",
+  "version": "0.1.4",
   "description": "Generate a Google-style engineering design doc (problem, goals/non-goals, options considered, recommended approach, risks, rollout) from a feature brief or short description. Use when the user wants to draft a design doc, technical proposal, or one-pager for an engineering review.",
   "entrypoint": "SKILL.md",
   "deps": { "npm": [], "pip": [] },
@@ -10,5 +10,5 @@
     { "to": "architecture-diagrams", "when": "the design is written and needs rendering", "purpose": "Render the prose as a diagram that must not disagree with it.", "fallback": "If architecture-diagrams is absent, emit Mermaid inline and check every node against a claim in the doc." }
   ],
   "tags": ["design-doc", "documentation", "engineering", "review"],
-  "model": { "tier": "standard", "rationale": "Synthesizes a design doc from a brief. Escalates to opus on big or genuinely contested inputs." }
+  "model": { "tier": "light", "rationale": "Measured (RFC-0073): on its held-out evals the light tier met 88% and 88% of checks in two tier trials, against standard's 92% and heavy's 91% and 91%, within 5 points of the best both times." }
 }

package/packs/solution-architect/skills/figma-diagrams/manifest.json

@@ -1,6 +1,6 @@
 {
   "name": "figma-diagrams",
-  "version": "0.1.3",
+  "version": "0.1.4",
   "description": "Work with Figma and FigJam files via the Figma REST API — read existing file structure, list frames/pages, post comments, and produce FigJam-importable diagram specs. Use when the user mentions a Figma URL, asks to inspect/audit a Figma file, wants to comment on a design programmatically, or wants their architecture diagram in Figma.",
   "entrypoint": "SKILL.md",
   "deps": {
@@ -41,7 +41,7 @@
     "notes": "Reads FIGMA_TOKEN from the environment to call the Figma REST API. Its instructions install the pinned requirements once with `python3 -m pip install -r requirements.txt`, which reaches PyPI."
   },
   "model": {
-    "tier": "standard",
-    "rationale": "API calls + spec generation. Bounded transformation."
+    "tier": "light",
+    "rationale": "Measured (RFC-0073): on its held-out evals the light tier met 92% and 92% of checks in two tier trials, against standard's 92% and heavy's 75% and 92%, within 5 points of the best both times."
   }
 }

package/packs/sre-oncall/skills/cloud-cost-review/SKILL.md

@@ -107,7 +107,6 @@ This looks backward at a real bill. `capacity-cost-model` looks forward: it size
 - ❌ Estimating cost before launch, or projecting at 3× or 10× growth. Use `capacity-cost-model`.
 - ❌ Designing telemetry or a logging budget from scratch. Use `observability-plan`, though this skill flags logging cost as a hot spot.
 - ❌ Writing up an incident, including a cost spike from a runaway job. Use `postmortem-generator`.
-- ❌ Reporting AI tool usage or spend by user. Use `ai-usage-report`.
 - ❌ Defining business KPIs for a feature or product. Use `success-metrics`.
 
 ## Anti-patterns to avoid

package/packs/sre-oncall/skills/cloud-cost-review/manifest.json

@@ -1,6 +1,6 @@
 {
   "name": "cloud-cost-review",
-  "version": "0.1.2",
+  "version": "0.1.3",
   "description": "Review actual cloud spend from a cost export (AWS CUR or Data Exports, GCP billing export, Azure cost details) and produce a ranked savings report — idle and unattached resources, oversized instances backed by utilisation evidence, storage tiering, data transfer hot spots, commitment coverage and untagged spend — each finding with a monthly saving computed from the bill, a confidence level and an ease rating. Use when the user shares a cost CSV and says \"where are we wasting money\", \"review our AWS bill\", \"why did the cloud bill jump this month\", \"find savings in our GCP/Azure spend\", or \"should we buy savings plans\".",
   "entrypoint": "SKILL.md",
   "deps": {
@@ -12,7 +12,6 @@
     "optional": []
   },
   "related": [
-    "ai-usage-report",
     "capacity-cost-model",
     "observability-plan",
     "postmortem-generator",

package/packs/sre-oncall/skills/delivery-metrics-report/SKILL.md

@@ -106,7 +106,6 @@ It uses the metric names DORA currently publishes on [dora.dev](https://dora.dev
 - ❌ Writing up one incident: timeline, impact, contributing factors. Use `postmortem-generator`.
 - ❌ Designing SLOs, alerts or dashboards for a service. Use `observability-plan`.
 - ❌ Product or business outcome metrics (activation, retention, revenue). Use `success-metrics`.
-- ❌ Reporting how people use AI tools. Use `ai-usage-report`.
 - ❌ Forecasting infrastructure cost or capacity. Use `capacity-cost-model`.
 
 ## Anti-patterns to avoid

package/packs/sre-oncall/skills/delivery-metrics-report/manifest.json

@@ -1,6 +1,6 @@
 {
   "name": "delivery-metrics-report",
-  "version": "0.1.4",
+  "version": "0.1.5",
   "description": "Produce a delivery metrics report for one service from deployment, incident and pull-request exports — the DORA metrics (deployment frequency, change lead time, change fail rate, failed deployment recovery time) plus flow metrics (WIP, cycle time p50/p85, throughput), computed by a script with per-week trends and explicit data gaps, then interpreted for what changed and why. Use when the user wants DORA metrics, says \"how are we doing on the four keys\", \"what's our change failure rate\", \"compute lead time and deploy frequency from this CSV\", or \"build our delivery metrics report\".",
   "entrypoint": "SKILL.md",
   "deps": {
@@ -12,7 +12,6 @@
     "optional": []
   },
   "related": [
-    "ai-usage-report",
     "capacity-cost-model",
     "observability-plan",
     "postmortem-generator",

package/packs/sre-oncall/skills/incident-comms/manifest.json

@@ -1,6 +1,6 @@
 {
   "name": "incident-comms",
-  "version": "0.1.0",
+  "version": "0.1.1",
   "description": "Draft audience-segmented updates during a live incident — customer status-page posts, internal stakeholder updates, and exec notifications — each leading with user-facing impact, never speculative cause or ETA, always naming the next-update time. Use when an incident is in progress and the user needs a status page post, customer notification, internal update, exec brief, or the resolved/all-clear message.",
   "entrypoint": "SKILL.md",
   "deps": { "npm": [], "pip": [] },
@@ -10,5 +10,5 @@
     { "to": "postmortem-generator", "when": "the incident is resolved", "purpose": "Analyse blamelessly and emit runbook deltas.", "fallback": "If postmortem-generator is absent, write the timeline, the contributing factors, and the procedural changes inline." }
   ],
   "tags": ["incident", "communication", "status-page", "outage", "stakeholder", "sre"],
-  "model": { "tier": "standard", "rationale": "Audience-segmented message generation under a strict don't-retract discipline. Same shape as exec-summary/audience-profile — translation and altitude, not adversarial reasoning." }
+  "model": { "tier": "light", "rationale": "Measured (RFC-0073): on its held-out evals the light tier met 93% and 100% of checks in two tier trials, against standard's 85% and heavy's 92% and 93%, within 5 points of the best both times." }
 }

package/packs/sre-oncall/skills/postmortem-generator/manifest.json

@@ -1,6 +1,6 @@
 {
   "name": "postmortem-generator",
-  "version": "0.2.0",
+  "version": "0.2.1",
   "description": "Write a blameless incident postmortem from the raw material (chat scrollback, alert history, timeline, notes) for the audience and length the user names — the cause stated as the change and the gap that let it through, never a person even when the notes name one; who or what noticed first and how late; known kept apart from still-unknown; and follow-up actions that close the gap. Invents no times, figures, owners or severities. Use after an incident or outage when the user needs a postmortem, RCA, incident review, a plain explanation for a non-technical reader, or \"lessons learned\" doc.",
   "entrypoint": "SKILL.md",
   "deps": { "npm": [], "pip": [] },
@@ -10,5 +10,5 @@
     { "to": "runbook-generator", "when": "the postmortem produced runbook deltas", "purpose": "Apply the deltas as edits to the existing runbook.", "fallback": "If runbook-generator is absent, phrase each delta as a concrete before/after edit so a human can apply it." }
   ],
   "tags": ["postmortem", "incident", "rca", "sre", "blameless", "outage"],
-  "model": { "tier": "standard", "rationale": "Synthesizes a structured doc from incident notes. Contributing-factor chains need judgment but are bounded; escalate via large-input on huge scrollbacks." }
+  "model": { "tier": "light", "rationale": "Measured (RFC-0073): on its held-out evals the light tier met 93% and 91% of checks in two tier trials, against standard's 92% and heavy's 90% and 87%, within 5 points of the best both times." }
 }

package/packs/stakeholder-comms/skills/decision-log/manifest.json

@@ -1,11 +1,11 @@
 {
   "name": "decision-log",
-  "version": "0.1.1",
+  "version": "0.1.2",
   "description": "Extract decisions, action items, owners, and due dates from meeting notes, Slack threads, design-review transcripts, or any unstructured discussion. Produces a clean structured log the user can paste into a doc, tracker, or ADR queue. Use when the user has notes/threads/transcripts and asks for a \"decision log\", \"action items\", \"what did we agree\", or \"follow-ups\".",
   "entrypoint": "SKILL.md",
   "deps": { "npm": [], "pip": [] },
   "env": { "required": [], "optional": [] },
   "related": [],
   "tags": ["meetings", "decisions", "action-items", "stakeholder-communication"],
-  "model": { "tier": "light", "rationale": "Extracts decisions/owners/dates from notes. Pattern extraction; escalates on long transcripts." }
+  "model": { "tier": "standard", "rationale": "Measured (RFC-0073): on its held-out evals the light tier fell more than 5 points behind the best in both tier trials (79% and 61% against standard's 79%); one step up, to standard." }
 }

package/packs/trackers/skills/team-status-report/manifest.json

@@ -1,6 +1,6 @@
 {
   "name": "team-status-report",
-  "version": "0.1.4",
+  "version": "0.1.5",
   "description": "Write a weekly team status report from tracker data (Jira, Linear or GitHub Projects, via CSV, JSON or an MCP tool) — shipped, in progress, blocked with the blocker and owner, slipped against plan, risks and asks — with every number computed from the data by a stdlib script, never estimated, and a RAG status that states the rule that set it. Use when the user wants a weekly status update, sprint report or stakeholder update from the tracker, or says \"write this week's status report\", \"are we on track?\".",
   "entrypoint": "SKILL.md",
   "deps": {
@@ -27,7 +27,7 @@
   ],
   "permissions": {"network": [], "commands": [], "files": "named-paths"},
   "model": {
-    "tier": "standard",
-    "rationale": "A script computes every count and the suggested RAG; the model writes plain-language summaries, attributes outside facts and frames risks and asks. Bounded writing over computed numbers."
+    "tier": "light",
+    "rationale": "Measured (RFC-0073): on its held-out evals the light tier met 93% and 93% of checks in two tier trials, against standard's 93% and heavy's 93% and 93%, within 5 points of the best both times."
   }
 }

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}
-]