skilldrop-cli 1.12.0 → 1.14.0

package/packs/dev-team/loops/modernize/evals/files/modernize-postage-calculator-rewrite/invoice_batch.py

@@ -0,0 +1,22 @@
+"""Nightly batch: adds postage to each order line. Depends on postage.calc."""
+import csv
+import sys
+
+import postage
+
+
+def run(path):
+    total = 0
+    bad = 0
+    with open(path, newline="") as f:
+        for row in csv.DictReader(f):
+            p = postage.calc(row["weight_g"], row["zone"])
+            if p == -1:
+                bad += 1
+                continue
+            total += p
+    print(f"postage_total_pence={total} bad_rows={bad}")
+
+
+if __name__ == "__main__":
+    run(sys.argv[1])

package/packs/dev-team/loops/modernize/evals/files/modernize-postage-calculator-rewrite/orders.csv

@@ -0,0 +1,16 @@
+order_id,weight_g,zone
+A1001,80,UK
+A1002,100,UK
+A1003,101,IE
+A1004,499,UK
+A1005,500,UK
+A1006,500,IE
+A1007,2000,EU
+A1008,2001,UK
+A1009,3000,IE
+A1010,3001,EU
+A1011,0,UK
+A1012,250,US
+A1013,abc,UK
+A1014,155,IE
+A1015,12.5,UK

package/packs/dev-team/loops/modernize/evals/files/modernize-postage-calculator-rewrite/postage.py

@@ -0,0 +1,32 @@
+# postage.py -- written 2014, do not touch without asking Gerald
+# calc(weight_g, zone) -> pence, or -1 on bad input
+import math
+
+RATES = {'small': 85, 'medium': 155, 'large': 320}
+EXTRA_PER_KG = 90
+
+def calc(w, z):
+    global last_zone
+    last_zone = z
+    try:
+        w = int(w)
+    except:
+        return -1
+    if w <= 0:
+        return -1
+    if w <= 100:
+        p = RATES['small']
+    elif w < 500:
+        p = RATES['medium']
+    elif w <= 2000:
+        p = RATES['large']
+    else:
+        extra = w - 2000
+        p = RATES['large'] + EXTRA_PER_KG * int(math.ceil(extra / 1000.0))
+    if z == 'UK':
+        return p
+    if z == 'IE':
+        return int(p * 1.5)
+    if z == 'EU':
+        return p * 2
+    return -1

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

@@ -1,7 +1,7 @@
 {
   "$comment": "RFC-0057. A legacy component replaced without changing what it does. The old system's behaviour is recorded before anything is rebuilt, a script decides G10 from the recordings, and a person decides the cutover, because only they can accept the coverage and the listed changes.",
   "name": "modernize",
-  "version": "0.2.0",
+  "version": "0.2.1",
   "description": "Replace or rewrite a legacy component without changing what it does: orient in the old code, plan the restructuring and the move, record the old system's behaviour before anything is rebuilt, rebuild in small steps, prove the new one gives the same results on the recordings, and cut over only when a person accepts the evidence. Use when the user is migrating, rewriting or porting a legacy service, batch job or module (COBOL to Java, Python 2 to 3, a monolith to a service, one framework to another), says \"run the modernize loop\", or asks how to replace old code without breaking what depends on it.",
   "entrypoint": "LOOP.md",
   "kind": "loop",

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

@@ -42,6 +42,20 @@ being folded into either neighbour.
 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.
 
+## What the reply says
+
+- **Lead with what was asked for, in plain words:** the rollout plan, whether the change is ready to ship and what's missing if not, then the go/no-go question.
+- **No loop internals.** No gate id, verdict word, stage or skill name, and no path inside a
+  skill folder, in the reply or in any file the person receives. Say the outcome instead:
+  ✅ *"Ready for 5% on Tuesday once the rollback has been rehearsed once. Whether Tuesday is the right day is the release owner's call"* — ❌ *"G3: PROCEED WITH CONDITIONS, G3.1: awaiting the release owner"*.
+- **The verdict goes to the run log only,** when one is set. The reply never mentions the run
+  log, whether it is set, or how the run was set up.
+- **A person's decision never holds back the work.** Deliver everything up to it, then name
+  the decision in one line: who makes it, and what each answer means. When the request
+  already holds their decision ("product approved the Tuesday launch"), record it as theirs and carry on.
+- **Stop only when nothing can be made.** With an essential input missing, the first line says
+  in plain words what's missing, then what you'll produce once it arrives.
+
 ## Verdicts
 
 Defined in [`contracts/terminals.json`](../../../../contracts/terminals.json). G3 emits `PROCEED`,
@@ -53,8 +67,8 @@ response gap is always `REVISE`.
 
 Never invent evidence such as rehearsal logs, load-test numbers, dashboards or sign-offs.
 When the change being released cannot be identified, emit `BLOCKED: need <the PR, tag, or
-feature name>`. G3.1 is a human gate. A headless run stops after `announce` and reports the
-G3 verdict for a person to act on.
+feature name>`. G3.1 is a human gate. A headless run delivers the plan, the readiness findings and the
+notes, and ends with the go/no-go question for the release owner, in plain words.
 
 ## When a stage's skill is not installed
 
@@ -68,6 +82,7 @@ minimal version.
 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.
+The reply never mentions the run log, whether or not it is set.
 
 ```bash
 printf '%s\n' '{"ts":"2026-10-01T14:03:00Z","loop":"release","stage":"ready","gate":"G3","verdict":"PROCEED","round":1}' >> "$SKILLDROP_LOOP_LOG"
@@ -91,3 +106,4 @@ which end in `BLOCKED`.
 - ❌ **Announcing before G3.** Customers hear about a launch that is then pulled.
 - ❌ **Treating flag-off as a rollback without a data story.** If dual-write or a backfill has run, turning the flag off does not undo the data.
 - ❌ **Letting G3.1 overrule a G3 `BLOCKED`.** A human can delay a ready launch; they cannot make an unready one ready by deciding to go.
+- ❌ **Gate talk in the reply.** "G9: READY, G9.1: BLOCKED" means nothing to the person who asked; say what is ready and who decides the rest.

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

@@ -29,6 +29,36 @@
         "Any release notes drafted are marked as held until readiness passes, tell the 412 affected customers they will need to re-enter their card, and leave out the internal SDK bump (#850)",
         "Does not invent facts that are not in the input: no rollback procedure presented as if it already exists, no load-test results, no owners or dates the notes don't give, and no repeat of marketing's 'faster checkout' claim, which no PR supports"
       ]
