skilldrop-cli 0.16.22 → 0.16.24

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "skilldrop-cli",
-  "version": "0.16.22",
+  "version": "0.16.24",
   "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/design-doc/manifest.json

@@ -1,6 +1,6 @@
 {
   "name": "design-doc",
-  "version": "0.1.2",
+  "version": "0.1.3",
   "description": "Generate a Google-style engineering design doc (problem, goals/non-goals, options considered, recommended approach, risks, rollout) from a feature brief or short description. Use when the user wants to draft a design doc, technical proposal, or one-pager for an engineering review.",
   "entrypoint": "SKILL.md",
   "deps": { "npm": [], "pip": [] },

package/packs/solution-architect/skills/design-doc/templates/design-doc.md

@@ -3,7 +3,7 @@
 | Field | Value |
 |---|---|
 | Status | {Draft / In Review / Approved / Implemented} |
-| Author(s) | {Names} |
+| Author(s) | {Names the brief gives; leave blank if it gives none} |
 | Reviewers | {Names — list the people whose approval you need} |
 | Date | {YYYY-MM-DD} |
 | Related | {Links to ADRs, prior design docs, tickets} |

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

@@ -1,6 +1,6 @@
 ---
 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 or sequence) 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 or a set of tables, or wants a diagram they can click through and share as one file.
+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
@@ -20,7 +20,8 @@ Two things follow:
   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, and draws groups as boxes that don't overlap.
+  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
 
@@ -35,6 +36,10 @@ Two things follow:
    | `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
@@ -47,6 +52,16 @@ Two things follow:
    - **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:
@@ -63,9 +78,14 @@ Two things follow:
    ```
 
    Labels are a few words; detail goes in `note` (shown on the box) or `detail` (shown when
-   clicked). Add a `story` of three to seven steps when the map has a main path worth walking.
+   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:
+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
@@ -79,11 +99,19 @@ Two things follow:
    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 first line is the link to the HTML file and what it
-   shows. 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. Keep the
-   spec beside the page so the map can be rebuilt after the code changes. No recap of
-   commands or layout.
+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.

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

@@ -69,6 +69,96 @@
         "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/10/build-4127-timing.json

