skilldrop-cli 1.1.0 → 1.1.1

package/packs/frontend/skills/bundle-size-review/evals/files/9/src/styles.ts

@@ -0,0 +1,11 @@
+const CSS = `
+#parcelpost-chat { position: fixed; right: 24px; bottom: 24px; font: 14px/1.4 system-ui, sans-serif; }
+#parcelpost-chat form { display: flex; gap: 8px; background: #fff; border-radius: 12px; padding: 12px; box-shadow: 0 4px 24px rgba(0,0,0,.15); }
+#parcelpost-chat textarea { flex: 1; min-height: 40px; resize: none; border: 1px solid #d0d4dc; border-radius: 8px; padding: 8px; }
+`;
+
+export function injectStyles(root: HTMLElement) {
+  const style = document.createElement('style');
+  style.textContent = CSS;
+  root.appendChild(style);
+}

package/packs/frontend/skills/bundle-size-review/evals/files/9/src/widget.ts

@@ -0,0 +1,15 @@
+import { render, h } from 'preact';
+import { Composer } from './composer';
+import { injectStyles } from './styles';
+
+const root = document.createElement('div');
+root.id = 'parcelpost-chat';
+document.body.appendChild(root);
+injectStyles(root);
+
+async function openPicker(onPick: (char: string) => void) {
+  const { default: mountPicker } = await import('./emoji/picker');
+  mountPicker(root, onPick);
+}
+
+render(h(Composer, { openPicker }), root);

package/packs/frontend/skills/bundle-size-review/manifest.json