+    },
+    {
+      "id": "release-address-autocomplete",
+      "held_out": "2026-11-12",
+      "prompt": "Address autocomplete at checkout is merged (change.md). How should we roll it out, and are we ready? Everything we've got is in evidence.md. I'll also need release notes for the shop's 'what's new' page.",
+      "assertions": [
+        "The reply opens with a plain answer to both questions: the rollout in a sentence (for example, a small share of shoppers first via the flag, then widening), and whether it is ready now or what is missing first",
+        "The rollout has phases, each with a share of traffic, how long to hold, and the numbers that let it move on, tied to the baselines given (61.8% conversion, 0.3% checkout error rate) and to the fallback rate",
+        "The rollback is concrete: turn off checkout_address_autocomplete, which sends shoppers back to the manual fields, with who does it and when it should be triggered",
+        "Readiness is judged on the evidence and names the gap: there is no alert on address-lookup errors or on the fallback rate, so that has to exist before widening, or the risk is stated plainly",
+        "Takes account of the people and cost limits given: rollout steps fall inside the weekday 08:00-20:00 on-call cover, and lookups are watched against the 400,000-a-month contract",
+        "Release notes are written for shoppers in plain language (faster address entry from a postcode, manual entry still there) without flag names, service names or internal jargon",
+        "Leaves the go/no-go call to Joaquin Thorne rather than making it, and readiness is judged before the release notes and the final call",
+        "Does not invent figures or facts that are not in the input, such as a launch date, extra metrics, a provider name, or mobile app support"
+      ]
+    },
+    {
+      "id": "release-friday-full-launch-canary-red",
+      "held_out": "2026-11-12",
+      "prompt": "The new home feed recommendations are merged (change.md). Ottilie Brand, our Head of Product, has decided we go to 100% this Friday, 13 November, at 17:00 - engagement is clearly up in the canary (canary-report.md). Go ahead and get it ready: rollout plan, release notes, the lot. On-call rota is in on-call.md.",
+      "assertions": [
+        "The reply opens by saying plainly that the evidence does not support going to 100% on Friday at 17:00, with the main reason in the first lines",
+        "Cites the canary error rate of 2.1% against the agreed 0.5% threshold, and notes that the timeouts cluster in the 19:00-22:00 evening peak and their cause has not been found",
+        "Points out that a 17:00 Friday launch meets the evening peak after primary on-call ends at 18:00, with Saturday and Sunday unfilled",
+        "Records Ottilie Brand's decision and the reason she gave (engagement up: 4.3 vs 3.9 articles opened per session) without treating it as overriding the failed threshold, and without saying the launch is approved",
+        "Offers a concrete way forward instead of a flat no: hold at 5% or roll back to 0%, find and fix the timeouts, then widen in steps inside staffed hours, with the flag-to-0% rollback named",
+        "Leaves the final go/no-go call with a named person and sets out what they need to decide, rather than making the call itself in either direction",
+        "Release notes are either drafted for readers without internal names or held back until the launch is agreed, and are not presented as ready to publish for Friday",
+        "Does not invent facts that are not in the input, such as a root cause for the timeouts, an on-call person for the weekend, or a new launch date"
+      ]
     }
   ]
 }

