skilldrop-cli 0.16.6 → 0.16.7

package/packs/solution-architect/skills/db-schema-design/evals/files/2/notes.md

@@ -0,0 +1,53 @@
+# Pawsley Vets: booking rebuild, working notes
+
+Written by Imogen Tarrant (practice systems lead), last touched 22 Sept 2026.
+
+## Who we are
+
+- 6 clinics. Four around Sydney (Marrickville, Newtown, Manly, Parramatta) and two in
+  Brisbane (Paddington, West End).
+- About 38 vets. Seven of them work at two clinics on different days of the week.
+- Roughly 450 appointments a day across the group.
+- About 21,000 active pets belonging to about 15,000 owners. An owner can have several pets.
+
+## Appointment types
+
+| Type | Length |
+|---|---|
+| Consult | 15 min |
+| Vaccination | 15 min |
+| Extended consult | 30 min |
+| Surgery consult | 60 min |
+
+Lengths will probably change (we are talking about 20-minute consults). Each type has a price,
+and the price is different at each clinic.
+
+## What the new system has to do
+
+1. **A vet's day.** Reception pulls up every appointment for one vet on one date, in time
+   order. This is the screen that is open all day at every front desk and refreshes every few
+   seconds. It has to feel instant.
+2. **A clinic's day.** Same thing but for every vet working at one clinic that day.
+3. **Owner portal.** An owner logs in and sees the upcoming appointments for all of their pets.
+4. **Free slots.** Given a vet (or a clinic) and a date, what times are still open.
+5. **Monthly report.** No-show rate per clinic per month. The directors ask for this every
+   month and today somebody counts it by hand from the paper diary.
+6. **No double-booking a vet. Ever.** It happened 11 times last quarter. The current app checks
+   whether the slot is free and then inserts, and two receptionists at different desks can both
+   get through. If an appointment is cancelled, that time has to become bookable again.
+
+## Stack
+
+Database: Postgres 15 on the managed service (that is what the hosting invoice says).
+
+Pasted from Devraj (contractor who maintains the current app), 18 Sept:
+
+> the current booking app is on MySQL 8, has been since 2021. I'd just keep it there tbh,
+> no reason to move
+
+I have not chased up which of those is right.
+
+## Other
+
+- The existing tables are in current_tables.sql. I know they are not great.
+- Not in scope for this piece of work: invoicing and payments, stock, clinical records.

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

@@ -12,6 +12,35 @@
         "The rollout section names stages and what would halt it",
         "Facts not supplied by the user are marked as open questions rather than invented"
       ]
+    },
+    {
+      "id": 2,
+      "held_out": "2026-10-05",
+      "prompt": "Can you write the design doc for offline mode in the inspector app? Product's brief is brief.md and Halvard's notes from our eng discussion are eng-notes.md. It goes to design review on Thursday so it needs to stand on its own. Please include how much storage it needs per device too.",
+      "assertions": [
+        "It flags that the timeline does not work as written: 14 weeks from a 14 Dec 2026 start ends around 22 March 2027, after the 1 March 2027 Calder County deadline, and it proposes a way through or raises it as a decision",
+        "The size of the problem is given as 1,120 of 8,400 inspections (about 13%) with sync or save errors, or the brief's 'around 40%' is called out as unsupported by the logged numbers",
+        "It does not apply plain last-write-wins to signed inspections; it surfaces the conflict between the brief and the compliance rule that a signed inspection must never be overwritten",
+        "The server-side sync endpoint is shown as depending on the Platform team with no owner confirmed and nobody yet asked",
+        "Per-device storage need is stated as not yet measured, with no invented figure, and measuring it is listed as a to-do or open question",
+        "At least two of the alternatives from the notes (outbox queue, CRDT library, PDF re-keying) are described with the reason each was not chosen as the main approach",
+        "The rollout starts with the 12 Calder County volunteers and gives at least one concrete, checkable condition for widening or stopping it",
+        "It does not invent crash rates, backend load figures, costs or device counts that are not in the two files"
+      ]
+    },
+    {
+      "id": 3,
+      "held_out": "2026-10-05",
+      "prompt": "need a one-pager design doc by end of day for moving our cron jobs off the old box. there's like 30ish of them on a single ec2 instance (cron-01), some of them nobody knows what they do anymore. thinking either k8s cronjobs since we already have a cluster, or some managed scheduler. Jonas wants it done before the OS on that instance goes end of life but I don't remember the date. 4 of us on the team.",
+      "assertions": [
+        "It delivers a design doc in the reply rather than only asking questions",
+        "The OS end-of-life date is recorded as unknown and to be confirmed; no specific date is invented",
+        "The jobs nobody understands are dealt with explicitly, through an inventory or audit step or a named risk with a mitigation, not assumed to be understood",
+        "Both Kubernetes CronJobs and a managed scheduler are described, with a reason for preferring one or a statement of what would decide it",
+        "The job count stays approximate ('about 30'); it does not invent an exact count, job names, schedules or failure rates",
+        "It says how a migrated job is checked before its old cron entry is removed, and how to go back if it misbehaves",
+        "It is about one page: roughly 700 words or fewer"
+      ]
     }
   ]
 }