@@ -1,6 +1,6 @@
 {
   "name": "bundle-size-review",
-  "version": "0.2.2",
+  "version": "0.2.3",
   "description": "Find what makes a JavaScript bundle heavy and what can safely come out, from the bundler's stats file (webpack stats.json, an esbuild metafile, or the rollup-plugin-visualizer raw-data JSON that Vite builds use) read together with the repo around it (package.json, .browserslistrc, the lockfile, the bundler config and the source files that import the heavy modules). Gives each entry's first-load JavaScript in the exact bytes the stats record, kept apart from lazy chunks; finds whole-library imports, CommonJS packages that can't be tree-shaken, packages bundled twice and polyfills the browser targets don't need; names the import chain that pulls each module in before suggesting a removal; and, given before and after stats, says what grew, why, whether it lands in the first load and which per-entry budget would have caught it. Use when the user says \"why is our bundle so big\", \"what can we cut from the bundle\", \"review this stats.json\", \"why is lodash or moment in our bundle\", \"the bundle grew in this PR\", or \"set a bundle size budget\".",
   "entrypoint": "SKILL.md",
   "deps": {

package/packs/solution-architect/skills/event-contract-draft/SKILL.md

@@ -24,7 +24,16 @@ APIs are `api-contract-draft`; a dataset's schema and quality SLAs for analytics
    by paymentId?") gets a direct answer in a few lines: yes or no, why, the fix. No AsyncAPI
    document. A request to define events gets the full contract (step 11).
 
-2. **List the facts, the producer and the consumers.** For each consumer, write what it does
+2. **When the user brings a draft, keep it theirs.** Their payload, event names or spec are the
+   starting point, not a sketch to redo. Keep their names, fields and shapes. Change one only
+   when it breaks a rule below: a float for money, personal data no consumer uses, a card
+   number, a command for a name, no event id. List each change: *"`price` (float) →
+   `priceMinor` + `currency`: floats lose pennies when summed"*. Anything you'd change that
+   breaks no rule goes under "Also worth considering", unapplied. ❌ Renaming their
+   events, dropping their fields and reshaping the payload, then answering their question
+   underneath.
+
+   **Then list the facts, the producer and the consumers.** For each consumer, write what it does
    with each event; that line decides payload size and justifies every field. Ask at most 2
    questions, spent on who consumes and what they do with it, and which broker. Missing broker
    → write broker-neutral with a Kafka binding, tagged `[assumption]`.
@@ -106,16 +115,30 @@ APIs are `api-contract-draft`; a dataset's schema and quality SLAs for analytics
     It checks AsyncAPI 3.x structure, `$ref`s, past-tense names, the envelope in every message,
     one type per schema, unmarked personal data, closed schemas, deprecation dates, and each
     channel's key, ordering, delivery, retention, replay and DLQ notes. When it can't run, say
-    the document is unchecked. Never claim a check that didn't run.
+    the document is unchecked. Never claim a check that didn't run. Report it as what it
+    checked and what it found: ✅ *"Checked against AsyncAPI 3.0 structure and the rules
+    above (envelope, past-tense names, PII marks, per-channel key, retention and DLQ): no
+    failures."* ❌ *"Passes the structural check."*
 
 11. **Reply in this order:**
-    1. **What the contract decides**, 3–6 lines, leading with every pushback from steps 3–9.
-    2. **Decisions**: a table of decision, choice, why (shape in [`reference.md`](reference.md)).
-    3. **What consumers must do**: numbered, at most 6: dedupe, ignore unknown fields, revision
+    1. **The answer to each question the user asked**, numbered in their order, in plain
+       words, one to three lines each: ✅ *"Versioning: add fields freely; a rename or type
+       change ships as `booking.confirmed.v2` beside v1 until a date agreed with
+       consumers."* A question the contract answers still gets its own line here, not left
+       for the reader to find in the spec.
+    2. **What the contract decides**, 3–6 lines, leading with every pushback from steps 3–9,
+       then each change you made to their draft (step 2).
+    3. **Decisions**: a table of decision, choice, why (shape in [`reference.md`](reference.md)).
+    4. **What consumers must do**: numbered, at most 6: dedupe, ignore unknown fields, revision
        check, no cross-key order, DLQ duty, the migration they owe and by when.
-    4. **The AsyncAPI document**, saved as `asyncapi.json` when files can be written, inline
-       otherwise; then one line on the check result.
-    5. **To confirm**: each open item with who can answer it.
+    5. **The AsyncAPI document**, saved as `asyncapi.json` when files can be written, inline
+       otherwise; then one line on the check result. When it's saved, show each event in the
+       reply as a short field table (field, type, required, who uses it), not as JSON. Never
+       paste part of the document: show all of it, or point to the file.
+    6. **To confirm**: each open item with who can answer it.
+
+    The reply starts with the answer: no leftover working notes ("This confirms it", "as
+    reworked above"), and no reference to anything the reader can't see.
 
 **Non-interactive runs** (subagent, CI, headless): a missing broker, retention, consumer
 detail or sunset date becomes a tagged `[assumption]` or a "To confirm" line, and the contract
@@ -140,6 +163,9 @@ happens in it that others react to`.
 - **Retention, replay and dead-letter are stated per channel**, with the DLQ owner named or open.
 - **The check result is reported only if it ran**, and the document has no FAIL.
 - **Nothing invented**: no team names, dates, volumes or retention the input didn't give, except as `[assumption]`.
+- **Every question asked is answered in its own line first,** before the contract.
+- **The user's draft stays theirs:** each change to their names, fields or shapes is listed with the rule it fixes, and nothing else is changed.
+- **The document is whole:** saved complete, or shown complete, never cut off.
 
 ## When to use this skill
 
@@ -165,3 +191,5 @@ happens in it that others react to`.
 - ❌ **In-place breaking change** to a live event, "so there's one version to maintain". Fulfilment breaks at deploy.
 - ❌ **`additionalProperties: false`** on payloads, which turns every additive change into a breaking one.
 - ❌ **A DLQ nobody owns.** Messages land there and the business notices weeks later.
+- ❌ **Redesigning the user's payload unasked.** Renamed events and dropped fields they didn't ask about make the contract yours, not theirs, and bury the answer they wanted.
+- ❌ **Answering inside the spec.** "See `x-delivery`" isn't an answer to "do we get exactly-once?". Say no, why, and what they get, in the first lines.

package/packs/solution-architect/skills/event-contract-draft/evals/evals.json

@@ -71,6 +71,36 @@
         "Provides a compact AsyncAPI 3.0 document describing the webhook messages (a common envelope with event id, type and occurrence time, and messages for the paid/overdue/voided cases with past-tense names) plus a short decisions summary, and recommends signing deliveries (e.g. an HMAC signature header with a timestamp) so receivers can verify the sender and reject replays.",
         "Invents nothing not in the input (no made-up existing Ledgerly endpoints, customer names, SLAs or numbers beyond 10s, 3 retries, ~40s and the example invoice), and keeps the answer sized to a chatty question — direct answers first, then the spec — rather than a sprawling design document."
       ]
+    },
+    {
+      "id": 6,
+      "held_out": "2026-10-22",
+      "prompt": "We're pulling order handling out of the Larkspur Goods checkout monolith. Right now the only 'contract' for the `orders` Kafka topic is src/checkout/order_events.py, and the topic config is in infra/topics.yaml. Three teams will consume it: fulfilment (needs every event for a given order in the order it happened), loyalty (counts orders per customer), and analytics (re-loads the last 7 days from the topic every Monday into the warehouse). Please draft a proper AsyncAPI contract for the topic that we can review with those teams, and tell me what has to change on the producer side.",
+      "assertions": [
+        "Answers the actual request directly: delivers an AsyncAPI 3.0 document (asyncapi: 3.0.x, with channels plus operations using action send/receive, not 2.x publish/subscribe) for the `orders` topic, plus a short list of producer-side changes / decisions rather than a long essay.",
+        "Renames the event types create_order, update_order_status and cancel_order to past-tense facts (e.g. OrderPlaced, OrderCancelled) and replaces the generic update_order_status with specific past-tense events for paid/packed/shipped/delivered or an explicitly justified OrderStatusChanged.",
+        "Removes card_number and card_expiry from the event payload entirely (not merely tagging them) and marks customer_email, customer_phone and shipping_address as PII, dropping or justifying them per consumer since none of fulfilment, loyalty or analytics obviously needs all of them.",
+        "Replaces key=None (round-robin, which gives no ordering at all) with an explicit partition key, choosing order_id (or justifying customer_id), and states that ordering holds only per key within one partition; also flags that raising partitions from 6 to 24 before the November peak remaps keys to partitions and breaks per-order ordering across the change unless handled (e.g. drain first or create a new topic).",
+        "Flags that retention.ms 86400000 (1 day) cannot support analytics' 7-day Monday replay and recommends retention of at least 7 days (with margin) or a different replay source.",
+        "Defines a required envelope with a unique event id (plus type, occurred-at time, schema version), states delivery is at-least-once, tells consumers to deduplicate on the event id, and notes the producer's acks=1 / enable.idempotence=false setting as at odds with the guarantees (recommend acks=all and idempotence).",
+        "Flags that _publish runs before session.commit() so an event can be emitted for an order that then rolls back, and recommends publishing after commit via a transactional outbox (or equivalent).",
+        "Invents nothing not in the input: no extra consumer teams, fields, SLAs, throughput figures or tooling are presented as existing facts; any proposed values (retention length, deprecation dates, DLQ topic names) are labelled as proposals for the review."
+      ]
+    },
+    {
+      "id": 7,
+      "held_out": "2026-10-22",
+      "prompt": "partners keep complaining they get invoice_paid twice, and our webhook doc (docs/webhooks.yaml) is a mess. can u redo it as asyncapi 3? also while we're at it change amount to amount_cents as an int, the float thing is embarrassing. want to ship next sprint. oh and Brightwell Payroll says sometimes they get paid before created?? not sure if thats related",
+      "assertions": [
+        "Answers the actual request directly: returns a rewritten AsyncAPI 3.0 document for the Tallyfern invoice webhooks (operations with action, the 2.6 `subscribe` mapped to Tallyfern sending) plus a brief decisions note sized for a quick review, not a lecture.",
+        "Does not rename or retype `amount` in place: calls that a breaking change for existing partners, adds a new integer minor-unit field alongside the deprecated `amount`, and gives a dated deprecation/removal plan rather than shipping the swap next sprint.",
+        "Catches that the currency enum includes JPY (zero decimal places), so a field named amount_cents is wrong for it; uses minor units with the currency exponent (e.g. amount_minor) or otherwise defines the scale per currency.",
+        "Explains the duplicate invoice_paid deliveries as expected under at-least-once delivery with the 10s timeout and up-to-5 retries, adds a required unique event id that stays the same across retries, and tells partners to deduplicate on it and return 2xx quickly before processing.",
+        "Addresses Brightwell Payroll's paid-before-created report as a separate issue from duplicates: states webhooks have no ordering guarantee (retries can reorder them) and gives consumers a way to cope, such as an occurred-at timestamp or per-invoice sequence/version, tolerating unknown invoices, or fetching current invoice state.",
+        "Replaces 'after the 5th failure the event is dropped' with keeping failed deliveries (dead-letter) and a way for partners to replay or redeliver them, with any retention window marked as a proposal for the team to decide.",
+        "Marks customer.email and customer.tax_id (and name) as PII and minimises the payload, e.g. dropping tax_id or the embedded customer object in favour of an id, and flags that the HMAC signature covers only raw_body with no timestamp, so a captured request can be replayed; recommends signing a timestamp and enforcing a tolerance window.",
+        "Invents nothing not in the input: no partner names other than Brightwell Payroll, no endpoints, API routes, fields or existing features beyond those in docs/webhooks.yaml are presented as current fact; new elements are clearly proposed."
+      ]
     }
   ]
 }