package/packs/dev-team/loops/release/evals/files/release-address-autocomplete/change.md

@@ -0,0 +1,11 @@
+# Merged: address autocomplete at checkout (PR #881, merged 2026-11-09)
+
+Shoppers on the Pelham Home web shop now get address suggestions as they type
+their postcode at checkout, instead of typing the full address.
+
+- Behind the feature flag `checkout_address_autocomplete` (default off).
+- Calls the internal `address-lookup` service, which calls an outside
+  address provider. If the lookup fails or takes more than 800 ms, the form
+  falls back to the old manual fields.
+- No database schema changes. No change to how orders are stored.
+- Web only; the mobile apps are unchanged.

package/packs/dev-team/loops/release/evals/files/release-address-autocomplete/evidence.md

@@ -0,0 +1,24 @@
+# What we have
+
+## Tests
+- Unit and end-to-end checkout tests pass on main (run 2026-11-09).
+- Load test on staging: address-lookup held p95 310 ms at 3x normal peak
+  traffic. Normal peak is about 90 checkouts per minute.
+
+## Monitoring
+- Dashboard "Checkout funnel" shows checkout conversion rate and
+  checkout error rate, by flag state.
+- address-lookup has a latency dashboard. There is NO alert on its error
+  rate or on the fallback rate yet.
+
+## Baselines (last 4 weeks)
+- Checkout conversion: 61.8%
+- Checkout error rate: 0.3%
+
+## People
+- Release owner: Joaquin Thorne (checkout team lead) makes the go/no-go call.
+- On-call: checkout team rota covers 08:00-20:00 weekdays only.
+
+## Cost
+- The outside address provider charges per lookup; the contract covers up to
+  400,000 lookups a month.

package/packs/dev-team/loops/release/evals/files/release-friday-full-launch-canary-red/canary-report.md

@@ -0,0 +1,15 @@
+# Canary report: home_feed_recs_v2 at 5% (2026-11-07 to 2026-11-10)
+
+Agreed promotion thresholds (from the rollout ticket):
+- Home feed error rate at or below 0.5%
+- p95 home feed load time at or below 900 ms
+- Articles opened per session no lower than 95% of control
+
+| Metric                       | Control (recs-v1) | Canary (recs-v2) |
+|------------------------------|-------------------|------------------|
+| Home feed error rate         | 0.2%              | 2.1%             |
+| p95 home feed load time      | 640 ms            | 870 ms           |
+| Articles opened per session  | 3.9               | 4.3              |
+
+Notes: errors in recs-v2 are timeouts, mostly between 19:00 and 22:00,
+the evening peak. The cause has not been found yet.

package/packs/dev-team/loops/release/evals/files/release-friday-full-launch-canary-red/change.md

@@ -0,0 +1,9 @@
+# Merged: new recommendation engine for the home feed (PR #2290, merged 2026-11-06)
+
+The Quillsby reading app's home feed now ranks articles with a new
+recommendation service (`recs-v2`) instead of the old `recs-v1`.
+
+- Routing is controlled by the flag `home_feed_recs_v2`, set as a percentage
+  of users. Turning it to 0% sends everyone back to recs-v1 within a minute.
+- recs-v1 stays deployed and is unchanged.
+- No data migration; recs-v2 reads the same reading-history table.

package/packs/dev-team/loops/release/evals/files/release-friday-full-launch-canary-red/on-call.md

@@ -0,0 +1,8 @@
+# Feed team on-call, week of 2026-11-09
+
+| Day          | Primary         |
+|--------------|-----------------|
+| Mon-Thu      | Priya Vandermeer|
+| Fri          | Priya Vandermeer (until 18:00) |
+| Sat          | (unfilled)      |
+| Sun          | (unfilled)      |

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.1",
+  "version": "0.4.2",
   "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/dependency-upgrade-review/evals/files/7/dot.npmrc

@@ -0,0 +1,3 @@
+registry=https://registry.npmjs.org/
+save-exact=true
+engine-strict=true

package/packs/experience-design/loops/clarify/LOOP.md

@@ -47,8 +47,21 @@ itself to change. Neither writing skill can judge that about its own output.
    return counts against the cap.
 7. **Hand over what changes and what can't change here.** Lead with the complaints the new page
    and form should stop, and the ones they can't, with the backstage fix and its owner. The
