skilldrop-cli 0.16.8 → 0.16.9

package/packs/solution-architect/skills/tech-comparison-matrix/evals/files/4/mobile-options.md

@@ -0,0 +1,45 @@
+# DriverRun app: rewrite or not?
+
+Notes for the decision. Ilse Vandermeer, mobile lead, Varley Parcels, 1 Oct 2026.
+
+## Where we are
+- DriverRun is two separate native apps: Android (Kotlin, since 2019) and iOS (Swift, since 2021).
+- Every feature gets built twice. iOS is currently 3 features behind Android.
+- Options on the table: (A) keep both native apps, (B) rewrite in React Native, (C) rewrite in Flutter.
+- My own preference going in is B, since half the team already writes React.
+
+## Who uses it
+- 2,650 employed drivers on company handhelds: Orrin H4 (Android 11, 3 GB RAM, built-in barcode scanner)
+- 1,150 subcontractor drivers on their own phones: about 700 iPhone, 450 Android
+- So about 80% of drivers are on the handheld.
+
+## Must-haves
+1. Scan with the H4's built-in scanner (through the Orrin SDK). Camera scanning is too slow for a 140-stop route.
+2. The whole route works offline.
+3. Proof-of-delivery photo feature live for all drivers by 1 Feb 2027. This is in the Hadleigh Home contract, with a penalty clause.
+4. Print to the Bluetooth label printers in the vans.
+
+## Team
+- 9 mobile engineers: 4 Android, 3 iOS, 2 who do both.
+- 5 of the 9 have shipped React/TypeScript (rotations on the web portal).
+- Nobody has shipped Dart. 2 have done a Flutter course.
+
+## Scanner SDK
+- Wiki page "Orrin integration" (last edited March 2024 by Stellan, who has since left):
+  "Orrin publishes official plugins for both Flutter and React Native, so cross-platform is not a problem."
+- Email from Orrin partner support, 9 Sept 2026: "The H4 SDK is distributed as an Android AAR only.
+  We do not publish or support React Native or Flutter wrappers. The community Flutter plugin you
+  mention was last updated in 2024 and does not support H4 firmware 7. Partners usually write their own bridge."
+- Our handhelds are on firmware 7.
+
+## Spike results (August, two weeks each, one engineer)
+- React Native prototype: the scan-to-stop-list screen works on the H4 using a bridge we wrote ourselves (4 days). Cold start 2.9 s on the H4.
+- Flutter prototype: cold start 2.1 s, measured on a Pixel 8 dev phone. On the H4 the scan screen crashed using the community plugin. Ran out of time, not investigated.
+- For reference, today's native Android app cold-starts in 1.8 s on the H4.
+- Label printing: not tried in either spike.
+
+## Estimates (the team's, calendar time, starting Mon 2 Nov 2026 after the current release)
+- A: proof-of-delivery photo in both native apps: 7 weeks.
+- B: React Native rewrite to parity with today's Android app: 26 weeks. Photo feature after that: +3 weeks.
+- C: Flutter rewrite to parity: 30 weeks. Photo feature after that: +3 weeks.
+- Nobody has estimated what it costs us to keep building everything twice under A.

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

@@ -42,6 +42,36 @@
         "It does not blame Lena or any individual",
         "It delivers the postmortem in the reply rather than only asking questions"
       ]