package/packs/solution-architect/skills/event-contract-draft/evals/files/6/infra/topics.yaml

@@ -0,0 +1,10 @@
+# Kafka topics owned by the checkout team (cluster: larkspur-prod-1)
+topics:
+  - name: orders
+    partitions: 6
+    replication_factor: 3
+    config:
+      cleanup.policy: delete
+      retention.ms: 86400000        # 1 day
+      min.insync.replicas: 2
+    # Capacity note (Priya, ops): bump partitions to 24 before the November peak.

package/packs/solution-architect/skills/event-contract-draft/evals/files/6/src/checkout/order_events.py

@@ -0,0 +1,57 @@
+"""Order events emitted by the Larkspur Goods checkout service.
+
+Today these go onto the `orders` Kafka topic. Nobody wrote down a contract;
+this module *is* the contract right now.
+"""
+
+import json
+from datetime import datetime, timezone
+
+from checkout.db import session
+from checkout.kafka import producer  # configured in checkout/kafka.py with acks=1, enable.idempotence=false
+
+TOPIC = "orders"
+
+
+def _publish(event_type: str, order, extra: dict | None = None) -> None:
+    body = {
+        "event_type": event_type,
+        "ts": datetime.now(timezone.utc).isoformat(),
+        "order_id": order.id,
+        "customer_id": order.customer_id,
+        "customer_email": order.customer.email,
+        "customer_phone": order.customer.phone,
+        "shipping_address": order.shipping_address.as_dict(),
+        "card_number": order.payment.card_number,
+        "card_expiry": order.payment.card_expiry,
+        "total": float(order.total),
+        "currency": order.currency,
+        "lines": [
+            {"sku": line.sku, "qty": line.qty, "unit_price": float(line.unit_price)}
+            for line in order.lines
+        ],
+        "status": order.status,
+    }
+    if extra:
+        body.update(extra)
+    # TODO: pick a key. Round-robin for now so partitions stay even.
+    producer.send(TOPIC, key=None, value=json.dumps(body).encode())
+
+
+def create_order(order) -> None:
+    session.add(order)
+    _publish("create_order", order)
+    session.commit()
+
+
+def update_order_status(order, new_status: str) -> None:
+    # new_status is one of: "paid", "packed", "shipped", "delivered"
+    order.status = new_status
+    _publish("update_order_status", order, {"new_status": new_status})
+    session.commit()
+
+
+def cancel_order(order, reason: str) -> None:
+    order.status = "cancelled"
+    _publish("cancel_order", order, {"reason": reason})
+    session.commit()

