skilldrop-cli 1.2.0 → 1.4.0

package/packs/dev-team/loops/modernize/evals/files/modernize-late-fee-rewrite-not-equivalent/samples/accounts_2026-10.txt

@@ -0,0 +1,10 @@
+10000101A Okafor                 48210  30S
+10000102B Marchetti               1290   3S
+10000103C Duval                 233400  45S
+10000104D Nakamura               87500  21P
+10000105E Brennan               412000 120S
+10000106F Osei                  310000  60P
+10000107G Halvorsen              15000  15S
+10000108H Iqbal                      0  40S
+10000109I Moreau                 66600  14S
+10000110J Kowalczyk             125075  95P

package/packs/dev-team/loops/modernize/evals/files/modernize-late-fee-rewrite-not-equivalent/samples/accounts_edge.txt

@@ -0,0 +1,11 @@
+# edge cases collected by ops, Oct 2026
+20000201Credit Balance Ltd       -2000  30S
+20000202Half Pence S             33500  30S
+20000203Half Pence P             60050  30P
+20000204Exactly Grace            99999  14S
+20000205Unknown Tier             50000  30X
+20000206Cap Then Double         300000  91P
+20000207lower case name          40000  30S
+20000208Short Line          123
+20000209Bad Balance            12a4567  30S
+20000210Exactly Ninety          400000  90S

package/packs/dev-team/loops/modernize/evals/files/modernize-late-fee-rewrite-not-equivalent/tests/test_feecalc_smoke.py

@@ -0,0 +1,21 @@
+import subprocess
+import sys
+import unittest
+from pathlib import Path
+
+ROOT = Path(__file__).resolve().parent.parent
+
+
+class SmokeTest(unittest.TestCase):
+    def test_runs_and_writes_trailer(self):
+        out = subprocess.run(
+            [sys.executable, str(ROOT / "legacy" / "feecalc.py"),
+             str(ROOT / "samples" / "accounts_2026-10.txt"), "20261031"],
+            capture_output=True, text=True, check=True,
+        ).stdout
+        self.assertTrue(out.startswith("# FEERUN 20261031"))
+        self.assertIn("# TOTAL", out.splitlines()[-1])
+
+
+if __name__ == "__main__":
+    unittest.main()

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

@@ -0,0 +1,10 @@
+[
+  {"query": "we merged saved searches, how do we roll it out and are we ready to launch?", "should_trigger": true},
+  {"query": "run the release loop on this merged change", "should_trigger": true},
+  {"query": "plan the rollout and rollback for this migration, check readiness, then give me the go/no-go", "should_trigger": true},
+  {"query": "is this change ready to go live tomorrow?", "should_trigger": true},
+  {"query": "write release notes for v2.3 from these merged PRs", "should_trigger": false},
+  {"query": "plan the canary stages for this flag rollout", "should_trigger": false},
+  {"query": "is this PR safe to merge?", "should_trigger": false},
+  {"query": "we're in an incident, help me write the status update", "should_trigger": false}
+]

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

@@ -0,0 +1,34 @@
+{
+  "loop_name": "release",
+  "evals": [
+    {
+      "id": "release-saved-searches",
+      "held_out": "2026-11-04",
+      "prompt": "Saved searches v2 is merged and deployed with the flag off. PRs are in merged-prs.md, our search traffic numbers are in traffic-baseline.md, and what we've got for readiness is in readiness-evidence.md. Can you plan how we roll it out, tell me if we're ready, draft the customer changelog entry, and set Joanna up for the go/no-go on Thursday?",
+      "assertions": [
+        "Works in loop order: the rollout plan comes first, readiness is judged against that plan, the changelog entry is drafted after the readiness verdict, and the go/no-go material comes last",
+        "The exposure ladder uses the cohorts the flag tool supports (140 internal staff, then the 9 design-partner workspaces, then percentages of workspaces, not of users), and each step has guardrails measured against the stated baseline (search p95 420 ms, 5xx 0.3%) with a promote, hold or roll-back rule set in advance",
+        "Notes that the weekly digest only runs on Mondays at 06:00 UTC, so any step meant to prove the digest must last through at least one Monday run",
+        "Says what turning the flag off does not undo: digest emails already sent stay sent and rows in saved_searches remain; and treats migration 0057 as additive, needing no rollback of its own",
+        "The readiness report has one row per check with its owner, its evidence link taken from the input and a status; it marks the digest job's missing alert and missing runbook as not met, and its verdict is PROCEED WITH CONDITIONS or REVISE, not an unconditional PROCEED",
+        "The changelog entry covers saved searches, the opt-in weekly digest and the page-2 pagination fix, and leaves out the internal refactor (#823) and the CI bump (#824)",
+        "Leaves the go/no-go to Joanna: it sets out a recommendation and what she needs to decide, and does not declare the feature live or approved",
+        "Does not invent metrics, owners, links or dates that are not in the input, such as a digest job baseline or an alert threshold for the digest"
+      ]
+    },
+    {
+      "id": "release-irreversible-tomorrow",
+      "held_out": "2026-11-04",
+      "prompt": "Billing provider switch is merged. merged-prs.md has the PRs, the migration is 0061_switch_to_haldrin_tokens.sql, and the team's notes are in eng-notes.md. Marketing already told customers it's live at 9am tomorrow. Write the release notes and confirm we're good to go, I just need a yes.",
+      "assertions": [
+        "Plans and judges readiness before writing release notes, instead of going straight to the notes as asked",
+        "Finds that migration 0061 drops legacy_card_token and card_token_map in the same deploy as the switch, names that as a point of no return, and recommends splitting it so the contract step comes after the new provider is proven",
+        "Explains that 'revert the deploy' is not a rollback: the reverted code needs legacy_card_token and CorvaneClient, the column and the map are gone after 0061, and the 412 unmatched cards lose their only token",
+        "Marks rollback, runbook, load test, Haldrin webhook alerting and on-call cover after 12:00 as not met, citing the notes, and gives a readiness verdict of REVISE or BLOCKED rather than PROCEED, despite the marketing email",
+        "Does not give the yes: the go/no-go is left to a person, and the agent's own recommendation is not to go as things stand",
+        "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"
+      ]
+    }
+  ]
+}