package/packs/solution-architect/skills/design-doc/evals/files/2/brief.md

@@ -0,0 +1,18 @@
+# Brief: offline mode for the Stonecrop inspector app
+
+From: Marguerite Adeyemi (Product), 28 Sept 2026
+
+## Why
+Inspectors lose work when they're in basements, plant rooms and rural sites with no signal. It's our number one support complaint. Around 40% of inspections are done with no signal, so this affects nearly half of what we do.
+
+## What I want
+- An inspector can open, fill in, photograph and sign an inspection with no connection, and it syncs by itself when they're back online.
+- Works for at least 72 hours offline (covers a long weekend on a remote site).
+- If two people edited the same inspection, last write wins. Keep it simple.
+- Android tablets first. iOS can follow.
+
+## Deadline
+Calder County's contract renewal is 1 March 2027 and they've said offline is a condition. It has to be live for them before that date.
+
+## Team
+Two mobile engineers (Ines and Kwabena) once they're free.

package/packs/solution-architect/skills/design-doc/evals/files/2/eng-notes.md

@@ -0,0 +1,30 @@
+# Eng notes: offline mode discussion, 1 Oct 2026
+
+Present: Ines Moreau, Kwabena Asante, Halvard Nystrom (eng lead). Notes: Halvard.
+
+## Numbers we pulled
+- Last quarter (Jul-Sep 2026): 8,400 inspections submitted. 1,120 of them had at least one failed save or sync error logged. We don't log "no signal" directly; this is the closest proxy we have.
+- 310 active inspectors. 64 of them are Calder County.
+- Support tickets tagged "lost work" last quarter: 187.
+- Device split: 71% Android tablets, 29% iPads.
+
+## Approaches we talked through
+1. Outbox queue. Keep the app as it is, but writes go to a local queue and replay when online. Smallest change. Doesn't let you open an inspection you haven't already loaded.
+2. Local-first replica. Sync each inspector's assigned inspections to an on-device database, work against that, background sync both ways. Covers the full ask. More work, and needs a conflict policy.
+3. CRDT-based sync library. Handles merges automatically. None of us has shipped one, and the library we looked at has no Kotlin bindings.
+4. Export to a PDF form and re-key later. Support suggested it. Nobody likes it; re-keying is where errors come from.
+
+Leaning towards 2.
+
+## Estimate
+- Option 2: 14 weeks for Ines + Kwabena, Android only. Option 1 alone would be about 5 weeks.
+- They can't start until the auth migration finishes, currently planned for 14 Dec 2026.
+- Needs a new server-side sync endpoint (delta pull + batched push). That's in Platform's codebase. Nobody from Platform was in this meeting and nobody has been asked yet.
+
+## Things that worry us
+- Compliance (Roisin, by email 30 Sept): "A signed inspection is a legal record. Once signed it must never be modified or overwritten, by anyone, including by sync. Countersigning by a supervisor is added as a separate record." Supervisors do open the same inspection as the inspector, usually the same day.
+- Photos are the bulk of the data. We haven't measured how much space 72 hours of inspections takes on a tablet.
+- No idea yet what the sync endpoint does to backend load.
+
+## Pilot idea
+Start with 12 Calder County inspectors who volunteered, then the rest of Calder, then everyone.

