skilldrop-cli 0.16.21 → 0.16.23

package/bin/skilldrop.js

@@ -485,14 +485,16 @@ function scanSkill(cat, s) {
     try { body = fs.readFileSync(file, "utf8"); } catch (e) { continue; }
     const rules = isScript ? SCRIPT_RULES : PROSE_RULES;
     // Eval fixtures are benchmark input: a sample repo, a risky script for a reviewer to catch.
-    // The skill never runs or follows them, so they are listed, not raised.
-    const fixture = rel.split(path.sep).join("/").startsWith("evals/files/");
+    // Example inputs are the material a worked example was made from. The skill never runs or
+    // follows either, so they are listed, not raised.
+    const relPosix = rel.split(path.sep).join("/");
+    const fixture = relPosix.startsWith("evals/files/") || relPosix.startsWith("examples/inputs/");
     body.split(/\r?\n/).forEach((line, i) => {
       if (line.length > 400) return; // minified/data line — not reviewable prose or code
       for (const r of rules) {
         if (r.re.test(line))
           findings.push({ sev: fixture ? "⚪" : r.sev, id: r.id, fixture,
-                          why: fixture ? `in an eval fixture, which the skill never runs: ${r.why}` : r.why,
+                          why: fixture ? `in ${relPosix.startsWith("examples/") ? "an example's input" : "an eval fixture"}, which the skill never runs: ${r.why}` : r.why,
                           owasp: r.owasp, file: rel, line: i + 1, text: line.trim().slice(0, 120) });
       }
     });

package/catalogue.json

@@ -28,6 +28,7 @@
         "design-doc",
         "architecture-diagrams",
         "reverse-architecture",
+        "interactive-diagram",
         "figma-diagrams",
         "api-contract-draft",
         "data-contract",

package/model-routing.json

@@ -278,6 +278,10 @@
       "tier": "standard",
       "rationale": "Structured synthesis from a content list into groups, labels and a nav model against fixed IA practice. Grouping needs judgment, but the method and the validation plan bound it."
     },