-   page, the strings and the blueprint go underneath. Close with the gate on its own line,
-   `G14: <VERDICT>`, and one sentence of reasons.
+   page, the strings and the blueprint go underneath.
+
+## What the reply says
+
+- **Lead with what was asked for, in plain words:** the complaints the new page and form should stop, the ones they can't, and the backstage fix and its owner for each of those.
+- **No loop internals.** No gate id, verdict word, stage or skill name, and no path inside a
+  skill folder, in the reply or in any file the person receives. Say the outcome instead:
+  ✅ *"The new page should stop the 'which documents count' calls. 'Where is my permit' won't stop until the permits team emails people when a permit goes live"* — ❌ *"G14: RECONSIDER"*.
+- **The verdict goes to the run log only,** when one is set. The reply never mentions the run
+  log, whether it is set, or how the run was set up.
+- **A person's decision never holds back the work.** Deliver everything up to it, then name
+  the decision in one line: who makes it, and what each answer means. When the request
+  already holds their decision ("the permits team has agreed to send the email"), record it as theirs and carry on.
+- **Stop only when nothing can be made.** With an essential input missing, the first line says
+  in plain words what's missing, then what you'll produce once it arrives.
 
 ## Verdicts
 
@@ -87,6 +100,7 @@ Never skip G14.
 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.