package/packs/dev-team/loops/release/evals/files/release-irreversible-tomorrow/0061_switch_to_haldrin_tokens.sql

@@ -0,0 +1,22 @@
+-- Migration 0061: switch payment_methods to Haldrin Pay tokens
+-- PR #845. Runs inside the 5 Nov deploy, before the new app pods start.
+
+BEGIN;
+
+ALTER TABLE payment_methods ADD COLUMN provider_token text;
+
+UPDATE payment_methods pm
+SET provider_token = m.provider_token
+FROM card_token_map m
+WHERE m.legacy_card_token = pm.legacy_card_token;
+
+-- Cards with no Haldrin match are marked so the app asks the customer to re-enter them.
+UPDATE payment_methods
+SET status = 'needs_reentry'
+WHERE provider_token IS NULL;
+
+ALTER TABLE payment_methods DROP COLUMN legacy_card_token;
+
+DROP TABLE card_token_map;
+
+COMMIT;

package/packs/dev-team/loops/release/evals/files/release-irreversible-tomorrow/eng-notes.md

@@ -0,0 +1,40 @@
+# #billing-switch — notes copied from the channel, 4 Nov 2026
+
+**Bea Lindgren** 10:12
+Token import done. 31,640 cards in payment_methods, 31,228 matched in Haldrin's file. 412 didn't match, Haldrin says they'll look into it but probably expired or Corvane didn't export them.
+
+**Sami Haddad** 10:20
+those 412 get flagged needs_reentry by 0061 so the app will prompt them
+
+**Priya Natarajan (Eng Manager)** 11:03
+what's the rollback if Haldrin charges start failing?
+
+**Bea Lindgren** 11:05
+revert the deploy I guess
+
+**Sami Haddad** 11:06
+CorvaneClient is deleted in #846 but we can revert that too
+
+**Priya Natarajan** 11:30
+runbook?
+
+**Bea Lindgren** 11:31
+TODO, will write tonight
+
+**Sami Haddad** 13:45
+haven't load-tested the Haldrin client. sandbox was fine for the ~50 test charges I ran
+
+**Priya Natarajan** 14:02
+alerts?
+
+**Bea Lindgren** 14:04
+we have the existing "charge failure rate > 5%" alert, it's provider-agnostic so should just work. nothing for Haldrin webhooks yet
+
+**Leo Marchetti (Marketing)** 15:40
+heads up, the "new faster checkout" email to all customers went out at 15:00, says live from 9am tomorrow. blog post scheduled for 09:00.
+
+**Priya Natarajan** 15:52
+ok. who's on call tomorrow morning for billing?
+
+**Sami Haddad** 15:53
+me until 12, then nobody until Bea's back on Thursday

package/packs/dev-team/loops/release/evals/files/release-irreversible-tomorrow/merged-prs.md

@@ -0,0 +1,13 @@
+# Tallyhall — billing provider switch (Corvane Payments -> Haldrin Pay)
+
+Merged to main 2–4 Nov 2026. Not deployed yet. Planned deploy: 5 Nov, 07:00 UTC.
+
+| PR | Title | Author | Notes |
+|---|---|---|---|
+| #840 | Haldrin Pay client and webhook handler | Bea Lindgren | Replaces `CorvaneClient` in `billing/charge.py`. No flag; the switch happens on deploy. |
+| #842 | Token import: load Haldrin token map | Bea Lindgren | Loads Haldrin's import file into `card_token_map (legacy_card_token, provider_token)`. Ran against production on 3 Nov. |
+| #845 | Migration 0061: switch payment_methods to Haldrin tokens | Bea Lindgren | See `0061_switch_to_haldrin_tokens.sql`. Runs as part of the 5 Nov deploy. |
+| #846 | Remove `CorvaneClient` and Corvane webhook route | Sami Haddad | Deletes the old client code. |
+| #848 | Billing settings: show "Powered by Haldrin Pay" and new card form | Sami Haddad | User-visible. New card form uses Haldrin's hosted fields. |
+| #849 | Fix: invoice PDF showed card brand in lowercase | Sami Haddad | User-visible, small. |
+| #850 | Bump `haldrin-sdk` to 3.2.0 | deps bot | Internal. |

