diff --git a/public/bundles/copilot-studio-agent-test.zip b/public/bundles/copilot-studio-agent-test.zip
new file mode 100644
index 00000000..4805ac1a
Binary files /dev/null and b/public/bundles/copilot-studio-agent-test.zip differ
diff --git a/src/content/guides/booth-loop-video.md b/src/content/guides/booth-loop-video.md
new file mode 100644
index 00000000..3e642e2d
--- /dev/null
+++ b/src/content/guides/booth-loop-video.md
@@ -0,0 +1,83 @@
+# Booth Loop Video
+
+You need something on the screen behind your stand. Not a slideshow with a
+transition every eight seconds, and not a video that needs an editor, a brief, and
+three weeks. This skill renders a **silent, looping MP4** — 1920x1080, 30 fps,
+one to two minutes — from a description of what you want it to say.
+
+Describe the message, hand over your brand colours, and the agent writes a Python
+render script, shows you a still from every scene, and only then renders the video.
+
+## What it does
+
+The agent generates a single self-contained script that paints **every frame** with
+Pillow and pipes them to ffmpeg. That means real motion — eased fades, animated
+counters, progress bars, typed-text reveals, orbiting nodes — not a set of static
+slides with a crossfade.
+
+Because the whole thing is a script, iteration is conversational: "slower orbit",
+"make the headline bigger", "swap magenta for green" edits a few constants and
+re-renders.
+
+## Why frame-by-frame instead of a slide export
+
+Exporting a deck to video gives you a deck playing at 0.1 fps. This gives you a
+motion graphic. The trade-off is that you're writing code rather than dragging
+boxes — which is exactly the trade-off an agent is good at absorbing.
+
+## What makes it different
+
+Most of this skill is the accumulated list of things that go wrong, written down so
+they don't go wrong again:
+
+- **The z-order rule.** Pillow paints in call order. Draw a hub, then its spokes,
+  and the spoke lines run straight across the hub and through your labels. The skill
+  forces a two-pass draw — all connectors, then all nodes — for any diagram layout.
+  This is the single most common defect and it's invisible until you look at a frame.
+- **Preview before render.** A full render takes minutes; a preview PNG takes
+  seconds. The agent renders one still per scene and shows them to you inline
+  *before* committing to the render.
+- **`-pix_fmt yuv420p`.** Without it the MP4 plays fine in VLC and in nothing else —
+  not QuickTime, not PowerPoint, not the media player on the screen at the venue.
+- **Font probing across platforms.** A hardcoded font path silently falls back to a
+  tiny bitmap font and produces a video that looks broken. The skill probes a
+  candidate list per weight and reports what actually resolved.
+- **Contrast for a show floor.** Dark card on dark background is a design-tool
+  favourite and unreadable on a badly calibrated panel under bright lights. Chat and
+  quote UI goes on a white card, and contrast gets checked on a rendered frame.
+- **Frames go to the system temp folder**, never the working directory — rendering
+  thousands of PNGs into a OneDrive- or Dropbox-synced folder stalls the render and
+  thrashes the sync client.
+
+## How to use it
+
+1. Tell the agent what the video is for and roughly what it should say — the pitch,
+   the three things you want a passer-by to take away, the call to action.
+2. Give it your brand colours, or let it use the neutral navy/blue default. It won't
+   invent a brand for you.
+3. Review the per-scene preview stills it sends back and correct anything that looks
+   wrong. This is the cheap moment to fix layout.
+4. Approve the render. Output lands at `output/booth_loop.mp4`.
+5. Iterate in plain language until it's right.
+
+## Requirements
+
+Python with `pillow`, `imageio`, `imageio-ffmpeg`, and `numpy`. The agent installs
+them if they're missing. `imageio-ffmpeg` bundles its own ffmpeg binary, so there's
+no system ffmpeg install and nothing to put on `PATH`.
+
+## Tips
+
+- **Write for eight seconds of attention at three metres.** If the opening scene
+  doesn't land on its own, nothing after it will.
+- Keep it under ~25 words on screen at any moment.
+- Make the first and last frames identical so the loop point disappears.
+- It's silent by design. Booths are loud and most venue screens are muted anyway.
+- The output works as a LinkedIn post or an embedded slide, not just a booth loop.
+
+## Known limitations
+
+- No audio track. Add one afterwards with ffmpeg if you need it.
+- No live footage or video-file editing — this generates from scratch.
+- Complex scenes at 30 fps take a few minutes to render. Preview stills are the
+  answer, not patience.
diff --git a/src/content/guides/browser-uat-analyst.md b/src/content/guides/browser-uat-analyst.md
new file mode 100644
index 00000000..073fc6b0
--- /dev/null
+++ b/src/content/guides/browser-uat-analyst.md
@@ -0,0 +1,89 @@
+# Browser UAT Analyst
+
+Testing done by an agent has a failure mode: it reads the docs, drives two clicks,
+and tells you the feature works. This skill exists to stop that. It turns the agent
+into a sceptical test analyst that will not claim a thing works until it has a
+screenshot proving it, and that tells you *which kind* of failure it found.
+
+Point it at anything you can drive in a browser — a Copilot Studio agent, a
+model-driven or canvas app, a Power Automate flow's run history, a Dataverse form,
+a Dynamics 365 module, the Teams web client, a Microsoft 365 admin centre, or your
+own web app.
+
+## What it does
+
+1. Writes a **test charter** first — objective, environment, test data, hypotheses,
+   success criteria, and what's out of scope.
+2. Verifies environment readiness before touching anything.
+3. Decomposes the request into user-visible scenarios, then adds an adversarial pass
+   for the ways it actually breaks in the field.
+4. Executes with Playwright, screenshotting **before and after** every key action.
+5. Keeps an evidence ledger as it goes.
+6. Synthesises findings into a summary, an outcome matrix, and a recommendation.
+
+## What makes it different
+
+**It classifies failures instead of just reporting them.** Every failure gets tagged
+as a product limitation, a product defect, a test-harness limitation, a tenant or
+configuration issue, an authentication issue, or model drift. This one habit is the
+difference between a report someone acts on and a report that gets dismissed —
+because filing a tenant misconfiguration as a product bug destroys the credibility
+of everything else in the document.
+
+**"Blocked" is a real result.** If the agent couldn't reach the state, it says so.
+It never upgrades an unobserved behaviour to a pass.
+
+**The evidence ledger has a "what it proves" column.** If you can't fill that column
+in, the screenshot is decoration and the scenario is untested. This is the discipline
+that stops evidence theatre.
+
+**Failed approaches get their own slides.** The "we tried this and it doesn't work"
+content is usually the most valuable output and the first thing that gets cut.
+The skill requires it.
+
+**It knows how rich chat UI actually fails.** Testing a conversational agent's
+formatting, Adaptive Cards, hosted images, dynamically generated images, and
+interactive actions are five separate tests with five separate failure modes — and
+all of them behave differently in the authoring test pane than in Teams. Model-emitted
+Adaptive Card JSON rendering as a code block instead of a card is the classic example
+this skill is built to catch.
+
+## How to use it
+
+Ask for what you need in plain language:
+
+- "UAT the new agent's escalation flow before we ship it"
+- "Check whether the chart actually renders in Teams or just in the test pane"
+- "Compare how this setting appears in the Teams admin centre vs the M365 admin centre"
+- "Work out whether that failure is our config or a product bug"
+
+The agent will propose a charter before it starts executing. Correct the scope there
+— it's much cheaper than correcting the report.
+
+## Requirements
+
+Playwright or equivalent browser automation, plus a signed-in browser session for
+whatever you're testing. Screenshots are written to `output/<test-name>/`.
+
+For the reporting step, pair it with a PowerPoint skill if you want a deck; the
+skill will export the slides to images and inspect them for overflow, tiny text,
+and clipping before handing it over.
+
+## Tips
+
+- **Let it be slow with admin centres.** Premature assertions against heavy SPAs
+  generate false failures that then take longer to disprove than the wait would have
+  taken.
+- Give it deterministic test data. Letting a model invent facts and then testing the
+  invention proves nothing.
+- Ask it explicitly for the negative cases — empty data, wrong permissions, expired
+  session. That's where the real findings are.
+- If a result surprises you, ask it what evidence would disambiguate the cause. It's
+  built to answer that rather than defend its first hypothesis.
+
+## Known limitations
+
+- Browser-observable behaviour only. Not for unit tests, API contract tests, or
+  load testing.
+- Non-deterministic AI responses can't be asserted the way a deterministic UI can;
+  the skill flags model drift as its own category rather than pretending otherwise.
diff --git a/src/content/guides/copilot-studio-agent-test.md b/src/content/guides/copilot-studio-agent-test.md
new file mode 100644
index 00000000..915b97df
--- /dev/null
+++ b/src/content/guides/copilot-studio-agent-test.md
@@ -0,0 +1,112 @@
+# Copilot Studio Agent Test
+
+Test a Microsoft Copilot Studio agent against your own question-and-answer set, and get back a
+graded pass/fail report — without driving a browser.
+
+Point it at a Word document or CSV of questions with their expected answers. It converts them
+into a test set, asks the agent every question in a **fresh conversation**, then reads each
+answer against the expected one and writes a report with a pass rate, a per-question table, and
+the reason behind every failure.
+
+Built for the case where a customer hands you a pile of Q&A documents and asks *"is our agent
+actually answering these correctly?"*
+
+## Why not just use the browser?
+
+Driving the Copilot Studio test pane with browser automation works, but it is slow and brittle:
+you are waiting on UI animations and guessing when an answer has finished streaming. This skill
+talks to the agent through the **Microsoft 365 Agents SDK** instead (`CopilotStudio.Copilots.Invoke`),
+which is roughly ten times faster and does not break when the UI changes.
+
+## What it does — and deliberately does not do
+
+**It does:** convert Word Q&A tables into test sets, run every question in an isolated
+conversation, capture answers and citations, detect escalation and empty turns, check optional
+required substrings, and assemble the final report.
+
+**It does not** decide by itself whether an answer is *correct*. That grading pass is done by
+the agent running the skill (or by you), reading each answer against the expected one.
+
+This is a deliberate design decision, not a missing feature. A similarity score would
+manufacture false failures: in practice a correct answer routinely differs in wording from the
+expected text, and sometimes improves on it. So the tool captures evidence, a human-or-model
+judgement produces verdicts, and the report carries those real verdicts instead of a number
+nobody trusts.
+
+## Setup
+
+**Prerequisite:** Node.js 22 or later.
+
+Ask your assistant: **"set up the Copilot Studio agent test skill"**. It will ask you for four
+values and configure everything:
+
+| Value | Where to find it |
+|---|---|
+| Application (client) ID | your Entra app registration → Overview |
+| Directory (tenant) ID | same page |
+| Environment ID | the GUID in the Copilot Studio URL, after `/environments/` |
+| Schema name | see below — it differs between the two Copilot Studio experiences |
+
+**Schema name** is not the display name; it looks like `cr1a3_myAgentName`.
+
+- **New authoring experience** (Build / Preview / Evaluate / Monitor tabs):
+  agent → **⋯ (More options)** → **Settings** → **Agent details** → **Identity** → **Schema name**
+- **Classic agents**: agent → **Settings** → **Advanced** → **Metadata** → **Schema name**
+
+You also need an Entra app registration with **Allow public client flows** enabled and the
+delegated **`CopilotStudio.Copilots.Invoke`** permission (note the plural) granted admin
+consent. The skill walks you through creating one if you do not have it.
+
+There is **no client secret** — sign-in is device code, so nothing confidential is stored. Your
+settings go to `~/.cs-agent-test/`, never into the skill folder.
+
+## Using it
+
+Ask: **"test my Copilot Studio agent with these questions"** and give it your file.
+
+Or drive it yourself:
+
+```
+node scripts/cs-agent-test.cjs convert  my-questions.docx testset.csv
+node scripts/cs-agent-test.cjs test     testset.csv --out .\results
+node scripts/cs-agent-test.cjs report   .\results\results-<ts>.json --template verdicts.csv
+REM   ... fill in PASS / FAIL / EXCLUDED and a reason for each row ...
+node scripts/cs-agent-test.cjs report   .\results\results-<ts>.json report.md --verdicts verdicts.csv
+```
+
+On macOS or Linux use `sh scripts/cs-agent-test.sh`, or `node scripts/cs-agent-test.cjs`
+anywhere.
+
+Expect **30–60 seconds per question** — a 60-question set takes about 45 minutes.
+
+## Two things that will otherwise waste your afternoon
+
+**It tests the PUBLISHED agent, not the draft.** The Copilot Studio test pane tests the draft.
+Anything you just changed in the authoring canvas is invisible here until you publish.
+
+**Agents built with the new authoring experience run on a different endpoint.** Reached on the
+classic endpoint, they reply with *"Enhanced task completion preview has ended. Go to
+copilotstudio.microsoft.com and republish the agent"* — which looks like a real answer and is
+not fixed by republishing. The skill detects that notice and transparently retries on the
+agentic runtime endpoint, so you should never have to think about it.
+
+## No executable
+
+This skill ships **no binary** — `scripts/cs-agent-test.cjs` is a single self-contained
+JavaScript file (~1.5 MB, no `npm install` needed), with thin `.cmd` and `.sh` launchers.
+
+An earlier version shipped a 57 MB packaged `.exe`. That was replaced on purpose: an unsigned
+executable is a reasonable thing for endpoint policy to block, code signing would not have
+removed SmartScreen warnings anyway (reputation comes from download history, not from a
+certificate), and 1.5 MB of readable JavaScript can actually be reviewed by a security team.
+As a bonus, the JavaScript runs on macOS and Linux too.
+
+`references/THIRD-PARTY-NOTICES.md` lists every open-source package in the bundle.
+
+## Limitations
+
+- **Delegated auth only.** The Agents SDK does not accept service principal tokens, so fully
+  unattended CI is not possible. One device-code sign-in is cached and covers a whole run.
+- **Windows, macOS and Linux**, wherever Node.js 22+ runs.
+- Occasional consent prompts or transient stalls surface as errors on individual rows; re-run
+  those with `--ids`.
diff --git a/src/content/guides/travel-cost-estimator.md b/src/content/guides/travel-cost-estimator.md
new file mode 100644
index 00000000..309184f9
--- /dev/null
+++ b/src/content/guides/travel-cost-estimator.md
@@ -0,0 +1,102 @@
+# Travel Cost Estimator
+
+"Roughly what will that trip cost?" is a question that gets answered with a guess,
+and the guess is wrong often enough that people stop trusting the number. This skill
+answers it with **live fares** pulled from your corporate booking tool, and fills the
+lines the booking tool doesn't cover by benchmarking against **your own approved
+expense reports** — so the number holds up when your manager pushes back on it.
+
+It produces a forwardable estimate: headline figure, cost table, all the options it
+considered, and the assumptions stated as assumptions.
+
+## The important part: it never books anything
+
+Your corporate booking tool is a live booking system. Real money, real tickets, real
+change fees. Letting an agent loose in one is a genuinely bad idea unless the
+boundary is explicit, so the boundary is the first thing in the skill and it's
+absolute:
+
+> **Search and price only.** Never click `Continue` past fare selection, `Select
+> hotel` into a booking funnel, `Book`, `Reserve`, `Hold`, `Confirm`, or anything on
+> a traveller-details or payment page. Reading fares off a results page is safe.
+> The results page is where you stop.
+
+If a flow ever lands on a payment or traveller-details page, the skill stops and
+tells you where it is rather than clicking its way back out. Every estimate it
+produces states **"Nothing booked."**
+
+## What makes it different
+
+**It benchmarks the unbookable lines against your actual reimbursements.** Ground
+transport, meals, and parking aren't in the booking tool, and this is exactly where
+estimates get invented. The skill pulls totals from your own approved expense
+reports for comparable trips and derives the figures from those — then labels them
+"assumption" in the table rather than dressing them up as priced.
+
+**It always surfaces a materially cheaper alternative**, even when that breaks your
+stated airline or hotel preference. You get the trade-off — cost vs. proximity vs.
+loyalty — and you choose. It won't silently optimise for price, and it won't
+silently optimise for your preferences. Presenting one option as if it were the only
+option is the failure mode it's built to avoid.
+
+**It knows the DOM tricks that make these portals workable.** Enterprise booking
+tools are old, slow, and hostile to automation. The skill carries the specific
+patterns:
+
+- **Date fields are hidden inputs behind a calendar widget.** Assigning `.value`
+  directly is ignored by the framework — you have to go through
+  `HTMLInputElement.prototype`'s native setter and dispatch `input`/`change`/`blur`
+  yourself. Driving the visible calendar picker instead is flaky and slow.
+- **Location controls are select2-style widgets** whose real `<select>` is
+  `aria-hidden` and unclickable. You drive the visible proxy span.
+- **Pick the airport option, not the metro/city option** — the city entry resolves to
+  a different and much less useful inventory set.
+- **Results take ~20 seconds.** Read the page text rather than snapshotting; the
+  results table is huge and a snapshot burns context for nothing.
+- **A search click that times out waiting for navigation usually submitted fine.**
+  Retrying double-submits.
+- **Don't reuse a deep link with a session token in it** — it expires and the symptom
+  is a misleading "Cookies are disabled" page, not a session error.
+
+**One gotcha worth the price of admission on its own:** when forwarding the estimate
+over Teams, resolve the recipient by **UPN**, not by vanity SMTP alias.
+`First.Last@company.com` works for mail and fails Teams chat creation with
+`user_not_found`. That error looks like "this person doesn't exist" and isn't.
+
+## How to use it
+
+1. Ask for a trip estimate — "price up a two-day visit to the Orlando customer the
+   week of the 26th".
+2. Confirm your travel preferences the first time: home airport, preferred airline
+   and hotel chain, cabin class your policy allows. It reuses these afterwards but
+   re-confirms dates every run.
+3. Watch it price flights and hotels, or don't — it writes the full working to a file.
+4. Read the headline number and the one or two judgement calls it flags.
+5. Optionally have it draft the message to your approver. It shows you the exact text
+   and recipient and waits for confirmation before sending.
+
+## Requirements
+
+- Browser automation (Playwright) with an existing SSO session to your corporate
+  booking tool. The skill never asks for credentials — if SSO isn't working it stops.
+- Read access to your own mailbox, for the expense-report benchmarking step.
+- The DOM selectors are written against Cytric/Amadeus-family portals. Concur Travel,
+  Egencia, and similar tools use different field names — inspect once and substitute.
+  The **techniques** (native setter, select2 proxy, long waits) transfer unchanged.
+
+## Tips
+
+- **Don't skip the home-airport confirmation.** Guessing it from your city silently
+  produces a plausible, useless number when your metro has several airports.
+- Ask it explicitly whether a rental car is likely. It's the most common reason an
+  estimate comes in low.
+- Prices drift daily. An estimate is a snapshot, and the skill says so in every
+  output — re-run it if the trip is more than a couple of weeks out.
+- The estimate contains your dates, destination, and customer. Treat it as private
+  until you've decided to share it.
+
+## Known limitations
+
+- Estimates only. By design it cannot and will not book, hold, or confirm anything.
+- Fares are not held. What it quotes today is not what you'll pay next week.
+- Selectors are portal-specific and will need adjusting for a different booking tool.
diff --git a/src/content/skills/booth-loop-video.md b/src/content/skills/booth-loop-video.md
new file mode 100644
index 00000000..2e02e5db
--- /dev/null
+++ b/src/content/skills/booth-loop-video.md
@@ -0,0 +1,244 @@
+---
+name: Booth Loop Video
+description: "Generate a silent, looping 1920x1080 MP4 for a conference booth, kiosk, or lobby screen — rendered frame-by-frame in Python (Pillow + ffmpeg), with previews before the full render."
+agentDescription: "Use this skill whenever the user asks for a looping booth, kiosk, trade-show, lobby-screen, or silent background video — including requests phrased as \"a video loop for our stand\", \"an animated explainer with no voiceover\", \"a motion graphic for the monitor\", or \"turn this pitch into a looping MP4\". Generate and run a self-contained Python render script (Pillow + ffmpeg) that outputs a 1920x1080 30fps MP4. Do NOT use this skill for videos that need narration, live footage, or editing of an existing video file."
+platforms: [Scout]
+tags: [video, animation, python, marketing, events, design, ffmpeg]
+author: Al Macey
+authorUrl: "https://github.com/amacey-msft"
+authorGithub: amacey-msft
+version: 1.0.0
+createdAt: 2026-08-04
+updatedAt: 2026-08-04
+---
+# Booth / kiosk loop video
+
+Produce a silent, looping MP4 (default 1920x1080, 30 fps, 60-135 s) suitable for a
+conference stand, a lobby screen, a reception kiosk, a LinkedIn post, or an embedded
+slide in a deck.
+
+The output is a **rendered animation**, not a slideshow export. Every frame is painted
+in Python, so layout, timing, and easing are fully under your control.
+
+## Execution model — do the work, don't hand out instructions
+
+You have Python and a shell. Never tell the user to open an editor or run the script
+themselves. You:
+
+1. Write a single self-contained script at `work/booth_video.py`.
+2. Install dependencies if missing: `pip install pillow imageio imageio-ffmpeg numpy`
+   (`imageio-ffmpeg` ships its own ffmpeg binary — no system install needed).
+3. Render preview PNGs and show them to the user.
+4. Only after previews look right, run the full render.
+5. Report the output path.
+
+All paths are relative to the current working directory:
+
+```
+{CWD}/
+  work/
+    booth_video.py
+    preview/scene_1.png ...
+  output/
+    booth_loop.mp4
+```
+
+Write intermediate frames to the **system temp directory**, not the working folder.
+Rendering thousands of PNGs into a cloud-synced folder (OneDrive, Dropbox, iCloud)
+will stall the render and thrash the sync client.
+
+## Design defaults
+
+Use these unless the user supplies a brand palette. Ask for their colours if the video
+is customer-facing; don't invent a brand.
+
+| | |
+|---|---|
+| Canvas | 1920x1080, 30 fps |
+| Duration | 60-135 s |
+| Background | deep navy `#0A1628` |
+| Accents | `#0078D4` primary, `#B4009E` secondary |
+| Cards | `#112244`, 18 px corner radius, ~86% alpha |
+| Type | humanist sans, generous whitespace |
+| Motion | 0.5 s fade in, 0.3 s fade out per scene, smooth-step easing |
+
+Dark, low-saturation background with two saturated accents reads well on a bright
+show floor and survives poor monitor calibration.
+
+## Script architecture
+
+One file. A `render_frame(t, total)` function that returns a Pillow `Image` for time
+`t` in seconds, and a scene table:
+
+```python
+SCENES = [
+    (0.0,  8.0,  scene_hook),
+    (8.0,  22.0, scene_problem),
+    (22.0, 40.0, scene_how_it_works),
+    # ...
+    (108.0, 120.0, scene_cta),
+]
+
+def render_frame(t, total):
+    img = Image.new("RGBA", (W, H), BG)
+    draw = ImageDraw.Draw(img)
+    for start, end, fn in SCENES:
+        if start <= t < end:
+            fn(draw, img, t - start, end - start)
+    return img
+```
+
+Time-relative scene functions (`local_t`, `duration`) make it trivial to reorder or
+retime scenes later without touching their internals.
+
+### Animation helpers — always include these
+
+```python
+def ease_in_out(t):  return t * t * (3 - 2 * t)
+def lerp(a, b, t):   return a + (b - a) * t
+def clamp(v, lo, hi): return max(lo, min(hi, v))
+def fade(t, start, end): return clamp((t - start) / (end - start + 1e-6), 0.0, 1.0)
+```
+
+Combine them: `alpha = ease_in_out(fade(local_t, 0, 0.5)) * (1 - fade(local_t, dur - 0.3, dur))`
+gives a clean in/out envelope for any element.
+
+### Cross-platform font loading
+
+Never hardcode a single font path — it will fail on another machine. Probe a
+candidate list per weight and fall back gracefully:
+
+```python
+import os
+from PIL import ImageFont
+
+FONT_DIRS = [
+    "C:/Windows/Fonts",                       # Windows
+    "/usr/share/fonts/truetype/dejavu",       # Linux
+    "/usr/share/fonts/truetype/liberation",   # Linux
+    "/System/Library/Fonts/Supplemental",     # macOS
+    "/Library/Fonts",                         # macOS
+]
+
+CANDIDATES = {
+    "light":    ["segoeuil.ttf", "HelveticaNeue.ttc", "DejaVuSans-ExtraLight.ttf", "arial.ttf"],
+    "regular":  ["segoeui.ttf", "Helvetica.ttc", "DejaVuSans.ttf", "LiberationSans-Regular.ttf", "arial.ttf"],
+    "semibold": ["seguisb.ttf", "DejaVuSans-Bold.ttf", "LiberationSans-Bold.ttf", "arialbd.ttf"],
+    "bold":     ["segoeuib.ttf", "DejaVuSans-Bold.ttf", "LiberationSans-Bold.ttf", "arialbd.ttf"],
+    "mono":     ["consola.ttf", "Menlo.ttc", "DejaVuSansMono.ttf", "cour.ttf"],
+}
+
+def get_font(weight, size):
+    for name in CANDIDATES.get(weight, CANDIDATES["regular"]):
+        for d in FONT_DIRS:
+            p = os.path.join(d, name)
+            if os.path.exists(p):
+                try:
+                    return ImageFont.truetype(p, size)
+                except OSError:
+                    continue
+    return ImageFont.load_default()
+```
+
+Print which font actually resolved on the first call. A silent fall back to
+`load_default()` produces a tiny bitmap font and a video that looks broken —
+you want to know before the full render, not after.
+
+## Z-order rule — the one that bites
+
+**Pillow paints in call order: later calls sit on top. Draw connectors before the
+things they connect.**
+
+For any hub-and-spoke, node-and-edge, or step-and-arrow layout, split into two passes:
+
+```python
+# Pass 1 — background layer: every connector
+for item in items:
+    draw.line([hub_xy, item.xy], fill=LINE, width=2)
+
+# Pass 2 — foreground layer: every node
+draw_hub(draw, hub_xy)
+for item in items:
+    draw_card(draw, item.xy, item.label)
+```
+
+Interleaving the two passes draws lines across cards and through label text. This is
+the single most common defect in generated diagrams-in-motion, and it is invisible
+until you look at a rendered frame — which is why previews are mandatory.
+
+## Scene planning
+
+Design for someone walking past at 3 m who gives you eight seconds.
+
+1. **Hook (0-8 s)** — one bold headline, one idea. No body copy. If a passer-by
+   can't get the point from this scene alone, the video has already failed.
+2. **Body scenes (8 s onward)** — one concept per scene, 10-18 s each. Card layouts,
+   animated counters, progress bars, typed-text reveals. Never more than ~25 words
+   on screen at once.
+3. **CTA (last 8-12 s)** — what to do next, plus a name, booth number, or short URL.
+
+End the CTA so it cuts cleanly back to the hook — the loop point should be invisible.
+Either fade fully to background colour, or make the first and last frames identical.
+
+## Contrast rules
+
+- Dark card on dark background is unreadable on a show floor. For any chat, answer,
+  or quote UI, put the response on a **white or near-white card** with dark text.
+- Never place accent-coloured text on the accent-coloured fill.
+- Check contrast on a **preview PNG**, not in your head. Show-floor lighting and
+  cheap panels both crush shadow detail.
+
+## Preview before rendering
+
+Full renders take minutes. Preview takes seconds. Always:
+
+```python
+if PREVIEW:
+    os.makedirs("work/preview", exist_ok=True)
+    for i, (start, end, _) in enumerate(SCENES, 1):
+        mid = (start + end) / 2
+        render_frame(mid, TOTAL).convert("RGB").save(f"work/preview/scene_{i}.png")
+    raise SystemExit
+```
+
+Display every preview inline to the user with markdown image syntax and get
+confirmation before the full render. URL-encode any spaces in the path.
+
+## Render loop
+
+```python
+import imageio, numpy as np
+
+writer = imageio.get_writer(
+    output_path, fps=FPS, codec="libx264",
+    output_params=["-crf", "18", "-pix_fmt", "yuv420p"],
+)
+for idx in range(int(TOTAL * FPS)):
+    t = idx / FPS
+    writer.append_data(np.array(render_frame(t, TOTAL).convert("RGB")))
+    if idx % max(1, int(TOTAL * FPS / 20)) == 0:
+        print(f"{100 * idx / (TOTAL * FPS):.0f}%", flush=True)
+writer.close()
+```
+
+`-pix_fmt yuv420p` is not optional — without it the file will not play in QuickTime,
+PowerPoint, or most hardware media players, even though VLC handles it fine.
+
+## Iteration
+
+After the first render, offer to tweak and accept plain-language feedback
+("slower orbit", "bigger headline", "green instead of magenta"). Edit the script,
+re-render the affected scene as a **preview PNG** first, then re-render the video.
+Never re-render the full video to check a colour change.
+
+## Quality checklist before delivering
+
+- [ ] Resolved a real TrueType font, not `load_default()`
+- [ ] No text overflowing a card boundary or the canvas
+- [ ] No label collisions in radial / orbit layouts
+- [ ] All connectors drawn before all nodes (z-order)
+- [ ] Readable contrast on every scene's preview PNG
+- [ ] Loop point is seamless — last frame flows into first
+- [ ] Encoded with `yuv420p`; plays outside VLC
+- [ ] Reasonable file size (< 200 MB for ~120 s)
+- [ ] Reported the absolute output path to the user
diff --git a/src/content/skills/browser-uat-analyst.md b/src/content/skills/browser-uat-analyst.md
new file mode 100644
index 00000000..52020192
--- /dev/null
+++ b/src/content/skills/browser-uat-analyst.md
@@ -0,0 +1,185 @@
+---
+name: Browser UAT Analyst
+description: "Run evidence-driven UAT on any browser-based app — Copilot Studio, Power Platform, Dataverse, Dynamics 365, admin centres, or a custom web app — with Playwright execution, a screenshot evidence ledger, and failure classification that separates product defects from tenant config."
+agentDescription: "Use this skill whenever the user asks to test, validate, UAT, regression-check, or investigate the behaviour of a browser-based application — including Copilot Studio agents, Power Platform apps and flows, Dataverse, Dynamics 365, Microsoft 365 admin centres, Teams web, and custom web apps. Covers test charter design, Playwright-driven execution, screenshot evidence capture, expected-vs-observed analysis, and stakeholder reporting. Use it BEFORE claiming any UI behaviour works or is broken. Do NOT use this skill for unit tests, API-only contract tests, or load testing."
+platforms: [Scout]
+tags: [testing, uat, playwright, quality, copilot-studio, power-platform, automation]
+author: Al Macey
+authorUrl: "https://github.com/amacey-msft"
+authorGithub: amacey-msft
+version: 1.0.0
+createdAt: 2026-08-04
+updatedAt: 2026-08-04
+---
+# Browser UAT analyst
+
+Act as a senior test analyst: sceptical, methodical, evidence-driven, and focused on
+user-visible outcomes. You combine exploratory testing, structured test design,
+browser automation, visual QA, and concise reporting.
+
+The output of this skill is never an opinion. It is a set of observed states, each
+backed by a screenshot, plus an interpretation clearly labelled as interpretation.
+
+## Core operating rules
+
+### 1. Evidence first
+
+- Drive the browser with Playwright wherever the behaviour is browser-observable.
+- Screenshot every meaningful state: setup, precondition, action, confirmation,
+  result, error, and any comparison point.
+- **Never claim something rendered or worked unless you observed it in the UI.**
+  "It should work" is not a test result. If you could not observe it, the result is
+  *blocked*, not *pass*.
+
+### 2. Separate expected from observed
+
+For every scenario track six fields, and keep them distinct:
+
+| Field | Meaning |
+|---|---|
+| Expected | What the spec, docs, or user said should happen |
+| Actual | What you observed, in neutral language |
+| Evidence | Path to the screenshot or artefact that proves it |
+| Severity | Blocker / major / minor / cosmetic |
+| Likely cause | Your hypothesis, explicitly flagged as a hypothesis |
+| Next action | Retest, escalate, log, or accept |
+
+### 3. Classify the failure before reporting it
+
+A failing test is not automatically a product bug. Classify every failure as one of:
+
+- **Product limitation** — the platform genuinely cannot do this
+- **Product defect** — it should work and doesn't
+- **Test harness limitation** — your automation couldn't reach the state
+- **Tenant / configuration issue** — environment, licence, feature flag, DLP policy
+- **Authentication issue** — wrong account, expired session, missing consent
+- **Model drift** — a non-deterministic AI response, not a code path
+
+Misclassifying a tenant config problem as a product defect destroys the credibility
+of the whole report. When you are unsure, say so and state what would disambiguate it.
+
+### 4. Use stable test data
+
+- Prefer deterministic, seeded data so a run is repeatable.
+- If an agent or model under test needs data, give it a small fixed dataset or a
+  tool/fixture. Do not let the model invent facts and then test the invention.
+- For dynamic rendering, use controlled inputs and verify the output artefact
+  directly rather than eyeballing the chat bubble.
+
+### 5. Browser testing standards
+
+- Keep the browser visible when the user wants to watch. Resume from whatever state
+  they've positioned it in rather than resetting.
+- Be patient with admin centres and heavy SPAs — they are slow, and a premature
+  assertion produces a false failure. Wait for a specific element, not a fixed sleep,
+  wherever possible.
+- Save screenshots to `output/<test-name>/` with descriptive, sortable names:
+  `03-after-submit-error-toast.png`, not `screenshot3.png`.
+
+## Standard workflow
+
+### 1. Charter — scope and hypothesis
+
+Write a short test charter before touching the browser:
+
+- Objective — the decision this testing needs to inform
+- Application under test
+- Environment: tenant, URL, browser, account, licence
+- Test data
+- Hypotheses to confirm or refute
+- Success criteria
+- Known risks and out-of-scope areas
+
+### 2. Readiness — verify the environment
+
+Before executing anything, confirm: authentication state, correct tenant and
+environment, required browser session, output folder exists, and tooling is
+available. Half of all "product bugs" found in a rushed pass are actually a wrong
+environment.
+
+### 3. Scenario map — user-visible behaviour
+
+Decompose the request into scenarios. For each: trigger/input, expected UI or
+behaviour, steps, evidence to capture, and pass/fail criteria. Write scenarios in
+terms of what a user sees, not what the code does.
+
+### 4. Adversarial pass — how this fails in the field
+
+Deliberately add scenarios for:
+
+- Empty, missing, or malformed data
+- Permission and authentication failures
+- Slow propagation and eventual consistency between surfaces
+- Unsupported rendering paths and fallbacks
+- Non-deterministic model output and hallucination
+- State mismatch between two admin surfaces that show "the same" setting
+
+### 5. Execute
+
+Per scenario: navigate, act, screenshot before and after each key action, capture
+relevant UI text and DOM signals, and record failures with exact evidence at the
+moment they occur. Do not batch evidence capture until the end — state will be gone.
+
+### 6. Evidence ledger
+
+Maintain an inventory as you go, not afterwards:
+
+| Screenshot path | Scenario | What it proves | Caveats |
+|---|---|---|---|
+
+The "what it proves" column is the discipline. If you cannot write it, the
+screenshot is decoration and the scenario is untested.
+
+### 7. Synthesis
+
+Produce: executive summary, scenario-by-scenario findings, an outcome matrix,
+risks and concerns, a recommended path forward, and an evidence index.
+
+## Testing rich chat and dynamic UI
+
+When testing conversational or agent UI, these are distinct capabilities that fail
+in distinct ways. Test them separately:
+
+1. **Prompt-only formatting** — Markdown, tables, headings, emoji, link lists.
+   Expected limitation: this is text, not native cards or actions.
+2. **Adaptive Card JSON** — test whether JSON emitted by instructions actually
+   renders, or appears as a code block. Common finding: model-generated card JSON is
+   displayed as text; native cards require a real card attachment or an authored
+   card node, not a prompt instruction.
+3. **Hosted static images** — host over HTTPS and test whether Markdown image syntax
+   renders inline in each channel.
+4. **Dynamically generated images** — verify the generated artefact directly for
+   readability, contrast, and *data correctness*, then verify it renders in-channel.
+   Two separate failures live here.
+5. **Interactive actions** — links, deep links, suggested actions, card actions,
+   quick replies. A Markdown link is not an action button; test the difference.
+6. **Carousels** — test native card collections where supported, and document the
+   composite-image or sequential fallback where not.
+
+Test each surface separately per channel. A response that renders in the authoring
+test pane frequently does not render in Teams, and vice versa.
+
+## Reporting
+
+When producing a deck or written report:
+
+- Include the charter and methodology — a result without its method is not reusable.
+- Include evidence for every material scenario.
+- Include a matrix: approach, outcome, evidence, pros, cons, guidance.
+- **Include explicit "this did not work" content.** Failed approaches are often the
+  most valuable output, and omitting them means the next person repeats them.
+- Export the finished slides to images and inspect them. Fix tiny text, overflow,
+  clipping, poor contrast, and missing screenshots before delivering.
+- Prefer more slides with fewer columns over one dense unreadable table.
+
+## Final response format
+
+Lead with the outcome, in this order:
+
+1. What was tested
+2. What worked
+3. What failed, and the classification of each failure
+4. Where the artefacts are saved
+5. What should happen next
+
+Keep the chat response short. The detail belongs in the report.
diff --git a/src/content/skills/copilot-studio-agent-test.md b/src/content/skills/copilot-studio-agent-test.md
new file mode 100644
index 00000000..9d093b74
--- /dev/null
+++ b/src/content/skills/copilot-studio-agent-test.md
@@ -0,0 +1,351 @@
+---
+name: Copilot Studio Agent Test
+description: Test a Copilot Studio agent against your own Q&A set and get a graded pass/fail report — no browser automation.
+agentDescription: "Test Microsoft Copilot Studio agents programmatically against a set of question/answer pairs, without driving a browser. Use when the user wants to evaluate, test, validate, benchmark or regression-test a Copilot Studio agent; run an eval set or test set against an agent; check whether an agent answers correctly from its knowledge bases; verify agent grounding or citations; or ask a Copilot Studio agent a question from the command line. Triggers include 'test my Copilot Studio agent', 'run an eval against the agent', 'validate agent answers', 'check the agent knowledge base', 'ask the agent', 'regression test the agent'. Do NOT use for building or authoring agents, for Copilot Studio topic design, or for testing declarative agents in Microsoft 365 Copilot."
+platforms: [Scout]
+tags: [copilot-studio, testing, evaluation, quality, agents, power-platform]
+author: Matteo Pagani
+authorUrl: "https://github.com/qmatteoq"
+authorGithub: qmatteoq
+version: 1.0.0
+createdAt: 2026-08-10
+updatedAt: 2026-08-10
+bundle: bundles/copilot-studio-agent-test.zip
+---
+# Copilot Studio agent testing
+
+Runs questions against a Copilot Studio agent through the Microsoft 365 Agents SDK
+(`CopilotStudio.Copilots.Invoke`), captures answers and citations, and writes results to
+CSV and JSON for review.
+
+Each question runs in a **fresh conversation** — the programmatic equivalent of clicking
+*New chat* — so no answer benefits from context set by a previous one.
+
+> **Requires Node.js 22 or later.** There is no bundled executable — the tool is a single
+> JavaScript file, so nothing unsigned is executed and endpoint policy has nothing to block.
+>
+> Invoke it from this skill's directory. **Prefer the `node` form** — it is identical on
+> Windows, macOS and Linux, and works in every shell:
+>
+> ```
+> node scripts/cs-agent-test.cjs <command>
+> ```
+>
+> Convenience launchers exist if you would rather not type `node`:
+> `.\scripts\cs-agent-test.cmd` on Windows, `sh scripts/cs-agent-test.sh` elsewhere.
+>
+> Examples below use the `node` form, so they can be copied as-is on any platform.
+>
+> **Check Node first.** If `node --version` fails or reports below v22, stop and tell the user
+> to install Node.js 22+ from https://nodejs.org — every command will fail until they do.
+
+## What this tool does and does not do
+
+**Does:** send questions, capture answers, extract citations, detect escalation, flag empty
+turns, check optional required substrings, convert Word Q&A documents into test sets, and
+assemble a pass/fail report from verdicts it is given.
+
+**Does not** decide by itself whether an answer is semantically correct. That grading pass is
+**step 3 of the workflow below and is performed by you**, by reading each answer against the
+expected one. The report then carries real pass/fail verdicts. Never fabricate a pass rate the
+tool did not receive from a grading pass.
+
+## First run
+
+Setup collects four values: application (client) ID, tenant ID, environment ID, and agent
+schema name. They are written to `~/.cs-agent-test/config.json` — the **user's** home folder,
+never this skill folder, so the skill stays shareable. There are no secrets involved: auth is
+delegated device-code, so nothing sensitive is ever collected or stored.
+
+**Preferred path — ask the user in chat and write the config yourself.** Do not drive the
+Copilot Studio portal with a browser to find these values; just ask, and give the exact click
+path below so the user knows where to look.
+
+The click path differs between the two authoring experiences. **Ask the user which one they
+have** if it is not obvious — or just give them both, they will recognise their own UI.
+
+**Step 1 — environment ID.** Same for everyone. It is the GUID in the Copilot Studio URL:
+
+```
+copilotstudio.microsoft.com/environments/<ENVIRONMENT-ID>/agents/...
+```
+
+Ask the user to paste the whole browser URL and take the GUID from it yourself.
+
+**Step 2 — schema name.** This is *not* the display name; it looks like `cr1a3_myAgentName`.
+
+- **New authoring experience** (agent page has Build / Preview / Evaluate / Monitor tabs):
+  > Open the agent → **⋯ (More options)** in the top right → **Settings** →
+  > **Agent details** → **Identity** → **Schema name**.
+
+  It is read-only — set when the agent was first saved and never changeable.
+
+- **Classic agents** (agent page has Overview / Topics / Channels in the left nav):
+  > Open the agent → **Settings** → **Advanced** → **Metadata** → **Schema name**.
+
+  Classic agents also expose **Channels → Native app**, whose **Connection string** contains
+  the environment ID *and* the schema name in one value. If the user has that page, it is the
+  fastest option — pass the whole URL to `--connection-string` and skip Steps 1 and 2.
+  **New-experience agents do not have a Native app channel**, so do not send users hunting
+  for it.
+
+**Step 3 — app registration.** Ask for the *Application (client) ID* and *Directory (tenant) ID*.
+Both are on the app's **Overview** page in the Entra admin center. If the user does not have an
+app registration yet, walk them through it:
+
+> **App registrations → New registration** — any name, single tenant, no redirect URI.
+> Then **Authentication → Allow public client flows → Yes**.
+> Then **API permissions → Add a permission → APIs my organization uses →
+> Power Platform API → Delegated → CopilotStudio.Copilots.Invoke** (note the plural), and
+> **Grant admin consent**.
+
+**Then write the config:**
+
+```
+node scripts/cs-agent-test.cjs setup --client-id <guid> --tenant-id <guid> ^
+                                --environment-id <guid> --schema-name <name>
+
+REM classic agents only, if they had the Native app connection string:
+node scripts/cs-agent-test.cjs setup --client-id <guid> --tenant-id <guid> ^
+                                --connection-string "<pasted url>"
+```
+
+Read the values back to the user before saving — a typo'd schema name fails quietly.
+
+**Fallback — the interactive wizard.** For users driving the CLI standalone, or when they would
+rather create the app registration guided step by step:
+
+```
+node scripts/cs-agent-test.cjs setup
+```
+
+It also accepts the connection string (press Enter to skip and type the values instead), and
+needs a real terminal; if stdin is not a TTY it says so and stops rather than hanging.
+
+Then:
+
+```
+node scripts/cs-agent-test.cjs login     # device code — needs a human at a browser
+node scripts/cs-agent-test.cjs doctor    # verifies config, sign-in and connectivity
+```
+
+`doctor` is the fastest way to diagnose a problem. Run it before anything else if a command fails.
+
+## Usage
+
+```
+node scripts/cs-agent-test.cjs ask "What is the company car policy?"
+node scripts/cs-agent-test.cjs test questions.csv --out .\results
+
+# flags
+--limit 5          # first N questions only
+--ids 1,7,23       # specific IDs
+--delay 1000       # ms between questions
+--timeout 180000   # per-turn timeout (default 120000)
+--config cfg.json  # alternative config file
+
+# other commands
+setup    configure (wizard, or --flags for scripted)
+config   show current settings and sign-in state
+doctor   end-to-end health check
+login / whoami / logout
+new      write a starter test set
+convert  Word (.docx) Q&A document -> test set CSV
+report   results JSON + your verdicts -> Markdown report
+```
+
+## The full workflow
+
+A complete evaluation is **four** steps. Steps 1–2 and 4 are the CLI; **step 3 is yours** and
+must not be skipped — a run without it produces a report where every row says REVIEW.
+
+```
+1. convert   Word Q&A document  ->  test set CSV        (skip if you already have a CSV)
+2. test      test set CSV       ->  results CSV + JSON
+3. GRADE     you read every answer against Expected  ->  verdicts CSV
+4. report    results + verdicts ->  Markdown report
+```
+
+### Step 1 — prepare the test set
+
+**Ask the user which Q&A file(s) to use. Never propose a file yourself.** This skill tests any
+agent against any question set — do not browse the user's disk for likely candidates, do not
+offer a menu of documents you happen to have seen, and do not assume a previous run's file is
+wanted again. Ask for a path, and ask how many questions to run.
+
+Accepted inputs:
+- a **Word document** (`.docx`) with a two-column Q&A table — convert it (below)
+- a **CSV** in the format documented under *Test set format*
+- the **Copilot Studio eval template** CSV, unchanged
+
+If the user names several files, confirm whether they want one run per file (usually right —
+results stay attributable to a knowledge base) or one combined run.
+
+Convert Word documents rather than retyping:
+
+```
+node scripts/cs-agent-test.cjs convert "<their-file>.docx" testset.csv
+node scripts/cs-agent-test.cjs convert "<their-file>.docx" --dry-run   REM preview first
+```
+
+This reads **two-column tables**: question in column 1, expected answer in column 2. A header
+row such as *Domanda / Risposta attesa* is skipped. Only `.docx` is supported — for `.doc`,
+`.pdf` or anything else, open it in Word and Save As `.docx`, or build the CSV by hand.
+
+Always `--dry-run` first and sanity-check the pair count against the document. If the layout is
+not a two-column table, do not fight the converter — write the CSV yourself in the format below.
+
+### Step 2 — run the questions
+
+```
+node scripts/cs-agent-test.cjs test carpolicy.csv --out .\results
+```
+
+On a large set, run `--limit 3` first to confirm connectivity before committing to a long run.
+Expect **30–60 seconds per question**; a 60-question set takes roughly 45 minutes. Tell the user
+that up front, and ask how many questions they want rather than deciding for them.
+
+### Step 3 — grade the answers (mandatory, and it is your job)
+
+The CLI cannot judge correctness and never pretends to. After the run, **read every answer in
+the results JSON against its `expected` value** and decide the verdict yourself.
+
+Get a pre-filled sheet to work from:
+
+```
+node scripts/cs-agent-test.cjs report .\results\results-<ts>.json --template verdicts.csv
+```
+
+Then fill in one row per question — `id`, `verdict`, `reason`:
+
+| Verdict | When to use it |
+|---|---|
+| `PASS` | The answer conveys what the expected answer conveys. **Different wording is fine.** A more complete or better-organised answer is still a PASS. |
+| `FAIL` | Wrong, contradicts the source, invents policy, misses the substance of the question, or returns nothing. |
+| `EXCLUDED` | The question itself is unsound — mis-filed, a conversational follow-up that cannot stand alone, or testing something out of scope. Removed from the denominator. |
+
+A `reason` is required for every FAIL and EXCLUDED. Make it specific and actionable — *"quotes
+a 30-day return window; the policy says 14 days"*, not *"incorrect"*.
+
+**Grading rules — these matter, and they are easy to get wrong:**
+
+1. Judge **substance, not wording**. Answers routinely differ from the expected text and
+   sometimes improve on it. That is a PASS.
+2. **Inventing policy is always a FAIL**, even when the invention sounds plausible. Check any
+   specific claim (numbers, deadlines, amounts) against the expected answer.
+3. **Escalating is not automatically a failure.** It is correct behaviour when the knowledge
+   genuinely is not in the KB. It is a FAIL only when the agent escalates *although the answer
+   exists in the source document*.
+4. If the source document itself is wrong or inconsistent, that is **not** an agent failure —
+   but call it out in the report as a knowledge-base finding. It usually matters more.
+
+### Step 4 — build the report
+
+```
+node scripts/cs-agent-test.cjs report .\results\results-<ts>.json report.md ^
+        --verdicts verdicts.csv --title "HR agent evaluation" --subject "KB_CarPolicy"
+```
+
+Produces a run summary (counts, pass rate, citation coverage, average response time), a table of
+every question with expected answer, actual answer, verdict and failure reason, and a detailed
+section for each failure. Exclusions are dropped from the pass-rate denominator.
+
+Add `--full` to stop truncating long answers.
+
+If the user wants Word or a vault page, convert the Markdown afterwards — the report is plain
+Markdown by design.
+
+## Test set format
+
+The required format is a CSV with these columns:
+
+```
+"id","question","expected","expectContains"
+"1","Chi ha diritto all'auto aziendale?","Va verificato con l'HR Business Partner.","HR Business Partner"
+```
+
+- `id` — **keep the original row number from the source document.** Do not renumber. Gaps and
+  IDs above the row count are expected, and let any finding be traced back to its source.
+- `question` — what is sent to the agent. Required.
+- `expected` — the answer from the Q&A document. Optional for capture-only runs, but
+  **required for grading** — without it there is nothing to judge against.
+- `expectContains` — optional; `|`-separated substrings that must appear. Literal matching only,
+  useful for things like a phone number or a portal URL. Not a substitute for grading.
+
+The **Copilot Studio eval template** is also accepted unchanged (`conversationNumber, question,
+response`); its `#` comment header is skipped automatically.
+
+Other input formats: use `convert` for Word documents. For anything else, produce the CSV above
+yourself — that is often quicker than coercing an odd layout.
+
+`new` writes a starter file with the correct header, and
+`assets/example-testset.csv` is a worked example.
+
+## Output
+
+`results-<timestamp>.csv` and `.json`, columns:
+
+`ID · Question · Expected · Actual · Citations · Escalated · Answered · ContainsAll · Missing · ElapsedMs · Error · Verdict · Notes`
+
+`Notes` is left empty for the reviewer's verdict.
+
+## Reading the results
+
+| Signal | Meaning |
+|---|---|
+| `Answered = no` | Turn returned nothing. Check `Error`. |
+| `Citations` empty | Answer not grounded in a knowledge source. Suspicious for a KB question. |
+| `Escalated = yes` | Agent handed off instead of answering. **Only a defect if the knowledge actually exists** — the tool cannot know that, so check the source document. |
+| `Error` mentions consent | Turn stalled behind an interactive permission prompt. Retry; usually transient. |
+| `ContainsAll = no` | A required substring was missing. See `Missing`. |
+
+## Known constraints
+
+- **Classic vs agentic runtime.** Agents built with the new Copilot Studio authoring experience
+  run on the *agentic* runtime, at a different endpoint than classic agents. The tool detects
+  this automatically: if the classic endpoint returns the notice *"Enhanced task completion
+  preview has ended... republish the agent"*, it silently retries on the agentic endpoint and
+  remembers the result for the rest of the run. Force it with `--runtime agentic` at setup if
+  you want to skip the probe. **That notice is not a publishing problem** — republishing does
+  not fix it, and the tool would otherwise have recorded it as the agent's answer to every
+  question.
+- **This tests the PUBLISHED agent, not the draft.** The Copilot Studio test pane tests the
+  draft. Changes made in the authoring canvas are invisible here until the agent is published,
+  and a draft that answers well can fail here. Always publish before a run.
+- **Delegated auth only.** The Agents SDK does not support service principal tokens, so fully
+  unattended CI is not possible. One device-code sign-in is cached and covers an entire run.
+  For true headless automation Microsoft directs you to the Direct Line API.
+- Answers take **seconds to a minute**. Long test sets take a while.
+- Occasional consent prompts or transient stalls surface as `Error`. Retry those rows.
+
+## Privacy
+
+The skill folder contains no user data — config and tokens live in `~/.cs-agent-test/`, so the
+skill can be shared or version-controlled without carrying anyone's settings.
+
+`references/THIRD-PARTY-NOTICES.md` lists the open-source packages bundled into
+`scripts/cs-agent-test.cjs`.
+
+## Guidance when running this for a user
+
+1. Run `doctor` first. It distinguishes "not configured" from "not signed in" from
+   "cannot reach the agent", which saves a lot of guessing.
+2. `setup` and `login` both need a human. Do not try to fake either.
+3. On a large test set, offer `--limit` first to confirm connectivity before a long run, and
+   warn the user it runs at roughly 30–60 seconds per question.
+4. **Ask for the inputs; do not supply them.** Ask which Q&A file(s) to test and how many
+   questions. Never pick a file for the user, never offer a menu of documents you found on
+   their disk, and never reuse a previous run's file without being asked. The agent under
+   test and the question set both belong to the user.
+5. **Always finish the job.** A `test` run is not the deliverable — the graded report is. Carry
+   on through step 3 (grade every answer) and step 4 (build the report) unless the user
+   explicitly asks you to stop at raw results.
+6. **Never invent a pass rate.** The number in the report must come from verdicts you actually
+   made by reading the answers. If you have not graded a question, leave it REVIEW and say so.
+7. When presenting results, lead with the pass rate and the failures, and state plainly that
+   grading was a judgement call you made against the source documents. Surface knowledge-base
+   problems separately from agent problems — the customer usually needs to fix the KB.
+8. **Tell the user where the report is**, and offer the contents inline. The deliverable is the
+   report, not a path they have to go and find.
+
+
diff --git a/src/content/skills/travel-cost-estimator.md b/src/content/skills/travel-cost-estimator.md
new file mode 100644
index 00000000..d8cacd68
--- /dev/null
+++ b/src/content/skills/travel-cost-estimator.md
@@ -0,0 +1,267 @@
+---
+name: Travel Cost Estimator
+description: "Price a business trip from live fares in your corporate booking tool, benchmark the non-bookable lines against your own approved expense reports, and produce an estimate a manager can approve — with a hard guardrail that never enters the booking funnel."
+agentDescription: "Use this skill whenever the user needs a cost estimate for a business trip — including \"what will it cost to get to X\", \"price up that customer visit\", \"I need a travel budget for the offsite\", or a manager asking for a number before approving travel. Prices flights and hotels live from the company's browser-based booking tool, benchmarks the non-bookable lines against the user's own approved expense reports, and produces a forwardable estimate. Do NOT use this skill to actually book, hold, or confirm travel."
+platforms: [Scout]
+tags: [travel, expenses, browser-automation, playwright, finance, productivity]
+author: Al Macey
+authorUrl: "https://github.com/amacey-msft"
+authorGithub: amacey-msft
+version: 1.0.0
+createdAt: 2026-08-04
+updatedAt: 2026-08-04
+---
+# Travel cost estimator
+
+Produce a defensible trip estimate from **live fares and rates**, not guesses, and
+present it so the user can forward or approve it in seconds.
+
+The estimate has two halves. Flights and hotels come from the corporate booking tool.
+Ground transport, meals, and parking are not in the booking tool, so they get
+benchmarked against what the user has actually been reimbursed before.
+
+---
+
+## HARD GUARDRAIL — read this first
+
+**The corporate booking tool is a live booking system. Real money, real tickets,
+real change fees, real non-refundable segments.**
+
+You are here to **search and price only.**
+
+**Never click:** `Continue` past fare selection · `Select hotel` into a booking
+funnel · `Book` · `Reserve` · `Hold` · `Confirm` · anything on a traveller-details
+or payment page.
+
+Reading fares off a **results page** is safe — results and the booking funnel are
+separate pages, and the results page is where you stop. That line is the whole
+guardrail.
+
+If a flow ever lands on a page showing traveller details, payment fields, or a
+confirm button: **stop immediately, do not click anything, and tell the user where
+you are.** Do not try to navigate back out by clicking through.
+
+Every estimate you produce must state **"Nothing booked."** explicitly.
+
+---
+
+## Step 0 — establish the traveller's preferences
+
+Before the first search, confirm (or reuse from a previous run):
+
+| | |
+|---|---|
+| Home airport | |
+| Preferred airline / alliance | |
+| Preferred hotel chain | |
+| Cabin class permitted by policy | |
+| Trip dates and destination | |
+| Rental car likely? | |
+
+Do not assume a home airport from the user's city — many metros have several, and
+the wrong one silently produces a plausible, useless number.
+
+Record these preferences so later runs skip this step, but **re-confirm the dates
+every time.**
+
+---
+
+## Step 1 — reach the booking tool
+
+Use the company's SSO entry point for the booking tool (commonly a corporate
+shortlink or an intranet tile) so the existing session is reused.
+
+**Two failure modes worth knowing:**
+
+1. **Don't reuse a previously pasted deep link** containing a session token
+   (`id=`, `_dp_=`, or similar). These are session-scoped and expire, and the
+   symptom is misleading — you land on a generic *"Cookies are disabled"* error
+   rather than a session-expired message. Go back to the clean entry point.
+2. **Don't use the vendor's direct login URL.** It presents a username/password
+   form with no SSO path. **Never ask the user for their credentials** — if SSO
+   isn't working, stop and say so.
+
+---
+
+## Step 2 — price the flight
+
+Navigate to the flight search. The DOM patterns below are typical of enterprise
+booking portals (Cytric/Amadeus, and similar Concur/Egencia-family tools) and will
+save a lot of wasted time:
+
+**1. Origin and destination are comboboxes, not text inputs.**
+
+```js
+await page.getByRole('combobox', { name: /arrival location/i }).click();
+await page.keyboard.type('Orlando');
+await page.waitForTimeout(3500);           // suggestion lookup is server-side and slow
+await page.getByRole('option', { name: /Orlando International \(MCO\)/i }).click();
+```
+
+Pick the **airport** option, not the city option. Metro-area city entries
+(e.g. a city code covering several fields) resolve to a different, less useful
+inventory set for air search.
+
+**2. Airline filter is another combobox** — type the carrier, click the option,
+then press `Escape` to close the dropdown. Leaving it open blocks the search button.
+
+**3. Date fields are hidden inputs behind a calendar widget.** Clicking the visible
+date label opens a date picker that is awkward and flaky to drive. Set the hidden
+inputs directly with the native setter and dispatch the events the framework
+listens for:
+
+```js
+await page.evaluate(({ depart, ret }) => {
+  function setVal(name, value) {
+    const el = document.querySelector(`input[name="${name}"]`);
+    if (!el) return;
+    const setter = Object.getOwnPropertyDescriptor(
+      window.HTMLInputElement.prototype, 'value'
+    )?.set;
+    if (!setter) return;
+    setter.call(el, String(value));
+    ['input', 'change', 'blur'].forEach(e =>
+      el.dispatchEvent(new Event(e, { bubbles: true }))
+    );
+  }
+  setVal('air-departure-date-month', depart.month);
+  setVal('air-departure-date-day', depart.day);
+  setVal('air-departure-date-year', depart.year);
+  setVal('air-return-date-month', ret.month);
+  setVal('air-return-date-day', ret.day);
+  setVal('air-return-date-year', ret.year);
+}, { depart: { month: 8, day: 26, year: 2026 }, ret: { month: 8, day: 27, year: 2026 } });
+```
+
+Field names vary by tool — inspect once and reuse. The **technique** transfers even
+when the names don't: assigning `.value` directly is ignored by React/Angular, so you
+must go through the prototype setter and fire the events.
+
+**4. Search, then wait ~20 s.** Results are genuinely slow. Read the rendered page
+text rather than taking a full accessibility snapshot — the results table is large
+and a snapshot wastes an enormous amount of context for no benefit.
+
+**Capture per option:** flight numbers, departure and arrival times, stops, total
+travel time, fare, and whether it is flagged **in policy**.
+
+---
+
+## Step 3 — price the hotel
+
+Start from a **fresh session at the entry point** rather than back-navigating out of
+flight results — back-navigation frequently restores a half-populated form.
+
+**DOM patterns:**
+
+1. **The location control is often a select2-style widget.** The real
+   `select[name="location"]` is `aria-hidden` and cannot be clicked. Drive the
+   visible proxy instead:
+
+   ```js
+   await page.locator('span.select2-selection[role="combobox"]').first().click();
+   await page.keyboard.type('Orlando');
+   await page.waitForTimeout(4500);
+   await page.locator('li[role="option"], .select2-results__option').first().click();
+   ```
+
+2. **Dates use the same hidden-input pattern** as flights, typically named
+   `date-range-from-*` and `date-range-to-*`.
+
+3. **The search click may time out waiting for navigation.** That's usually fine —
+   the form submitted and the page updated in place. Wait ~20 s and read the page
+   rather than retrying the click, which can double-submit.
+
+4. **Chain filters live in a facet list** and are often overlapped by a sticky
+   header. Click with `{ force: true }`, then wait ~12 s for the results to refilter.
+
+**Capture per option:** hotel name, brand, distance from the search point, nightly
+rate, whether breakfast is included, and the in-policy flag.
+
+---
+
+## Step 4 — fill the non-bookable lines
+
+Ground transport, meals, and parking aren't in the booking tool. **Benchmark them
+against the user's own approved expense reports rather than inventing numbers** —
+this is what makes the estimate defensible when a manager questions it.
+
+Search the user's mail for their expense system's notification messages (approved
+report summaries usually carry a report ID and a total). Pull the totals for
+comparable trips — same trip length, similar destination type — and derive the
+per-line figures from those.
+
+Then state each non-bookable line **as an explicit assumption**, e.g.:
+
+- Ground transport (rideshare, both directions)
+- Meals (per diem x days)
+- Airport parking (x days) — or omit if arriving by other means
+
+Never present these as if they were priced. Label them "assumption" in the table.
+
+**If a rental car is plausible, say so.** It moves the number materially and is the
+most common reason an estimate turns out low.
+
+---
+
+## Step 5 — build the estimate
+
+Write the full working to a file so it can be revisited, and keep the chat response
+short.
+
+Structure:
+
+1. **Header** — customer or purpose, traveller, route, dates, and the date priced
+2. **Recommended estimate** — a single rounded figure a manager can approve, with
+   the cost table beneath it
+3. **All flight options** — times, stops, fares, in-policy flags, plus your
+   recommendation and the reasoning
+4. **All hotel options** — preferred chain first, alternatives after
+5. **Basis for the non-bookable lines** — which past reports you benchmarked against
+6. **Caveats** — live pricing is not held, fares drift daily, **nothing booked**
+
+### Two judgement rules
+
+**Always surface a materially cheaper alternative, even when it breaks the stated
+preference.** Give the trade-off — cost vs. proximity vs. loyalty status — and let
+the traveller choose. Do not silently optimise for price, and do not silently
+optimise for preference. Presenting one option as though it were the only option is
+the failure mode here.
+
+**Recommend the non-stop when the time saved is significant.** On a short trip a
+modest premium that buys back hours in each direction is usually correct — but
+present it as a choice with the delta stated in both dollars and hours, not as a
+foregone conclusion.
+
+---
+
+## Step 6 — send it on (only when asked)
+
+If the user asks you to forward the estimate to their manager or approver:
+
+**Resolve the recipient by UPN, not by display alias.** A vanity SMTP alias
+(`First.Last@company.com`) usually works for mail but **fails for Teams chat
+creation with `user_not_found`** — Teams resolves on the UPN
+(`flast@company.com`). Look the UPN up rather than guessing, and don't conclude the
+person doesn't exist when the alias fails.
+
+**Show the user the exact message and recipient, and get explicit confirmation
+before sending.** A travel estimate contains the user's dates, destination, and
+customer — treat it as private until they say otherwise.
+
+Message shape — keep it to a screen:
+
+- One line of context (purpose, dates)
+- **The headline number, in bold**
+- The cost table
+- The one or two judgement calls, stated as explicit questions rather than buried
+  in prose
+- "Fares are live as of today and in policy. **Nothing booked yet.**"
+
+Approvers want the number and the options, not the process.
+
+---
+
+## Output style
+
+Lead with the number. Put the trade-offs where they cannot be missed. Never present
+a single option as if it were the only one. Always state that nothing was booked.
diff --git a/src/data/downloads.json b/src/data/downloads.json
index 892b5f97..4ed76b82 100644
--- a/src/data/downloads.json
+++ b/src/data/downloads.json
@@ -1,12 +1,12 @@
 {
-  "agent-harness-explorer": 142,
-  "ai-usecase-assessment": 133,
-  "brand-template-enforcer": 98,
-  "chart-builder": 255,
-  "doc-format-converter": 177,
-  "linkedin-content-writer": 60,
-  "powerpoint-deck-designer": 101,
-  "redlining-content": 81,
-  "rich-html-presentation": 110,
-  "skill-authoring-coach": 101
+  "agent-harness-explorer": 198,
+  "ai-usecase-assessment": 157,
+  "brand-template-enforcer": 113,
+  "chart-builder": 321,
+  "doc-format-converter": 211,
+  "linkedin-content-writer": 72,
+  "powerpoint-deck-designer": 142,
+  "redlining-content": 109,
+  "rich-html-presentation": 142,
+  "skill-authoring-coach": 124
 }