+    },
+    {
+      "id": 4,
+      "held_out": "2026-10-06",
+      "prompt": "Need the postmortem for INC-0847 (the double direct debit on 22 Sept) for the exec team on Thursday. Two pages max, they won't read more. Material is in incident-channel.txt, scheduler-log.txt and finance-recon.md. Dermot wants the summary to say the root cause was the cloud provider's network blip. Please also put in how many customers went overdrawn because of us.",
+      "assertions": [
+        "Impact is given from the finance reconciliation: 2,961 duplicate debits across 2,917 customers, GBP 184,306.20 taken in error; the early '~3,400 customers' estimate is not presented as the final figure",
+        "It says refunds are not complete: 2,935 of 2,961 were refunded (2,804 plus 131) and 26 are still outstanding with no date, contradicting the 'all customers refunded' closing message",
+        "The number of customers who went overdrawn is stated as unknown; it reports only that 43 support contacts mention a fee or overdraft and does not invent a count",
+        "The network blip is not given as the sole root cause; the output names at least that the original run carried on after its node lost the lock and that the job had no check against debiting the same customer twice",
+        "The lock TTL change from 300s to 30s on 3 Sep (CHG-2210) is listed as a contributing factor",
+        "No individual is blamed: neither the on-call engineer who acknowledged the 01:35 page nor the author of the TTL change is given as a cause",
+        "It states the problem was found from customer calls to support at 07:06 UTC, roughly five and a half hours after the second run started at 01:31 UTC, and after the bank's 04:00 recall cutoff had passed",
+        "The action to alert on more than one debit file per night is shown as having no owner, and the scheduler fix (stop a job when its node loses the lock) as having no date"
+      ]
+    },
+    {
+      "id": 5,
+      "held_out": "2026-10-06",
+      "prompt": "can you write this up for the incident log, half a page is plenty. this morning the DNS change for the student portal went wrong, Marek's change pointed it at the old load balancer. live from about 08:15, helpdesk started getting calls 08:30ish, we rolled it back at 09:50 but some people were still seeing the broken site until around lunchtime because of the TTL (4 hours? not sure). course registration opened at 9 so terrible timing. no idea how many students were hit. it went through CAB as a standard change",
+      "assertions": [
+        "It delivers a written incident record in the reply rather than only asking questions",
+        "The outage is given as roughly 08:15 to the 09:50 rollback (about 95 minutes), with a tail to around midday for some users from cached DNS, and these times are marked approximate",
+        "The number of students affected is stated as unknown and no figure is invented",
+        "It notes that the outage overlapped the opening of course registration at 09:00",
+        "Marek is not blamed; the cause is described in terms of the change and the process (record pointed at the old load balancer, passed as a standard change) and not the person",
+        "The TTL value is marked as unconfirmed, not stated as a definite 4 hours",
+        "It says the problem was noticed through helpdesk calls about 15 minutes after the change went live, and does not invent a monitoring alert or page",
+        "At least one follow-up action addresses checking a DNS change right after it is made, lowering the TTL before a change, or avoiding changes around registration, written so someone can tell whether it was done"
+      ]
     }
   ]
 }

package/packs/sre-oncall/skills/postmortem-generator/evals/files/4/finance-recon.md

@@ -0,0 +1,28 @@
+# INC-0847 reconciliation
+
+Finance Ops (Aoife Brennan), Fri 25 Sep 2026. Brindle Energy, internal.
+
+Matched bank file DD-20260922-B against DD-20260922-A.
+
+- Rows in file B: 3,401
+- Of which legitimate retries of Monday's failed debits: 440
+- Duplicate debits: 2,961
+- Customers affected: 2,917 (44 customers have two supply accounts and were debited twice on both)
+- Total taken in error: GBP 184,306.20
+
+## Refunds
+
+- 23 Sep, refund file 1: 2,804 credits
+- 24 Sep, refund file 2: 131 credits
+- Could not be sent, or rejected by the bank: 26 (account closed or switched since the debit).
+  Passed to Customer Ops to contact by letter. No date for these yet. Value outstanding: GBP 1,702.48
+
+## Bank charges and overdrafts
+
+We have no way to see whether a customer went overdrawn. Support has tagged 43 contacts
+where the customer says they were charged a fee or went overdrawn. No decision yet on
+reimbursing fees.
+
+## Support
+
+Contacts tagged INC-0847 up to 25 Sep: 487

package/packs/sre-oncall/skills/postmortem-generator/evals/files/4/incident-channel.txt

