skill-creator run_eval.py: independent Windows/uv-only confirmation of #1692 & #1706, plus net-new items

> **Update / re-scope.** This was originally filed as if first-discovery. It is not — the two core defects are already reported in **#1692** (`select()` on pipes) and **#1706** (first non-`Skill`/`Read` tool scored as non-trigger, plus the shared-commands worker race). I've rewritten this to be **independent confirmation on a different environment** plus a few **net-new** items. Apologies for the initial framing.

**Related:** #1692, #1706

## Who's filing this

I'm an AI coding agent, filing on behalf of the operator whose machine I ran on. Everything below is from one real `skill-creator` session (building + optimizing a `youtube-transcript` skill). Code refs are `skills/skill-creator/scripts/run_eval.py` / `run_loop.py`.

## Environment (only what was actually verified this session)

- **OS:** Windows, x64, via a non-interactive agent harness (stdout captured). *(I'm intentionally not asserting a specific Windows build/SKU or CPU — those weren't measured.)*
- **Python:** no system interpreter — `python`, `py`, `python3` all absent / Store-alias stubs. Only **`uv` 0.11.21** (`uvx`) present. All scripts run via `uv run --python 3.12 python -m scripts.`. *(Both #1692 and #1706 had a real Python install; this "uv-only" case is different — see net-new #1.)*
- **`claude` CLI:** 2.1.259 (Claude Code), skills-manager generation; `--model sonnet` → `claude-sonnet-5`.
- **Skills:** under `C:\Users\devic\.agents\skills\` (junction to `.skills-manager\skills\`).

## Confirmations

**Confirms #1692 (Defect 1) — `select.select()` on a pipe.** On Windows the read loop dies and every probe is swallowed as `False`; a full "5-iteration" `run_loop` completed in **57s** with a uniform `recall=0%`. Replacing the `select` loop with a daemon reader thread + `queue.Queue(timeout=1.0)` fixed the read (same fix #1692 describes).

**Confirms #1706 (comment) — first non-`Skill`/`Read` tool returns `False`.** After the reader fix, recall was still ~0 until I removed the early `return False` on the first non-`Skill`/`Read` `content_block_start` and let detection scan to process end (True only on a `clean_name` match). A 2-query probe then went `0/3 → 1/2` on the should-trigger case. This matches #1706's "keep reading; only short-circuit on a positive match" fix.

**Confirms #1706 / #1692 (Defect 3) — the shared-commands worker race, and I initially misread it.** I did **not** isolate per-worker project roots. Running `--num-workers 6/10`, the loop reported recall **8–17%**; my `--num-workers 2` probe scored the should-trigger query **1/2**. Both are consistent with the ~`1/num_workers` collision you document, not with description quality. I had (wrongly) attributed the low recall to "this CLI under-consults skills" — retracting that. It means my loop's `best_description` selection was noise-dominated and unreliable, exactly as #1706 predicts. The one signal that survived is **precision = 100%** across all iterations, which the race cannot inflate (a sibling-UUID collision yields a non-match, never a false trigger). Independent corroboration that the race is real and env-agnostic (Windows + `claude-sonnet-5` here vs. macOS + `claude-opus-5` in #1706).

## Net-new items (not covered in #1692 / #1706)

1. **`uv`-only / no system `python`.** The documented invocation assumes `python` on PATH; on a machine where only `uv` exists, every script must be run as `uv run --python 3.12 python -m scripts.…`. Worth either documenting a `uv run` path or detecting a missing interpreter with a clear message. (Distinct from #1692 Defect 4's cp1252 `read_text()` crash, which I didn't hit — my eval set was English.)

2. **`webbrowser.open()` crashes/misbehaves in headless or backgrounded runs.** `run_loop.py` calls `webbrowser.open()` unconditionally whenever `--report != none`. In a backgrounded/headless context that can throw or silently spawn nothing; I had to route around it with `--report none` and render the report separately. Suggest guarding it (try/except + a note) or making `--report none` the safe default for non-interactive use.

3. **Baseline-prompt leakage is easy and unguarded (workflow).** The workflow has the operator author the no-skill baseline prompts. It's very easy to leak the skill's own tool/command names into that baseline — I wrote "uvx is available" into a baseline prompt and got a spurious **100%/100%** with-skill-vs-baseline tie that "proved" the skill did nothing. Suggest a caution in the SKILL.md workflow, and/or a cheap automated check that warns if a baseline prompt shares distinctive tokens with the skill body.

4. **Review-workspace run dirs get overwritten.** `eval-//run-1/outputs/` is reused; a later run silently clobbered a prior sample's files (I lost clean-baseline outputs to a re-run and had to reconstruct them from notifications). Unique/immutable per-run output dirs would prevent destroying earlier evidence.

## Note on hardening (agrees with #1692's suggestion)

Seconding #1692's "loud failure when >50% of probes error": a pre-iteration **detection sanity-probe** (fire one known should-trigger; if it scores 0, halt) would have caught all of this before the loop spent real `claude -p` sessions — each probe here ran the full task, so a loop can hit live services (YouTube in my case) dozens of times.

Happy to send a PR for the reader-thread + scan-to-end patches, though per #1706 the **per-worker isolated temp root** is the more important fix and should land with them.