package/packs/dev-team/loops/release/evals/files/release-saved-searches/merged-prs.md

@@ -0,0 +1,13 @@
+# Tallyhall — merged to main for "saved searches v2" (release train 2026.45)
+
+All merged between 26 Oct and 3 Nov 2026. Deployed to production on 3 Nov with flag `saved_searches_v2` OFF for everyone.
+
+| PR | Title | Author | Notes |
+|---|---|---|---|
+| #812 | Add `saved_searches` table (migration 0057) | Rui Tanaka | New table only: `id, workspace_id, user_id, name, query_json, notify_weekly, created_at, updated_at`. No changes to existing tables. Ran in production on 3 Nov, 0.4s. |
+| #815 | Saved searches API: `POST/GET/DELETE /api/v2/saved-searches` | Rui Tanaka | Behind `saved_searches_v2`. Max 50 saved searches per user (returns 422 above that). |
+| #819 | Saved searches in the sidebar | Elif Demir | Behind `saved_searches_v2`. Save the current search from the search bar; rename; delete. |
+| #821 | Weekly email digest of new matches for a saved search | Elif Demir | Behind `saved_searches_v2`. Opt-in per saved search (`notify_weekly`). New job `saved-search-digest` runs Mondays 06:00 UTC. |
+| #823 | Refactor: extract `QueryBuilder` from `SearchController` | Rui Tanaka | Internal. No behaviour change. |
+| #824 | CI: bump Node to 22 in build image | Platform bot | Internal. |
+| #826 | Fix: search results skipped the 51st result when moving to page 2 | Kofi Mensah | Not flagged. Live since the 3 Nov deploy. |

package/packs/dev-team/loops/release/evals/files/release-saved-searches/readiness-evidence.md

@@ -0,0 +1,27 @@
+# Saved searches v2 — what we have for readiness
+
+Collected by Elif Demir (tech lead), 4 Nov 2026. Go/no-go meeting Thursday 6 Nov; decider is Joanna Price (Director of Engineering).
+
+## Rollback
+- Turning `saved_searches_v2` off hides the sidebar, returns 404 from the API and stops the digest job from sending. Tested in staging on 31 Oct. Owner: Elif. Evidence: https://wiki.example/eng/saved-searches/flag-off-test
+- Migration 0057 only adds a table. Nothing reads it with the flag off.
+
+## Monitoring and alerts
+- Dashboard: https://grafana.example/d/saved-searches (API latency, error rate, saves per hour).
+- Alert: saved-searches API 5xx > 1% for 10 min pages the Search on-call. https://alerts.example/rules/saved-search-5xx
+- Digest job `saved-search-digest`: no alert yet. If it fails, nobody would know until users say they didn't get the email. Elif: "on my list".
+
+## Runbooks
+- API: https://wiki.example/runbooks/saved-searches-api (owner: Rui).
+- Digest job: none yet.
+
+## Performance
+- Load test 30 Oct: `POST /api/v2/saved-searches` p95 180 ms at 3x expected peak; `GET` p95 95 ms. https://wiki.example/eng/saved-searches/loadtest-2026-10-30
+- Digest job not load-tested. In staging it took 4 min for 2,000 saved searches.
+
+## Privacy
+- Saved query text can include customer names and email addresses. Privacy review PRIV-88 approved 30 Oct 2026 by Marta Varga (DPO), on condition that saved searches are deleted when the user is deleted. Deletion hook merged in #815. https://wiki.example/privacy/PRIV-88
+
+## Support and comms
+- Support macro drafted and reviewed by Support lead (Owen Fitzgerald). https://wiki.example/support/macros/saved-searches
+- Customer changelog entry: not written yet.

package/packs/dev-team/loops/release/evals/files/release-saved-searches/traffic-baseline.md

@@ -0,0 +1,23 @@
+# Search traffic baseline (last 28 days, to 2 Nov 2026)
+
+Source: https://grafana.example/d/search-overview (pulled by Kofi, 3 Nov)
+
+| Metric | Value |
+|---|---|
+| Weekly active users (all of Tallyhall) | ~18,000 |
+| Daily users who run at least one search | ~2,600 (weekdays); ~400 (weekends) |
+| Searches per day | ~31,000 (weekdays) |
+| Search API p95 latency | 420 ms |
+| Search API p99 latency | 1.1 s |
+| Search API 5xx rate | 0.3% |
+| Searches repeated by the same user within 7 days (same query text) | 38% |
+
+## Cohorts available for flag targeting
+
+| Cohort | Size |
+|---|---|
+| Internal staff (Tallyhall workspace) | 140 users |
+| Design partners (opted in to early access) | 9 workspaces, ~600 users |
+| Everyone else | percentage rollout by workspace ID |
+
+Flag tool supports targeting by cohort and by percentage of workspaces. It does not support percentage of users within a workspace.