@@ -0,0 +1,179 @@
+{
+  "exporter": "Ridgeback CI timing export v2",
+  "pipeline": "lantern-nightly",
+  "build": "4127",
+  "started_at": "2026-10-18T02:00:00Z",
+  "result": "success",
+  "time_unit": "ms, relative to started_at",
+  "steps": [
+    {
+      "id": 1,
+      "parent_id": null,
+      "name": "build-4127",
+      "agent": "ci-coord-01",
+      "start_ms": 0,
+      "end_ms": 2760000
+    },
+    {
+      "id": 2,
+      "parent_id": 1,
+      "name": "sync_sources",
+      "agent": "build-agent-07",
+      "start_ms": 0,
+      "end_ms": 140000,
+      "avg_cpu_pct": 21
+    },
+    {
+      "id": 3,
+      "parent_id": 1,
+      "name": "compile",
+      "agent": "build-agent-07",
+      "start_ms": 140000,
+      "end_ms": 1040000
+    },
+    {
+      "id": 4,
+      "parent_id": 3,
+      "name": "compile_engine",
+      "agent": "build-agent-07",
+      "start_ms": 140000,
+      "end_ms": 1040000,
+      "avg_cpu_pct": 94
+    },
+    {
+      "id": 5,
+      "parent_id": 3,
+      "name": "compile_gameplay",
+      "agent": "build-agent-11",
+      "start_ms": 140000,
+      "end_ms": 620000,
+      "avg_cpu_pct": 91
+    },
+    {
+      "id": 6,
+      "parent_id": 3,
+      "name": "compile_editor_tools",
+      "agent": "build-agent-12",
+      "start_ms": 140000,
+      "end_ms": 470000,
+      "avg_cpu_pct": 88
+    },
+    {
+      "id": 7,
+      "parent_id": 3,
+      "name": "upload_debug_symbols",
+      "agent": "build-agent-11",
+      "start_ms": 620000,
+      "end_ms": 1460000,
+      "avg_cpu_pct": 6,
+      "blocking": false
+    },
+    {
+      "id": 8,
+      "parent_id": 1,
+      "name": "cook_assets",
+      "agent": "build-agent-07",
+      "start_ms": 1040000,
+      "end_ms": 1400000
+    },
+    {
+      "id": 9,
+      "parent_id": 8,
+      "name": "cook_textures",
+      "agent": "build-agent-07",
+      "start_ms": 1040000,
+      "end_ms": 1400000,
+      "avg_cpu_pct": 92
+    },
+    {
+      "id": 10,
+      "parent_id": 8,
+      "name": "compile_shaders",
+      "agent": "build-agent-14",
+      "start_ms": 1040000,
+      "end_ms": 1220000,
+      "avg_cpu_pct": 95
+    },
+    {
+      "id": 11,
+      "parent_id": 8,
+      "name": "cook_audio",
+      "agent": "build-agent-15",
+      "start_ms": 1040000,
+      "end_ms": 1160000,
+      "avg_cpu_pct": 63
+    },
+    {
+      "id": 12,
+      "parent_id": 1,
+      "name": "bake_lighting",
+      "agent": "bake-agent-02",
+      "start_ms": 1400000,
+      "end_ms": 2040000,
+      "avg_cpu_pct": 97
+    },
+    {
+      "id": 13,
+      "parent_id": 1,
+      "name": "package",
+      "agent": "build-agent-07",
+      "start_ms": 2040000,
+      "end_ms": 2760000
+    },
+    {
+      "id": 14,
+      "parent_id": 13,
+      "name": "sign_binaries",
+      "agent": "sign-02",
+      "start_ms": 2580000,
+      "end_ms": 2670000,
+      "avg_cpu_pct": 41
+    },
+    {
+      "id": 15,
+      "parent_id": 13,
+      "name": "make_installer",
+      "agent": "build-agent-07",
+      "start_ms": 2670000,
+      "end_ms": 2760000,
+      "avg_cpu_pct": 78
+    }
+  ],
+  "events": [
+    {
+      "t_ms": 620000,
+      "step_id": 7,
+      "msg": "upload started in background (blocking=false); 3.8 GB of .pdb files for gameplay and editor_tools"
+    },
+    {
+      "t_ms": 1040000,
+      "step_id": 10,
+      "msg": "compile_shaders: 2,214 permutations, 1,980 from shader cache, 234 compiled (includes 61 for water_surface)"
+    },
+    {
+      "t_ms": 1400000,
+      "step_id": 12,
+      "msg": "bake_lighting: lightmap cache miss for 38 of 38 levels (cache key changed); baking all"
+    },
+    {
+      "t_ms": 1460000,
+      "step_id": 7,
+      "msg": "upload finished"
+    },
+    {
+      "t_ms": 2040000,
+      "step_id": 13,
+      "msg": "waiting for a free agent in pool 'sign-pool' (0 of 2 free)"
+    },
+    {
+      "t_ms": 2580000,
+      "step_id": 13,
+      "msg": "agent sign-02 acquired after 540000 ms in queue"
+    },
+    {
+      "t_ms": 2760000,
+      "step_id": 1,
+      "msg": "build succeeded"
+    }
+  ]
+}

package/packs/solution-architect/skills/interactive-diagram/evals/files/11/src/org/example/greenhouse/AbstractSensor.java

@@ -0,0 +1,36 @@
+package org.example.greenhouse;
+
+/**
+ * Shared range checking and calibration for every sensor.
+ * Subclasses only supply the raw value.
+ */
+public abstract class AbstractSensor implements Sensor {
+    protected final String id;
+    private final double min;
+    private final double max;
+    private final double offset;
+
+    protected AbstractSensor(String id, double min, double max, double offset) {
+        this.id = id;
+        this.min = min;
+        this.max = max;
+        this.offset = offset;
+    }
+
+    @Override
+    public String id() {
+        return id;
+    }
+
+    @Override
+    public final double read() {
+        return rawValue() + offset;
+    }
+
+    @Override
+    public boolean isOutOfRange(double value) {
+        return value < min || value > max;
+    }
+
+    protected abstract double rawValue();
+}

package/packs/solution-architect/skills/interactive-diagram/evals/files/11/src/org/example/greenhouse/AlertService.java

@@ -0,0 +1,15 @@
+package org.example.greenhouse;
+
+/** Shared by every greenhouse on the site; created once at startup. */
+public class AlertService {
+    private int raised;
+
+    public void raise(String greenhouse, String zone, String sensorId, double value) {
+        raised++;
+        System.out.printf("ALERT %s/%s %s=%.1f%n", greenhouse, zone, sensorId, value);
+    }
+
+    public int raisedCount() {
+        return raised;
+    }
+}