@@ -0,0 +1,34 @@
+#inc-0847-double-debit -- channel export. All timestamps UTC.
+
+== Tue 22 Sep 2026 ==
+07:14 Priyanka Rao (Support lead): we've had 6 calls since 07:06 from customers saying we took their direct debit twice this morning. first call logged 07:06. is something up with collections?
+07:19 Callum Reid (Payments eng): looking
+07:25 Dermot Fahy (Incident commander): declaring an incident, INC-0847. Callum pls check dd-collect from last night
+07:41 Callum Reid: confirmed. bank received TWO files from us overnight. DD-20260922-A at 01:50 and DD-20260922-B at 02:17. dd-collect ran twice, run 55120 on sched-a and run 55121 on sched-b
+07:45 Callum Reid: file B has about 3,400 rows so looks like ~3,400 customers double charged
+07:48 Wen Li (Platform): dd-collect disabled on both schedulers until we understand this
+07:52 Dermot Fahy: can we recall file B from the bank?
+08:10 Callum Reid: bank portal says the recall window for same-day files closes at 04:00. we missed it by hours. asking our account manager anyway
+08:31 Wen Li: scheduler logs are in scheduler-log.txt. short version: sched-a lost the lock store for ~3 min during the cloud zone network blip at 01:27, sched-b took over and started the job again. sched-a never stopped its own run
+08:40 Tomasz Zielinski (Platform on-call): for the record I got paged 01:35, "sched-a: lock store unreachable", low priority. acked it, saw sched-b was leader and healthy, which is what the runbook says to check, and went back to sleep. nothing told me a job was running twice
+08:44 Callum Reid: honestly if Tomasz had dug in at 01:35 we'd have had 2.5 hours to recall the file. that's on him
+08:47 Dermot Fahy: let's not do that here. the page said nothing about jobs
+08:55 Wen Li: also relevant: lock TTL was 300s until CHG-2210 on 3 Sep, which dropped it to 30s so failover would be faster. with 300s a 3 minute blip would not have caused a takeover at all
+08:58 Callum Reid: that was Ines's change. who approved a 30s TTL??
+09:03 Ines Carvalho (Platform): it went through normal review, two approvals. it was asked for after the August failover took 6 min. nobody (me included) thought about jobs that don't stop when they lose the lock
+09:30 Dermot Fahy: bank confirms no recall possible. both debits will land in customer accounts today. we have to send the money back as credits
+09:42 Callum Reid: why B isn't a full copy of A: the job commits in batches. 55120 had committed 14 of 20 batches when sched-b started 55121, so 55121 only picked up batches 15-20. but 55120 carried on and did 15-20 as well. so the duplicates are batches 15-20 only. and I was wrong earlier, file B also has the retries of Monday's failed debits in it, so 3,400 is too high. Finance will get the real number
+11:20 Dermot Fahy: status page + email to affected customers going out at 12:00
+16:05 Farah Okonkwo (Payments eng lead): dd-collect has no check for "has this debit already gone into a file today". adding one. re-enabling tonight's run on sched-a only, with the job removed from sched-b, and I'll watch it
+
+== Wed 23 Sep ==
+10:15 Farah Okonkwo: refund file 1 submitted to the bank, 2,804 credits
+10:20 Priyanka Rao: support has had 310 contacts about this so far
+
+== Thu 24 Sep ==
+14:30 Farah Okonkwo: refund file 2 submitted, 131 credits (these needed manual matching)
+15:02 Dermot Fahy: all customers refunded. closing the incident. actions:
+   - dd-collect: skip any debit already included in a file that day (Farah, due 16 Oct)
+   - scheduler: a job must stop itself when its node loses the lock (Wen, date TBD)
+   - alert when more than one debit file goes to the bank in a night (owner?)
+   - revisit lock TTL (Ines, no date)

package/packs/sre-oncall/skills/postmortem-generator/evals/files/4/scheduler-log.txt

@@ -0,0 +1,15 @@
+2026-09-22T01:02:00Z sched-a leader=sched-a job=dd-collect run=55120 START batches=20
+2026-09-22T01:26:41Z sched-a run=55120 batch 14/20 committed
+2026-09-22T01:27:09Z sched-a WARN lock store unreachable (timeout)
+2026-09-22T01:27:39Z lockstore lease holder=sched-a expired (ttl=30s)
+2026-09-22T01:27:40Z sched-b acquired leadership
+2026-09-22T01:30:12Z sched-a lock store reachable; leader is sched-b; demoting. running jobs: 1 (not interrupted)
+2026-09-22T01:31:00Z sched-b job=dd-collect last_status=RUNNING owner=sched-a (not leader) -> treating as orphaned, START run=55121
+2026-09-22T01:31:02Z sched-b run=55121 resuming from batch 15/20
+2026-09-22T01:33:20Z alert job-duration-anomaly job=dd-collect -> #batch-alerts (severity=info)
+2026-09-22T01:35:04Z page LOW "sched-a: lock store unreachable" -> platform on-call, acked 01:36:10
+2026-09-22T01:49:30Z sched-a run=55120 batch 20/20 committed, DONE
+2026-09-22T01:50:05Z sched-a run=55120 submitted DD-20260922-A rows=9870
+2026-09-22T02:16:48Z sched-b run=55121 batch 20/20 committed, DONE
+2026-09-22T02:17:15Z sched-b run=55121 submitted DD-20260922-B rows=3401
+2026-09-22T07:48:22Z job=dd-collect disabled on sched-a, sched-b by wli

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

@@ -42,6 +42,36 @@
         "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"
       ]
