skilldrop-cli 1.4.0 → 1.5.0

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

package/packs/ai-engineering/loops/adopt/evals/files/adopt-first-wave-to-sign-off/ai-ideas.md

@@ -1,15 +0,0 @@
-# AI ideas: collected from the staff forum and team leads, September 2026
-
-1. **Delivery-date replies (Customer service).** About 600 emails a week ask "where's my kitchen / when is my delivery". That's roughly 40% of the inbox. An assistant could draft the reply from the order status in KitchenTrack and the agent checks and sends. Submitted by the customer service team lead.
-
-2. **Kitchen renders from sketches (Design).** Turn a designer's hand sketch into a photo-style render to show the customer in the showroom. Today renders take a designer about half a day each. Submitted by two designers.
-
-3. **Showroom visit notes (Sales).** Summarise showroom visit notes into a follow-up email. Notes are handwritten in notebooks; there is no CRM. Submitted by a sales manager.
-
-4. **Invoice matching (Finance).** Match supplier invoices to purchase orders automatically. Around 900 invoices a month, matched by hand in the accounts package. Supplier price lists are commercially confidential. Submitted by the finance manager.
-
-5. **Machine breakdown prediction (Manufacturing).** Predict when the edge-banding and CNC machines will fail. Only 3 of 19 machines have sensors fitted; the rest have paper maintenance logs. Submitted by the factory engineer.
-
-6. **Staff handbook Q&A (HR).** A chatbot that answers holiday, sick-pay and shift-swap questions from the staff handbook. HR gets about 40 of these a week. Submitted by HR.
-
-7. **Product descriptions (Marketing).** Write website product descriptions from the spec sheets for the 2027 range (about 120 products). Submitted by marketing.

package/packs/ai-engineering/loops/adopt/evals/files/adopt-first-wave-to-sign-off/org-context.md

@@ -1,27 +0,0 @@
-# Pellmore Kitchens Ltd: background for the AI work
-
-## The company
-- Designs, makes and fits fitted kitchens. 240 staff across the factory and the head office/showroom.
-- Teams: Manufacturing 130, Operations and logistics 26, Sales 22, Design 18, Customer service 14, Finance 9, Marketing 8, Leadership 6, HR 4, IT 3.
-
-## Sponsor
-- Ruth Calloway, Operations Director, sponsors the AI work and signs off the first rollout wave. She wants a first wave live before the January peak.
-
-## Tools
-- Office suite with its enterprise AI chat assistant, licensed since June 2026 for 25 seats. The contract says prompts and files are not used to train models and data is held in the UK/EU. Nobody has been given a seat yet; IT holds all 25.
-- KitchenTrack, the in-house order system. Holds customer names, delivery addresses, phone numbers, email addresses, order lines, prices paid and delivery slots. No API; IT runs a nightly CSV export of order status.
-- Accounts package for finance; no AI features switched on.
-
-## Data
-- Customer personal data lives in KitchenTrack and the customer service inbox.
-- Supplier price lists are commercially confidential under the supplier agreements.
-- Staff HR records are held by HR only.
-- The finance manager is also the company's data protection lead (part of the role). There is a data protection policy (2023). There is no AI policy of any kind.
-
-## What people are worried about
-- The staff survey (staff-survey.csv) found people already using personal AI accounts at work, including pasting customer emails into chatbots on their phones.
-- The customer service team's union rep has asked whether this is about cutting jobs in customer service.
-- Finance is worried about supplier pricing leaking.
-
-## Skills and support
-- No AI training has been run. IT (3 people) can give two days a month to support a rollout.

package/packs/ai-engineering/loops/adopt/evals/files/adopt-first-wave-to-sign-off/staff-survey.csv

@@ -1,11 +0,0 @@
-team,respondents,used_ai_at_work_last_month,used_personal_account_for_work,wants_training,worried_about_jobs
-Customer service,12,9,8,11,7
-Sales,15,6,5,9,2
-Design,14,10,7,8,3
-Finance,8,2,1,5,1
-Operations and logistics,10,1,1,4,2
-Marketing,6,6,3,4,1
-Manufacturing,21,0,0,6,9
-HR,4,1,0,3,0
-Leadership,5,3,2,2,0
-IT,3,3,1,0,0

package/packs/ai-engineering/loops/adopt/evals/files/adopt-sponsor-slice-blocked-by-client-data/ai-ideas.md

@@ -1,13 +0,0 @@
-# AI ideas from the October partners' meeting
-
-1. **Client tax-query replies.** Draft replies to client emails asking about their tax position, using the client's file (prior returns, correspondence, working papers). Roughly 350 such emails a month across the tax team; each takes a manager 20 to 40 minutes. Margaret's priority.
-
-2. **Bank statement extraction.** Pull transactions from the PDF bank statements clients send in, ready for bookkeeping. About 1,100 statements a month.
-
-3. **Client call notes.** Record and summarise client calls into the practice management system.
-
-4. **Procedures manual Q&A.** Answer staff questions from the firm's internal procedures manual (onboarding, filing deadlines process, how to raise an invoice). The manual is 140 pages and nobody can find anything in it. No client data in it.
-
-5. **Weekly guidance briefing.** Summarise the week's published tax guidance updates into a one-page staff briefing. Uses only public material.
-
-6. **Newsletter drafts.** Draft the quarterly client newsletter from the partners' bullet points.