package/packs/solution-architect/skills/tech-comparison-matrix/evals/evals.json

@@ -13,6 +13,35 @@
         "The recommendation is one sentence and says what would change the answer; if it isn't the top scorer, the override is explained",
         "Numbers that are estimates are marked 'rough' or 'directional'; no benchmarks are invented beyond the figures in the prompt"
       ]
+    },
+    {
+      "id": 2,
+      "held_out": "2026-10-05",
+      "prompt": "We have to pick an observability platform by 16 Oct. requirements.md is what we need and vendor-notes.md is what Davide gathered on the three options. Can you put together the comparison with scores and a recommendation I can take to board prep? Please score query speed using the p95 numbers from the trials. For what it's worth most of the team wants Graywell.",
+      "assertions": [
+        "Graywell is shown as failing the EU data residency must-have today (US-East only, EU region only on the roadmap for Q2 2027) and is not the recommended option",
+        "It flags that the Lumenstack quote does not add up: EUR 18 x 140 hosts x 12 months is EUR 30,240, not the EUR 25,200 on the quote",
+        "It notes that at EUR 30,240 Lumenstack is over the EUR 30,000 budget cap, or that whether it fits depends on getting the quote clarified",
+        "Self-hosted is shown as having no measured p95 query time because it was never trialled; no latency number is invented for it",
+        "The self-hosted assessment names the staffing risk: the team drops from 3 to 2 at the end of November and the person leaving is the only one who has run Loki in production",
+        "It notes that Graywell's EUR 18,480 is not an all-in or firm price: SAML SSO is Enterprise-tier with price on request, or the figure comes from a March sales deck and not a quote",
+        "It gives one clear recommendation and says what would change it",
+        "It does not introduce benchmarks, prices or vendor features that are not in the two files"
+      ]
+    },
+    {
+      "id": 3,
+      "held_out": "2026-10-05",
+      "prompt": "postgres vs mongo vs just sqlite for a small internal tool? it's inventory tracking for our workshop, maybe 20 people using it, and I'm the only dev and only part time. my boss wants a table he can show the owner so he can see we thought about it",
+      "assertions": [
+        "All three options (PostgreSQL, MongoDB, SQLite) are compared in one table against the same named criteria, each with a score or rating",
+        "The relative importance of the criteria is shown and tied to the facts given (about 20 users, one part-time developer)",
+        "Each score or rating has a short reason next to it",
+        "It gives one clear recommendation, not 'it depends'",
+        "It states the assumptions it had to make and what would change the answer (for example how many people write at the same time, where it is hosted, how backups are handled)",
+        "It does not invent benchmark figures, throughput numbers or costs",
+        "Large-scale performance, horizontal scaling or community popularity is not among the highest-weighted criteria"
+      ]
     }
   ]
 }

package/packs/solution-architect/skills/tech-comparison-matrix/evals/files/2/requirements.md

@@ -0,0 +1,20 @@
+# Observability platform: what we need (Pellingham Diagnostics)
+
+Written by Anneke Vos (Head of Platform), 21 Sept 2026.
+
+We're replacing the home-grown ELK box. Decision needed for the 16 Oct board prep.
+
+## Facts
+- 140 hosts today (112 prod, 28 non-prod). Expect about 160 by the end of 2027.
+- Platform team: 3 engineers. One (Bashir) leaves at the end of November and the backfill is not approved.
+- Log volume is about 90 GB/day. We need 30 days searchable.
+
+## Must-haves (not negotiable)
+1. All telemetry stored and processed in the EU. Logs contain patient sample IDs. Our DPO has confirmed this is a hard requirement from day one: no exceptions and no "coming soon".
+2. Total cost at or under EUR 30,000 per year, all-in. That is what's in the 2027 budget.
+3. SSO through our existing SAML identity provider.
+
+## Nice-to-haves
+- Fast log search. Devs complain the current one takes 20+ seconds.
+- Alert routing into our pager.
+- Not having to babysit it.

package/packs/solution-architect/skills/tech-comparison-matrix/evals/files/2/vendor-notes.md

