fix(skill-creator): close run_eval's 0% recall and harden the loop

[ob-aion]

Summary

Closes the 0% trigger-rate bug in skill-creator's description eval (#556) end to end. run_eval.py reported 0% recall for every query, so run_loop.py was optimizing against a metric that was always zero.

This builds directly on @MartinCajiao's #1298 — I've folded its isolated-project rewrite in here with credit, added the one fix it was missing, and pinned the whole thing with tests, so there's a single reviewable change instead of scattered halves.

Root causes:

• Wrong surface. The candidate was installed as a .claude/commands/ file, which claude -p never auto-triggers. It now installs as a real skill in an isolated, UUID-keyed temp project — the surface that actually auto-triggers.
• Shadowing (the missing half). Skill name resolution is user > project (docs), so a same-name skill already under ~/.claude/skills overrode the candidate and the eval measured the installed description. fix(skill-creator): run_eval.py always reports 0% recall — install the eval artifact as a real skill; fix Windows stream reading, trigger detection, and parallel workers #1298 warns about this; here run_eval moves the installed copy aside for the run and restores it after. Without it, recall still reads 0% whenever you optimize a skill you already have installed — the common case.
• Detection. Field-scoped, so a short name like pdf no longer counts reading report.pdf as a hit. Windows stream reading uses reader threads over select(), and shutil.which resolves the claude.cmd shim.
• Loop robustness. run_loop and generate_report crashed on max() over empty history for runs that exit before the first iteration; an improve_description failure discarded every collected iteration. Both are guarded.

What's new since #1298

• The user > project shadow is fixed, not just warned.
• Detection is extracted to a pure _detect_trigger, and the repo gets its first test scaffolding: 18 offline tests pinning the metric — short-name false positives, Windows paths, explore-then-trigger, shadow move/restore, the loop guards. Stdlib only, no API cost.

Consolidates the scattered attempts at this bug (#1298, #1323). Merging this closes #556 in one pass.

Test plan

• cd skills/skill-creator && python3 -m unittest discover -s scripts/tests — 18 pass
• python -m scripts.run_eval --eval-set <set>.json --skill-path <installed-skill>: recall reflects the description under test, not the installed copy
• python -m scripts.run_loop --eval-set <set>.json --skill-path <skill> --model <m> --max-iterations 0 exits cleanly

Fixes #556. Credit: @MartinCajiao (isolated-project rewrite), @KhalifaGad (field-scoped detection), @Vaikri-costume (loop guards), @xg-gh-25 (review that shaped the isolation).

[ob-aion]

@maheshmurag @rlancemartin — could one of you take a look when you get a chance? This fixes #556 (run_eval.py reporting a 0% trigger rate) and has been open since April, mergeable with no conflicts.

Update: #1298 independently reworks the same run_eval.py path, and its isolated temp-project approach is the cleaner base — I've followed up there to consolidate. The two are largely complementary: #1298 handles run_eval, while this PR also fixes run_loop.py, where an installed same-name skill shadows the eval and pins recall at 0%. Happy to fold that into #1298 so there's a single thing to review.

[ob-aion]

@maheshmurag @rlancemartin — refreshed this into the complete fix for #556 and rebased on current main.

It folds in @MartinCajiao's #1298 (the isolated-project run_eval rewrite, credited) plus the one thing that PR was missing: skill resolution is user > project, so an installed same-name skill shadows the project-level candidate and the eval measures the installed description — the reason recall reads 0% whenever you optimize a skill you already have installed. run_eval now moves the installed copy aside for the run.

Also adds the loop crash guards (@Vaikri-costume) and the repo's first offline test scaffolding — 18 tests, stdlib only, no API cost. Verified end to end: a matching query now scores 1.0, a non-matching one 0.0.

Merging this closes #556 and supersedes #1298/#1323 in one pass. Happy to adjust anything.