package/packs/ai-engineering/loops/adopt/evals/files/adopt-sponsor-slice-blocked-by-client-data/firm-context.md

@@ -1,23 +0,0 @@
-# Corrow Lane Accounting LLP: background
-
-## The firm
-- 58 people: 6 partners, 14 in the tax team, 21 in accounts and bookkeeping, 9 in payroll, 8 in practice support (admin, IT, marketing).
-- Around 1,900 clients: sole traders, small companies and some high-net-worth individuals.
-
-## Sponsor
-- Margaret Ilsley, managing partner, sponsors the AI work and will sign off any rollout. She has decided client tax-query replies come first.
-
-## Systems
-- Client files live on an on-premises file server and in LedgerDesk, the practice management system. LedgerDesk has no AI features and no export API.
-- Email is hosted by our email provider.
-- No AI tool is licensed or approved. In August 2026 the IT manager blocked two public chatbot sites after a junior was seen pasting a client's payslip into one.
-
-## Client contracts
-- Every client signs our standard engagement letter. Clause 9.2 reads: "We will not disclose your information to any third party, or process it using third-party services other than those listed in Schedule B, without your prior written consent."
-- Schedule B lists three services: our email hosting provider, our payroll bureau, and our cloud backup provider. Nothing else.
-- Engagement letters are reissued each April.
-
-## Other
-- Our professional indemnity insurer's renewal questionnaire, due January 2027, asks whether we use AI on client work and how it is controlled.
-- Practice support has one IT manager and no one with AI experience.
-- Staff survey (informal, September): 31 of 58 said they would use an AI tool if the firm approved one.

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

@@ -1,53 +0,0 @@
-{
-  "$comment": "RFC-0069. AI ideas to a first rollout wave a sponsor approved. Readiness is scored against the first slice, not the whole organisation, because a gap only blocks the use cases that need what is missing; the gate sits there so a slice that needs it goes back to triage before anyone writes a policy for it.",
-  "name": "adopt",
-  "version": "0.1.0",
-  "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.",
-  "entrypoint": "LOOP.md",
-  "kind": "loop",
-  "cap": 3,
-  "stages": [
-    {
-      "id": "triage",
-      "type": "generate",
-      "intent": "Rank the candidate use cases on value, feasibility and risk with the weights shown, and name one first slice with the observable that would prove or kill it.",
-      "skills": ["ai-use-case-triage"]
-    },
-    {
-      "id": "readiness",
-      "type": "verify",
-      "intent": "Score readiness against what the first slice needs, and judge whether any blocking gap stands between the slice and its first users.",
-      "skills": ["ai-readiness-assessment"],
-      "gate": {
-        "id": "G11",
-        "kind": "review",
-        "verdicts": ["PROCEED", "PROCEED WITH CONDITIONS", "REVISE", "RECONSIDER", "BLOCKED"],
-        "revise_to": "triage"
-      }
-    },
-    {
-      "id": "policy",
-      "type": "generate",
-      "intent": "Write the usage rules for the people in the slice, covering every kind of data the slice puts into a tool, each restriction paired with what to do instead.",
-      "skills": ["ai-usage-policy"]
-    },
-    {
-      "id": "rollout",
-      "type": "generate",
-      "intent": "Plan the cohorts, enablement, champions and comms, with the slice's users as the pilot and the slice's observable as the pilot's adoption gate.",
-      "skills": ["ai-adoption-rollout"]
-    },
-    {
-      "id": "sign-off",
-      "type": "gate",
-      "intent": "The sponsor approves the first wave, with the policy and the readiness conditions it opens under.",
-      "skills": ["doc-critique"],
-      "gate": {
-        "id": "G11.1",
-        "kind": "human",
-        "verdicts": ["PROCEED", "PROCEED WITH CONDITIONS", "REVISE", "BLOCKED"],
-        "revise_to": "policy"
-      }
-    }
-  ]
-}

package/packs/career/loops/apply/LOOP.md