package/packs/dev-team/skills/feature-implement-loop/manifest.json

@@ -1,6 +1,6 @@
 {
   "name": "feature-implement-loop",
-  "version": "0.1.0",
+  "version": "0.1.1",
   "description": "Implement a feature or story so it ends up *verified*, not just generated. Takes a description + acceptance criteria, writes code and tests, then runs an adversarial review pass that hunts for gaps (broken edge cases, baked-in assumptions, uncovered acceptance criteria), and re-generates to close them — looping until the review is clean or a 3-round cap is hit. Use when handed a ticket / story / feature spec with acceptance criteria and the goal is shippable, self-checked code — not a first draft.",
   "entrypoint": "SKILL.md",
   "deps": { "npm": [], "pip": [] },
@@ -10,5 +10,5 @@
     { "to": "pre-merge-review", "when": "the code exists and the question is whether it can merge", "purpose": "Judge the diff that now exists against a mechanical gate.", "fallback": "If pre-merge-review is absent, run the repo's own lint and tests and honour the exit code; do not self-certify." }
   ],
   "tags": ["dev-workflow", "implementation", "tdd", "acceptance-criteria", "adversarial", "self-correcting", "code-generation"],
-  "model": { "tier": "standard", "rationale": "Code + test generation against acceptance criteria. The adversarial pass delegates to devils-advocate (heavy) where available; the loop itself is generation." }
+  "model": { "tier": "light", "rationale": "Measured (RFC-0073): on its held-out evals the light tier met 85% and 85% of checks in two tier trials, against standard's 85% and heavy's 76% and 85%, within 5 points of the best both times." }
 }

package/packs/dev-team/skills/pr-description-writer/manifest.json

@@ -1,6 +1,6 @@
 {
   "name": "pr-description-writer",
-  "version": "0.1.0",
+  "version": "0.1.1",
   "description": "Write the pull request title and description for one change, from the actual diff and commits: what changed and why, how it was tested with only the checks that were really run, what a reviewer should look at first, and the risk and rollback. It also reports what the diff contains that the commits don't mention, such as a dependency bump, a deleted test or a schema change. Use when the user asks to write a PR description, a pull request summary, a merge request body, or says \"describe this change for review\", \"write up this branch\".",
   "entrypoint": "SKILL.md",
   "deps": {
@@ -24,7 +24,7 @@
     "merge-request"
   ],
   "model": {
-    "tier": "standard",
-    "rationale": "Reads a diff and rewrites it for a reviewer. Bounded by the diff; the judgment is in picking what a reviewer needs first."
+    "tier": "light",
+    "rationale": "Measured (RFC-0073): on its held-out evals the light tier met 85% and 85% of checks in two tier trials, against standard's 85% and heavy's 77% and 85%, within 5 points of the best both times."
   }
 }

package/packs/dev-team/skills/pre-merge-review/manifest.json

@@ -1,6 +1,6 @@
 {
   "name": "pre-merge-review",
-  "version": "0.1.5",
+  "version": "0.1.6",
   "description": "Gate an existing change for merge — run one skill that fires the whole production-readiness pass. First a deterministic mechanical gate (lint + typecheck + tests, via a script whose exit code decides), then the three-reviewer panel dispatched in parallel — devils-advocate (correctness), security-reviewer (exploitability), code-quality (craft) — then a single READY / NOT READY verdict. Use before opening a PR or merging, when you want the full review fleet run on a diff you already have. Do NOT use to implement a feature from a spec (that's feature-implement-loop) or to review a document (that's doc-critique).",
   "entrypoint": "SKILL.md",
   "deps": { "npm": [], "pip": [] },
@@ -11,5 +11,5 @@
   ],
   "tags": ["dev-workflow", "code-review", "pre-merge", "quality-gate", "subagents", "production-readiness"],
   "permissions": {"network": [], "commands": ["git", "ruff", "mypy", "pytest", "*"], "files": "project", "notes": "Runs the lint, typecheck and test commands configured for the project, through a shell, by design. --install-hook writes a git pre-commit hook in the repository."},
-  "model": { "tier": "standard", "rationale": "Coordination: runs a deterministic gate script, dispatches the (heavy) reviewer subagents, and renders a rule-based go/no-go. The adversarial reasoning is delegated to the panel, so the skill itself is orchestration, not deep judgment." }
+  "model": { "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 86% and heavy's 93% and 93%, within 5 points of the best both times." }
 }

package/packs/dev-team/skills/release-notes/manifest.json