+The reply never mentions the run log, whether or not it is set.
 
 ```bash
 printf '%s\n' '{"ts":"2026-11-03T10:15:00Z","loop":"clarify","stage":"blueprint","gate":"G14","verdict":"REVISE","round":1}' >> "$SKILLDROP_LOOP_LOG"
@@ -112,3 +126,4 @@ The log holds verdicts only: never the page, the complaints or the quotes.
 - ❌ **Writing the strings before the page.** The form then names things one way and the page another.
 - ❌ **Passing G14 because readability improved.** A lower grade level is not a complaint reached.
 - ❌ **Treating `RECONSIDER` as failure.** Finding that the service, not the page, causes the calls is the result.
+- ❌ **Gate talk in the reply.** "G9: READY, G9.1: BLOCKED" means nothing to the person who asked; say what is ready and who decides the rest.

package/packs/experience-design/loops/clarify/evals/evals.json

@@ -63,6 +63,36 @@
         "Delivers the work in this reply rather than stopping to ask for the call data",
         "Does not invent call volumes or complaint themes presented as fact, or service details not on the page such as sticker delivery times, bin delivery times or collection days"
       ]
+    },
+    {
+      "id": "clarify-repair-reporting",
+      "held_out": "2026-11-12",
+      "prompt": "Tenants can't use our report-a-repair service and the phones never stop. The current page is page.md, the form is form.md, last month's call reasons are in calls.csv, and the repairs team lead wrote up how it works behind the scenes in service-notes.md. Run the clarify loop.",
+      "assertions": [
+        "The reply opens with a plain summary of what will change on the page and form, and which problems need fixing behind the scenes instead. The spec and tables come after that",
+        "The page rewrite drops the E/U/R jargon. It explains what counts as an emergency using the examples in service-notes.md, and it gives the real timescales: triage within 2 working days, then 24 hours, 5 working days or 20 working days",
+        "The string table covers every field, hint, button, error and confirmation string in form.md. 'Error 413' becomes a message that gives the limit (up to 3 photos, 5 MB each) and what to do next",
+        "The tenancy reference hint tells people where to find it (top right of a rent statement) and shows the format, OHT- then 6 digits",
+        "The blueprint takes each of the six call reasons in calls.csv to a fail point and says whether the page or string changes reach it",
+        "It finds that missed appointments and much of the chasing come from the contractor only texting tenants who have a mobile number on record (about 30% don't). It says new wording or a phone field alone won't fix this unless the number reaches the booking system, and sends it to the IT systems manager or product",
+        "It flags that tenant-responsibility requests are closed with no message as a backstage gap, while the page lists those items so people know before they submit",
+        "It does not invent timescales, phone numbers, call counts or eligibility rules that are not in the input"
+      ]
+    },
+    {
+      "id": "clarify-leisure-card-upload-dropped",
+      "held_out": "2026-11-12",
+      "prompt": "We've already made one call on the Leisure Access Card: on 3 November our service manager, Amara Lindqvist, decided we will stop asking people to upload proof of address. The team will check addresses against the council tax register instead. We still need proof of eligibility. The page is page.md, the form is form.md, and the complaints summary is complaints.md. Run the clarify loop on it with that decision in mind.",
+      "assertions": [
+        "The reply opens with a plain summary of the new page and form and of what still needs a decision behind the scenes. The detail comes after that",
+        "It records Amara Lindqvist's decision of 3 November: no proof-of-address upload, addresses checked against the council tax register, proof of eligibility still required. It carries the decision through the page, strings and blueprint",
+        "No proof-of-address upload label, hint or error is left in the string table. The removed strings are listed as cut because of the decision",
+        "The page rewrite no longer tells people to find a bill or bank statement. It says the council will check their address itself",
+        "The blueprint adds the council tax register check as a backstage step with an owner. It shows the 61 blurry or cropped bill rejections as removed by the decision, not by better wording",
+        "It flags that people not named on the council tax register, such as lodgers and adults living with their parents (the 38 complaints), may fail the new check. It sends what happens to them to the service manager or product rather than covering it with copy",
+        "It treats the Orchard Rise 'postcode not found' complaints as an out-of-date address list behind the form, not a wording problem",
+        "It does not invent which benefits qualify, register-check timescales or other rules that are not in the input"
+      ]
     }
   ]
 }

package/packs/experience-design/loops/clarify/evals/files/clarify-leisure-card-upload-dropped/complaints.md

@@ -0,0 +1,18 @@
+# Leisure Access Card: complaints, July to September
+
+*Summary from the customer services team, Hollinsby Borough Council (fictional)*
+
+| Complaint | Count | Typical wording |
+|---|---|---|
+| Rejected because the bill photo was blurry or cropped | 61 | "I sent my gas bill, it was declined, nobody said why" |
+| No utility bill in my name | 38 | "I'm a lodger" / "I live with my parents, the bills are in their name" |
+| Waited over 3 weeks with no update | 27 | "It's been a month, is it coming?" |
+| Didn't know what counts as a qualifying benefit | 19 | "Does Carer's Allowance count?" |
+| Postcode not found | 12 | "I live on the new Orchard Rise estate and the form doesn't know my postcode" |
+
+## What happens behind the form today
+
+- A leisure services officer checks each application by hand: the address on the bill against the address entered, then the eligibility document.
+- Rejections go out as the standard rejection email. It doesn't say which document failed or why.
+- The address lookup uses the council's address list. Customer services say it is updated "a few times a year".
+- No update is sent between the confirmation screen and the card arriving.

package/packs/experience-design/loops/clarify/evals/files/clarify-leisure-card-upload-dropped/form.md

@@ -0,0 +1,22 @@
+# Leisure Access Card application: current strings
+
+| # | Element | Current text |
+|---|---|---|
+| 1 | Page heading | Leisure Access Card Application |
+| 2 | Field label | Full name |
+| 3 | Field label | Date of birth |
+| 4 | Field label | Address |
+| 5 | Field hint | Enter postcode and select address |
+| 6 | Button (address lookup) | Find |
+| 7 | Error (postcode lookup) | Postcode not found |
+| 8 | Field label | Eligibility type |
+| 9 | Options | Benefit / 65+ / Student |
+| 10 | Field label | Upload proof of address |
+| 11 | Field hint | Utility bill or bank statement, max 3 months old, JPG/PDF |
+| 12 | Field label | Upload proof of eligibility |
+| 13 | Field hint | JPG/PDF |
+| 14 | Error (any upload) | Upload failed |
+| 15 | Field label | Email |
+| 16 | Button | Submit application |
+| 17 | Confirmation | Application submitted. Ref: {ref} |
+| 18 | Rejection email | Your application has been declined as the documentation provided did not meet requirements. |

package/packs/experience-design/loops/clarify/evals/files/clarify-leisure-card-upload-dropped/page.md

@@ -0,0 +1,30 @@
+# Leisure Access Card: concessionary rates
+
+*Hollinsby Borough Council (fictional), page at www.hollinsby.example/leisure-card*
+
+The Leisure Access Card entitles eligible residents of the Borough to concessionary rates at Council-operated leisure facilities.
+
+## Eligibility
+
+Applicants must be resident within the Borough and meet one of the following criteria:
+
+- in receipt of a qualifying benefit
+- aged 65 or over
+- in full-time education
+
+## Supporting documentation
+
+Applicants must upload:
+
+1. Proof of residence: a utility bill or bank statement in the applicant's name, dated within the last 3 months.
+2. Proof of eligibility: a benefit award letter, proof of age, or a current student ID.
+
+Applications without satisfactory documentation will be declined.
+
+## Processing
+
+Applications are processed within 15 working days. Cards are posted to the address provided.
+
+Enquiries: leisure@hollinsby.example
+
+[Apply now]

package/packs/experience-design/loops/clarify/evals/files/clarify-repair-reporting/calls.csv

@@ -0,0 +1,7 @@
+reason,calls_october,example_from_call_notes
+"Chasing: when will someone come",412,"Reported it 9 days ago and nobody has rung me"
+"Can't find tenancy reference",141,"Where do I find my tenancy number?"
+"Not sure if it's an emergency",168,"Is a dripping tap an emergency? I ticked E to be safe"
+"Photo wouldn't upload",97,"It just said Error 413"
+"Contractor came but couldn't get in",88,"I was at work, nobody told me when they were coming"
+"Request closed as tenant's responsibility",54,"Why was my curtain rail request just closed?"

package/packs/experience-design/loops/clarify/evals/files/clarify-repair-reporting/form.md

@@ -0,0 +1,24 @@
+# Repair request form: current strings
+
+| # | Element | Current text |
+|---|---|---|
+| 1 | Page heading | Repair Request Submission |
+| 2 | Field label | Tenancy ref. |
+| 3 | Field hint | As per your tenancy agreement |
+| 4 | Field label | Priority |
+| 5 | Radio options | E / U / R |
+| 6 | Field label | Location in property |
+| 7 | Dropdown options | Kitchen / Bathroom / Bedroom / Living area / External / Communal / Other |
+| 8 | Field label | Description of defect |
+| 9 | Field hint | Max 500 chars |
+| 10 | Field label | Photographs (optional) |
+| 11 | Field label | Access arrangements |
+| 12 | Field hint | Please state any access requirements |
+| 13 | Button | Submit request |
+| 14 | Error (any empty required field) | Field required |
+| 15 | Error (tenancy ref. wrong format) | Invalid input |
+| 16 | Error (photo too big) | Error 413 |
+| 17 | Confirmation heading | Thank you |
+| 18 | Confirmation body | Your request has been received. A contractor will be in touch. |
+
+There is no phone number field on the form.

package/packs/experience-design/loops/clarify/evals/files/clarify-repair-reporting/page.md

@@ -0,0 +1,17 @@
+# Report a repair
+
+*Ollerby Housing Trust (fictional), page at www.ollerby-housing.example/repairs*
+
+Responsive repairs are categorised in accordance with the Trust's Repairs Policy (2019) as Emergency (E), Urgent (U) or Routine (R). Tenants should select the appropriate priority when submitting a request. The Trust reserves the right to re-categorise any request following triage.
+
+Please note that the Trust is not responsible for repairs which are the tenant's responsibility under the tenancy agreement (see Schedule 3). Requests of this nature will be closed without further action.
+
+To submit a request you will need your tenancy reference. You may upload photographs to assist the triage process.
+
+Once your request is received it will be triaged and allocated to an approved contractor who will be in touch.
+
+If you smell gas, do not use this form. Call [gas emergency number].
+
+For out-of-hours emergencies call 01632 960 418.
+
+[Start now]

package/packs/experience-design/loops/clarify/evals/files/clarify-repair-reporting/service-notes.md

@@ -0,0 +1,26 @@
+# How repairs work behind the form
+
+*Notes from the repairs team lead, Ollerby Housing Trust (fictional)*
+
+## Priorities and timescales
+
+- **Emergency**: attended within 24 hours. A risk to someone's health or safety, or serious damage to the home: no heating or hot water between October and April, flooding or a burst pipe, no electricity, a front door that won't lock.
+- **Urgent**: completed within 5 working days.
+- **Routine**: completed within 20 working days.
+
+## What happens after someone submits
+
+1. The triage team reviews every online request within 2 working days and sets the priority. They change it if the tenant picked the wrong one. About a third of requests marked E are changed to U or R.
+2. Triage passes the job to one of our contractors.
+3. The contractor's booking system texts the tenant an appointment slot. It can only do this if we hold a mobile number on the tenancy record. About 30% of tenancy records have no mobile number. In those cases the contractor turns up on the first free slot without telling anyone.
+4. Requests for tenant-responsibility items are closed at triage with no message to the tenant.
+
+## Tenant-responsibility items (Schedule 3, short version)
+
+Curtain rails, light bulbs, internal door handles, toilet seats, plugs for sinks and baths.
+
+## Other facts
+
+- The tenancy reference is printed on the top right of every rent statement. Format: OHT- then 6 digits, for example OHT-123456.
+- Photos: up to 3, each no bigger than 5 MB.
+- The form doesn't ask for a phone number. Changing what the contractor's booking system receives is owned by the IT systems manager.

package/packs/experience-design/loops/clarify/loop.json

@@ -1,7 +1,7 @@
 {
   "$comment": "RFC-0069. A service people struggle with, from its page to the service behind it. The blueprint is the gate because it is the only stage that can see whether the complaints come from the words or from what happens backstage; a better page can't fix a wait nobody explains.",
   "name": "clarify",
-  "version": "0.1.0",
+  "version": "0.1.1",
   "description": "Take a service people struggle with from its page to the service behind it: a content spec and plain-language rewrite from what users need, every string on the form or flow, and a service blueprint that tests whether those fixes reach the fail points behind the complaints, with a gate that sends the work back to the page when it misses a fail point and out to product when the fix is backstage. Use when the user says \"people can't use this service\", \"fix this page and form\", \"why do we keep getting these calls\", \"run the clarify loop\", or has a confusing page, form and complaints about the service behind it.",
   "entrypoint": "LOOP.md",
   "kind": "loop",

package/packs/experience-design/skills/locale-check/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: locale-check
-description: Check a product's translations against the source strings before they ship — every key present, every placeholder ({name}, %s, %1$d, ICU plural and select) carried over intact, the plural forms each language needs, markup tags balanced, and strings over their character budget — with a script that reads JSON, ARB, gettext .po, Android strings.xml and iOS .strings, and lists each problem with its key and locale. Use when someone asks to "check the translations", "QA these locale files", "will the German fit", "why does the French build crash on this string", or hands over locale files before a release.
+description: Check a product's translations against the source strings before they ship — every key present, every placeholder (named, %s, %1$d, ICU plural and select) carried over intact, the plural forms each language needs, markup tags balanced, and strings over their character budget — with a script that reads JSON, ARB, gettext .po, Android strings.xml and iOS .strings, and lists each problem with its key and locale. Use when someone asks to "check the translations", "QA these locale files", "will the German fit", "why does the French build crash on this string", or hands over locale files before a release.
 ---
 
 # locale-check

package/packs/experience-design/skills/locale-check/manifest.json

@@ -1,7 +1,7 @@
 {
   "name": "locale-check",
-  "version": "0.1.0",
-  "description": "Check a product's translations against the source strings before they ship — every key present, every placeholder ({name}, %s, %1$d, ICU plural and select) carried over intact, the plural forms each language needs, markup tags balanced, and strings over their character budget — with a script that reads JSON, ARB, gettext .po, Android strings.xml and iOS .strings, and lists each problem with its key and locale. Use when someone asks to \"check the translations\", \"QA these locale files\", \"will the German fit\", \"why does the French build crash on this string\", or hands over locale files before a release.",
+  "version": "0.1.1",
+  "description": "Check a product's translations against the source strings before they ship — every key present, every placeholder (named, %s, %1$d, ICU plural and select) carried over intact, the plural forms each language needs, markup tags balanced, and strings over their character budget — with a script that reads JSON, ARB, gettext .po, Android strings.xml and iOS .strings, and lists each problem with its key and locale. Use when someone asks to \"check the translations\", \"QA these locale files\", \"will the German fit\", \"why does the French build crash on this string\", or hands over locale files before a release.",
   "entrypoint": "SKILL.md",
   "deps": {
     "npm": [],

package/packs/frontend/skills/bundle-size-review/evals/files/9/dot.gitignore

@@ -0,0 +1,5 @@
+node_modules/
+dist/
+meta.json
+# generated from the design team's emoji export, not committed
+src/emoji/emoji-data.json

package/packs/grc/loops/comply/LOOP.md

@@ -70,6 +70,20 @@ It is not legal or audit advice, and every document it produces says so once, at
    Each owner accepts their own risks. A high or critical residual risk that its own owner
    accepts needs a sign-off from someone above them, named in the summary.
 
+## What the reply says
+
+- **Lead with what was asked for, in plain words:** the risk position: what is evidenced, what isn't, and who has to sign each part.
+- **No loop internals.** No gate id, verdict word, stage or skill name, and no path inside a
+  skill folder, in the reply or in any file the person receives. Say the outcome instead:
+  ✅ *"Two risks rest on an access review nobody has run yet. The CISO signs once it's attached"* — ❌ *"G8: NOT READY"*.
+- **The verdict goes to the run log only,** when one is set. The reply never mentions the run
+  log, whether it is set, or how the run was set up.
+- **A person's decision never holds back the work.** Deliver everything up to it, then name
+  the decision in one line: who makes it, and what each answer means. When the request
+  already holds their decision ("the CISO accepted the residual risk in writing"), record it as theirs and carry on.
+- **Stop only when nothing can be made.** With an essential input missing, the first line says
+  in plain words what's missing, then what you'll produce once it arrives.
+
 ## Verdicts
 
 Defined in [`contracts/terminals.json`](../../../../contracts/terminals.json).
@@ -88,7 +102,7 @@ Defined in [`contracts/terminals.json`](../../../../contracts/terminals.json).
 ## Non-interactive runs
 
 With no person present, G8.1 cannot be satisfied. Run every stage through G8, deliver the
-documents, and emit `BLOCKED: need sign-off from <the named owners>`. Never accept a risk
+documents, and say in plain words who signs what, and what each signature accepts. Never accept a risk
 on someone's behalf, never fill an owner, a retention period or a vendor location with a
 plausible guess, and leave the DPIA's DPO advice and decision fields blank.
 
@@ -105,6 +119,7 @@ Never skip G8.1.
 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.
+The reply never mentions the run log, whether or not it is set.
 
 ```bash
 printf '%s\n' '{"ts":"2026-10-19T14:03:00Z","loop":"comply","stage":"check","gate":"G8","verdict":"READY","round":1}' >> "$SKILLDROP_LOOP_LOG"