package/packs/solution-architect/skills/interactive-diagram/evals/files/11/src/org/example/greenhouse/Greenhouse.java

@@ -0,0 +1,36 @@
+package org.example.greenhouse;
+
+import java.util.ArrayList;
+import java.util.List;
+
+/**
+ * A greenhouse owns its zones and raises alerts through a shared AlertService.
+ * Watering for each zone is planned by {@link WateringSchedule}.
+ */
+public class Greenhouse {
+    private final String name;
+    private final List<Zone> zones = new ArrayList<>();
+    private final AlertService alerts;
+
+    public Greenhouse(String name, AlertService alerts) {
+        this.name = name;
+        this.alerts = alerts;
+    }
+
+    public Zone addZone(String label) {
+        Zone zone = new Zone(label);
+        zones.add(zone);
+        return zone;
+    }
+
+    public void checkAll() {
+        for (Zone zone : zones) {
+            for (Sensor sensor : zone.sensors()) {
+                double value = sensor.read();
+                if (sensor.isOutOfRange(value)) {
+                    alerts.raise(name, zone.label(), sensor.id(), value);
+                }
+            }
+        }
+    }
+}

package/packs/solution-architect/skills/interactive-diagram/evals/files/11/src/org/example/greenhouse/Sensor.java

@@ -0,0 +1,10 @@
+package org.example.greenhouse;
+
+/** Anything that can be polled for a single numeric reading. */
+public interface Sensor {
+    String id();
+
+    double read();
+
+    boolean isOutOfRange(double value);
+}

package/packs/solution-architect/skills/interactive-diagram/evals/files/11/src/org/example/greenhouse/SoilMoistureSensor.java

@@ -0,0 +1,25 @@
+package org.example.greenhouse;
+
+/** Volumetric soil moisture, percent. Fed by the ADC polling loop. */
+public class SoilMoistureSensor extends AbstractSensor {
+    private final int adcChannel;
+    private volatile double lastSample;
+
+    public SoilMoistureSensor(String id, int adcChannel) {
+        super(id, 20.0, 60.0, 0.0);
+        this.adcChannel = adcChannel;
+    }
+
+    public int adcChannel() {
+        return adcChannel;
+    }
+
+    public void onSample(double percent) {
+        this.lastSample = percent;
+    }
+
+    @Override
+    protected double rawValue() {
+        return lastSample;
+    }
+}

package/packs/solution-architect/skills/interactive-diagram/evals/files/11/src/org/example/greenhouse/TemperatureSensor.java

@@ -0,0 +1,19 @@
+package org.example.greenhouse;
+
+/** Air temperature in degrees Celsius. */
+public class TemperatureSensor extends AbstractSensor {
+    private volatile double lastCelsius;
+
+    public TemperatureSensor(String id, double offset) {
+        super(id, 12.0, 32.0, offset);
+    }
+
+    public void onSample(double celsius) {
+        this.lastCelsius = celsius;
+    }
+
+    @Override
+    protected double rawValue() {
+        return lastCelsius;
+    }
+}

package/packs/solution-architect/skills/interactive-diagram/evals/files/11/src/org/example/greenhouse/Zone.java

@@ -0,0 +1,26 @@
+package org.example.greenhouse;
+
+import java.util.ArrayList;
+import java.util.List;
+
+/** One bench or bed. Sensors are created by the hardware layer and attached here. */
+public class Zone {
+    private final String label;
+    private final List<Sensor> sensors = new ArrayList<>();
+
+    Zone(String label) {
+        this.label = label;
+    }
+
+    public String label() {
+        return label;
+    }
+
+    public void attach(Sensor sensor) {
+        sensors.add(sensor);
+    }
+
+    public List<Sensor> sensors() {
+        return List.copyOf(sensors);
+    }
+}

package/packs/solution-architect/skills/interactive-diagram/evals/files/6/notes.txt