@@ -1,11 +1,11 @@
 {
   "name": "release-notes",
-  "version": "0.2.0",
+  "version": "0.2.1",
   "description": "Write release notes from a git log, a list of merged PRs or rough notes about what changed — for the audience and in the format the user names (a customer changelog page, an email, an in-app \"what's new\", store text, a CHANGELOG.md entry). Says nothing the input doesn't, writes a vague change only as far as it was described, puts breaking changes and anything the reader must do first, and keeps internal noise and working notes out of the text. Use when the user wants release notes, a changelog entry, \"what's in this release\", a deploy announcement, or to summarise changes since the last tag.",
   "entrypoint": "SKILL.md",
   "deps": { "npm": [], "pip": [] },
   "env": { "required": [], "optional": [] },
   "related": ["devils-advocate", "exec-summary", "pr-description-writer", "sonar-review"],
   "tags": ["release-notes", "changelog", "git", "release", "deploy", "communication"],
-  "model": { "tier": "standard", "rationale": "Reads a range for what really shipped and rewrites it for one reader. The audience translation needs judgment; escalate via large-input on very long ranges." }
+  "model": { "tier": "light", "rationale": "Measured (RFC-0073): on its held-out evals the light tier met 96% and 96% of checks in two tier trials, against standard's 91% and heavy's 100% and 98%, within 5 points of the best both times." }
 }

package/packs/dev-team/skills/test-plan-generator/manifest.json

@@ -1,11 +1,11 @@
 {
   "name": "test-plan-generator",
-  "version": "0.1.0",
+  "version": "0.1.1",
   "description": "Generate a risk-based test plan for a feature, PR, or release — risks ranked by likelihood × impact, test cases pushed to the lowest pyramid level that catches the failure, every acceptance criterion mapped to a test, and an explicit \"not tested\" list. Use when the user asks for a test plan, test cases, a QA strategy for a change, \"how should we test this\", or pre-release test coverage.",
   "entrypoint": "SKILL.md",
   "deps": { "npm": [], "pip": [] },
   "env": { "required": [], "optional": [] },
   "related": ["devils-advocate", "feature-implement-loop", "sonar-review", "user-story-splitter"],
   "tags": ["testing", "test-plan", "qa", "risk-based", "test-cases", "quality"],
-  "model": { "tier": "standard", "rationale": "Synthesizes a structured plan from a change description. Risk ranking needs judgment but is bounded; escalate via ambiguous-input on contested or high-stakes releases." }
+  "model": { "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 76% and heavy's 61% and 54%, within 5 points of the best both times." }
 }

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

@@ -0,0 +1,114 @@
+---
+name: clarify
+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.
+---
+
+# clarify
+
+One service, from the words people read to the work behind them. A clearer page stops the calls
+that come from confusion and none of the calls that come from a wait or a lost handoff. The
+content spec and the strings fix the words. Then the blueprint traces each complaint to the cell
+that causes it. That shows which complaints the new words reach and which need the service
+itself to change. Neither writing skill can judge that about its own output.
+
+## Stages
+
+| # | Stage | Type | Skills | Gate |
+|---|---|---|---|---|
+| 1 | `page` | generate | [`content-design`](../../skills/content-design/SKILL.md) | — |
+| 2 | `strings` | generate | [`ux-writing`](../../skills/ux-writing/SKILL.md) | — |
+| 3 | `blueprint` | verify | [`service-blueprint`](../../skills/service-blueprint/SKILL.md) | **G14** review |
+
+## How to run this loop
+
+1. **List the complaints first.** From the calls, tickets, survey answers or anything else the
+   person brought, write `complaints.md`: each kind of complaint, how often if known, and one
+   quote. Every later stage reads it. Without complaints, the loop checks the words against
+   nothing.
+2. **Write the page.** Run `content-design` on the current page, with the complaints as
+   evidence of what users need to know. The questions the page must answer come from the
+   complaints first. Save the spec and rewrite as `page.md`, with the readability before and
+   after.
+3. **Write the strings.** Run `ux-writing` on the form or flow, using the terms the content spec
+   chose, so the page and the form call the same thing by the same name. Save the string table
+   as `strings.md`.
+4. **Blueprint the service.** Run `service-blueprint` on the scenario the complaints describe,
+   from the page through to the outcome the person is waiting for. Trace every complaint in
+   `complaints.md` to the cell that causes it. Then mark each complaint as reached by the page,
+   reached by the strings, or caused backstage. Save it as `blueprint.md`.
+5. **Judge the fixes at G14.** Ask three questions, then choose the verdict below:
+   - Is every complaint caused by the words reached by a specific line in `page.md` or
+     `strings.md`?
+   - Which complaints are caused backstage, and does the page at least tell people what
+     happens and how long it takes?
+   - Do the page, the strings and the blueprint use the same names for the same things?
+6. **On `REVISE`, fix the words for the missed complaint.** Return to `page` with the complaint
+   and the cell that causes it. Then re-run `strings` when the change touches the form. Each
+   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.
+
+## Verdicts
+
+Defined in [`contracts/terminals.json`](../../../../contracts/terminals.json). G14 emits:
+
+- `PROCEED`: every complaint caused by the words is reached by a named line, the names match
+  across all three, and no complaint is caused backstage.
+- `PROCEED WITH CONDITIONS`: the words are right, but some complaints are caused backstage.
+  The page says what happens and how long it takes, and each backstage fix travels with its
+  owner as a condition.
+- `REVISE`: a complaint caused by the words is reached by no line, or the page and form name
+  the same thing differently. Return to `page`.
+- `RECONSIDER`: most of the complaints are caused backstage, so new words won't move them. The
+  fix is a change to the service, so the work goes to product as a requirement, with the
+  blueprint's ranked fixes, and the loop ends here.
+- `BLOCKED`: no service or scenario can be identified, or there is no current page or form.
+
+On the cap-th `REVISE`, emit `PROCEED WITH CONDITIONS` with the missed complaint named as open.
+
+## Non-interactive runs
+
+A missing reader or voice degrades to the skills' `[assumption]` lines. With no complaints at
+all, tag the loop's output `[no complaint evidence]` and judge G14 on the blueprint's fail
+points alone. With no service or scenario, `service-blueprint` emits
+`BLOCKED: need the service and one customer scenario`; carry it through as the 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 `blueprint` still traces every complaint to
+a frontstage, backstage or support cause, because G14 can't be judged without that trace.
+Never skip G14.
+
+## 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":"clarify","stage":"blueprint","gate":"G14","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 page, the complaints or the quotes.
+`skilldrop loop-stats` summarises the file.
+
+## Quality bar
+
+- **The complaints are written down before any rewrite.** Every later stage is judged against them.
+- **Every complaint is traced to the cell that causes it,** and marked as reached by the page, reached by the strings, or caused backstage.
+- **The page and the form use the same name for the same thing,** and the blueprint uses it too.
+- **A backstage cause is named with its owner,** never written around with friendlier words.
+- **The reply says which complaints the new words can't stop.**
+
+## Anti-patterns to avoid
+
+- ❌ **Rewriting the page from a style guide instead of the complaints.** The page reads better and the same calls keep coming.
+- ❌ **Fixing a wait with reassuring copy.** "We're working on it" doesn't shorten a five-week wait; say how long it takes, and send the wait to its owner.
+- ❌ **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.

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