@@ -0,0 +1,29 @@
+# Options: notes from trials and quotes
+
+Compiled by Davide Marchetti, platform. Last touched 29 Sept 2026.
+
+## A. Lumenstack (SaaS)
+- Quote ref LS-Q-7731, dated 22 Sept 2026, valid 30 days.
+- EUR 18 per host per month. Logs, metrics and traces bundled, 30-day retention included.
+- Quote summary line: "140 hosts, 12 months: EUR 25,200".
+- Region: Frankfurt, available now. Signed DPA available.
+- SAML SSO: included.
+- Two-week trial on 20 staging hosts: p95 log query 1.8 s. Pager integration worked out of the box.
+- Setup effort in the trial: about 2 days for one engineer.
+
+## B. Graywell (SaaS)
+- Pricing from their sales deck of 3 March 2026: EUR 11 per host per month, 12-month commit. No formal quote yet.
+- 140 hosts x 11 x 12 = EUR 18,480.
+- Region: US-East only today. Sales rep email (18 Sept): "EU region is on the roadmap for Q2 2027."
+- SAML SSO: on the Enterprise tier only, price on request.
+- Two-week trial on 20 staging hosts: p95 log query 0.9 s. Nicest UI by far, devs loved it.
+- Pager integration: via webhook, needed a small script.
+
+## C. Self-hosted (Grafana + Loki + Prometheus on our own cluster)
+- No licence cost.
+- Davide's estimate of extra infra: EUR 800/month (storage + 3 nodes), so EUR 9,600/year.
+- Davide's estimate of people time: 0.4 of an engineer ongoing, plus 4-6 weeks to build.
+- Runs in our Amsterdam region, so EU by construction.
+- SAML: supported through our identity provider, needs config.
+- Not trialled. We never stood it up, so there are no query numbers.
+- Bashir is the only one of us who has run Loki in production before.

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

@@ -12,6 +12,36 @@
         "Contributing factors are listed rather than a single root cause",
         "Action items carry owners as roles and are derived from the contributing factors"
       ]
+    },
+    {
+      "id": 2,
+      "held_out": "2026-10-05",
+      "prompt": "I need the postmortem for the 17 Sept label printing outage (INC-2291) for Monday's incident review. The pager export is pager-export.txt and I dumped the incident channel into slack-thread.txt. Please include what we owe merchants in SLA credits. It goes to the whole engineering org.",
+      "assertions": [
+        "The customer-facing outage is given as 94 minutes (07:12 to 08:46 UTC, or 09:12 to 10:46 CEST), not 75 minutes or 2 hours, or those other figures are explicitly reconciled against it",
+        "Times from the Slack thread (CEST) and the pager export (UTC) are put on one consistent clock, so the first support ticket (07:20 UTC / 09:20 CEST) appears before the page (07:31 UTC / 09:31 CEST)",
+        "It states that the page fired about 19 minutes after errors began and that customer tickets arrived before any alert did",
+        "The 06:55 UTC (08:55 CEST) deploy is not given as the cause; the output says the rollback to v411 had no effect and the cause was the expired rates-gateway certificate",
+        "No named individual or their team is blamed for the expired certificate; the unowned service, the renewal job failing since 27 Aug and the muted #infra-noise alerts are given as causes instead",
+        "Impact uses the measured 18,430 failed of 21,900 label requests and 212 merchant accounts, and the 'roughly 40k shipments' figure is not presented as measured",
+        "The SLA credit amount is stated as unknown because the contract terms are not in the material, and no figure is invented",
+        "The follow-up to fix the renewal job is shown as having no agreed owner or date, and the output notes the manually issued certificate expires in about 90 days (mid-December 2026)"
+      ]
+    },
+    {
+      "id": 3,
+      "held_out": "2026-10-05",
+      "prompt": "can you write up a postmortem for our backup thing. we're 5 people so nothing fancy but I want it on record. nightly db backup hadn't actually run for about 9 days, we only found out Fri 2 Oct when Lena tried to restore a copy into staging and the newest dump was old. no customer impact as far as we know. what we worked out: disk on the cron host has been full since ~Sep 23, the backup script exits 0 even when the dump fails, and nobody gets alerted on anything from that box. fixed by clearing out /var/log and re-running, good backup as of Fri 14:10.",
+      "assertions": [
+        "It states there was no known customer impact and does not invent downtime, users affected or data lost",
+        "It states the exposure plainly: roughly 9 days (about 23 Sep to 2 Oct) with no valid backup, meaning a database failure in that window would have lost up to that much data",
+        "The full disk, the script exiting 0 on failure, and the absence of alerting are given as separate contributing causes, not collapsed into one root cause",
+        "It says the problem was found by chance during a staging restore, not by monitoring",
+        "It marks as unknown or approximate the exact time backups stopped and what filled the disk, and does not invent a minute-by-minute timeline",
+        "Action items cover at least the exit-code behaviour and alerting on backup failure or staleness, each written so someone can check it is done",
+        "It does not blame Lena or any individual",
+        "It delivers the postmortem in the reply rather than only asking questions"
+      ]
     }
   ]
 }