@@ -0,0 +1,7 @@
+quote api slowness - notes (Wed 14 Oct)
+
+- trace above is one of the slow ones from this morning. the customer said the quote page hung for "just over 4 seconds".
+- my bet is the rate limiter. ops told me the ratelimiter check against redis has been taking 300ms+ since the redis upgrade last week.
+- also the two carrier calls add up to ~5s on their own so carriers are basically the whole story?
+- rates team owns rates-svc and the carrier integrations. quote team owns quote-svc.
+- want something I can send the rates team that shows where the time goes.

package/packs/solution-architect/skills/interactive-diagram/evals/files/6/trace-quote-slow.jsonl

@@ -0,0 +1,13 @@
+{"trace_id": "4b9e1c07a2d35f68e0c1b7a94d2f6031", "span_id": "a1f0c3d2e4b50002", "parent_span_id": "a1f0c3d2e4b50001", "service": "auth-svc", "name": "verify_token", "kind": "SERVER", "start_time": "2026-10-14T09:41:07.312Z", "end_time": "2026-10-14T09:41:07.358Z", "duration_ms": 46, "status": "OK", "attributes": {"auth.scheme": "bearer"}}
+{"trace_id": "4b9e1c07a2d35f68e0c1b7a94d2f6031", "span_id": "a1f0c3d2e4b50005", "parent_span_id": "a1f0c3d2e4b50004", "service": "postgres", "name": "SELECT contracts", "kind": "CLIENT", "start_time": "2026-10-14T09:41:07.375Z", "end_time": "2026-10-14T09:41:07.600Z", "duration_ms": 225, "status": "OK", "attributes": {"db.system": "postgresql", "db.table": "contracts", "db.rows": 14}}
+{"trace_id": "4b9e1c07a2d35f68e0c1b7a94d2f6031", "span_id": "a1f0c3d2e4b50004", "parent_span_id": "a1f0c3d2e4b50003", "service": "quote-svc", "name": "load_customer_contract", "kind": "INTERNAL", "start_time": "2026-10-14T09:41:07.370Z", "end_time": "2026-10-14T09:41:07.610Z", "duration_ms": 240, "status": "OK", "attributes": {}}
+{"trace_id": "4b9e1c07a2d35f68e0c1b7a94d2f6031", "span_id": "a1f0c3d2e4b50007", "parent_span_id": "a1f0c3d2e4b50003", "service": "rates-svc", "name": "carrier_rates coastal", "kind": "CLIENT", "start_time": "2026-10-14T09:41:07.625Z", "end_time": "2026-10-14T09:41:10.010Z", "duration_ms": 2385, "status": "OK", "attributes": {"carrier": "coastal", "peer.service": "coastal-carrier-api", "http.status_code": 200}}
+{"trace_id": "4b9e1c07a2d35f68e0c1b7a94d2f6031", "span_id": "a1f0c3d2e4b50006", "parent_span_id": "a1f0c3d2e4b50003", "service": "rates-svc", "name": "carrier_rates north-line", "kind": "CLIENT", "start_time": "2026-10-14T09:41:07.620Z", "end_time": "2026-10-14T09:41:10.220Z", "duration_ms": 2600, "status": "OK", "attributes": {"carrier": "north-line", "peer.service": "north-line-carrier-api", "http.status_code": 200}}
+{"trace_id": "4b9e1c07a2d35f68e0c1b7a94d2f6031", "span_id": "a1f0c3d2e4b50009", "parent_span_id": "a1f0c3d2e4b50008", "service": "cache", "name": "GET fx:EUR-USD", "kind": "CLIENT", "start_time": "2026-10-14T09:41:10.240Z", "end_time": "2026-10-14T09:41:10.248Z", "duration_ms": 8, "status": "OK", "attributes": {"cache.hit": true}}
+{"trace_id": "4b9e1c07a2d35f68e0c1b7a94d2f6031", "span_id": "a1f0c3d2e4b50008", "parent_span_id": "a1f0c3d2e4b50003", "service": "quote-svc", "name": "price_and_rank", "kind": "INTERNAL", "start_time": "2026-10-14T09:41:10.230Z", "end_time": "2026-10-14T09:41:11.280Z", "duration_ms": 1050, "status": "OK", "attributes": {"rank.candidates": 1840, "rank.algorithm": "rank_v2"}}
+{"trace_id": "4b9e1c07a2d35f68e0c1b7a94d2f6031", "span_id": "a1f0c3d2e4b5000b", "parent_span_id": "a1f0c3d2e4b5000a", "service": "postgres", "name": "INSERT quotes", "kind": "CLIENT", "start_time": "2026-10-14T09:41:11.290Z", "end_time": "2026-10-14T09:41:11.430Z", "duration_ms": 140, "status": "OK", "attributes": {"db.system": "postgresql", "db.table": "quotes"}}
+{"trace_id": "4b9e1c07a2d35f68e0c1b7a94d2f6031", "span_id": "a1f0c3d2e4b5000a", "parent_span_id": "a1f0c3d2e4b50003", "service": "quote-svc", "name": "persist_quote", "kind": "INTERNAL", "start_time": "2026-10-14T09:41:11.285Z", "end_time": "2026-10-14T09:41:11.440Z", "duration_ms": 155, "status": "OK", "attributes": {}}
+{"trace_id": "4b9e1c07a2d35f68e0c1b7a94d2f6031", "span_id": "a1f0c3d2e4b50003", "parent_span_id": "a1f0c3d2e4b50001", "service": "quote-svc", "name": "build_quote", "kind": "SERVER", "start_time": "2026-10-14T09:41:07.360Z", "end_time": "2026-10-14T09:41:11.450Z", "duration_ms": 4090, "status": "OK", "attributes": {"quote.lanes": 3, "quote.mode": "FTL"}}
+{"trace_id": "4b9e1c07a2d35f68e0c1b7a94d2f6031", "span_id": "a1f0c3d2e4b5000d", "parent_span_id": "a1f0c3d2e4b50001", "service": "api-gateway", "name": "serialize_response", "kind": "INTERNAL", "start_time": "2026-10-14T09:41:11.452Z", "end_time": "2026-10-14T09:41:11.495Z", "duration_ms": 43, "status": "OK", "attributes": {"http.response_size_bytes": 18233}}
+{"trace_id": "4b9e1c07a2d35f68e0c1b7a94d2f6031", "span_id": "a1f0c3d2e4b50001", "parent_span_id": null, "service": "api-gateway", "name": "POST /v2/quotes", "kind": "SERVER", "start_time": "2026-10-14T09:41:07.300Z", "end_time": "2026-10-14T09:41:11.500Z", "duration_ms": 4200, "status": "OK", "attributes": {"http.method": "POST", "http.route": "/v2/quotes", "http.status_code": 200, "customer.tier": "standard"}}
+{"trace_id": "4b9e1c07a2d35f68e0c1b7a94d2f6031", "span_id": "a1f0c3d2e4b5000c", "parent_span_id": "a1f0c3d2e4b50003", "service": "notify-svc", "name": "emit quote.created", "kind": "PRODUCER", "start_time": "2026-10-14T09:41:11.446Z", "end_time": "2026-10-14T09:41:11.910Z", "duration_ms": 464, "status": "OK", "attributes": {"messaging.destination": "quote.created", "messaging.system": "kafka"}}