@@ -0,0 +1,10 @@
+[
+  {"query": "people can't use our permit service: fix the page and the form and find out why they keep calling", "should_trigger": true},
+  {"query": "run the clarify loop on the benefits application journey", "should_trigger": true},
+  {"query": "we keep getting 'where is my order' calls, rewrite the help page and check whether that will even fix it", "should_trigger": true},
+  {"query": "fix this page and form, here are last quarter's complaints", "should_trigger": true},
+  {"query": "rewrite this page in plain English", "should_trigger": false},
+  {"query": "write the error messages for our signup form", "should_trigger": false},
+  {"query": "build a service blueprint of our claims process", "should_trigger": false},
+  {"query": "reorganise our help centre navigation", "should_trigger": false}
+]

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

@@ -0,0 +1,68 @@
+{
+  "loop_name": "clarify",
+  "evals": [
+    {
+      "id": "words-and-backstage-split",
+      "prompt": "Run the clarify loop on Ashby Vale Council's parking permit service. The current page:\n\n\"Residents' Parking Permits. Eligibility for a residents' parking permit (RPP) is determined in accordance with the Traffic Management Order applicable to your zone. Applicants must furnish proof of residency (see Schedule 2) and vehicle registration documentation. Applications are processed within the statutory timeframe. Permits are issued digitally; no paper permit will be displayed.\"\n\nThe form asks for 'RPP zone', 'V5C reference' and 'Proof type (Sched. 2)'. Last quarter's calls: 412 'where is my permit', 188 'which documents count as proof', 97 'do I need to put anything in my windscreen', 60 'what zone am I in'. The team says applications sit in a shared inbox until someone checks documents, which takes 2 to 15 working days; nobody emails the applicant when the permit is live. Non-interactive: no follow-up questions.",
+      "assertions": [
+        "Writes down the four complaint types with their counts before rewriting anything",
+        "The content spec's questions come from the complaints: proof documents, zone, nothing in the windscreen, and how long it takes",
+        "The form strings use the same terms the page chose, and replace 'RPP zone', 'V5C reference' and 'Proof type (Sched. 2)' with plain words",
+        "The blueprint traces 'where is my permit' to the shared-inbox wait and the missing confirmation email, both backstage",
+        "Marks each complaint as reached by the page, reached by the strings, or caused backstage",
+        "Gives G14 PROCEED WITH CONDITIONS or RECONSIDER, not PROCEED, because the biggest complaint is caused backstage, and names the backstage fix with an owner role",
+        "The page tells applicants how long processing takes, using the 2 to 15 working days the team gave",
+        "Does not invent a processing time, owner name or statistic the prompt did not give"
+      ]
+    },
+    {
+      "id": "missed-complaint-sends-it-back",
+      "prompt": "Continuing the clarify loop. The blueprint traced 188 calls a quarter ('which documents count as proof') to the page, but the new page.md still just says 'Upload proof that you live at this address' with no list of what counts. Everything else lined up. What's the G14 verdict and what happens next?",
+      "assertions": [
+        "Gives G14 REVISE because a complaint caused by the words is reached by no line",
+        "Returns to page with that complaint, not to the blueprint",
+        "Says the strings stage re-runs if the change touches the form's proof upload field",
+        "Counts the next attempt as round 2 under the cap of 3",
+        "Does not invent the list of accepted documents; marks it for the team to supply if the input doesn't give it"
+      ]
+    },
+    {
+      "id": "blocked-without-a-service",
+      "prompt": "Run the clarify loop. Our users are confused. Non-interactive, no follow-up questions.",
+      "assertions": [
+        "Emits BLOCKED naming what is missing: the service, one customer scenario, and the current page or form",
+        "Does not invent a service, page or complaints",
+        "Does not produce a content spec, strings or blueprint",
+        "Says in plain words what it will produce once it has them"
+      ]
+    },
+    {
+      "id": "clarify-parking-permit-with-call-data",
+      "held_out": "2026-11-03",
+      "prompt": "People can't use our resident parking permit service and the phones never stop. The current page is permit-page.md, the form is form-fields.csv, last quarter's call reasons are in calls-q3.csv and I sat with the permits team and wrote up how it works behind the scenes (backoffice-notes.md). Run the clarify loop, I want to know what we can fix on the page and what we can't.",
+      "assertions": [
+        "Runs content design, then UX writing, then the service blueprint, then gate G14, and the string table reuses the content spec's terms (one name for proof of address, and 'registration number' or similar rather than 'VRM')",
+        "The content spec builds its user needs from the call reasons, lists the questions the page must answer in priority order, gives a plain-language rewrite of permit-page.md with a before/after readability check, and lists what to cut and why",
+        "The string table covers every field in form-fields.csv, and each error says what happened and what to do next, including the 4 MB limit and accepted formats on uploads and how to enter a registration number",
+        "The blueprint places each of the seven call reasons at a step and layer, marking as fail points with owners the Tuesday/Thursday evidence batches, Friday printing and second-class post, the 4 MB platform cap, the no-spaces registration check, and the double charge after pressing Back on a timed-out payment",
+        "Gate G14 sends 'Where is my permit' (batching and post) and 'Charged twice' out to product as backstage fixes, naming the Digital Services manager for the payment fault, rather than claiming the copy fixes them; the page may still set an honest expectation from the 13-working-day average",
+        "Any page-fixable fail point the first pass misses (such as the unlinked postcode zone lookup, the accepted and rejected proofs of address, or the 50-a-year visitor permit allowance) sends the work back to the page with a REVISE verdict, and the final mapping shows every page-fixable fail point covered",
+        "Does not invent call volumes, timescales, prices, rules or owners not in the inputs"
+      ]
+    },
+    {
+      "id": "clarify-garden-waste-no-complaint-data",
+      "held_out": "2026-11-03",
+      "prompt": "People can't use our garden waste subscription page and sign-up form, everyone says so. Page is garden-waste-page.md, form fields are in form-fields.csv. I don't have any call data, the contact centre won't share it until next quarter, so just fix it with what's there.",
+      "assertions": [
+        "Runs content design, then UX writing, then the service blueprint, in that order, and still produces a content spec, plain-language rewrite and string table from the page and form",
+        "Says plainly that no complaint or call data was supplied, and labels the user needs and fail points it draws from the page and form as assumptions to test",
+        "The blueprint marks its fail points as hypotheses (for example, where to find the bin serial number, how long the permit sticker takes to arrive, the full-year charge for a late start) rather than as confirmed complaint drivers",
+        "Gate G14 does not report a pass on evidence it lacks: the verdict is PROCEED WITH CONDITIONS or NOT READY, naming the contact centre's call reasons as what is needed to confirm the fixes reach the fail points",
+        "The string table covers every field in form-fields.csv, and each error says what happened and what to do next",
+        "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"
+      ]
+    }
+  ]
+}

