skilldrop-cli 0.16.5 → 0.16.7

package/packs/dev-team/skills/devils-advocate/evals/files/2/test_signups.py

@@ -0,0 +1,69 @@
+import sqlite3
+from datetime import datetime, timedelta
+
+import pytest
+
+from signups import (NotSignedUp, ShiftFull, TooLateToCancel, cancel, init_db,
+                     roster, sign_up)
+
+
+@pytest.fixture
+def conn():
+    c = sqlite3.connect(":memory:")
+    init_db(c)
+    # shift 1: next week, room for 2.  shift 2: starts in two hours, room for 2.
+    c.execute(
+        "INSERT INTO shifts (id, starts_at, capacity) VALUES (1, ?, 2)",
+        ((datetime.now() + timedelta(days=7)).isoformat(),),
+    )
+    c.execute(
+        "INSERT INTO shifts (id, starts_at, capacity) VALUES (2, ?, 2)",
+        ((datetime.now() + timedelta(hours=2)).isoformat(),),
+    )
+    c.commit()
+    return c
+
+
+def test_sign_up_confirms(conn):
+    assert sign_up(conn, 1, 101) == "confirmed"
+    assert roster(conn, 1) == [101]
+
+
+def test_unknown_shift(conn):
+    with pytest.raises(KeyError):
+        sign_up(conn, 99, 101)
+
+
+def test_waitlist_when_full(conn):
+    sign_up(conn, 1, 101)
+    sign_up(conn, 1, 102)
+    sign_up(conn, 1, 103)
+    assert sign_up(conn, 1, 104) == "waitlisted"
+
+
+def test_no_waitlist_raises(conn):
+    for volunteer in (101, 102, 103):
+        sign_up(conn, 1, volunteer)
+    try:
+        sign_up(conn, 1, 104, allow_waitlist=False)
+    except ShiftFull:
+        pass
+
+
+def test_cancel_promotes_waitlist(conn):
+    for volunteer in (101, 102, 103, 104):
+        sign_up(conn, 1, volunteer)
+    cancel(conn, 1, 101)
+    assert 104 in roster(conn, 1)
+    assert 101 not in roster(conn, 1)
+
+
+def test_cancel_too_late(conn):
+    sign_up(conn, 2, 101)
+    with pytest.raises(TooLateToCancel):
+        cancel(conn, 2, 101)
+
+
+def test_cancel_not_signed_up(conn):
+    with pytest.raises(NotSignedUp):
+        cancel(conn, 1, 555)

package/packs/dev-team/skills/devils-advocate/manifest.json

@@ -1,6 +1,6 @@
 {
   "name": "devils-advocate",
-  "version": "0.1.1",
+  "version": "0.1.2",
   "description": "Adversarial review of just-generated code, run *after* an agent (or human) declares a feature done. Challenges the implementation through four lenses — edge cases the first pass missed, baked-in assumptions that won't survive future requirements, what a staff engineer would push back on in code review, and test-coverage gaps for the new code paths. Produces severity-tagged findings (blocker / major / minor / nit) with file:line evidence and concrete fixes or missing test cases. Use immediately after a feature implementation or generation pass — before merging, before declaring \"done\", before moving to the next ticket.",
   "entrypoint": "SKILL.md",
   "deps": { "npm": [], "pip": [] },

package/packs/dev-team/skills/pre-merge-review/SKILL.md

@@ -11,6 +11,14 @@ Two gates, and they are different kinds. The mechanical gate is **not a judgment
 
 ## How to respond
 
+**Four rules come before the steps and outrank them:**
+
+- **Answer what was asked, first.** Open with the answer, the decision or the artifact, in plain words. Scores, matrices, frameworks and tags come after it, and anything that doesn't change the answer is cut.
+- **Use only what you were given.** Don't add facts, names, numbers, incidents, history, steps or sections the input doesn't contain. What you need and don't have is left out of the artifact and listed once at the end under "To confirm".
+- **Deliver from what you have.** When the request gives you something to work on, state your assumptions in a line and produce the result. When it gives you nothing to work on, ask for it in one or two plain sentences and say what you will do once you have it.
+- **Write for someone who has never heard of this skill.** No skill names, no paths or scripts from this folder, no internal terms, and nothing about how the run was set up. A next step is one plain sentence at the end that describes the work.
+- **For this skill:** With no repository or diff to review, say so in a sentence, ask where the change is, and mention any risk already visible in what the user wrote. Don't announce a verdict for code you haven't seen.
+
 1. **Scope the change.** The diff, the branch vs. its base, or the files the user names. Everything below reviews *that change*, never the whole repo.
 
 2. **Run the mechanical gate first — it is un-bypassable.** Run the bundled gate script:

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

@@ -1,6 +1,6 @@
 {
   "name": "pre-merge-review",
-  "version": "0.1.2",
+  "version": "0.1.3",
   "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": [] },

package/packs/dev-team/skills/release-notes/SKILL.md

@@ -9,6 +9,14 @@ Converts commit history into two artifacts with different readers: **customer-fa
 
 ## How to respond
 
+**Four rules come before the steps and outrank them:**
+
+- **Answer what was asked, first.** Open with the answer, the decision or the artifact, in plain words. Scores, matrices, frameworks and tags come after it, and anything that doesn't change the answer is cut.
+- **Use only what you were given.** Don't add facts, names, numbers, incidents, history, steps or sections the input doesn't contain. What you need and don't have is left out of the artifact and listed once at the end under "To confirm".
+- **Deliver from what you have.** When the request gives you something to work on, state your assumptions in a line and produce the result. When it gives you nothing to work on, ask for it in one or two plain sentences and say what you will do once you have it.
+- **Write for someone who has never heard of this skill.** No skill names, no paths or scripts from this folder, no internal terms, and nothing about how the run was set up. A next step is one plain sentence at the end that describes the work.
+- **For this skill:** Write one set of notes for the audience the user named. Add the second, internal version only when they ask for both. Use the product's name only if they gave it, and count commits and pull requests from the list in front of you.
+
 1. **Resolve the range.** Default: last tag to HEAD (`git describe --tags --abbrev=0`). If no tags exist, ask for a start ref or take the user's two refs. State the resolved range at the top of the output: "`v1.4.0..HEAD`, 37 commits, 2026-05-02 → 2026-06-10".
 
 2. **Gather the raw material.** `git log <range> --no-merges --pretty='%h|%s|%an|%ad' --date=short` for the commit list; `git log <range> --stat` only when a subject line is too vague to classify. Where the `gh` CLI is available and the repo uses PRs, prefer PR titles over commit subjects (`gh pr list --state merged --search "merged:>={date}"`) — they're written closer to reader language. Don't require `gh`; commits alone are enough.

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

@@ -14,6 +14,35 @@
         "No marketing adjectives; the performance line states the measured change (~3x faster export) rather than 'blazing fast'",
         "Does not invent features or fixes not present in the log"
       ]