package/packs/solution-architect/skills/event-contract-draft/evals/files/7/docs/webhooks.yaml

@@ -0,0 +1,40 @@
+asyncapi: 2.6.0
+info:
+  title: Tallyfern Invoice Webhooks
+  version: 0.3.0
+  description: |
+    Tallyfern POSTs these to the HTTPS endpoint a partner registers in the dashboard.
+    Delivery: we wait 10s for a 2xx. On timeout or non-2xx we retry up to 5 times
+    (1m, 5m, 15m, 1h, 6h). After the 5th failure the event is dropped.
+    Signing: header X-Tallyfern-Signature = hex(HMAC-SHA256(partner_secret, raw_body)).
+channels:
+  invoice-events:
+    subscribe:
+      message:
+        name: InvoiceEvent
+        payload:
+          type: object
+          properties:
+            event:
+              type: string
+              enum: [invoice_created, invoice_paid, invoice_voided]
+            invoice_id:
+              type: string
+            amount:
+              type: number
+              description: Invoice total in major units, e.g. 129.99
+            currency:
+              type: string
+              enum: [USD, EUR, GBP, JPY]
+            customer:
+              type: object
+              properties:
+                name:
+                  type: string
+                email:
+                  type: string
+                tax_id:
+                  type: string
+            paid_at:
+              type: string
+              format: date-time

package/packs/solution-architect/skills/event-contract-draft/manifest.json

@@ -1,6 +1,6 @@
 {
   "name": "event-contract-draft",
-  "version": "0.1.2",
+  "version": "0.1.3",
   "description": "Draft the contract for an event or message interface (Kafka topics, SNS/SQS, EventBridge, Pub/Sub, RabbitMQ, webhooks) as an AsyncAPI 3.0 document plus a short decisions page — past-tense event names, a required envelope with event id for deduplication, the partition key and the ordering it does and doesn't give, at-least-once delivery and how consumers stay idempotent, data minimisation with PII marked, additive-only versioning with dated deprecation, and retention, replay and dead-letter handling. Use when the user wants to define events, design a Kafka topic or message schema, write an AsyncAPI spec, agree what a producer publishes and what consumers must do, or version an event safely.",
   "entrypoint": "SKILL.md",
   "deps": { "npm": [], "pip": [] },