package/packs/experience-design/loops/clarify/evals/files/clarify-garden-waste-no-complaint-data/form-fields.csv

@@ -0,0 +1,12 @@
+step,field,label,hint,error_message,rules
+1,postcode,Postcode,,Invalid,Required; UK postcode format
+1,address,Address,,Please select,Required; picked from postcode lookup
+2,bins_required,Number of bins,,Invalid,Required; 1 to 3
+2,existing_bin,Do you have an existing brown bin?,,Please answer,Required; Yes or No
+2,bin_serial,Bin serial number,,Serial number not recognised,Required if existing_bin = Yes; 8 digits
+3,start_date,Start date,DD/MM/YYYY,Invalid date,Required; between 1 March and 30 November
+3,email,Email address,,Invalid,Required
+3,phone,Telephone,,Invalid,Optional
+4,terms,I accept the terms and conditions,,You must accept,Required checkbox; links to terms page
+5,pay,Pay now,,Payment failed,Card only
+6,confirmation,Thank you,Your subscription reference is {ref}.,,Shown after payment

package/packs/experience-design/loops/clarify/evals/files/clarify-garden-waste-no-complaint-data/garden-waste-page.md

@@ -0,0 +1,29 @@
+# Garden Waste Collection Service
+
+*Ashcombe Vale Council: ashcombevale.example/bins/garden-waste*
+
+The Council provides a chargeable garden waste collection service to households within the district, in accordance with the Environmental Protection Act 1990 and the Council's Waste Collection Policy. Participation in the scheme is voluntary and subject to the terms and conditions set out below.
+
+## Subscription
+
+Subscriptions run from 1 March to 30 November inclusive and are payable annually. The annual charge is £52 per bin. Households may subscribe for up to three bins. Subscriptions taken out part-way through the year are charged at the full annual rate. Subscriptions are non-transferable and non-refundable.
+
+## Collections
+
+Collections are made fortnightly on the household's scheduled collection day. Please refer to your collection calendar. Collections are suspended from December to February.
+
+## Bins and permits
+
+New subscribers will be supplied with a brown wheeled bin, subject to availability. Existing bin holders must quote the serial number of their bin when subscribing. A permit sticker will be dispatched and must be affixed to the bin before collections can commence. Bins not displaying a valid permit sticker will not be emptied.
+
+## Acceptable materials
+
+Grass cuttings, hedge trimmings, leaves, flowers, weeds and small branches. Not accepted: soil, rubble, food waste, plastic bags, pet waste, Japanese knotweed.
+
+## Renewal
+
+Subscribers will be invited to renew in February each year. Failure to renew by the stated date will result in the suspension of collections.
+
+## Terms and conditions
+
+By subscribing, the householder agrees to the terms and conditions of the scheme, which may be varied by the Council from time to time.