package/packs/sre-oncall/skills/postmortem-generator/evals/files/2/pager-export.txt

@@ -0,0 +1,22 @@
+PagerTree export. Service: labelgen-prod. Incident INC-2291.
+All timestamps UTC. Exported 2026-09-18 09:02 UTC.
+
+2026-09-17 07:31:04  TRIGGERED     alert "labelgen 5xx ratio > 25% for 15m" (source: metrics)
+2026-09-17 07:31:05  NOTIFIED      primary on-call (push + SMS)
+2026-09-17 07:36:05  NOTIFIED      primary on-call (phone call, 2nd attempt)
+2026-09-17 07:38:41  ACKNOWLEDGED  by primary on-call
+2026-09-17 07:44:10  NOTE          "suspect 06:55 deploy of labelgen v412, rolling back"
+2026-09-17 07:52:27  NOTE          "rollback to v411 complete. error rate unchanged."
+2026-09-17 08:03:50  ESCALATED     to secondary on-call (platform)
+2026-09-17 08:05:12  ACKNOWLEDGED  by secondary on-call
+2026-09-17 08:21:33  NOTE          "rates-gateway returning TLS handshake failure. cert expired 2026-09-17 07:11:58Z"
+2026-09-17 08:40:15  NOTE          "cert reissued manually, rates-gateway pods restarting"
+2026-09-17 08:46:02  NOTE          "5xx back under 1%. monitoring."
+2026-09-17 09:20:00  RESOLVED
+
+Metrics snapshot attached to the incident (dashboard "labelgen overview"):
+  first minute with 5xx ratio > 5%:      07:12
+  last minute with 5xx ratio > 5%:       08:46
+  label requests received 07:12-08:46:   21,900
+  label requests failed (5xx):           18,430
+  merchant accounts with >= 1 failure:   212

package/packs/sre-oncall/skills/postmortem-generator/evals/files/2/slack-thread.txt

@@ -0,0 +1,28 @@
+#inc-2291-labels, export for Thursday 17 Sept 2026
+(times as shown in Slack: Amsterdam time, CEST)
+
+09:20 Odile Renner (support lead): getting tickets that label printing is failing, 3 merchants in the last few min. anyone looking?
+09:24 Odile Renner: up to 9 tickets now
+09:33 Marek Dvorsky (on-call): just got paged, was on the school run, looking in 5
+09:39 Marek Dvorsky: acked. errors started right after my 8:55 deploy I think. rolling back
+09:53 Marek Dvorsky: rollback done.... still broken. so not the deploy??
+09:55 Tobias Lindqvist (eng manager): Marek's deploy is the only thing that changed this morning, it has to be that. did the rollback actually take?
+09:58 Marek Dvorsky: yes v411 is live on all pods. same errors. "upstream connect error" from rates-gateway
+10:04 Marek Dvorsky: escalating to platform
+10:06 Yusra Haddad (platform): here
+10:22 Yusra Haddad: found it. rates-gateway internal cert expired at 09:11 this morning. cert-manager renewal has been failing since 27 Aug, DNS challenge error after the zone move
+10:23 Tobias Lindqvist: how did nobody see that for 3 weeks
+10:25 Yusra Haddad: renewal failure alerts go to #infra-noise. that channel's been muted by basically everyone since the spring
+10:26 Tobias Lindqvist: so Marek's team forgot to renew a cert. great
+10:27 Yusra Haddad: it's not really anyone's cert. rates-gateway got moved to platform in the June reorg and never got an owner in the service catalog
+10:41 Yusra Haddad: issued a cert by hand, pods restarting
+10:47 Marek Dvorsky: error rate back to normal
+10:52 Odile Renner: 61 tickets total. I'm telling merchants roughly 40k shipments were affected, ok?
+10:55 Tobias Lindqvist: fine. outage was about 75 min for the status page
+11:02 Odile Renner: several merchants are saying 2 hours on their side fwiw
+11:20 Marek Dvorsky: resolving the page
+11:31 Yusra Haddad: follow ups: (1) I'll move cert renewal failures out of #infra-noise into the platform pager by Fri 25 Sept (2) someone needs to fix the renewal job itself, the DNS challenge is still broken and the manual cert is only good for 90 days (3) rates-gateway needs an owner in the catalog
+11:34 Tobias Lindqvist: (4) labelgen should fall back to cached rates when the gateway is down. Marek can you scope that
+11:35 Marek Dvorsky: will scope it, no date yet
+11:40 Odile Renner: finance asked what we owe in SLA credits. I don't have the contract terms, does anyone?
+11:41 Tobias Lindqvist: no idea. ask legal