+    },
+    {
+      "id": 2,
+      "held_out": "2026-10-05",
+      "prompt": "We're cutting 3.2.0 of Tidewater Booking tomorrow. The log since 3.1.0 is in commits.txt. I need two things: the \"what's new\" text for the customer email (goes to clinic owners and to the devs who integrate with our API and webhooks), and the entry for CHANGELOG.md in the repo. Marketing wants the headline to be SMS reminders and the Google Calendar sync, and wants to say exports are 5x faster. We're a hosted service, nobody runs our code themselves.",
+      "assertions": [
+        "Google Calendar sync is not announced as shipping in 3.2.0; the output says it was reverted (commit a4e8b60 / #225) and is not in this release",
+        "The export speed-up is given as 41s to 14s for 50k bookings, or roughly 3x, and the requested '5x faster' claim is not used or is called out as unsupported by the log",
+        "The webhook field rename (start/end to starts_at/ends_at in booking payloads) is called out as a breaking change that integrators must act on, even though its commit is labelled refactor",
+        "The removal of X-Tidewater-Key header auth is called out as breaking with the instruction to switch to Bearer tokens, and breaking changes appear before the new features",
+        "The 'wip' (3b7c5e2) and 'more fixes' (71f9d3b) commits are flagged as unclear and needing someone to check, not described as specific features or fixes",
+        "The duplicate-calendar-events fix (#218) is not listed as a fix customers receive, because it was reverted along with the sync",
+        "The customer email text does not mention the twilio or vite bumps, the BookingRepo rename, CI changes or the Node 20 server requirement",
+        "Each line of the CHANGELOG entry carries a commit hash or PR number from the log"
+      ]
+    },
+    {
+      "id": 3,
+      "held_out": "2026-10-05",
+      "prompt": "need release notes for pressroom (our static site CLI, the people using it are our clients' developers), going out as 0.9.0 today. this is what's gone in since 0.8.2, half from git log --oneline and half from memory, sorry:\n\nd41c0aa add --watch flag\n77e2b19 fix crash on empty frontmatter\nbump deps\n3a9f6c1 config: `output_dir` now `outDir` (old key ignored)\nc08e512 misc cleanup\n9b1d7e4 faster builds\n\nalso Priya fixed something with image paths on windows, I don't have the commit",
+      "assertions": [
+        "The output_dir to outDir config change is flagged as breaking, with the action to rename the key in existing config files because the old key is now ignored",
+        "'Faster builds' is reported without any invented figure or percentage, and the output says the size of the speed-up is not known",
+        "The Windows image-path fix is included only as far as described and marked as unconfirmed or missing its commit; no specific bug behaviour is invented for it",
+        "'misc cleanup' (c08e512) and 'bump deps' are not turned into user-facing claims",
+        "The --watch flag and the empty-frontmatter crash fix both appear as user-facing items",
+        "It does not invent dates, PR numbers, a commit count for commits it was not shown, or features not in the pasted list",
+        "It delivers usable release notes in the reply rather than only asking questions, and lists the items that need confirming before sending"
+      ]
     }
   ]
 }

package/packs/dev-team/skills/release-notes/evals/files/2/commits.txt