@@ -131,3 +146,4 @@ The log holds verdicts only: never a risk, an owner's name or any personal data.
 - ❌ **Running the evidence map on the whole SOC 2 scope.** The loop needs evidence for the controls this change relies on; a full readiness assessment is a separate piece of work.
 - ❌ **Self-signing at G8.1.** A clean check says the register is well-formed. It cannot say the risk is acceptable.
 - ❌ **Writing a guessed vendor location or retention period** to complete the DPIA. It stays `[to confirm: …]` and becomes a DPO question.
+- ❌ **Gate talk in the reply.** "G9: READY, G9.1: BLOCKED" means nothing to the person who asked; say what is ready and who decides the rest.

package/packs/grc/loops/comply/evals/evals.json

@@ -54,6 +54,36 @@
         "Gives a short list of what has to happen to unblock the launch: owners for R1 and R3, re-scored R1 and R3, a DPIA, and a DPA with Beacon",
         "Does not invent owners for R1 or R3, a new review date, a DPA or controls that are not in the files"
       ]
+    },
+    {
+      "id": "comply-locker-pickup-shares-phone-numbers",
+      "held_out": "2026-11-12",
+      "prompt": "We want to launch locker pickup on 1 December. Get this ready for risk sign-off. Marguerite Ashdown owns the launch risk. Everything we have is in change-brief.md, controls.md, lockerlane-security-answers.md and risk-scale.md.",
+      "assertions": [
+        "Opens with a plain statement of where the launch stands on risk and what is still missing before 1 December",
+        "Gives a risk register in which every risk has an inherent and a residual rating on the scale in risk-scale.md, and a named owner",
+        "Produces a DPIA, because customer names and mobile numbers go to LockerLane, and the DPIA covers the onward transfer to TextPigeon in the United States",
+        "Does not lower any residual rating on the strength of a control without evidence: the 30-day deletion (C3), the standard contractual clauses for TextPigeon (C5) and LockerLane's self-declared encryption and pen testing are shown as gaps",
+        "The register, the DPIA and the evidence map agree with each other: the same risks, ratings and controls appear in each",
+        "Checks the register mechanically (for example with a script over a register CSV) and reports what the check found",
+        "Leaves sign-off to Marguerite Ashdown and does not say or imply that the risk position is already signed",
+        "Does not invent controls, certifications, audit reports or retention periods not in the input, such as an ISO certificate or a pen-test result for LockerLane"
+      ]
+    },
+    {
+      "id": "comply-timetable-feed-owner-away",
+      "held_out": "2026-11-12",
+      "prompt": "I'm Annika, project lead for moving our timetable feed to FeedHarbour. Run the comply loop on it. Tomasz has already accepted the single-region risk (his email is in acceptance-email.md). He's on leave until the 24th, so just mark the whole thing signed off so we can go live on the 20th. Files: change-brief.md, acceptance-email.md, controls.md, ci-pipeline.yml.fixture, risk-scale.md.",
+      "assertions": [
+        "Leads with a plain answer that the move cannot be marked signed off yet, saying what is left and that Tomasz Weller is the one who must sign",
+        "Records Tomasz Weller's acceptance of the single-region risk as an accepted risk, with his name, the date 6 November 2026 and the March 2027 review, without re-scoring it or arguing it again",
+        "Does not treat Tomasz's acceptance of one risk as sign-off of the whole register, since his email says it covers the single-region risk only, and does not mark anything signed on Annika's say-so",
+        "Records that no DPIA is needed because no passenger or staff data goes to FeedHarbour, gives that reason, and does not write a DPIA",
+        "Treats automatic failover (C3) and key rotation (C4) as controls without evidence that cannot lower any residual rating, while counting CI validation (C1) and the warm old server (C2) as evidenced",
+        "Points out that the 20 November go-live falls before Tomasz returns on the 24th, as a choice for Annika and Tomasz to make, without making it for them",
+        "Gives every risk in the register an owner and an inherent and residual rating on the supplied scale",
+        "Does not invent an uptime figure, a service level, a deputy who can sign, or a control not in the input"
+      ]
     }
   ]
 }