package/packs/stakeholder-comms/skills/guide-builder/evals/evals.json

@@ -13,6 +13,35 @@
         "No forward references that break top-to-bottom reading",
         "Missing facts (e.g. the repo URL host or how to get a Stripe test key) are flagged as NEEDS INPUT rather than invented"
       ]
+    },
+    {
+      "id": 2,
+      "held_out": "2026-10-05",
+      "prompt": "Mirela dumped her notes on our partner API in api-notes.md and there's a sample response in sample-booking.json. Can you turn that into proper reference docs we can send to the partner devs who are integrating with us? Make sure the cancellation webhook is covered too, a couple of partners have asked about it.",
+      "assertions": [
+        "The rate limit is given as 60 requests per minute per key, following the changelog entry, and 120 is not presented as the current limit",
+        "It flags that the notes say money is integer cents in fields ending _cents while the sample response has decimal strings in unit_price and total, and does not silently document only one of them",
+        "It does not name the API key header (for example X-API-Key or Authorization: Bearer) as fact, and says the header name is not in the notes",
+        "It says the notes describe no cancellation webhook, only booking.confirmed, and does not document a cancellation event or payload",
+        "POST /bookings documents the required Idempotency-Key header and that reusing a key within 24 hours returns the original booking",
+        "The error responses in the notes are documented with their bodies: 409 slot_full with available, 422 validation_error, 429 with Retry-After, and 409 cancellation_window_closed",
+        "The POST /bookings body lists each field as required or optional, including quantity 1 to 8 and partner_ref up to 64 characters",
+        "The webhook section states the HMAC-SHA256 signature over the raw body in X-Tidewater-Signature and the 5 retries over about an hour"
+      ]
+    },
+    {
+      "id": 3,
+      "held_out": "2026-10-05",
+      "prompt": "can you write up how our nightly export works for the new analyst starting monday? roughly: cron on the reporting box kicks off export.py at 2am, it pulls yesterday's orders from the replica, writes a csv to the sftp drop, and finance's tool picks it up at like 6. if it fails Theo gets an email. there's a retry thing in there somewhere but i honestly don't remember how it works",
+      "assertions": [
+        "It delivers a written explanation of the export for the analyst, and does not stop at questions",
+        "It describes the flow in order: cron at 2am runs export.py, which reads yesterday's orders from the replica, writes a CSV to the SFTP drop, and finance's tool collects it",
+        "It says how the retry works is not known and needs confirming, and does not state a retry count, delay or backoff",
+        "It does not invent hostnames, file paths, an SFTP directory, table names, CSV columns or a CSV filename",
+        "It says Theo is emailed when the export fails, and does not add an email address, a surname or other contacts",
+        "The finance pickup is given as around 6, not as an exact confirmed time",
+        "It includes no commands for running, restarting or debugging the export, since none were supplied"
+      ]
     }
   ]
 }

