skilldrop-cli 0.16.12 → 0.16.13

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

@@ -1,76 +0,0 @@
-{
-  "skill_name": "tech-comparison-matrix",
-  "evals": [
-    {
-      "id": 1,
-      "prompt": "Help us pick a message broker: Kafka (self-managed), Amazon Kinesis, or RabbitMQ. Use case: order-event streaming for a multi-tenant SaaS app at Acme, about 5k events/sec at peak, consumers need replay for up to 7 days, ordering per tenant matters. Hard constraints: we run on AWS, and the platform team is two people with no capacity to run self-hosted clusters on call.",
-      "assertions": [
-        "Uses 8 to 10 criteria spanning capability fit, operational, cost, and risk, and names any criteria deliberately excluded",
-        "Shows a 1-5 weight for every criterion with the weight tied in writing to the use case or constraints (e.g. operational burden weighted high because the platform team is two people)",
-        "Every score has a one-line justification, and every 5 and every 1 is explained",
-        "Totals are computed as sum(weight x score), and a gap under 5% between the top options is called out",
-        "Ties are allowed where options genuinely don't differ; scores are not uniformly 3/5",
-        "The recommendation is one sentence and says what would change the answer; if it isn't the top scorer, the override is explained",
-        "Numbers that are estimates are marked 'rough' or 'directional'; no benchmarks are invented beyond the figures in the prompt"
-      ]
-    },
-    {
-      "id": 2,
-      "held_out": "2026-10-05",
-      "prompt": "We have to pick an observability platform by 16 Oct. requirements.md is what we need and vendor-notes.md is what Davide gathered on the three options. Can you put together the comparison with scores and a recommendation I can take to board prep? Please score query speed using the p95 numbers from the trials. For what it's worth most of the team wants Graywell.",
-      "assertions": [
-        "Graywell is shown as failing the EU data residency must-have today (US-East only, EU region only on the roadmap for Q2 2027) and is not the recommended option",
-        "It flags that the Lumenstack quote does not add up: EUR 18 x 140 hosts x 12 months is EUR 30,240, not the EUR 25,200 on the quote",
-        "It notes that at EUR 30,240 Lumenstack is over the EUR 30,000 budget cap, or that whether it fits depends on getting the quote clarified",
-        "Self-hosted is shown as having no measured p95 query time because it was never trialled; no latency number is invented for it",
-        "The self-hosted assessment names the staffing risk: the team drops from 3 to 2 at the end of November and the person leaving is the only one who has run Loki in production",
-        "It notes that Graywell's EUR 18,480 is not an all-in or firm price: SAML SSO is Enterprise-tier with price on request, or the figure comes from a March sales deck and not a quote",
-        "It gives one clear recommendation and says what would change it",
-        "It does not introduce benchmarks, prices or vendor features that are not in the two files"
-      ]
-    },
-    {
-      "id": 3,
-      "held_out": "2026-10-05",
-      "prompt": "postgres vs mongo vs just sqlite for a small internal tool? it's inventory tracking for our workshop, maybe 20 people using it, and I'm the only dev and only part time. my boss wants a table he can show the owner so he can see we thought about it",
-      "assertions": [
-        "All three options (PostgreSQL, MongoDB, SQLite) are compared in one table against the same named criteria, each with a score or rating",
-        "The relative importance of the criteria is shown and tied to the facts given (about 20 users, one part-time developer)",
-        "Each score or rating has a short reason next to it",
-        "It gives one clear recommendation, not 'it depends'",
-        "It states the assumptions it had to make and what would change the answer (for example how many people write at the same time, where it is hosted, how backups are handled)",
-        "It does not invent benchmark figures, throughput numbers or costs",
-        "Large-scale performance, horizontal scaling or community popularity is not among the highest-weighted criteria"
-      ]
-    },
-    {
-      "id": 4,
-      "held_out": "2026-10-06",
-      "prompt": "We need to decide what to do with our driver app: keep the two native apps, rewrite in React Native, or rewrite in Flutter. Everything I've collected is in mobile-options.md. Leadership wants a scored table and a recommendation on one page. Use the cold start times from the spikes for the performance score.",
-      "assertions": [
-        "It states that a full rewrite cannot deliver the proof-of-delivery photo feature by 1 Feb 2027: 26 weeks (React Native) or 30 weeks (Flutter) from 2 Nov 2026 ends in May 2027, so the feature has to ship in the native apps first or the rewrite options miss the contract date",
-        "It says Orrin does not publish or support React Native or Flutter wrappers (the 9 Sept 2026 email) and that a bridge has to be written in-house; the March 2024 wiki claim of official plugins is not relied on",
-        "It points out that the Flutter cold start of 2.1 s was measured on a Pixel 8 and not on the H4, so it is not comparable with the 2.9 s (React Native) and 1.8 s (native) H4 figures; no H4 figure is invented for Flutter",
-        "It notes that the Flutter prototype's scan screen crashed on the H4 and was not investigated, as an open risk against the scanner must-have",
-        "The share of drivers on the handheld is given as about 70% (2,650 of 3,800), or the '80%' in the notes is flagged as not matching the counts",
-        "All three options are scored against the same named criteria, with weights shown and a total per option",
-        "It gives one clear recommendation and says what would change it",
-        "It does not introduce costs, benchmark figures or effort estimates that are not in the file"
-      ]
-    },
-    {
-      "id": 5,
-      "held_out": "2026-10-06",
-      "prompt": "need to pick how we run inference for our model: the GPU box in the office, cloud GPU instances, or just pay for a hosted inference API. we're 6 people, it's a document classifier, the documents are customers' contracts and a couple of them are touchy about where their data goes. volume is low right now but a big customer might sign. Kofi says the office box is basically free since we already own it. just the table and your pick, I'm pasting it into slack",
-      "assertions": [
-        "All three options (office GPU box, cloud GPU instances, hosted inference API) are compared in one table against the same named criteria, each with a score or rating",
-        "Where customer data goes, or data confidentiality, is one of the criteria and is among the most heavily weighted, tied to the remark that the documents are customers' contracts",
-        "The office box is not treated as free: the output names at least one ongoing cost or risk of it, such as the team's time to run it, no redundancy if it fails, or power and hardware upkeep",
-        "It gives one clear pick, not 'it depends'",
-        "It states that current and future volume are unknown and says how the pick would change if the big customer signs or volume grows",
-        "It does not invent prices, per-hour or per-request costs, latency or throughput figures",
-        "It is short enough to paste into Slack: the table plus no more than about 250 words of other text"
-      ]
-    }
-  ]
-}

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

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

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

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

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

