skilldrop-cli 0.16.6 → 0.16.8

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

@@ -14,6 +14,35 @@
         "Output ends with a 'what's solid' section so the author knows what not to touch",
         "The review scopes to the change under review, never sweeping the whole codebase"
       ]
+    },
+    {
+      "id": 2,
+      "held_out": "2026-10-05",
+      "prompt": "Just finished the volunteer shift sign-up feature for the food bank's scheduling app (signups.py, tests in test_signups.py). Volunteers sign up until the shift's full, after that they go on a waitlist, and when someone cancels the first person on the waitlist gets the spot. No cancelling inside 24 hours of the shift. Tests all pass. Anything I've missed before I merge?",
+      "assertions": [
+        "It flags that sign_up compares the confirmed count with > instead of >=, so a shift with capacity N confirms N+1 volunteers",
+        "It flags that cancel picks the waitlisted row with ORDER BY created_at DESC, so the most recent person on the waitlist is promoted, not the first",
+        "It flags that the same volunteer can sign up twice for one shift because nothing checks for an existing sign-up",
+        "It flags that the 24-hour cutoff subtracts local-time datetime.now() from a start time stored in UTC, so the window is off by the server's UTC offset",
+        "It points out that test_waitlist_when_full puts three volunteers into a capacity-2 shift before asserting, so it passes because of the capacity bug",
+        "It points out that test_no_waitlist_raises passes even when ShiftFull is never raised",
+        "It does not report SQL injection, since every query is parameterised",
+        "It says plainly that the change is not ready to merge as it stands"
+      ]
+    },
+    {
+      "id": 3,
+      "held_out": "2026-10-05",
+      "prompt": "wrote this quick script to dedupe our newsletter subscriber export before we import it into the new mail tool. worked fine on the 50-row sample i tried. good to run on the real file? it's about 40k rows, email is the third column\n\n```python\nimport sys\n\nrows = open(sys.argv[1]).read().split(\"\\n\")\nseen = {}\nfor r in rows[1:]:\n    if not r.strip():\n        continue\n    cols = r.split(\",\")\n    seen[cols[2]] = r\n\nout = open(sys.argv[1], \"w\")\nout.write(rows[0] + \"\\n\")\nfor r in seen.values():\n    out.write(r + \"\\n\")\n```",
+      "assertions": [
+        "It answers the question near the top: not as it stands, or only on a copy of the file",
+        "It flags that emails are compared exactly, so addresses differing only in letter case or surrounding spaces are kept as separate subscribers",
+        "It flags that split(\",\") breaks on a quoted field containing a comma, which shifts the column treated as the email",
+        "It flags that the script overwrites the input file in place with no backup, and recommends writing to a new file or keeping a copy",
+        "It notes that when rows share an email the last one wins, and that whether that is the right row to keep is something to confirm",
+        "It gives a concrete fix, such as reading with the csv module and normalising the email with strip and lower",
+        "It does not state as fact what the other columns hold or what the real file contains beyond what was given"
+      ]
     }
   ]
 }

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

@@ -0,0 +1,116 @@
+"""Volunteer shift sign-ups for the Harbourside Food Bank scheduling app."""
+import sqlite3
+from datetime import datetime, timedelta, timezone
+
+CANCEL_CUTOFF_HOURS = 24
+
+SCHEMA = """
+CREATE TABLE IF NOT EXISTS shifts (
+    id INTEGER PRIMARY KEY,
+    starts_at TEXT NOT NULL,      -- ISO 8601, stored in UTC
+    capacity INTEGER NOT NULL
+);
+CREATE TABLE IF NOT EXISTS signups (
+    id INTEGER PRIMARY KEY AUTOINCREMENT,
+    shift_id INTEGER NOT NULL REFERENCES shifts(id),
+    volunteer_id INTEGER NOT NULL,
+    status TEXT NOT NULL,         -- 'confirmed' | 'waitlisted' | 'cancelled'
+    created_at TEXT NOT NULL
+);
+"""
+
+
+class ShiftFull(Exception):
+    pass
+
+
+class TooLateToCancel(Exception):
+    pass
+
+
+class NotSignedUp(Exception):
+    pass
+
+
+def init_db(conn: sqlite3.Connection) -> None:
+    conn.executescript(SCHEMA)
+
+
+def _confirmed_count(conn: sqlite3.Connection, shift_id: int) -> int:
+    row = conn.execute(
+        "SELECT COUNT(*) FROM signups WHERE shift_id = ? AND status = 'confirmed'",
+        (shift_id,),
+    ).fetchone()
+    return row[0]
+
+
+def sign_up(conn: sqlite3.Connection, shift_id: int, volunteer_id: int,
+            allow_waitlist: bool = True) -> str:
+    """Sign a volunteer up for a shift. Returns 'confirmed' or 'waitlisted'."""
+    shift = conn.execute(
+        "SELECT capacity FROM shifts WHERE id = ?", (shift_id,)
+    ).fetchone()
+    if shift is None:
+        raise KeyError(f"no shift {shift_id}")
+    capacity = shift[0]
+
+    if _confirmed_count(conn, shift_id) > capacity:
+        if not allow_waitlist:
+            raise ShiftFull(f"shift {shift_id} is full")
+        status = "waitlisted"
+    else:
+        status = "confirmed"
+
+    conn.execute(
+        "INSERT INTO signups (shift_id, volunteer_id, status, created_at) "
+        "VALUES (?, ?, ?, ?)",
+        (shift_id, volunteer_id, status, datetime.now().isoformat()),
+    )
+    conn.commit()
+    return status
+
+
+def cancel(conn: sqlite3.Connection, shift_id: int, volunteer_id: int) -> None:
+    """Cancel a sign-up. The first volunteer on the waitlist takes the spot."""
+    row = conn.execute(
+        "SELECT id, status FROM signups "
+        "WHERE shift_id = ? AND volunteer_id = ? AND status != 'cancelled'",
+        (shift_id, volunteer_id),
+    ).fetchone()
+    if row is None:
+        raise NotSignedUp(f"volunteer {volunteer_id} is not on shift {shift_id}")
+    signup_id, status = row
+
+    starts_at = datetime.fromisoformat(
+        conn.execute(
+            "SELECT starts_at FROM shifts WHERE id = ?", (shift_id,)
+        ).fetchone()[0]
+    )
+    if starts_at - datetime.now() < timedelta(hours=CANCEL_CUTOFF_HOURS):
+        raise TooLateToCancel(
+            f"cancellations close {CANCEL_CUTOFF_HOURS}h before the shift"
+        )
+
+    conn.execute("UPDATE signups SET status = 'cancelled' WHERE id = ?", (signup_id,))
+
+    if status == "confirmed":
+        nxt = conn.execute(
+            "SELECT id FROM signups WHERE shift_id = ? AND status = 'waitlisted' "
+            "ORDER BY created_at DESC LIMIT 1",
+            (shift_id,),
+        ).fetchone()
+        if nxt is not None:
+            conn.execute(
+                "UPDATE signups SET status = 'confirmed' WHERE id = ?", (nxt[0],)
+            )
+    conn.commit()
+
+
+def roster(conn: sqlite3.Connection, shift_id: int) -> list[int]:
+    """Volunteer ids confirmed for a shift, in sign-up order."""
+    rows = conn.execute(
+        "SELECT volunteer_id FROM signups "
+        "WHERE shift_id = ? AND status = 'confirmed' ORDER BY id",
+        (shift_id,),
+    ).fetchall()
+    return [r[0] for r in rows]

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/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/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/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

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.