skilldrop-cli 1.1.3 → 1.3.0

package/packs/design/skills/brand-kit/manifest.json

@@ -1,6 +1,6 @@
 {
   "name": "brand-kit",
-  "version": "0.1.3",
+  "version": "0.1.4",
   "description": "Capture a brand once as a reusable brand.json — logo files (and an on-dark version), colour roles as hex codes, heading and body fonts, voice, imagery rules, a PowerPoint template, contact details and the legal footer — plus a one-page BRAND.md, with text contrast checked and every value traced to where it came from. Use when the user wants decks, flyers or documents in their branding, says \"use our brand\", \"here's our logo and colours\", \"set up our brand kit\", or hands over brand guidelines.",
   "entrypoint": "SKILL.md",
   "deps": {
@@ -12,22 +12,8 @@
     "optional": []
   },
   "related": [
-    "deck-builder",
-    "marketing-flyer"
-  ],
-  "handoff": [
-    {
-      "to": "deck-builder",
-      "when": "the brand kit is written and the user wants a deck",
-      "purpose": "Build the PowerPoint deck in this brand: build_deck.py --brand brand.json.",
-      "fallback": "If deck-builder is absent, give the user the brand.json path and the five hex codes to paste into whatever deck tool they use."
-    },
-    {
-      "to": "marketing-flyer",
-      "when": "the brand kit is written and the user wants a flyer or one-page sheet",
-      "purpose": "Build a print-ready flyer in this brand from the flyer spec's brand field.",
-      "fallback": "If marketing-flyer is absent, give the user BRAND.md so a designer or tool can apply it by hand."
-    }
+    "md-to-pptx",
+    "md-to-docx"
   ],
   "tags": [
     "brand",

package/packs/design/skills/brand-kit/templates/brand.json

@@ -1,5 +1,5 @@
 {
-  "$comment": "brand-kit output. deck-builder and marketing-flyer read this file; any field left out is asked for or defaulted by them. Paths are relative to this file. Every value carries where it came from in `sources`.",
+  "$comment": "brand-kit output. md-to-docx and md-to-pptx read this file; any field left out is asked for or defaulted by them. Paths are relative to this file. Every value carries where it came from in `sources`.",
   "name": "Northwind Health",
   "tagline": "Care that comes to you",
   "logo": {

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

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

@@ -0,0 +1,27 @@
+# Resident Parking Permits
+
+*Brindlemoor District Council: brindlemoor.example/parking/resident-permits*
+
+## Introduction
+
+Brindlemoor District Council operates a number of Controlled Parking Zones (CPZs) within the district under the provisions of the Brindlemoor (Controlled Parking Zones) Traffic Management Order 2019, as amended. Within a CPZ, parking in designated resident bays is restricted to vehicles displaying a valid resident parking permit issued for the relevant zone during the hours of operation shown on the zone entry signage.
+
+## Eligibility
+
+Permits may be issued to residents whose principal place of residence is situated within a CPZ and who are the registered keeper of the vehicle, or who can otherwise demonstrate that the vehicle is in their care and control on an ongoing basis. Satisfactory evidence of residency and of the vehicle's details will be required. The Council reserves the right to request further evidence at its discretion.
+
+## Charges
+
+The permit charge is payable annually in advance. The charge for a first permit is £68. The charge for a second permit at the same address is £112. Permits are not transferable between vehicles except on application. Refunds are not normally given.
+
+## Visitor permits
+
+Residents within a CPZ are also entitled to purchase visitor permits, subject to annual limits.
+
+## How to apply
+
+Applications should be made using the online form. Applicants must ensure that all evidence submitted is legible and current. Incomplete applications cannot be processed and will be returned. Permits will be issued in due course following verification of the application.
+
+## Further information
+
+For further information please contact the Parking Services team on 0306 999 0142 or parking@brindlemoor.example.

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

@@ -0,0 +1,35 @@
+{
+  "$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",
+  "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",
+  "cap": 3,
+  "stages": [
+    {
+      "id": "page",
+      "type": "generate",
+      "intent": "Write the content spec from the user needs and the complaints: the questions the page must answer in order, its structure, and a plain-language rewrite with its readability before and after.",
+      "skills": ["content-design"]
+    },
+    {
+      "id": "strings",
+      "type": "generate",
+      "intent": "Write every string on the form or flow, in the content spec's terms, with errors that say what happened and what to do next.",
+      "skills": ["ux-writing"]
+    },
+    {
+      "id": "blueprint",
+      "type": "verify",
+      "intent": "Blueprint the service behind the page and form, trace each complaint to the cell that causes it, and judge whether the page and strings reach the fail points that cause the complaints.",
+      "skills": ["service-blueprint"],
+      "gate": {
+        "id": "G14",
+        "kind": "review",
+        "verdicts": ["PROCEED", "PROCEED WITH CONDITIONS", "REVISE", "RECONSIDER", "BLOCKED"],
+        "revise_to": "page"
+      }
+    }
+  ]
+}

package/packs/infra-as-code/loops/provision/LOOP.md

@@ -0,0 +1,128 @@
+---
+name: provision
+description: Take an infrastructure change from a described need to a Terraform apply a person approved: a module with secure defaults, a review of the real plan that names every destroy, replace, widening and out-of-scope change, and a check right before apply that the plan being applied is the one reviewed, with a gate that sends the module back when the plan would destroy state or widen access unasked. Use when the user says "write the terraform and check it before we apply", "provision this safely", "run the provision loop", or wants new infrastructure from module to apply in one pass.
+---
+
+# provision
+
+One infrastructure change, from a need to an apply. A module with secure defaults can still
+produce a plan that replaces a database, because the plan depends on the state and the
+environment, not only on the code. So the loop reviews the real plan against the scope written
+when the module was, and checks at apply time that nothing moved between review and apply.
+
+## Stages
+
+| # | Stage | Type | Skills | Gate |
+|---|---|---|---|---|
+| 1 | `module` | generate | [`terraform-module`](../../skills/terraform-module/SKILL.md) | — |
+| 2 | `plan` | verify | [`terraform-plan-review`](../../skills/terraform-plan-review/SKILL.md) | **G13** review |
+| 3 | `apply` | gate | [`terraform-plan-review`](../../skills/terraform-plan-review/SKILL.md) | **G13.1** human |
+
+## How to run this loop
+
+1. **Write the module and the scope together.** Run `terraform-module` on the need. Beside it,
+   write `scope.md`: the resource addresses this change is meant to create, change or destroy,
+   and one sentence of intent. The scope is written now, before any plan exists, so the review
+   can't read the plan to fit it.
+2. **Get a saved plan.** The person, or you where credentials allow, runs the commands below.
+   A plan printed without `-out` can't be applied as reviewed, so it doesn't count.
+
+   ```bash
+   terraform init
+   terraform plan -out=tfplan
+   terraform show -json tfplan > plan.json
+   ```
+
+   Record the planfile's SHA-256 in `scope.md`. Without credentials or state, stop and say
+   exactly which commands to run and what to bring back.
+3. **Review the plan against the scope.** Run `terraform-plan-review` on `plan.json`, passing
+   every address in `scope.md` as the intended scope. Every change outside it is listed, even
+   when harmless. Save the review as `review.md`.
+4. **Judge the plan at G13.** Map the review's verdict and findings to the gate:
+   - `SAFE TO APPLY` with nothing out of scope is `PROCEED`.
+   - `APPLY WITH CARE` is `PROCEED WITH CONDITIONS`, and the review's pre-apply checks are the
+     conditions.
+   - `DO NOT APPLY` caused by the code (a forced replacement, a widened rule, a missing
+     `prevent_destroy`) is `REVISE`.
+   - `DO NOT APPLY` caused by the change itself, such as a stateful resource that has to be
+     replaced to reach the goal, is `RECONSIDER`.
+5. **On `REVISE`, fix the module, then re-plan.** Return to `module` with the forcing attribute
+   or the widened rule named. Re-plan from the fixed code; never edit `plan.json`. Each return
+   counts against the cap.
+6. **Check the apply at G13.1.** Right before apply, confirm two things:
+   - the planfile's SHA-256 matches the one recorded in `scope.md`;
+   - `terraform show -json tfplan` still lists the same resource changes `review.md` reviewed.
+
+   Any difference is `REVISE` back to `plan`: re-plan and re-review. Then the person who will
+   run `terraform apply tfplan` reads every destroy and replace in `review.md` and decides.
+   Only they choose the verdict. Never run `terraform apply` yourself in this loop.
+7. **Hand over the verdict and what apply will do.** Lead with what changes in plain words,
+   what is destroyed or replaced, and the checks to do first. The review goes underneath.
+   Close with each gate on its own line, `G13: <VERDICT>` and `G13.1: <VERDICT>` (or
+   `G13.1: awaiting <role>`), and one sentence of reasons.
+
+## Verdicts
+
+Defined in [`contracts/terminals.json`](../../../../contracts/terminals.json). G13 emits:
+
+- `PROCEED`: every change is in scope, nothing stateful is destroyed or replaced, no access is
+  widened, and no unexplained drift.
+- `PROCEED WITH CONDITIONS`: in-scope replacements of stateless resources, in-place changes to
+  stateful ones, or drift the plan overwrites. The review's pre-apply checks travel to G13.1.
+- `REVISE`: the code causes a destroy, a replace or a widening nobody asked for. Return to
+  `module`.
+- `RECONSIDER`: the change can only be made by replacing state. It needs a migration with a
+  backup and a rollback, not a module edit, so the loop ends here and names that work.
+- `BLOCKED`: no plan to review, or a plan that errored.
+
+G13.1 emits `PROCEED`, `REVISE` (back to `plan`, when the planfile or its changes moved) or
+`BLOCKED` (no planfile, or nobody named to run apply).
+
+On the cap-th `REVISE` at G13, emit `RECONSIDER`: the module isn't converging on a safe plan,
+so the change needs a person to rethink it.
+
+## Non-interactive runs
+
+Missing provider or Terraform versions degrade to `terraform-module`'s `[assumption]` tags.
+With no plan and no way to run one, the loop ends after `module` with
+`G13: BLOCKED: need a saved plan (terraform plan -out=tfplan, then terraform show -json tfplan)`.
+G13.1 always stops at the person who runs apply.
+
+## 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 `plan` still lists every resource whose
+actions include `delete`, every change to a security group, IAM policy or bucket policy, and
+every address outside `scope.md`, because G13 can't be judged without them. Never skip G13 or
+G13.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":"provision","stage":"plan","gate":"G13","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 resource names, plan contents or values.
+`skilldrop loop-stats` summarises the file.
+
+## Quality bar
+
+- **The scope is written before the plan exists,** as resource addresses. A scope written after reading the plan covers whatever the plan does.
+- **Only a saved planfile is reviewed.** A plan printed without `-out` can't be applied as reviewed.
+- **Every change outside the scope is listed,** even when harmless.
+- **The plan applied is the plan reviewed.** G13.1 checks the planfile's hash and its resource changes.
+- **The loop never runs `terraform apply`.** The person who runs it decides at G13.1.
+
+## Anti-patterns to avoid
+
+- ❌ **Reviewing the module instead of the plan.** Secure code can still replace a database when the state disagrees with it.
+- ❌ **Fixing a bad plan by editing plan.json.** Fix the code and re-plan.
+- ❌ **Passing G13 because the destroy is "probably fine".** A stateful destroy without a confirmed backup is `DO NOT APPLY`, and the loop maps it to `REVISE` or `RECONSIDER`.
+- ❌ **Applying a fresh plan after reviewing an old one.** Anything merged in between is unreviewed.
+- ❌ **Treating `RECONSIDER` as a bigger `REVISE`.** A change that has to replace state is a migration; another module edit won't make it safe.

package/packs/infra-as-code/loops/provision/evals/eval_queries.json

@@ -0,0 +1,9 @@
+[
+  {"query": "write the terraform for an RDS read replica and check the plan before we apply", "should_trigger": true},
+  {"query": "run the provision loop on this new VPC", "should_trigger": true},
+  {"query": "provision a private bucket for backups safely, module to apply", "should_trigger": true},
+  {"query": "I'm about to apply the plan we reviewed yesterday, is it still the same one?", "should_trigger": true},
+  {"query": "review this terraform plan, is it safe to apply?", "should_trigger": false},
+  {"query": "turn this terraform into a reusable module", "should_trigger": false},
+  {"query": "plan the migration of our database to a new instance class", "should_trigger": false}
+]

package/packs/infra-as-code/loops/provision/evals/evals.json

@@ -0,0 +1,67 @@
+{
+  "loop_name": "provision",
+  "evals": [
+    {
+      "id": "scope-before-plan",
+      "prompt": "Run the provision loop: we need a private S3 bucket for nightly Postgres backups from our billing service, versioned, encrypted with our existing KMS key alias/billing-backups, with objects moving to Glacier after 30 days and expiring after a year. AWS provider 5.x, Terraform 1.9. I'll run the plan myself and paste it back. Non-interactive: no follow-up questions.",
+      "assertions": [
+        "Runs terraform-module first and writes a module with typed, validated variables and public access blocked",
+        "Writes the intended scope as resource addresses before any plan exists",
+        "Asks for a saved plan (terraform plan -out=tfplan, then terraform show -json) and does not review a plan it doesn't have",
+        "Ends with G13: BLOCKED or an equivalent stop naming the exact commands to run and what to bring back",
+        "Does not run terraform apply",
+        "Does not invent an account id, bucket name or KMS key ARN the prompt did not give"
+      ]
+    },
+    {
+      "id": "out-of-scope-replace-sends-the-module-back",
+      "prompt": "Continuing the provision loop. Scope was: create module.backups.aws_s3_bucket.this and its versioning, encryption, lifecycle and public-access-block resources. Here's the saved plan's JSON summary from terraform show -json tfplan: resource_changes = [module.backups.aws_s3_bucket.this create; module.backups.aws_s3_bucket_versioning.this create; module.backups.aws_s3_bucket_server_side_encryption_configuration.this create; module.backups.aws_s3_bucket_lifecycle_configuration.this create; module.backups.aws_s3_bucket_public_access_block.this create; aws_db_instance.billing actions [delete, create], replace_paths [[\"engine_version\"]]]. The billing DB change wasn't in my PR.",
+      "assertions": [
+        "Flags the aws_db_instance.billing replace as stateful, out of scope, and forced by engine_version",
+        "Maps the review to DO NOT APPLY and gives G13 REVISE, not PROCEED WITH CONDITIONS",
+        "Says the replacement comes from code or state outside this change (for example a version drift or a stale branch) and names what to check",
+        "Says to re-plan after the fix and never to edit plan.json",
+        "Does not reach G13.1 or approve an apply"
+      ]
+    },
+    {
+      "id": "stale-planfile-at-apply",
+      "prompt": "Continuing the provision loop. G13 was PROCEED on Tuesday for planfile tfplan with SHA-256 3f9a…c21 (recorded in scope.md). It's Thursday and I'm about to apply. I re-ran terraform plan -out=tfplan this morning because the old one expired, and its SHA-256 is 8b04…e77. Can I go ahead?",
+      "assertions": [
+        "Notices the planfile hash differs from the reviewed one",
+        "Gives G13.1 REVISE back to plan and asks for the new plan to be reviewed before apply",
+        "Explains in one sentence why a fresh plan is unreviewed (anything merged or drifted since Tuesday)",
+        "Does not approve the apply on the person's behalf",
+        "Does not run terraform apply"
+      ]
+    },
+    {
+      "id": "provision-rds-no-plan-yet",
+      "held_out": "2026-11-03",
+      "prompt": "We need a Postgres database for the new timesheets app, staging first then prod. Network details and our tag conventions are in network.md, and the staging env's lock file is .terraform.lock.hcl.fixture. Write the terraform and check it before we apply. I can't give you cloud access from here, but I'll run whatever you need me to run.",
+      "assertions": [
+        "Runs the module stage first and writes main.tf, variables.tf, outputs.tf and versions.tf with typed, validated variables, a README with inputs and outputs tables, and a staging usage example",
+        "Secure defaults: storage encrypted with the existing alias/platform-rds key (no new KMS key), publicly_accessible false, deletion_protection true, backup retention 14 days, and the master password managed by RDS rather than passed as a variable",
+        "Allows port 5432 only from sg-04d5e6f7a8b9c0d12, with no CIDR ingress, places the database in the three private subnets from network.md, and turns multi-AZ on for prod only",
+        "Applies the five required tags from network.md through a merged tags variable, and the versions.tf provider constraint admits the locked hashicorp/aws 5.62.0 without requiring 6.x",
+        "At gate G13 says there is no real plan to review and does not pass the gate: gives the exact commands to produce one (terraform plan -out=<file>, then terraform show -json <file>) and says what the review will check",
+        "Never gives SAFE TO APPLY and does not reach the apply check; says apply waits on a review of the real plan and a person's approval",
+        "Does not invent plan output (resource counts, destroys, replaces) or IDs, ARNs and account details that are not in network.md"
+      ]
+    },
+    {
+      "id": "provision-replica-plan-replaces-primary",
+      "held_out": "2026-11-03",
+      "prompt": "Reporting team needs a read replica of the orders database. I've made the change on my branch (the module's main.tf and variables.tf are attached) and ran the prod plan, json is in plan.json. Can you run provision on it? I'd like to apply this afternoon.",
+      "assertions": [
+        "Runs the module stage on the change, then reviews plan.json at gate G13, rather than going straight to a verdict",
+        "Flags module.orders_db.aws_db_instance.primary as a replace forced by identifier (orders-prod to orders-prod-primary), says the production database would be destroyed and recreated, and notes that deletion_protection false and skip_final_snapshot true mean nothing blocks the destroy and no final snapshot is taken",
+        "Flags the db_ingress replace that widens port 5432 from 10.40.0.0/16 to 0.0.0.0/0 as access widening the request never asked for, noting that var.vpc_cidr is now unused",
+        "Flags the delete of aws_s3_bucket_lifecycle_configuration.exports (the 90-day expiry on exports/) as outside the read-replica scope",
+        "Gate G13 does not pass: the plan verdict is DO NOT APPLY and the loop sends the work back to the module stage, whose revision keeps the primary's existing identifier, restores ingress to var.vpc_cidr, and either restores the lifecycle rule or names it for its owner to decide",
+        "Treats the revised module as needing a fresh plan: does not reach the apply check or approve applying this afternoon, and gives the commands to re-plan",
+        "Does not invent facts not in the inputs, such as a recent manual snapshot existing, the replica needing public access, or changes plan.json does not contain"
+      ]
+    }
+  ]
+}

package/packs/infra-as-code/loops/provision/evals/files/provision-rds-no-plan-yet/.terraform.lock.hcl.fixture

@@ -0,0 +1,24 @@
+# This file is maintained automatically by "terraform init".
+# Manual edits may be lost in future updates.
+
+provider "registry.terraform.io/hashicorp/aws" {
+  version     = "5.62.0"
+  constraints = ">= 5.40.0, < 6.0.0"
+  hashes = [
+    "h1:8qY3kG0a1mX2rT4vN6pB9cD5eF7hJ1kL3mN5pQ7rS9u=",
+    "zh:0a1b2c3d4e5f60718293a4b5c6d7e8f90a1b2c3d4e5f60718293a4b5c6d7e8f9",
+    "zh:1b2c3d4e5f60718293a4b5c6d7e8f90a1b2c3d4e5f60718293a4b5c6d7e8f90a",
+    "zh:2c3d4e5f60718293a4b5c6d7e8f90a1b2c3d4e5f60718293a4b5c6d7e8f90a1b",
+    "zh:3d4e5f60718293a4b5c6d7e8f90a1b2c3d4e5f60718293a4b5c6d7e8f90a1b2c",
+  ]
+}
+
+provider "registry.terraform.io/hashicorp/random" {
+  version     = "3.6.2"
+  constraints = "~> 3.6"
+  hashes = [
+    "h1:Rm4vY2kT9pB1cN3dF5gH7jK9lM1nP3qR5sT7uV9wX1y=",
+    "zh:4e5f60718293a4b5c6d7e8f90a1b2c3d4e5f60718293a4b5c6d7e8f90a1b2c3d",
+    "zh:5f60718293a4b5c6d7e8f90a1b2c3d4e5f60718293a4b5c6d7e8f90a1b2c3d4e",
+  ]
+}