@@ -1,45 +0,0 @@
-# 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/solution-architect/skills/tech-comparison-matrix/examples/queue-selection.md

@@ -1,41 +0,0 @@
-# Worked example — weighted comparison of message queues
-
-Input → output oracle for `tech-comparison-matrix`. Shows shown weights, a one-line
-justification per score, honest "rough" markers, and a one-sentence recommendation.
-
-## Input
-
-> "We need a message queue for an order-processing pipeline: ~5k msg/s, must not
-> lose messages, small team, already on AWS. Compare [managed-broker-A],
-> [self-hosted-broker-B], and [cloud-queue-C]."
-
-## Output
-
-**Weights** (sum to 100, set by the stated constraints — durability and ops-load dominate because the team is small and messages can't be lost):
-
-| Criterion | Weight | Why this weight |
-|---|--:|---|
-| Durability / no message loss | 30 | Hard requirement — order data. |
-| Operational load | 25 | Small team; running a broker is a tax. |
-| Throughput headroom | 15 | 5k/s is modest; all three clear it, so it's not decisive. |
-| Delivery semantics / ordering | 15 | Orders need per-key ordering. |
-| Ecosystem fit (AWS) | 15 | Already on AWS; native integration saves glue. |
-
-**Scores** (1–5, each justified; ties kept where real):
-
-| Criterion | Wt | [managed-broker-A] | [self-hosted-broker-B] | [cloud-queue-C] |
-|---|--:|--:|--:|--:|
-| Durability | 30 | 5 — replicated, managed | 5 — replicated *if* configured right | 5 — replicated, managed |
-| Ops load | 25 | 4 — managed, some tuning | 2 — you patch/scale/monitor it | 5 — fully serverless |
-| Throughput (rough) | 15 | 4 — ~tens of k/s | 5 — highest ceiling | 4 — ample for 5k/s |
-| Semantics/ordering | 15 | 4 — ordered per partition | 5 — most flexible | 3 — FIFO variant, lower quotas |
-| AWS fit | 15 | 3 — runs on AWS, not native | 2 — self-run on EC2/EKS | 5 — native service |
-| **Weighted total** | | **4.15** | **3.55** | **4.45** |
-
-**Recommendation:** Pick **[cloud-queue-C]** — its serverless ops profile decisively fits a small team with a modest, durability-critical load, and the only real gap (ordering quotas) is manageable at 5k/s.
-
-*Directional note:* throughput scores are rough (order-of-magnitude, not benchmarked); if load is likely to 10× within a year, re-weight throughput up and re-score — [self-hosted-broker-B]'s ceiling starts to matter.
-
-## Why this passes the quality bar
-
-Weights are shown and tied to the question; every score carries a one-line justification; ties (durability 5/5/5) are left as ties; the guessed throughput numbers are flagged "rough"/"directional"; and the recommendation is one decisive sentence, not hedged.

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

@@ -1,11 +0,0 @@
-{
-  "name": "tech-comparison-matrix",
-  "version": "0.1.1",
-  "description": "Produce a weighted comparison matrix for a technology selection question (e.g., \"Postgres vs DynamoDB\", \"Kafka vs Kinesis vs RabbitMQ\", \"Snowflake vs Databricks\"). Surfaces criteria, weights, per-option scores, totals, and a recommended pick. Use when the user is choosing between technologies, vendors, frameworks, or architectural approaches.",
-  "entrypoint": "SKILL.md",
-  "deps": { "npm": [], "pip": [] },
-  "env": { "required": [], "optional": [] },
-  "related": [],
-  "tags": ["decisions", "comparison", "tech-selection", "vendor-evaluation"],
-  "model": { "tier": "heavy", "rationale": "Weighted multi-criteria judgment with a recommendation. Mis-weighting is the failure mode. Never downgrade." }
-}

package/packs/solution-architect/skills/tech-comparison-matrix/templates/matrix.md

@@ -1,45 +0,0 @@
-# {Decision title — e.g. "Primary OLTP datastore for ProjectX"}
-
-**Use case:** {one sentence describing the workload / constraints — this is what the weights are tuned to}
-
-**Hard constraints:** {bulleted list of things that must be true; an option failing any of these is eliminated, not scored}
-
-**Options evaluated:** {Option A}, {Option B}, {Option C}
-**Options excluded (and why):** {e.g. "MongoDB — single-region writes only, fails the multi-region constraint"}
-
-## Scoring scheme
-
-- **Weight (1–5):** how much this criterion matters for *this* use case. Justified inline.
-- **Score (1–5):** how well the option meets the criterion. Each 5 and 1 has a one-line justification.
-
-## Matrix
-
-| Criterion | Weight | {Option A} | {Option B} | {Option C} |
-|---|---:|---:|---:|---:|
-| Throughput (writes/sec at p99 < 50ms) — *weight 5: directly stated in use case* | 5 | 5 — published bench 50k/s | 3 — caps around 15k/s | 4 — 30k/s with read replicas |
-| Consistency model fit — *weight 5: financial data, no eventual consistency tolerated* | 5 | 5 | 2 — eventual by default | 5 |
-| Operational complexity (self-hosted) — *weight 4: team has 1 SRE* | 4 | 3 | 4 — fully managed | 2 — manual sharding |
-| Cost at projected scale — *weight 3: budget approved but not unlimited* | 3 | 4 | 2 — egress fees | 5 |
-| Team familiarity — *weight 3: shortens ramp* | 3 | 5 | 2 | 3 |
-| Vendor lock-in — *weight 2: prefer portable but not blocking* | 2 | 5 — open source | 2 — proprietary | 4 |
-| Ecosystem / tooling — *weight 2* | 2 | 5 | 4 | 3 |
-| Backup & restore story — *weight 4: compliance requirement* | 4 | 4 | 5 | 3 |
-| **Weighted total** | | **{=Σ w·s}** | **{=Σ w·s}** | **{=Σ w·s}** |
-
-## Justifications for outlier scores
-
-- *{Option A}, Throughput = 5:* {one-line evidence — link to vendor bench, internal load test, or known reference deployment}
-- *{Option B}, Consistency = 2:* {one-line evidence}
-- *{Option C}, Operational complexity = 2:* {one-line evidence}
-
-## Recommendation
-
-**Pick {Option X}** — it's strongest on the two highest-weighted criteria (throughput + consistency) and acceptable on the rest. The gap to {next option} is meaningful (~{N}%), so this is not a close call.
-
-**What would change this answer:**
-- If managed-ness becomes the top constraint (e.g., SRE leaves), reconsider {Option B}.
-- If we relax the latency target above 100ms, {Option C} becomes viable and cheaper.
-
-## Open questions
-
-- {Question for stakeholders — e.g., "Is multi-region active-active in scope for v1, or v2+?"}