+    },
+    {
+      "id": 4,
+      "held_out": "2026-10-06",
+      "prompt": "Laleh starts on Monday the 12th and I need a laptop setup guide she can follow on her own, she's an architect not an IT person. Bram's setup notes are in it-notes.txt and there's some later email in handover-thread.txt. Can you also include how to set up the big plotter, she'll need it in her first week.",
+      "assertions": [
+        "The P: drive is mapped to \\\\fo-nas02\\projects, and \\\\studio-nas\\projects is not given as the address to use",
+        "Setting up Keyhaven comes before the step to join the Fenwick-Staff Wi-Fi, since the Wi-Fi password is stored in Keyhaven",
+        "It does not tell Laleh that Odile will send the Keyhaven invite; it says Odile has left and who sends the invite is not confirmed, without naming Tomasz or Bram as the confirmed sender",
+        "It says the material has nothing on the plotter, and does not invent a plotter model, driver, address or setup steps",
+        "The DraftForge step gives the licence server as 27000@fo-lic01 and says that a \"no licence available\" message means a colleague has to close DraftForge to free a seat",
+        "It tells her the Keyhaven master password cannot be reset if lost",
+        "It tells her Desktop and Documents are not backed up and project files belong on P:",
+        "Working from home is covered: connect Tailgate VPN first, then P: and DraftForge work as in the office"
+      ]
+    },
+    {
+      "id": 5,
+      "held_out": "2026-10-06",
+      "prompt": "can you write a short reference for the event our door sensors send? here's one off the queue:\n\n{\"dev\":\"ds-0417\",\"st\":1,\"bat\":83,\"ts\":1791188400123,\"rssi\":-71,\"fw\":\"2.4.1\"}\n\nst is 0 closed 1 open, there might be a 2 but i've never seen one. bat is percent i think. ts is epoch something. it's going in the README for the two contractors building the dashboard so keep it short",
+      "assertions": [
+        "It delivers the reference, and does not stop at questions",
+        "All six fields in the sample are listed: dev, st, bat, ts, rssi and fw",
+        "st is documented as 0 for closed and 1 for open, and a value of 2 is mentioned as possible with its meaning unknown, not given a made-up meaning",
+        "It says ts looks like epoch milliseconds going by its 13 digits, and marks that as read from the sample, not confirmed",
+        "bat is described as probably a percentage and marked as unconfirmed",
+        "The meanings given for rssi and fw are marked as inferred from the sample, since the user did not explain them",
+        "It does not invent a queue or topic name, how often events are sent, delivery guarantees, value ranges stated as fact, or fields that are not in the sample",
+        "The reference is about a page or less, with no sections on things that were not supplied such as authentication, retries or versioning"
+      ]
     }
   ]
 }

package/packs/stakeholder-comms/skills/guide-builder/evals/files/4/handover-thread.txt

@@ -0,0 +1,39 @@
+From: Bram Kessel
+To: Ines Oduya
+Date: Tue 18 Aug 2026
+Subject: NAS swap done
+
+Ines - the old NAS was retired last night. Everything is on the new one, fo-nas02.
+The project share is \\fo-nas02\projects now. I've remapped P: on all nine laptops.
+The old name (studio-nas) doesn't resolve any more, so anything still pointing at it
+will just fail. Haven't updated my setup notes yet, sorry.
+Backups unchanged, still nightly.
+
+Bram
+
+----------------------------------------------------------------
+
+From: Ines Oduya
+To: Bram Kessel; Tomasz Fenwick
+Date: Fri 25 Sep 2026
+Subject: Odile's last day + new starter
+
+Both - today was Odile's last day. As far as I know she was the only Keyhaven admin,
+so somebody else needs to be able to send invites before Laleh starts on 12 Oct.
+Tomasz, can you or Bram pick that up?
+
+Laleh gets the desk by the model shop. It has a dock with a network cable, so she'll
+be online as soon as she plugs the laptop in.
+
+Ines
+
+----------------------------------------------------------------
+
+From: Tomasz Fenwick
+To: Ines Oduya; Bram Kessel
+Date: Mon 28 Sep 2026
+Subject: Re: Odile's last day + new starter
+
+Will get it sorted this week.
+
+T

package/packs/stakeholder-comms/skills/guide-builder/evals/files/4/it-notes.txt

@@ -0,0 +1,21 @@
+NEW STARTER LAPTOP SETUP - Fenwick & Oduya Architects
+Bram Kessel (IT, contract) - last touched 14 Feb 2026
+
+1. Log in with the account from the welcome email (firstname.lastname@fenwickoduya.example).
+   Change the password when it asks.
+2. Install the apps from Company Portal (it's in the Start menu): Tailgate VPN, DraftForge,
+   Keyhaven (password manager). DraftForge is big, takes 20-30 min.
+3. Map the P: drive -> \\studio-nas\projects
+   File Explorer > This PC > Map network drive. Tick "Reconnect at sign-in".
+   All project work lives on P:.
+4. Open DraftForge. First launch asks for a licence server, type 27000@fo-lic01
+   We have 8 floating seats. If it says "no licence available" all 8 are in use and
+   someone has to close DraftForge to free one. Ask around.
+5. Join the office wifi: Fenwick-Staff. Password is in Keyhaven in the "Office" folder.
+   (Fenwick-Guest is for visitors, it can't see P: or the licence server.)
+6. Keyhaven: Odile sends the invite to your work email. Accept it, set a master password.
+   DON'T LOSE THE MASTER PASSWORD. We can't reset it, you'd lose everything in the vault.
+7. Working from home: connect Tailgate VPN first, then P: and the DraftForge licence work
+   same as in the office. VPN login is the same as the laptop login.
+8. Backups: nothing to do. Anything on P: is backed up every night.
+   Desktop and Documents are NOT backed up. Don't keep project files there.