@@ -1,97 +0,0 @@
----
-name: apply
-description: Take one job posting and one resume to an application ready to send — an honest fit check, a tailored resume, a cover letter and the answers to the application form — with the candidate deciding whether to apply before any writing, and confirming every claim is true before anything is sent. Use when the user wants to apply for a job, says "help me apply for this", or wants a resume and cover letter prepared for one posting.
----
-
-# apply
-
-One application, start to send, for any job. It opens with a gate because the cheapest
-application is the one you decide not to write, and it closes with one because the candidate
-signs these documents and answers for them at interview. Both gates are **human**: an agent
-can say what the resume shows, but only the candidate knows what is true and what they want.
-
-## Stages
-
-| # | Stage | Type | Skills | Gate |
-|---|---|---|---|---|
-| 1 | `fit` | gate | [`job-fit-analysis`](../../skills/job-fit-analysis/SKILL.md) | **G6** human |
-| 2 | `tailor` | generate | [`resume-tailor`](../../skills/resume-tailor/SKILL.md) | — |
-| 3 | `letter` | generate | [`cover-letter`](../../skills/cover-letter/SKILL.md) | — |
-| 4 | `form` | generate | [`application-form-answers`](../../skills/application-form-answers/SKILL.md) | — |
-| 5 | `confirm` | verify | [`output-hygiene`](../../../core/skills/output-hygiene/SKILL.md) | **G6.1** human |
-
-## How to run this loop
-
-1. **Check the fit and stop.** Run `job-fit-analysis` on the posting, the resume and any
-   other material of the candidate's: a LinkedIn summary, a portfolio, a project. Put its
-   verdict, what could get the application rejected and its questions to the candidate,
-   including whether anything outside the resume covers a gap, then wait at G6.
-   - `PROCEED`: they are applying. Go on.
-   - `PROCEED WITH CONDITIONS`: they are applying and have answered the questions. Save
-     their answers to `notes.md`; from here on those answers are source material alongside
-     the resume.
-   - `RECONSIDER`: they are not applying. The loop ends here, and that is a good outcome.
-2. **Tailor the resume.** Run `resume-tailor` with the resume, the posting and `notes.md`
-   if it exists. It works in the resume's own format, on a copy. Carry forward its three
-   lists: "Not claimed", "Cut" and "Added from outside the resume".
-3. **Write the letter.** Run `cover-letter` with the tailored resume, the posting, `notes.md`
-   and the candidate's reason for wanting the job if they gave one. Skip this stage when the
-   posting says not to send a letter.
-4. **Answer the form.** When the application has a form with questions beyond uploading
-   the documents, run `application-form-answers` with those questions and the tailored
-   resume. Skip this stage when there is no form.
-5. **Clean the documents.** Run `output-hygiene` on the resume and the letter.
-6. **Confirm at G6.1.** Show the candidate the documents with four short lists: what the
-   posting asks for that the documents do not claim; every fact added from outside the
-   resume and where it came from; every line cut from the resume; and the form questions
-   that are theirs alone to answer. Ask them to confirm every line is true. `NOT READY` returns to `tailor` with their
-   corrections added to `notes.md`. The candidate sends the application; the loop never does.
-
-## Verdicts
-
-Defined in [`contracts/terminals.json`](../../../../contracts/terminals.json). G6 emits
-`PROCEED`, `PROCEED WITH CONDITIONS`, `RECONSIDER` or `BLOCKED`. G6.1 emits `READY`,
-`NOT READY` or `BLOCKED`. `RECONSIDER` leaves the loop: the candidate's time goes to a
-better posting.
-
-## Non-interactive runs
-
-With no person present, neither gate can be satisfied. Run `fit`, deliver the analysis and
-emit `BLOCKED: need the candidate's decision to apply`. Do not decide for them, and do not
-produce documents carrying their name that they have not confirmed.
-
-## 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 under the same rule (nothing the candidate didn't supply), and record that it ran
-degraded. Never skip G6.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-10-05T14:03:00Z","loop":"apply","stage":"fit","gate":"G6","verdict":"PROCEED","round":1}' >> "$SKILLDROP_LOOP_LOG"
-```
-
-Fields: `ts` (UTC), `loop`, `stage`, `gate` (`null` for a stage without one), `verdict` (the
-gate's exact word), and `round` (1 for the first attempt, counting returns under the cap).
-The log holds verdicts only: never the posting, the resume or the candidate's name.
-
-## Quality bar
-
-- **The candidate decides to apply before anything is written.** A tailored resume for a job they would have skipped is wasted work.
-- **Every claim in both documents traces to the resume or to something the candidate said.** Answers given at G6 are written to `notes.md`, so the trace exists.
-- **The resume, the letter and the form agree.** Same titles, dates and numbers in all three.
-- **The candidate confirms and sends.** G6.1 is their signature; the loop never submits an application.
-
-## Anti-patterns to avoid
-
-- ❌ **Skipping `fit` because the candidate is keen.** The screening requirements are what they most need to see before investing the time.
-- ❌ **Treating a `Not shown` item as true** because the candidate proceeded. Only what they answered goes in.
-- ❌ **Writing the letter from the original resume.** The letter follows the tailored one, or the two will disagree.
-- ❌ **Answering a declaration on the form** for the candidate, or leaving out the list of what was added and cut.
-- ❌ **Self-confirming at G6.1.** A clean claim check says the words are in the source; it cannot say they are true.
-- ❌ **Submitting the application.** Sending is the candidate's act.