+    "interactive-diagram": {
+      "tier": "standard",
+      "rationale": "Tracing a path through code and citing each part is careful reading, not adversarial judgement; the layout and the checks are done by the script."
+    },
     "job-fit-analysis": {
       "tier": "standard",
       "rationale": "Matches a posting's requirements to resume lines and reports the gaps. The rule is mechanical: no line in the resume, no credit."

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "skilldrop-cli",
-  "version": "0.16.21",
+  "version": "0.16.23",
   "description": "Portable AI-agent skills, measured against the agent without them. ADRs, PRDs, runbooks, decks and reviews, installable into Claude Code, Cursor, Kiro, and any IDE that takes custom instructions. One command per skill or per role-based pack.",
   "author": {
     "name": "Sanjay Ananthanarayan",

package/packs/solution-architect/skills/interactive-diagram/SKILL.md

@@ -0,0 +1,160 @@
+---
+name: interactive-diagram
+description: Turn a codebase, a system description, a process or a database schema into one self-contained interactive HTML diagram (architecture, workflow, data flow, lifecycle, ERD, sequence, class, tree, timeline or waterfall) where every box and arrow cites the file and line or the words it came from, anything inferred is drawn dashed as an assumption, and each cited line is checked against the repository before the page is written. Laid out automatically, opens offline with no CDN, and exports SVG, PNG and Mermaid. Use when the user asks to "visualize", "map" or "make an interactive diagram of" a repo, a request path, a pipeline, an approval process, a set of tables, an incident's events or a slow trace, or wants a diagram they can click through and share as one file.
+---
+
+# interactive-diagram
+
+**The rule: nothing goes on the map that the material doesn't show.** A diagram is trusted
+more than prose, so an invented box misleads more than an invented sentence. Asked to draw a
+repo, the agent's habit is to draw the system such repos usually have: a load balancer, an
+auth service, the Kafka the README says is planned. Here every part and every connection
+either cites where it came from (`src/api.py:40-52`, or the person's own words) or is drawn
+dashed and listed as an assumption. The script checks each cited file and line before it
+writes the page, and refuses a spec that cites a line that isn't there.
+
+Two things follow:
+
+- **One question per map.** Draw what answers the question asked ("what happens when an order
+  is placed"), not every module in the repo. A part that doesn't help answer it stays off,
+  and the reply says in one line what was left out.
+- **You write the meaning; the script does the layout.** Never write coordinates. List the
+  parts and connections in the order a reader meets them, and the script places them, routes
+  every arrow around the boxes, draws groups as boxes that don't overlap, and wraps a long
+  flow onto rows so its text stays readable.
+
+## How to respond
+
+1. **Name the question and pick the type.** One sentence: what will the reader understand
+   after looking? Then the type:
+
+   | Type | For |
+   |---|---|
+   | `architecture` | What a system is made of and what talks to what |
+   | `dataflow` | Where data or money or documents go, stage by stage |
+   | `workflow` | A process with steps, decisions and hand-offs, technical or everyday |
+   | `lifecycle` | The states something moves through and what moves it |
+   | `erd` | Tables, their columns and keys, and how they reference each other |
+   | `sequence` | Who calls whom, in order, for one request or exchange |
+   | `class` | Types, their members, and inherits, implements, composition and the rest |
+   | `tree` | What contains what, one parent each: a repo's folders, a capability breakdown, an org |
+   | `timeline` | When things happened, on a clock, one lane per source: an incident, a release history |
+   | `waterfall` | Where the time went in one request or run: spans to scale, nested, with the critical path |
+
+2. **Gather the facts, with where each came from.**
+   - **A repository:** trace the one path the question is about. Read the entry point, follow
+     the calls, and for each part and each arrow note the file and lines that show it. Add a
+     few characters from those lines after `#` (`src/api.py:12#stripe.PaymentIntent`) so a
+     wrong line number is caught. Config and README files show intent, not behaviour: a
+     service the README mentions but no code calls is left off, or drawn as an assumption with
+     the README as its only evidence and said so in the reply.
+   - **A description:** cite the person's words: `"user: anything over ten days goes to HR"`.
+   - **Something you believe but can't point to** (who calls the API, what the worker does
+     next): `"assumed": true`. It is drawn dashed and listed. Leave it off if it doesn't help
+     answer the question.
+   - **Times, for a timeline:** write each time as its source gives it, with its offset when
+     sources differ (`2026-10-11T03:41:00Z`, `2026-10-10T22:41-05:00`); the script puts them
+     on one clock. A time the source is unsure of gets `"approx": true`. Link two events
+     (`caused`, `fixed`) only when the material says one led to the other; an event that came
+     after another did not necessarily follow from it.
+   - **Spans, for a waterfall:** copy each span's start and end from the trace as they are,
+     including one that ends after its parent; the script flags it.
+   - **The person's guesses or questions** ("is it the north fetch?", "was it the vacuum?"):
+     answer each in `answers`, with evidence, or as an assumption when the material is silent.
+     They appear as a table at the top of the page.
+
+3. **Write the spec** as JSON next to where the page will go. The full shape, every kind and
+   the ERD and sequence fields are in [`reference.md`](reference.md). The essentials:
+
+   ```json
+   {"type": "architecture", "title": "What a checkout request touches",
+    "question": "What happens when a shopper checks out?",
+    "summary": "One or two sentences: the takeaway a reader should leave with.",
+    "groups": [{"id": "vpc", "label": "Private VPC"}],
+    "nodes": [{"id": "api", "label": "Checkout API", "kind": "service", "group": "vpc",
+               "note": "FastAPI", "evidence": ["src/api.py:8-14#def checkout"]}],
+    "edges": [{"from": "api", "to": "db", "label": "insert order", "evidence": ["src/api.py:13"]}],
+    "story": [{"text": "The API checks the cache first.", "edges": ["e2"]}]}
+   ```
+
+   Labels are a few words; detail goes in `note` (shown on the box) or `detail` (shown when
+   clicked). For a timeline, set `timezone` to the zone the reader works in. Write `summary`
+   last, from what the script computed: a summary that says "over four hours" beside a
+   computed 3h 37m is the kind of slip the page exists to prevent. Add a `story` of three to seven steps when the map has a main path worth walking.
+
+4. **Build it.** With a repository, always pass `--repo-root` so the citations are checked.
+   For a waterfall or a timeline the script also prints what it computed (each span's own
+   time, which spans overlap, the longest quiet stretch, time zones): use those numbers in the
+   reply as they are, and never add up durations yourself.
+
+   ```bash
+   # Claude Code
+   python3 "${CLAUDE_SKILL_DIR}/scripts/build_diagram.py" diagram.json -o diagram.html --repo-root .
+   # Other IDEs (from the skill folder)
+   python3 scripts/build_diagram.py diagram.json -o diagram.html --repo-root .
+   ```
+
+   Errors list the item, what is wrong and the fix, and nothing is written until they're gone.
+   Fix the spec, never the evidence: a citation the check can't find is wrong, so find the
+   right lines or mark the item assumed. Add `--mermaid diagram.mmd` for a version to paste
+   into a README, and `--compare old.json` to show what a change adds, removes and alters.
+
+5. **Reply with the map first.** The script prints the line to open with: a link to the page,
+   titled. Use it as the first line, then the takeaway in one or two sentences, then one line
+   each for what is drawn as an assumption and what was left out, and last how many citations
+   were checked:
+
+   > **What a checkout request touches** (the script's link line: the title, linked to the page)
+   >
+   > The API charges Stripe before it records the order, and a worker books the courier later.
+   > Assumed: the shopper's browser (no client in this repo). Left out: the products table's
+   > other readers. 22 of 22 citations checked.
+
+   Keep the spec beside the page so the map can be rebuilt after the code changes. No recap of
+   commands or layout, and nothing before the link.
+
+6. **When the script can't run** (no `python3`), give the Mermaid version in the reply, with
+   assumptions marked, and say that the interactive page needs Python 3.
+
+This is a non-interactive skill: don't stop to ask. With too little to draw from, draw what
+you have, mark the rest as assumptions, and say in the reply what would settle them.
+
+**Sharing:** the page shows the cited lines when a part is clicked. Files that hold secrets
+(`.env`, keys, credential files) are never shown and secret-looking lines are masked, but
+don't cite them in the first place, and read the page before it leaves the team.
+
+## Quality bar
+
+- **Every part and connection cites its source or is drawn as an assumption.** No exceptions
+  for the "obvious" ones.
+- **Every file citation was checked** against the repository, with the count in the reply.
+- **Nothing on the map comes only from a README, a plan or what such systems usually have.**
+- **The map answers one stated question,** and what was left out is said.
+- **One HTML file that works offline:** no CDN, no external fonts, no network requests.
+- **The reply opens with the link and the takeaway,** not with how it was made.
+
+## When to use this skill
+
+- ✅ "Map what happens when an order is placed in this repo, as something I can click through"
+- ✅ "Turn this description of our approval process into an interactive flowchart for the team"
+- ✅ "Give me an interactive ERD of schema.sql"
+- ✅ "Show what this branch changes in the architecture" (two specs and `--compare`)
+
+## When NOT to use this skill
+
+- ❌ A Mermaid, PlantUML or C4 diagram to paste into a doc — use `architecture-diagrams`
+- ❌ An as-is architecture write-up in C4 levels from infrastructure files — use `reverse-architecture`
+- ❌ Fixing or rendering an existing Mermaid diagram — use `mermaid-render`
+- ❌ Charts of numbers, dashboards or metrics — this draws structure, not data
+
+## Anti-patterns to avoid
+
+- ❌ **The usual architecture.** A load balancer, CDN or auth service drawn because systems
+  like this have one.
+- ❌ **README as evidence of behaviour.** "We use Kafka" in a README is a plan until code
+  calls it.
+- ❌ **Deleting evidence to pass the check.** A failed citation means the line is wrong or
+  the part is an assumption.
+- ❌ **Everything in the repo.** Forty boxes answer no question.
+- ❌ **Hand-placed coordinates** or a hand-written SVG instead of the script.
+- ❌ **A page that loads a library from a CDN.** It breaks offline and leaks the viewer's IP.

package/packs/solution-architect/skills/interactive-diagram/evals/eval_queries.json

@@ -0,0 +1,12 @@
+[
+  {"query": "Make an interactive diagram of what happens when someone places an order in this repo", "should_trigger": true},
+  {"query": "Visualize our request flow as an HTML page I can click around and send to the team", "should_trigger": true},
+  {"query": "Turn this description of our purchase approval process into an interactive flowchart", "should_trigger": true},
+  {"query": "Give me an explorable ERD of schema.sql as a single HTML file", "should_trigger": true},
+  {"query": "Map how this service talks to the database and the queue, with links back to the code", "should_trigger": true},
+  {"query": "Show what this branch changes in the architecture compared with main, as an interactive diagram", "should_trigger": true},
+  {"query": "Write a Mermaid C4 container diagram for the design doc from this description", "should_trigger": false},
+  {"query": "My mermaid flowchart says parse error on line 3, can you fix it and export a PNG", "should_trigger": false},
+  {"query": "Reverse-engineer the as-is architecture from our Terraform and write it up in C4 levels", "should_trigger": false},
+  {"query": "Build a dashboard chart of weekly signups from this CSV", "should_trigger": false}
+]

package/packs/solution-architect/skills/interactive-diagram/evals/evals.json

@@ -0,0 +1,164 @@
+{
+  "skill_name": "interactive-diagram",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "This is the Larder repo. I'm onboarding two new developers next week. Can you make an interactive diagram, one HTML file I can send them, of what happens when a customer places an order?",
+      "assertions": [
+        "An HTML file is written that works on its own offline: it loads no script, stylesheet or font from a CDN or any http(s) URL",
+        "The diagram shows the order path the code shows: the web checkout posting to the API's POST /orders, the API validating and inserting into Postgres, pushing an email job onto the Redis 'emails' list, and the worker popping it and posting to the mailer service",
+        "Kafka does not appear as part of the order path; if it is mentioned at all, it is described as planned in the README and not in the code",
+        "No payment step or payment provider appears in the order path (the README says payment is taken in the shop on collection)",
+        "It does not add parts the repo does not contain, such as a load balancer, CDN, auth service, cache or separate analytics service",
+        "The parts or connections in the diagram, or the page's text, name the files they come from (for example api/app.py, worker/worker.py, web/checkout.js, docker-compose.yml)",
+        "Anything drawn that the code does not show (for example who hosts the mailer, or what happens after the email is sent) is marked as an assumption, or left off",
+        "The reply opens with where the file is and what the diagram shows, in a few sentences, without a long account of how it was built"
+      ]
+    },
+    {
+      "id": 2,
+      "prompt": "Can you turn this into an interactive flowchart I can share with the team as a single file? Here's how expense claims work at our office: you fill in a claim in the finance portal and attach the receipts. Your line manager approves it. If it's over £500 it also needs the finance director. Finance then checks the receipts match and pays it in the next payroll run. Claims older than 90 days are rejected automatically when you submit them.",
+      "assertions": [
+        "An HTML file is written that works on its own offline, loading nothing from a CDN or any http(s) URL",
+        "The flow includes, in order: submit in the finance portal with receipts, the automatic rejection of claims older than 90 days, line manager approval, the over £500 decision leading to finance director approval, finance checking receipts, and payment in the next payroll run",
+        "The over £500 rule and the 90-day rule are drawn as decisions or branches, not as plain steps",
+        "What happens when the line manager or finance director declines, or when receipts don't match, is not stated in the description, so it is either left off or visibly marked as an assumption, never drawn as a definite step",
+        "It adds no steps, roles, systems or thresholds the description does not contain (for example no budget-holder step, no expense card, no second threshold)",
+        "The reply is short: where the file is, what it shows, and which paths were not covered by the description"
+      ]
+    },
+    {
+      "id": 3,
+      "prompt": "I need an interactive ERD of schema.sql for the team wiki - something people can click on to see the columns. One self-contained HTML file.",
+      "assertions": [
+        "An HTML file is written that works on its own offline, loading nothing from a CDN or any http(s) URL",
+        "All five tables appear (clinics, practitioners, patients, appointments, appointment_notes) with every column the schema defines and no column it does not",
+        "The four foreign keys are drawn as relationships with the right direction: practitioners to clinics, appointments to practitioners, appointments to patients, appointment_notes to appointments",
+        "booked_by_user_id is shown as a column but no relationship is drawn for it to a users or staff table as if it existed; if it is mentioned, the reply or page says it has no table in this schema",
+        "Primary keys and foreign keys are marked on their columns, and appointment_notes.appointment_id is shown as both",
+        "appointment_notes to appointments is shown as one-to-one or at most one note per appointment, not one-to-many",
+        "It invents no tables, columns, indexes or constraints that schema.sql does not contain"
+      ]
+    },
+    {
+      "id": 4,
+      "held_out": "2026-10-18",
+      "prompt": "This is castbox-media, the backend for our podcast hosting platform. I need to explain to the new on-call engineer what actually happens when a creator's episode upload finishes and the storage webhook hits us, up to the point where we stop being in control. Make me an interactive diagram of that path I can click through and send them as one file.",
+      "assertions": [
+        "Writes one self-contained HTML file that opens offline: no <script src>, <link href>, @import or font URL pointing at http(s), and the diagram's code and styles are inline",
+        "Shows the path in order: the object store's webhook to POST /webhooks/storage (src/server.js), handleStorageWebhook checking the x-storage-signature HMAC and the object.finalized event type (src/handlers/storageWebhook.js), the episodes row set to 'uploaded' in PostgreSQL, a 'transcribe-episode' job added to the Redis/BullMQ 'media' queue, the worker (src/worker.js) running transcribeEpisode (src/jobs/transcribeEpisode.js), submitTranscription POSTing to the transcription API's /v2/jobs (src/clients/transcription.js), the episode set to 'transcribing' with its transcription_job_id, and the processing email sent over SMTP via src/mailer.js",
+        "Shows at least one of the branches the code takes: bad signature returns 401, non-finalized events return 204 and are ignored, an unknown or already-taken upload_key is ignored, the email only goes out when notify_on_processing is true, or the episode is marked 'failed' after the 3 attempts are used up",
+        "Boxes and arrows cite the source file (and line where given) they came from, and every cited file is one that exists in the repo",
+        "Does not draw transcoding, the search indexing or the CDN purge as steps on this path: the README and config/default.json mention them but no code on the upload path calls them (search is only used by the nightly 'nightly-reindex' job, and transcoding and CDN purge appear in no code). If shown at all, they are marked as not called or as claims from the README",
+        "Keeps the other paths out of the main flow: the GET /feeds/:showId.xml RSS route and the 03:00 nightly-reindex job are either absent or clearly marked as separate from the upload path",
+        "Does not present what the transcription service does after accepting the job as fact: the callback to /webhooks/transcription is dashed, marked as an assumption or left out, and the reply or diagram notes that src/server.js registers no /webhooks/transcription route, so nothing in this repo receives the result or moves the episode to 'published'",
+        "The reply opens with where the HTML file is and the main takeaway (for example that the app's part ends once the job is submitted and the email sent, and the transcript callback has no handler), not with a long account of how the diagram was made"
+      ]
+    },
+    {
+      "id": 5,
+      "held_out": "2026-10-18",
+      "prompt": "Can you make an interactive sequence diagram of how a repair request goes through at Fernhill Housing Co-op? I want to show it to our board next week as one file they can open. Here's how it works as far as I know:\n\nA tenant phones the contact centre or fills in the web form to report a repair. The contact centre logs it in our housing management system (HMS) and gives the tenant a reference number. Every weekday morning the repairs coordinator goes through the new jobs in HMS, decides the priority (emergency = attend within 24 hours, routine = within 20 working days) and assigns it to one of our two contractors by emailing them the job sheet. The contractor rings the tenant to book a visit, then does the work. After the visit the contractor marks the job complete in their own portal. At the end of each month the contractor sends us an invoice listing the jobs they finished, and finance closes those jobs in HMS when they pay the invoice.\n\nIf the contractor needs to order parts I'm honestly not sure what happens, I think they tell the coordinator? We used to post the tenant a confirmation letter when a job was closed but we stopped doing that in 2025. There's also the annual gas safety check programme but that's a different process, leave it out.",
+      "assertions": [
+        "Writes one self-contained HTML file that opens offline: no <script src>, <link href>, @import or font URL pointing at http(s), and the diagram's code and styles are inline",
+        "It is a sequence diagram with at least these participants: tenant, contact centre, HMS, repairs coordinator, contractor and finance (the contractor's portal may be its own participant or part of the contractor)",
+        "The messages run in this order: tenant reports by phone or web form; contact centre logs the job in HMS and gives the tenant a reference number; the coordinator reviews new jobs each weekday morning, sets the priority (emergency 24 hours, routine 20 working days) and emails the job sheet to a contractor; the contractor rings the tenant to book and does the visit; the contractor marks the job complete in its own portal; the contractor sends a monthly invoice to finance; finance closes the jobs in HMS on payment",
+        "The parts-ordering step is drawn dashed or labelled as an assumption or unconfirmed (the user said they are not sure), not as a solid confirmed message",
+        "The posted confirmation letter does not appear as a current step (absent, or shown only as stopped in 2025), and the gas safety check programme does not appear",
+        "Points out at least one hand-off gap the description reveals: nothing tells the tenant the repair is finished or closed; HMS only learns a job is done when finance pays the monthly invoice, so jobs stay open in HMS for weeks; or an emergency reported after the morning review waits until the next weekday morning before the coordinator sees it",
+        "Each message carries or cites the words from the user's description it came from, and the diagram adds no participants or systems the user did not describe (for example no SMS service, CRM, scheduling tool or tenant app)",
+        "The reply opens with where the HTML file is and the main takeaway (such as the gap found), not with a long account of how the diagram was made"
+      ]
+    },
+    {
+      "id": 6,
+      "held_out": "2026-10-19",
+      "prompt": "Quote requests on our freight API have been slow since last week. I exported one of the slow traces to trace-quote-slow.jsonl and put my notes in notes.txt. Can you make me an interactive diagram showing where the time went? I want to send it to the rates team.",
+      "assertions": [
+        "The output is one self-contained .html file that works offline: it has no <script src>, <link href>, @import or font URL pointing at http(s) or a CDN, and its scripts and styles are inline",
+        "The request's total is given as 4,200 ms (4.2 s), the root span POST /v2/quotes from 09:41:07.300 to 09:41:11.500 UTC; the total is not given as 4,610 ms (the late end of emit quote.created) or as the sum of the span durations",
+        "The biggest contributor is named as the carrier_rates north-line call in rates-svc at 2,600 ms, about 62% of the 4,200 ms total",
+        "carrier_rates north-line (2,600 ms) and carrier_rates coastal (2,385 ms) are shown or described as running in parallel, with coastal entirely inside north-line's window; their sum (4,985 ms, the notes' '~5s') is not presented as time the request spent on carriers, and the carrier calls together take about 2,600 ms of wall-clock time",
+        "build_quote (4,090 ms) is distinguished as almost all waiting on its children, with under 100 ms of its own time, while price_and_rank (1,050 ms) is called out as about 1,040 ms of its own work (its only child, GET fx:EUR-USD, takes 8 ms), the second place to look after north-line",
+        "The emit quote.created span (notify-svc, PRODUCER) is flagged as ending at 4,610 ms, after its parent build_quote (4,150 ms) and the root (4,200 ms) end, so it is async or clock skew, and it is not counted in the 4.2 s the user waited",
+        "The rate limiter or Redis rate-limit check from the notes is said not to be in the trace; it is not drawn as a measured span or given a duration (if it is shown at all, it is marked as not in the trace or an assumption), and no other spans, services or timings are made up",
+        "The reply's first line is the path of, or a link to, the HTML file, followed by the takeaway (for example, north-line's carrier call is about 62% of the 4.2 s), not an account of how the diagram was built"
+      ]
+    },
+    {
+      "id": 7,
+      "held_out": "2026-10-19",
+      "prompt": "Can you turn INC-0412 (the frozen arrival boards on Saturday night) into an interactive timeline I can drop into the review doc? system-log.txt is the export from the central log and oncall-notes.md is what I typed during the night. Review is Tuesday.",
+      "assertions": [
+        "The output is one self-contained .html file that works offline: it has no <script src>, <link href>, @import or font URL pointing at http(s) or a CDN, and its scripts and styles are inline",
+        "The notes' CDT times and the log's UTC times are on one clock (UTC = CDT + 5 h): the supervisor's 10:41pm call is placed at 03:41 UTC on 11 Oct, after the 00:03:40 UTC warning and before the 03:44:20 UTC page, not at 22:41 UTC on 10 Oct; the 12:05am all-clear is on 11 Oct and comes last, not before the evening events",
+        "The logged events appear at their correct times: v3.14.0 deploy at 23:58:12 UTC on 10 Oct (6:58pm CDT), the 'serving last-known positions' warning at 00:03:40 UTC, INC-0412 opened at 03:44:20 and acknowledged at 03:46:02, the feed recovering at 04:12:07, the rollback to v3.13.2 at 04:31:45 and the incident resolved at 05:05:40 UTC",
+        "Events from the system log and from the on-call notes are kept apart as two lanes or clearly labelled sources, and each event can be traced back to the file it came from",
+        "The quiet gap of about 3 h 37 min (00:03:40 UTC to the 03:41 UTC call; about 3 h 41 min to the 03:44:20 page) is shown or stated as a period with nothing logged and no alert, and it says the FeedStale alert never fired and a person found the problem; no events are invented inside the gap",
+        "The avl-ingest restart is shown as uncertain or approximate, around 11:05 to 11:15pm CDT (04:05 to 04:15 UTC), drawn dashed or labelled as not confirmed by any log, and is not given as a precise logged time",
+        "The rollback to v3.13.2 at 04:31:45 UTC is not presented as what fixed the boards, since the feed had already recovered at 04:12:07 (about 19 minutes earlier), and the v3.14.0 deploy is not stated as the confirmed cause; the boards are given as stale for about 4 h 8 min (00:03:40 to 04:12:07 UTC)",
+        "The reply's first line is the path of, or a link to, the HTML file, followed by the takeaway (for example, the boards were stale for about 4 h 8 min and no alert fired, so a person found it after about 3 h 37 min), not an account of how the timeline was built"
+      ]
+    },
+    {
+      "id": 8,
+      "held_out": "2026-10-19",
+      "prompt": "Last night's nightly-sky-ingest run at the observatory took 25 minutes and the morning team wants to know where the time went. The orchestrator export is run-4471.json. My guess: it's the north site fetch again (their link has been flaky), plus the vacuum on catalog-db that kicks off around 1am. Calibrate is probably just sitting there waiting on the dark and flat loads. Can you make me an interactive diagram I can share with the team that shows where the time went?",
+      "assertions": [
+        "Writes one self-contained HTML file that opens offline: no <script src>, <link href>, @import or font URL pointing at http(s) or a CDN",
+        "Shows the run's wall-clock time as 25 minutes (1,500 s, 01:00:00 to 01:25:00 UTC) with the five top-level steps nested under it at their real durations: checkout_config 20 s, fetch_frames 600 s, calibrate 480 s, stack_and_publish 392 s, send_summary 8 s",
+        "Treats fetch_north, fetch_south and fetch_east as parallel (all start at 01:00:22): does not add their 1,084 s (or 1,092 s with verify_checksums) as time spent, and names fetch_south (588 s, finished 01:10:10) as the step that held fetch_frames to 600 s",
+        "Says the north site fetch was not the bottleneck: fetch_north took 278 s and finished at 01:05:00, about five minutes before fetch_south, contrary to the user's guess",
+        "Distinguishes calibrate, which is long because of its own work (about 420 s of its 480 s falls outside load_darks and load_flats, 30 s each), from fetch_frames, which is long only because it waits on its children (about 4 s of its own), and so contradicts the guess that calibrate is just waiting on the loads",
+        "Flags upload_thumbnails as detached or asynchronous: it finishes at 01:28:40, 228 s after its parent stack_and_publish ended (01:24:52) and 220 s after the run reported finished, and does not count those minutes in the 25-minute run time",
+        "Says the catalog-db vacuum does not appear anywhere in the export, so this data can neither confirm nor blame it; if it is drawn at all it is marked as an assumption, not as a measured step. Invents no other steps, durations, hosts or a 'usual' run time not in the file or the prompt",
+        "The reply's first line is the path of (or a link to) the HTML file, followed by the takeaway (for example that fetch_south and calibrate's own work account for most of the 25 minutes), not an account of how the diagram was built"
+      ]
+    },
+    {
+      "id": 9,
+      "held_out": "2026-10-19",
+      "prompt": "We need a timeline of what happened with the lesson-sync downloads on the night of 14 October for Thursday's review. I've exported the team chat (chat-export.txt), the service log (lesson-sync.log) and the support ticket history (ticket-8812.csv). Make me an interactive diagram showing when things happened.",
+      "assertions": [
+        "Writes one self-contained HTML file that opens offline: no <script src>, <link href>, @import or font URL pointing at http(s) or a CDN",
+        "Puts all three sources on one labelled clock, converting the chat from Asia/Kolkata (UTC+05:30) and handling the date change: for example the chat's '15/10 03:55 rolling back' is shown as 14 Oct 22:25 UTC, between the deploy (21:40:12 UTC) and rollback complete (22:31:04 UTC), not as a separate set of events on 15 October after the log",
+        "Shows these events at the right times (UTC, or correctly converted): v4.12.0 deploy complete 21:40:12 on 14 Oct; first 'manifest checksum mismatch' 21:52:30; ticket 8812 opened 22:05; rollback to v4.11.3 complete 22:31:04; last checksum error 22:33:41; school confirms downloads working 22:48; max_retries 3 -> 5 config change 06:12 on 15 Oct; ticket resolved 06:40 on 15 Oct",
+        "Shows the quiet period with no events in any source, from about 22:50 UTC on 14 Oct to 06:12 UTC on 15 Oct (about 7 h 22 min), as a gap, and does not suggest the outage continued through it",
+        "Marks the CDN purge as uncertain (dashed, flagged or worded as unconfirmed) at about 22:20 UTC (03:50 IST), because dev-ravi's message hedges it and it does not appear in the log or the ticket; it is not presented as a confirmed event or as the fix",
+        "Does not credit the 06:12 max_retries change as the fix, despite the ticket's resolution note: errors stopped at 22:33:41, about 2.5 minutes after the rollback completed, the success rate was back to 99.6% at 22:40 and the school confirmed at 22:48, all more than 7 hours before the config change",
+        "Invents nothing: no root cause for why v4.12.0 broke checksums beyond what the sources say (the errors starting after the deploy and stopping after the rollback may be described as a correlation), and no events, people or times not in the three files, nor error or school counts beyond what can be counted from them (the log has 9 checksum-mismatch errors)",
+        "The reply's first line is the path of (or a link to) the HTML file, followed by the takeaway (for example that the errors began about 12 minutes after the v4.12.0 deploy and ended with the rollback, not the morning retry change), not an account of how the diagram was built"
+      ]
+    },
+    {
+      "id": 10,
+      "held_out": "2026-10-19",
+      "prompt": "Last night's nightly build of our game took 46 minutes. build-4127-timing.json is the timing export from our CI. Make me an interactive diagram of where the time went that I can share with the team as one file. My guess is the new water shaders made shader compilation slow, or else we're stuck waiting for the signing machines. Someone on the team also reckons the debug-symbol upload holds up the rest of the build. Which of those is it?",
+      "assertions": [
+        "Writes one self-contained HTML file that opens offline: no CDN, and no http(s) script, stylesheet or font references",
+        "Shows all 15 steps nested under the right parents, with the right durations: build 46:00, sync_sources 2:20, compile 15:00, cook_assets 6:00, bake_lighting 10:40, package 12:00. compile_engine (15:00), compile_gameplay (8:00) and compile_editor_tools (5:30) are drawn as parallel bars starting together at 2:20, and compile is 15 minutes, set by compile_engine, not their 28:30 sum",
+        "Confirms the signing guess: package takes 12 minutes, but 9 minutes of that (540 s, 34:00 to 43:00) is spent waiting for a free agent in sign-pool. sign_binaries and make_installer take only 1:30 each, 3 minutes in all",
+        "Rejects the shader guess as not supported: compile_shaders took 3:00, running alongside cook_textures (6:00), so cook_assets' 6 minutes is set by cook_textures and a faster shader compile would not shorten the build. Mentioning the 61 water_surface permutations is fine, but they must not be blamed for the build time",
+        "Shows upload_debug_symbols (10:20 to 24:20, 14:00) running past the end of its parent compile (17:20) rather than cutting it off at the parent's end, and rejects the claim that it holds up the build: it is marked blocking=false and bake_lighting starts at 23:20 without waiting for it",
+        "Identifies bake_lighting (10:40, about 97% CPU, a leaf step with no children and no wait) as time spent on its own work, citing the lightmap cache miss on 38 of 38 levels, and does not call it waiting",
+        "Gives durations in minutes and seconds, not raw milliseconds such as 2760000. Invents nothing: no steps, causes or timings that are not in the export, and no claim about what changed since earlier builds, because the export covers one build only",
+        "The reply's first line is a link to or the path of the HTML file, followed by the takeaway: about 9 of the 46 minutes is queueing for a signing agent, and the shader and symbol-upload guesses are not supported"
+      ]
+    },
+    {
+      "id": 11,
+      "held_out": "2026-10-19",
+      "prompt": "These are the core classes from our greenhouse controller, under src/. A new developer starts on Monday. Can you make them a class diagram they can click through, one file I can send them? It should show what implements or extends what, and which things a class owns versus just holds a reference to.",
+      "assertions": [
+        "Writes one self-contained HTML file that opens offline: no CDN, and no http(s) script, stylesheet or font references",
+        "Shows all seven types from the source and their kinds: Sensor is an interface; AbstractSensor is abstract and implements Sensor; SoilMoistureSensor and TemperatureSensor extend AbstractSensor (they do not implement Sensor directly); Zone, Greenhouse and AlertService are concrete classes",
+        "Draws Greenhouse to Zone as composition (ownership), because Greenhouse creates each Zone in addZone, holds them in a private list, and Zone's constructor is package-private. This is drawn differently from Greenhouse to AlertService, a plain reference to a shared service passed in through the constructor",
+        "Draws Zone to Sensor as an association or aggregation to the Sensor interface (sensors are created elsewhere and attached with attach()), not as composition and not as links to the concrete sensor classes",
+        "WateringSchedule, which appears only in Greenhouse's doc comment, is not drawn as a real class. Either it is left out, or it is drawn dashed and marked as not found in the source, and the reply says it does not exist in the code",
+        "Members shown are accurate: for example, AbstractSensor has the final read(), isOutOfRange(), id() and the abstract rawValue(); both concrete sensors have onSample(); SoilMoistureSensor has adcChannel. No invented classes, fields, methods or relations, such as a Reading class, setters, or a link from a sensor back to Zone",
+        "Each class and relation cites the file it came from, with a line where one applies (for example Greenhouse.java line 12 or 21 for the zones composition, AbstractSensor.java line 7 for implements Sensor)",
+        "The reply's first line is a link to or the path of the HTML file, followed by the takeaway: one interface, one abstract base and two sensors; Greenhouse owns its Zones but only references AlertService; and WateringSchedule is named in a comment but missing from the code"
+      ]
+    }
+  ]
+}

package/packs/solution-architect/skills/interactive-diagram/evals/files/1/README.md

@@ -0,0 +1,11 @@
+# Larder
+
+Grocery ordering for small shops. Customers order on the web, the shop gets an email.
+
+## Architecture
+
+- `web/` - the storefront
+- `api/` - order API (Flask)
+- `worker/` - sends confirmation emails
+- Order events go to Kafka so analytics can consume them (planned for Q3).
+- Payments are taken in the shop on collection, not online.

package/packs/solution-architect/skills/interactive-diagram/evals/files/1/api/app.py

@@ -0,0 +1,43 @@
+import json
+import os
+
+import psycopg
+import redis
+from flask import Flask, jsonify, request
+
+app = Flask(__name__)
+db = psycopg.connect(os.environ["DATABASE_URL"])
+queue = redis.Redis.from_url(os.environ["REDIS_URL"])
+
+
+def validate(order):
+    if not order.get("items"):
+        return "an order needs at least one item"
+    if not order.get("email"):
+        return "an order needs an email for the confirmation"
+
+
+@app.post("/orders")
+def place_order():
+    order = request.get_json()
+    problem = validate(order)
+    if problem:
+        # the first rule the order breaks, in words the storefront can show
+        return jsonify(error=problem), 400
+    with db.cursor() as cur:
+        cur.execute(
+            "insert into orders (shop_id, email, items) values (%s, %s, %s) returning id",
+            (order["shop_id"], order["email"], json.dumps(order["items"])),
+        )
+        order_id = cur.fetchone()[0]
+    db.commit()
+    queue.lpush("emails", json.dumps({"order_id": order_id, "to": order["email"]}))
+    return jsonify(id=order_id), 201
+
+
+@app.get("/orders/<int:order_id>")
+def get_order(order_id):
+    with db.cursor() as cur:
+        cur.execute("select id, status from orders where id = %s", (order_id,))
+        row = cur.fetchone()
+    return jsonify(id=row[0], status=row[1]) if row else ("", 404)

package/packs/solution-architect/skills/interactive-diagram/evals/files/1/docker-compose.yml

@@ -0,0 +1,20 @@
+services:
+  web:
+    build: ./web
+    ports: ["8080:80"]
+  api:
+    build: ./api
+    environment:
+      DATABASE_URL: postgresql://larder@db/larder
+      REDIS_URL: redis://queue:6379/0
+    depends_on: [db, queue]
+  worker:
+    build: ./worker
+    environment:
+      REDIS_URL: redis://queue:6379/0
+      MAILER_URL: https://api.mailer.example/v1/send
+    depends_on: [queue]
+  db:
+    image: postgres:16
+  queue:
+    image: redis:7

package/packs/solution-architect/skills/interactive-diagram/evals/files/1/web/checkout.js

@@ -0,0 +1,9 @@
+export async function placeOrder(cart, email, shopId) {
+  const res = await fetch("/api/orders", {
+    method: "POST",
+    headers: { "Content-Type": "application/json" },
+    body: JSON.stringify({ items: cart.items, email, shop_id: shopId }),
+  });
+  if (!res.ok) throw new Error((await res.json()).error);
+  return (await res.json()).id;
+}

package/packs/solution-architect/skills/interactive-diagram/evals/files/1/worker/worker.py

@@ -0,0 +1,23 @@
+import json
+import os
+
+import redis
+import requests
+
+queue = redis.Redis.from_url(os.environ["REDIS_URL"])
+MAILER_URL = os.environ["MAILER_URL"]
+
+
+def run():
+    while True:
+        _, raw = queue.brpop("emails")
+        job = json.loads(raw)
+        requests.post(MAILER_URL, json={
+            "to": job["to"],
+            "template": "order-confirmation",
+            "data": {"order_id": job["order_id"]},
+        }, timeout=10)
+
+
+if __name__ == "__main__":
+    run()