package/packs/solution-architect/skills/interactive-diagram/evals/files/7/oncall-notes.md

@@ -0,0 +1,16 @@
+# INC-0412 - arrival boards frozen - my notes
+
+Sat 10 Oct, on call for transit-data. All times below are local (CDT).
+
+- 10:41pm  night supervisor at Central Station called. Arrival boards showing the same times "for a couple of hours at least". Asked them to open an incident so it pages properly.
+- 10:46pm  acked the page.
+- 10:58pm  on VPN. feed-builder says it has been serving last-known positions since about 7pm. Vehicle count looks normal (~210) but the positions aren't moving, which is why nothing looked wrong. Freshness panel in Grafana says OK?? The FeedStale alert never fired.
+- ~11:10pm?  restarted avl-ingest on the ingest box (`systemctl restart avl-ingest`). Didn't write the time down, could have been 11:05 or as late as 11:15. The ingest box doesn't ship logs to the central log so I can't check.
+- 11:14pm  supervisor says the Central Station boards are moving again.
+- 11:30pm  rolled feed-builder back to 3.13.2 anyway. 3.14.0 went out just before all this started and I didn't want to risk it overnight.
+- 12:05am  posted all-clear in #ops-transit and resolved the incident.
+
+Open questions for the review:
+- why didn't FeedStale fire? (it checks feed age, but we were re-publishing old positions with a fresh timestamp?)
+- was it 3.14.0 or did avl-ingest just hang? not sure yet.
+- ask Track Ops if the Riverside tram boards were affected too.