@@ -0,0 +1,35 @@
+# git log v3.1.0..release/3.2.0 --reverse --date=short --format='%h|%ad|%an|%s'
+# repo: tidewater-booking (hosted service: API + embeddable booking widget)
+4c1e9a2|2026-06-09|Imani Okafor|feat(reminders): send SMS reminders before a booking (#201)
+7b03f1d|2026-06-10|Imani Okafor|test: reminder scheduler unit tests
+1e8d4c6|2026-06-11|Imani Okafor|fix(reminders): don't send SMS for cancelled bookings (#204)
+a93b2e0|2026-06-12|Tomasz Wrobel|chore(deps): bump twilio 5.0.4 -> 5.2.1
+5f6a7d1|2026-06-15|Ruben Halvorsen|feat(calendar): two-way Google Calendar sync (#207)
+c2d91b8|2026-06-16|Tomasz Wrobel|ci: cache pnpm store
+9e4f0a3|2026-06-17|Dee Castellanos|fix(widget): date picker showed the wrong day for customers west of UTC (#209)
+3b7c5e2|2026-06-18|Ruben Halvorsen|wip
+d0a6e48|2026-06-19|Dee Castellanos|feat(widget): let customers reschedule from the confirmation email (#211)
+6a2f9c7|2026-06-22|Tomasz Wrobel|refactor(webhooks): rename `start`/`end` to `starts_at`/`ends_at` in booking.* payloads (#214)
+f18b3d5|2026-06-23|Tomasz Wrobel|docs: update webhook payload examples
+2c9e7a4|2026-06-24|Imani Okafor|perf(export): stream CSV export; 50k bookings 41s -> 14s (#216)
+b5d0c19|2026-06-25|Ruben Halvorsen|fix(calendar): duplicate events when a booking is edited twice (#218)
+8e3a1f6|2026-06-26|Tomasz Wrobel|chore: rename internal BookingRepo -> BookingStore
+0d7b4c2|2026-06-29|Imani Okafor|fix(auth): staff sessions stayed logged in after a password change (#220)
+e6c2a95|2026-06-30|Imani Okafor|feat(reminders): per-location reminder lead time setting, default 24h (#222)
+71f9d3b|2026-07-01|Ruben Halvorsen|more fixes
+a4e8b60|2026-07-02|Ruben Halvorsen|Revert "feat(calendar): two-way Google Calendar sync (#207)" (#225)
+    Reverts 5f6a7d1. Google has not approved our OAuth verification yet. Re-land in 3.3.
+3f5c8d7|2026-07-02|Ruben Halvorsen|Revert "fix(calendar): duplicate events when a booking is edited twice (#218)" (#225)
+    Reverts b5d0c19. Depends on the sync code removed in a4e8b60.
+c9a1e04|2026-07-03|Tomasz Wrobel|chore(deps): bump vite 5.2 -> 5.3
+5b2d7f9|2026-07-06|Dee Castellanos|fix(widget): "Book" button unresponsive on iOS Safari 16 (#227)
+1a6e3c8|2026-07-07|Tomasz Wrobel|feat(api): GET /v2/bookings accepts a `location_id` filter (#229)
+d8f4b21|2026-07-08|Tomasz Wrobel|chore(node): require Node 20 on our servers; drop Node 18 from CI (#230)
+9c0e5a7|2026-07-09|Imani Okafor|fix(reminders): reminders went out an hour early after the clocks changed (#232)
+4e7a2d0|2026-07-10|Dee Castellanos|test: e2e for reschedule flow
+b1c6f83|2026-07-13|Imani Okafor|fix(export): CSV export dropped the notes column (#234)
+6d9b0e5|2026-07-14|Tomasz Wrobel|feat(api)!: remove deprecated `X-Tidewater-Key` header auth; use Bearer tokens (#236)
+2f8c4a1|2026-07-15|Dee Castellanos|docs: changelog housekeeping
+e0b7d36|2026-07-16|Dee Castellanos|style: prettier
+7a3e9c2|2026-07-17|Dee Castellanos|fix: typo in reschedule email subject
+0c5d8b4|2026-07-20|Tomasz Wrobel|ci: bump runner image

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

@@ -1,6 +1,6 @@
 {
   "name": "release-notes",
-  "version": "0.1.1",
+  "version": "0.1.2",
   "description": "Turn git history between two refs into release notes — a customer-facing version written in reader benefits and an internal Keep-a-Changelog version with commit traceability, breaking changes always first. Use when the user wants release notes, a changelog, \"what's in this release\", a deploy announcement, or to summarize changes since the last tag.",
   "entrypoint": "SKILL.md",
   "deps": { "npm": [], "pip": [] },

package/packs/product-manager/skills/prfaq/SKILL.md

@@ -9,6 +9,14 @@ The working-backwards forcing function: write the launch press release *before*
 
 ## How to respond
 
+**Four rules come before the steps and outrank them:**
+
+- **Answer what was asked, first.** Open with the answer, the decision or the artifact, in plain words. Scores, matrices, frameworks and tags come after it, and anything that doesn't change the answer is cut.
+- **Use only what you were given.** Don't add facts, names, numbers, incidents, history, steps or sections the input doesn't contain. What you need and don't have is left out of the artifact and listed once at the end under "To confirm".
+- **Deliver from what you have.** When the request gives you something to work on, state your assumptions in a line and produce the result. When it gives you nothing to work on, ask for it in one or two plain sentences and say what you will do once you have it.
+- **Write for someone who has never heard of this skill.** No skill names, no paths or scripts from this folder, no internal terms, and nothing about how the run was set up. A next step is one plain sentence at the end that describes the work.
+- **For this skill:** Put the full PR/FAQ in the reply. A quote is attributed to a role ("an operations lead at a mid-size clinic"), never to an invented name, and the author line uses only what the user gave.
+
 1. **Pin the three anchors** — customer, problem, differentiator. Ask at most 2 questions, spent on the weakest anchors: *"Who exactly is the customer, and what do they do today instead?"* and *"What does this do that the thing they use today doesn't?"* A PRFAQ for "everyone" with a problem stated in industry jargon produces a marketing document, not a forcing function — don't start drafting until all three anchors are concrete. Non-interactive run (no user to ask): derive missing anchors from the input where defensible and tag them `[assumption]` at the top; an anchor with no defensible derivation → emit `BLOCKED: need <anchor>` naming what to rerun with, instead of fabricating a customer.
 
 2. **Write the press release** — one page, datelined with a city and a realistic launch date; no product name exists yet → invent a plausible working name and mark it as a placeholder. The blocks:

package/packs/product-manager/skills/prfaq/manifest.json

@@ -1,6 +1,6 @@
 {
   "name": "prfaq",
-  "version": "0.1.1",
+  "version": "0.1.2",
   "description": "Write an Amazon-style PR/FAQ — the launch press release for a product that doesn't exist yet, plus the customer FAQ and internal FAQ that force the hard questions before engineering starts. Use when the user wants a PRFAQ, a working-backwards document, a \"write the press release first\" exercise, or needs to align stakeholders on what a product must be before committing a team to build it.",
   "entrypoint": "SKILL.md",
   "deps": { "npm": [], "pip": [] },

package/packs/product-manager/skills/strategy-analysis/SKILL.md

@@ -9,6 +9,14 @@ Runs the classic strategy frameworks the way a good strategist does and a bad de
 
 ## How to respond
 
+**Four rules come before the steps and outrank them:**
+
+- **Answer what was asked, first.** Open with the answer, the decision or the artifact, in plain words. Scores, matrices, frameworks and tags come after it, and anything that doesn't change the answer is cut.
+- **Use only what you were given.** Don't add facts, names, numbers, incidents, history, steps or sections the input doesn't contain. What you need and don't have is left out of the artifact and listed once at the end under "To confirm".
+- **Deliver from what you have.** When the request gives you something to work on, state your assumptions in a line and produce the result. When it gives you nothing to work on, ask for it in one or two plain sentences and say what you will do once you have it.
+- **Write for someone who has never heard of this skill.** No skill names, no paths or scripts from this folder, no internal terms, and nothing about how the run was set up. A next step is one plain sentence at the end that describes the work.
+- **For this skill:** Today's date matters: a recommended window or deadline must be in the future. Analyse the market the user named, not a neighbouring one.
+
 1. **Classify the question, then pick ONE framework** (two only when the question genuinely spans both, and say why):
 
    | The question is about… | Framework |
@@ -17,7 +25,7 @@ Runs the classic strategy frameworks the way a good strategist does and a bad de
    | Industry attractiveness / profit pressure: "should we enter", "why are margins thin", "can we defend" | **Porter's Five Forces** |
    | Macro environment: regulation, technology shifts, demographics affecting a multi-year bet | **PESTLE** |
 
-   The user asked for a framework by name and it fits → run it. It doesn't fit → say so in one line and run the fitting framework instead — the quality bar treats a misfit framework as a category error, and a "SWOT" request that's really "should we enter this market" is Five Forces work; then give the framework they asked for as well, after it and shorter (a SWOT still arrives as TOWS). They asked for it by name, and a reply that withholds it reads as not listening. Portfolio-allocation questions across many products (BCG-matrix territory) → name it, note it needs per-product market-share and growth data, and run it only if that data is supplied.
+   The user asked for a framework by name and it fits → run it. It doesn't fit → run the framework they asked for, in full (a SWOT still arrives as TOWS), because they asked for it by name. Then say in two or three sentences which framework fits the question better and what it would add — a "SWOT" request that's really "should we enter this market" is Five Forces work — and offer to run it. Don't replace or shorten what they asked for. Portfolio-allocation questions across many products (BCG-matrix territory) → name it, note it needs per-product market-share and growth data, and run it only if that data is supplied.
 
 2. **Collect the evidence base before filling anything.** Name what is known `[data: …]`, reported `[reported by …]`, drawn from general market knowledge `[market: …]`, and assumed `[assumption]`. The `[market: …]` tag exists because on a short prompt most cells are filled from the model's own market knowledge — that's legitimate, but it must stay distinguishable from the user's facts and from guesses. Ask at most 2 questions, spent on the decision the analysis feeds ("what decision does this inform, and by when?") and the competitive set ("who do customers actually compare you to?"). No decision named → the analysis has no ranking criterion; get one before proceeding. Non-interactive run (no user to ask): derive the most plausible decision from the input, state it as `[assumption]` at the top, and rank against it; none derivable → emit `BLOCKED: need the decision this analysis feeds` rather than an unranked survey.
 

package/packs/product-manager/skills/strategy-analysis/manifest.json

@@ -1,6 +1,6 @@
 {
   "name": "strategy-analysis",
-  "version": "0.1.1",
+  "version": "0.1.2",
   "description": "Run a strategy framework — SWOT/TOWS, Porter's Five Forces, or PESTLE — on a product, company, or market question, choosing the right framework for the question and forcing every cell to carry evidence and a so-what. Use when the user asks for a SWOT, a competitive/market analysis, \"should we enter this market\", \"what's our position against X\", or a macro-environment scan.",
   "entrypoint": "SKILL.md",
   "deps": { "npm": [], "pip": [] },

package/packs/product-manager/skills/user-journey-map/SKILL.md

@@ -9,6 +9,14 @@ Maps what one customer experiences on the way to one outcome — outside-in, fro
 
 ## How to respond
 
+**Four rules come before the steps and outrank them:**
+
+- **Answer what was asked, first.** Open with the answer, the decision or the artifact, in plain words. Scores, matrices, frameworks and tags come after it, and anything that doesn't change the answer is cut.
+- **Use only what you were given.** Don't add facts, names, numbers, incidents, history, steps or sections the input doesn't contain. What you need and don't have is left out of the artifact and listed once at the end under "To confirm".
+- **Deliver from what you have.** When the request gives you something to work on, state your assumptions in a line and produce the result. When it gives you nothing to work on, ask for it in one or two plain sentences and say what you will do once you have it.
+- **Write for someone who has never heard of this skill.** No skill names, no paths or scripts from this folder, no internal terms, and nothing about how the run was set up. A next step is one plain sentence at the end that describes the work.
+- **For this skill:** Call the map a hypothesis when it isn't built on research. Scores on the emotion arc show its shape; say once that they are estimates, and build the persona only from what the user told you.
+
 1. **Anchor persona, outcome, and evidence level.** Ask at most 2 questions, spent on the weakest anchors: *"whose journey — one specific persona?"* and *"what outcome are they trying to reach?"* No persona or outcome → don't draft; a journey for "users" toward "using the product" has no stage boundaries. Non-interactive run (no user to ask): derive a specific persona and outcome from the input if defensible and tag them `[assumption]`; underivable → emit `BLOCKED: need persona + outcome` naming both. Tag the whole map's **evidence level**: `[observational]` (interviews, session recordings), `[survey/analytics]`, or `[assumption-based]` (team hypothesis). Assumption-based is legitimate — it's a hypothesis that directs research — but it must say so at the top, not masquerade as findings.
 
 2. **Fix the journey's edges.** Start trigger (the event that puts the persona on this path — in their life, not on your site: ✅ *"payroll fails on the last Friday of the month"*) and end state (what "done" means *to the persona* — ❌ "completes checkout" if their outcome is "salary problem solved"). Wrong edges are the most common defect: starting at the landing page amputates the discovery pain, ending at purchase hides the abandonment cliff in activation.

package/packs/product-manager/skills/user-journey-map/manifest.json

@@ -1,6 +1,6 @@
 {
   "name": "user-journey-map",
-  "version": "0.1.1",
+  "version": "0.1.2",
   "description": "Map a customer's end-to-end journey toward an outcome — 3–6 stages, each with actions, emotions, pains, and opportunities, plus a rendered Mermaid emotion arc and the ranked pain points design should attack first. Use when the user wants a journey map, customer experience map, \"map the user's path through onboarding\", touchpoint analysis, or \"where do users feel friction\".",
   "entrypoint": "SKILL.md",
   "deps": { "npm": [], "pip": [] },

package/packs/research/skills/hypothesis-comparison/SKILL.md

@@ -19,6 +19,14 @@ the evidence in the first place, plan it with `research-plan` and summarise sour
 
 ## How to respond
 
+**Four rules come before the steps and outrank them:**
+
+- **Answer what was asked, first.** Open with the answer, the decision or the artifact, in plain words. Scores, matrices, frameworks and tags come after it, and anything that doesn't change the answer is cut.
+- **Use only what you were given.** Don't add facts, names, numbers, incidents, history, steps or sections the input doesn't contain. What you need and don't have is left out of the artifact and listed once at the end under "To confirm".
+- **Deliver from what you have.** When the request gives you something to work on, state your assumptions in a line and produce the result. When it gives you nothing to work on, ask for it in one or two plain sentences and say what you will do once you have it.
+- **Write for someone who has never heard of this skill.** No skill names, no paths or scripts from this folder, no internal terms, and nothing about how the run was set up. A next step is one plain sentence at the end that describes the work.
+- **For this skill:** End on the hypothesis the evidence favours, with your confidence, when one is ahead; a tie is for when the evidence really is even. Check shares against absolute numbers before scoring: a stable share of a larger total is a rise.
+
 1. **Ask once for what's missing.** You need three things: the **observation** to explain,
    stated as a fact with a time and a size (✅ *"Mobile conversion fell 18% from 8 Sep"* — ❌
    *"sales are weird"*); the **evidence** the user has; and any **hypotheses** already on the

package/packs/research/skills/hypothesis-comparison/manifest.json

@@ -1,6 +1,6 @@
 {
   "name": "hypothesis-comparison",
-  "version": "0.1.0",
+  "version": "0.1.1",
   "description": "Compare rival explanations for an observation with analysis of competing hypotheses (ACH) — list the hypotheses and the evidence, build a consistency matrix (consistent / inconsistent / neutral), rank hypotheses by how little evidence contradicts them rather than how much supports them, name the diagnostic evidence and the linchpins, and say which next observation would tell the leaders apart. Use when the user asks \"why did X happen\", \"which explanation fits the evidence\", \"what's really causing this\", wants to stop arguing over a favourite theory, or says \"compare these hypotheses\", \"competing explanations\", \"ACH\".",
   "entrypoint": "SKILL.md",
   "deps": {

package/packs/research/skills/source-synthesis/SKILL.md

@@ -18,6 +18,14 @@ a brief for another skill rather than findings, use `brief-intake`.
 
 ## How to respond
 
+**Four rules come before the steps and outrank them:**
+
+- **Answer what was asked, first.** Open with the answer, the decision or the artifact, in plain words. Scores, matrices, frameworks and tags come after it, and anything that doesn't change the answer is cut.
+- **Use only what you were given.** Don't add facts, names, numbers, incidents, history, steps or sections the input doesn't contain. What you need and don't have is left out of the artifact and listed once at the end under "To confirm".
+- **Deliver from what you have.** When the request gives you something to work on, state your assumptions in a line and produce the result. When it gives you nothing to work on, ask for it in one or two plain sentences and say what you will do once you have it.
+- **Write for someone who has never heard of this skill.** No skill names, no paths or scripts from this folder, no internal terms, and nothing about how the run was set up. A next step is one plain sentence at the end that describes the work.
+- **For this skill:** The reply itself carries the answer: the recommendation, the numbers behind it and the caveats. Saved files are extra. Don't report that your own checks passed.
+
 1. **Ask once for what's missing.** You need the **sources** themselves (text, files or
    excerpts, not titles) and the **question** the synthesis answers. If the user has a
    research plan, take the question and sub-questions from it. Ask for both in one message.

package/packs/research/skills/source-synthesis/evals/evals.json

@@ -14,6 +14,36 @@
         "Does not add facts, benchmarks or figures that are not in the three sources, unless tagged [outside]",
         "Runs or recommends the citation checker and reports its result"
       ]
+    },
+    {
+      "id": 2,
+      "held_out": "2026-10-05",
+      "prompt": "We're a 45-person architecture practice and the directors are split on the 3-days-in-the-studio rule. Everything we have is in this folder: staff-survey-summary.md, badge-data.md, exit-interviews.md, director-email.md and practice-weekly-article.md. Can you pull it together for Thursday's directors' meeting? The choice is keep 3 days, drop to 2, or go up to 4 like Lucian wants. And tell me what changing it would do to retention.",
+      "assertions": [
+        "It corrects the claim that productivity is down 20%: the Castellan survey found 20% of managers believed productivity had fallen (and 34% believed it had risen), and it measured perceptions, not output",
+        "It treats Lucian's email and the Practice Weekly article as resting on the same Castellan survey, not as two independent pieces of evidence",
+        "It notes the Castellan fieldwork dates from October–November 2021 and treats it as dated or weak evidence for a 2026 decision",
+        "It points out that the Q1 answers in the staff survey add up to 40 (27 + 9 + 4) against 38 stated responses",
+        "It states that actual attendance already averages 2.4 days a week, below the 3-day rule, with 14 of 45 staff averaging 3 or more days",
+        "On retention it says the material cannot answer the question: three leavers, only one of whom (the technologist who moved to Bristol) linked leaving to office days; it gives no predicted retention effect",
+        "Each finding names the file it comes from, and the findings are grouped by topic, not written as one summary per file",
+        "It does not bring in studies, statistics or claims about hybrid working that are not in the five files"
+      ]
+    },
+    {
+      "id": 3,
+      "held_out": "2026-10-05",
+      "prompt": "I talked to five cafe owners last week about whether they'd pay for our stock-ordering app. My notes are rubbish, sorry, here's what I've got:\n\n- Marta, Kiln St Coffee (2 sites). Orders by WhatsApp to 3 suppliers. Forgets oat milk 'every other week'. Said 'I'd try it'. Asked if it works with her till (Lumo), I didn't know.\n- Joss, The Larder. Does the ordering Sunday nights, takes about 2 hrs. 'If it saved me an hour I'd pay, maybe £30 a month?'\n- Dee, Dee's. Happy with her spreadsheet, 'not a problem for me'. But said her friend who runs a bakery would def pay £50/mo.\n- Priyank, Corner Cup. Ran out of time, he mostly talked about a supplier delivering late. Didn't get to the app.\n- can't find my notes for the fifth one. think it was positive\n\nCan you pull together what we learned? Do they want it, and what should we charge?",
+      "assertions": [
+        "It delivers the write-up from the notes as given and does not stop to ask for better notes first",
+        "It says only one owner, Joss, named a price they would pay (about £30 a month, said tentatively and conditional on saving an hour)",
+        "It does not treat the £50 a month figure as evidence of willingness to pay: it is Dee's second-hand remark about a bakery owner who was not interviewed",
+        "It says Dee does not see ordering as a problem and that Priyank's conversation never reached the app, so at most two of the four noted conversations show interest",
+        "The fifth conversation is treated as no evidence because the notes are missing; 'think it was positive' is not counted as a positive result",
+        "Marta's 'I'd try it' is reported as interest in trying, not as agreement to pay",
+        "It says five conversations are too few to set a price or to conclude that cafe owners want it, and gives any price suggestion as tentative",
+        "It does not add market figures, competitor prices or cafe-industry facts that are not in the notes"
+      ]
     }
   ]
 }

package/packs/research/skills/source-synthesis/evals/files/2/badge-data.md

@@ -0,0 +1,27 @@
+# Studio door badge data
+
+Pulled by Odette Marsh from the access system. Covers 8 weeks, Monday 5 January to
+Friday 27 February 2026. 45 staff.
+
+## Average attendance
+
+Average days in the studio per person per week: **2.4**
+
+Staff who averaged 3 or more days a week over the period: **14 of 45**
+
+## By weekday (share of staff badged in, average over the 8 weeks)
+
+| Day | Share in |
+|---|---|
+| Monday | 31% |
+| Tuesday | 74% |
+| Wednesday | 77% |
+| Thursday | 40% |
+| Friday | 18% |
+
+## Caveats
+
+- The reader misses anyone let in by a colleague. Facilities think the undercount is small
+  but nobody has measured it.
+- The period includes no school holidays.
+- Site visits and client offices are not recorded, so a day on site looks like a day at home.

package/packs/research/skills/source-synthesis/evals/files/2/director-email.md

@@ -0,0 +1,16 @@
+From: Lucian Farrow
+To: Directors
+Date: 2 March 2026
+Subject: Office days, my view before the meeting
+
+All,
+
+I'll be blunt. Productivity is down 20% since hybrid. It's in the Castellan research, see
+the Practice Weekly piece I forwarded. That is a fifth of our output gone.
+
+I also hear from two clients that they like seeing the team together when they visit.
+
+Three days is not working. I want us at four days from the summer, with Friday as the
+flexible day.
+
+Lucian

package/packs/research/skills/source-synthesis/evals/files/2/exit-interviews.md

@@ -0,0 +1,17 @@
+# Exit interview notes, September 2025 to February 2026
+
+Notes taken by Odette Marsh. Three people left in the period.
+
+## Leaver A, Part 2 assistant, left October 2025
+
+Went to a larger practice for a higher salary. Asked about office days: "fine, didn't
+bother me". Main reason given: pay.
+
+## Leaver B, senior architectural technologist, left January 2026
+
+Moved to Bristol for family reasons. Said: "Three days in made it impossible to stay on
+after the move. Two I could have done." Main reason given: relocation.
+
+## Leaver C, associate, left February 2026
+
+Left to set up their own practice. Office days were not discussed.

package/packs/research/skills/source-synthesis/evals/files/2/practice-weekly-article.md

@@ -0,0 +1,21 @@
+# Is hybrid hurting studios?
+
+Practice Weekly, 9 February 2026. By Ines Calloway.
+
+Five years on from the first lockdowns, studio principals are still arguing about how many
+days their teams should be at their desks.
+
+The most widely quoted figures come from the Castellan Institute's Workplace Pulse survey.
+Castellan questioned 1,200 managers at professional-services firms. Fieldwork ran in October
+and November 2021. Asked how their team's productivity had changed since moving to hybrid
+working, 20% of managers said they believed it had fallen, 46% said it had not changed and
+34% said they believed it had risen. The survey recorded managers' perceptions. It did not
+measure output.
+
+Castellan did not publish a breakdown for architecture practices.
+
+"You cannot teach someone to detail a junction over a video call," said one studio principal
+who asked not to be named. Another said her practice had dropped its fixed days altogether
+and "nobody noticed, except the people who used to commute two hours".
+
+No newer wave of the survey has been published.

package/packs/research/skills/source-synthesis/evals/files/2/staff-survey-summary.md

@@ -0,0 +1,41 @@
+# Staff survey on office days: summary
+
+Compiled by Odette Marsh, studio manager, 12 March 2026.
+Sent to all 45 staff. 38 responses. Anonymous.
+
+## Q1. How many days a week would you choose to be in the studio?
+
+| Answer | Responses |
+|---|---|
+| 2 or fewer | 27 |
+| 3 | 9 |
+| 4 or 5 | 4 |
+
+## Q2. "The 3-day rule helps me do my job well."
+
+| Answer | Responses |
+|---|---|
+| Agree | 11 |
+| Neutral | 9 |
+| Disagree | 18 |
+
+## Q3. Main reason you come in (pick one)
+
+| Answer | Responses |
+|---|---|
+| Design reviews and crits | 19 |
+| Mentoring / being mentored | 8 |
+| Client meetings | 7 |
+| Home is not a good place to work | 4 |
+
+## Free text
+
+- 7 respondents identified themselves as Part 1 or Part 2 assistants. 6 of those 7 wrote
+  that they learn more on days when senior staff are in.
+- "Tuesdays are great. Fridays I sit on my own with my headphones on."
+- "I'd come in more if I knew my team would be there."
+- "Three days is fine, it's being told which three I mind."
+
+## Limits
+
+No breakdown by team or seniority beyond the assistants who identified themselves.

package/packs/research/skills/source-synthesis/manifest.json

@@ -1,6 +1,6 @@
 {
   "name": "source-synthesis",
-  "version": "0.1.0",
+  "version": "0.1.1",
   "description": "Synthesise a set of supplied sources — papers, articles, reports, interview transcripts — into findings where every claim is cited to a source and a location ([S1:p4]), agreement and disagreement across sources are explicit, each finding carries an evidence-strength rating with the criteria used, and the gaps and what the sources do not say are listed. Never adds outside facts unless tagged as such, and ships a citation checker. Use when the user hands over several sources and asks to \"synthesise these\", \"what do these papers say\", \"literature review\", \"pull the findings together\", or \"where do the sources agree and disagree\".",
   "entrypoint": "SKILL.md",
   "deps": {

package/packs/solution-architect/skills/db-schema-design/SKILL.md

@@ -9,6 +9,14 @@ Designs the storage layer **from the queries backward** — because a schema is
 
 ## How to respond
 
+**Four rules come before the steps and outrank them:**
+
+- **Answer what was asked, first.** Open with the answer, the decision or the artifact, in plain words. Scores, matrices, frameworks and tags come after it, and anything that doesn't change the answer is cut.
+- **Use only what you were given.** Don't add facts, names, numbers, incidents, history, steps or sections the input doesn't contain. What you need and don't have is left out of the artifact and listed once at the end under "To confirm".
+- **Deliver from what you have.** When the request gives you something to work on, state your assumptions in a line and produce the result. When it gives you nothing to work on, ask for it in one or two plain sentences and say what you will do once you have it.
+- **Write for someone who has never heard of this skill.** No skill names, no paths or scripts from this folder, no internal terms, and nothing about how the run was set up. A next step is one plain sentence at the end that describes the work.
+- **For this skill:** Give DDL that runs, and the query for each access pattern the user named. Leave out multitenancy, partitioning, rollups and reconciliation unless they asked or a named query needs them.
+
 1. **Collect the access patterns before drawing a single table.** The deliverable starts as a list: each read and write the feature needs, with **frequency**, **latency sensitivity**, **selectivity** (one row / a range / a scan), and **consistency need** (read-your-writes? eventual ok?). Ask at most 2 questions, spent on the highest-frequency query and the largest-growth entity. A schema designed from the entity diagram instead of the queries is how you get a clean model that can't serve its hottest path.
 
 2. **Choose the paradigm deliberately, with a reason** (selection matrix in [`reference.md`](reference.md)). Relational is the correct default for most transactional features and needs no defense; reaching *past* it does. ✅ *"Document store — the entity is read and written whole, no cross-entity queries, and the shape varies per type"* — ❌ *"NoSQL because scale"* (scale is a property of access patterns and data size, not a vibe). For NoSQL especially, the access patterns *are* the schema — you cannot add a query later for free the way SQL lets you.

package/packs/solution-architect/skills/db-schema-design/evals/evals.json

@@ -11,6 +11,35 @@
         "Every index maps to a real predicate from the listed queries rather than being speculative",
         "Denormalization, where proposed, names the read it serves and the write cost it adds"
       ]
+    },
+    {
+      "id": 2,
+      "held_out": "2026-10-05",
+      "prompt": "We're rebuilding the booking system for our vet clinics and I need the database tables designed properly this time. My notes on what it has to do are in notes.md and the tables we have today are in current_tables.sql. Can you give me the new schema, with the SQL to create it and the queries for the screens and the report?",
+      "assertions": [
+        "It includes CREATE TABLE statements for the new schema, with owners and pets as their own tables instead of the owner_name, owner_phone and pet_name columns repeated on each appointment",
+        "Double-booking a vet is prevented by a database constraint that handles appointments of different lengths (for example an exclusion constraint on a time range, or one row per time slot with a unique key), not only by an application check or by a unique key on vet and start time alone",
+        "Cancelled appointments are excluded from that constraint, so a cancelled time can be booked again",
+        "It points out that the notes say Postgres 15 while the contractor says the current app runs on MySQL 8, and states which one the SQL is written for",
+        "Prices are stored as an exact type (integer cents or a decimal/numeric), not FLOAT, and the price is modelled per appointment type per clinic",
+        "Appointment times are stored with a time zone or in UTC with each clinic's time zone recorded, and it notes that storing Sydney local time is wrong for the Brisbane clinics",
+        "It says the no-show report cannot be produced from the current statuses (booked, cancelled, completed) and adds a no-show status or an equivalent field",
+        "It gives a query or a named index for the vet's-day screen that leads on the vet and the appointment start time, and does not add tables for invoicing, payments, stock or clinical records"
+      ]
+    },
+    {
+      "id": 3,
+      "held_out": "2026-10-05",
+      "prompt": "need somewhere to store sensor readings from our greenhouses. about 200 sensors, each does temperature + humidity, a reading every minute or so I think. I want to chart the last 24h for any one sensor and get an alert when something goes out of range. haven't picked a database yet. what tables do I need?",
+      "assertions": [
+        "It gives concrete table definitions (SQL or an equivalent column-by-column layout) in the reply, and does not stop to ask questions before delivering them",
+        "The readings table has a key or index on the sensor and the reading time together, and the reply ties it to the last-24-hours chart for one sensor",
+        "It works out the volume from the numbers given: about 288,000 readings a day (roughly 105 million a year) at one reading per sensor per minute, or an equivalent calculation",
+        "It names a database to use, or says which one it assumed, with a reason linked to the chart and alert queries",
+        "It says how long readings should be kept is not known and lists it as something to decide, without stating a retention period as if it had been given",
+        "It stores the allowed range somewhere (per sensor, per greenhouse or per sensor type) and says the actual range values were not given; any numbers shown are labelled as examples",
+        "Reading times are stored with a time zone or in UTC"
+      ]
     }
   ]
 }

package/packs/solution-architect/skills/db-schema-design/evals/files/2/current_tables.sql

@@ -0,0 +1,29 @@
+-- Dump of the tables the current booking app uses. Schema only.
+-- NOTE (Devraj): all times are stored as Sydney local time, for every clinic.
+
+CREATE TABLE clinics (
+  id            INT AUTO_INCREMENT PRIMARY KEY,
+  name          VARCHAR(80) NOT NULL,
+  city          VARCHAR(40) NOT NULL
+);
+
+CREATE TABLE vets (
+  id            INT AUTO_INCREMENT PRIMARY KEY,
+  full_name     VARCHAR(120) NOT NULL,
+  clinic_id     INT NOT NULL            -- home clinic only
+);
+
+CREATE TABLE appointments (
+  id            INT AUTO_INCREMENT PRIMARY KEY,
+  clinic_id     INT NOT NULL,
+  vet_id        INT NOT NULL,
+  appt_time     DATETIME NOT NULL,      -- start time, Sydney local
+  appt_type     VARCHAR(40) NOT NULL,   -- free text: 'consult', 'Consult', 'vacc', ...
+  price         FLOAT,
+  owner_name    VARCHAR(120),
+  owner_phone   VARCHAR(40),
+  pet_name      VARCHAR(80),
+  status        VARCHAR(20) NOT NULL    -- 'booked', 'cancelled', 'completed'
+);
+
+-- no indexes other than the primary keys