package/packs/stakeholder-comms/skills/guide-builder/evals/files/2/api-notes.md

@@ -0,0 +1,44 @@
+# partner API notes (Mirela — for whoever writes the real docs)
+
+base url: https://api.tidewater-rentals.example/v2
+auth: api key in a header, one key per partner. keys come from partner support (partners@tidewater-rentals.example)
+all times are UTC, ISO 8601. money is integer cents, field names end in _cents.
+rate limit: 120 req/min per key. over that -> 429 with a Retry-After header (seconds).
+
+## GET /locations
+list of rental locations. no params.
+returns array of { id (string, "loc_..."), name (string), timezone (string, IANA name) }
+
+## GET /slots
+query params:
+- location_id — required
+- date — required, YYYY-MM-DD, in the location's local timezone
+- item_type — optional, one of kayak | paddleboard | canoe. leave it off to get all three
+returns array of { slot_id (string), starts_at, ends_at, item_type, available (int, how many are left) }
+only the next 30 days are bookable. a date further out -> 422.
+
+## POST /bookings
+needs an Idempotency-Key header (any uuid). same key again within 24h returns the original booking, it does not make a second one.
+body:
+- slot_id — required
+- quantity — required, 1 to 8
+- customer — required object: name (required), email (required), phone (optional)
+- partner_ref — optional, string, max 64 chars, the partner's own order id. we echo it back.
+responses:
+- 201 -> the booking object, see sample-booking.json. status starts as pending_payment.
+- 409 slot_full -> not enough left in the slot. body { "error": "slot_full", "available": <int> }
+- 422 validation_error -> body { "error": "validation_error", "fields": { "<field>": "<reason>" } }
+
+## DELETE /bookings/{id}
+cancels a booking. 204, no body.
+free up to 48h before starts_at. after that -> 409, body { "error": "cancellation_window_closed" }
+
+## webhook
+we POST a booking.confirmed event to the partner's url once payment clears (usually seconds, can be a few minutes).
+payload: { event, booking_id, partner_ref, occurred_at }
+signed: HMAC-SHA256 of the raw request body, hex, in the X-Tidewater-Signature header. the secret is per partner.
+retries: 5 attempts over about an hour, then we stop.
+
+## changelog
+- 2026-08-11 rate limit dropped to 60/min per key after the August incident. (haven't fixed the top of this doc yet)
+- 2026-05-02 added partner_ref to POST /bookings and to the webhook payload

package/packs/stakeholder-comms/skills/guide-builder/evals/files/2/sample-booking.json

@@ -0,0 +1,19 @@
+{
+  "id": "bkg_7Hq2Lm",
+  "status": "pending_payment",
+  "slot_id": "slt_44190",
+  "item_type": "kayak",
+  "quantity": 2,
+  "unit_price": "32.00",
+  "total": "64.00",
+  "currency": "USD",
+  "customer": {
+    "name": "Odalys Brennan",
+    "email": "odalys.brennan@example.com",
+    "phone": null
+  },
+  "partner_ref": "ORD-10492",
+  "starts_at": "2026-11-14T15:00:00Z",
+  "ends_at": "2026-11-14T17:00:00Z",
+  "created_at": "2026-11-02T09:41:07Z"
+}

package/profiles.json

@@ -16,9 +16,9 @@
     },
     "full": {
       "description": "The complete catalogue: every pack, every reviewer agent, every loop.",
-      "packs": ["core", "solution-architect", "product-manager", "dev-team", "sre-oncall", "stakeholder-comms", "design", "ai-engineering", "api-builder", "converters", "experience-design", "research", "trackers", "data-analytics", "grc", "infra-as-code", "skill-engineering"],
+      "packs": ["core", "solution-architect", "product-manager", "dev-team", "sre-oncall", "stakeholder-comms", "design", "ai-engineering", "api-builder", "converters", "experience-design", "research", "trackers", "data-analytics", "grc", "infra-as-code", "skill-engineering", "career"],
       "agents": ["devils-advocate", "security-reviewer", "code-quality"],
-      "loops": ["discover", "design", "build", "release", "operate", "ship-a-draft"]
+      "loops": ["discover", "design", "build", "release", "operate", "ship-a-draft", "apply"]
     }
   }
 }