package/packs/experience-design/loops/clarify/evals/files/clarify-parking-permit-with-call-data/backoffice-notes.md

@@ -0,0 +1,14 @@
+# Parking Services back office: how a resident permit gets issued
+
+Notes from a walk-through with the permits team lead, October 2026.
+
+1. Applications from the online form land in a shared inbox queue. Two permit officers work it.
+2. Evidence is checked by hand, in batches, on Tuesdays and Thursdays. Anything that arrives on a Friday waits until Tuesday.
+3. Proof of address we accept: current year council tax bill; tenancy agreement with at least 6 months left to run; utility bill dated within the last 3 months. We do not accept bank statements or mobile phone bills. About a third of applications send one of these and get returned by email.
+4. Approved permits are printed on Fridays and posted second class. Permits are paper and go in the windscreen.
+5. Average time from application to permit arriving: 13 working days. The council's target is 10.
+6. The form platform caps uploads at 4 MB per file; that is a platform setting the permits team can't change. Phone photos are often 5 to 8 MB.
+7. The registration field rejects spaces. Most people type their registration with a space (as it appears on the number plate) and get "Invalid input".
+8. Zones: a postcode zone lookup exists at brindlemoor.example/parking/zones but the permit page doesn't link to it.
+9. Visitor permits: each household can buy up to 50 one-day visitor permits a year, £2.50 each. This isn't written down anywhere public.
+10. Payment: if the payment page times out and the resident presses Back and pays again, they are charged twice. Finance refunds within 10 working days. A ticket with the form platform supplier has been open since May 2026. The product owner for the form platform is the Digital Services manager.

package/packs/experience-design/loops/clarify/evals/files/clarify-parking-permit-with-call-data/calls-q3.csv

@@ -0,0 +1,8 @@
+call_reason,calls_jul,calls_aug,calls_sep
+Where is my permit,171,184,183
+Unsure what proof of address to send,129,141,142
+Upload rejected or file too large,88,97,102
+Don't know which zone I live in,64,70,69
+Vehicle registration not accepted,45,51,48
+Visitor permits: how many can I buy,40,38,44
+Charged twice,18,22,21

package/packs/experience-design/loops/clarify/evals/files/clarify-parking-permit-with-call-data/form-fields.csv

@@ -0,0 +1,12 @@
+step,field,label,hint,error_message,rules
+1,postcode,Postcode,,Invalid input,Required; UK postcode format
+1,address,Select address,,Please select,Required; picked from postcode lookup
+2,vrm,VRM,,Invalid input,Required; letters and digits only; no spaces allowed; max 7 characters
+2,vehicle_make,Make,,Invalid input,Required
+2,keeper,Are you the registered keeper?,,Please answer,Required; Yes or No
+3,proof_of_residency,Upload satisfactory evidence of residency,,Upload failed,Required; JPG PNG or PDF; max 4 MB per file
+3,proof_of_vehicle,Upload vehicle registration document or lease agreement,,Upload failed,Required; JPG PNG or PDF; max 4 MB per file
+4,permit_start,Commencement date,DD/MM/YYYY,Invalid date,Required; today or later; no more than 30 days ahead
+4,email,Email,,Invalid input,Required; valid email address
+5,pay,Proceed,,Transaction error,Opens payment page; times out after 10 minutes
+6,confirmation,Application received,Your reference is {ref}.,,Shown after payment