fix(skill-creator): match real skill name in eval trigger detection (#1338) - #1340

Fixes the trigger-detection bug reported in #1338.

Supersedes #1339, which was auto-closed after an accidental force-push corrupted its branch history (blowing the diff up to the whole tree). History rebuilt; this PR is the intended single-file change.

Problem

run_eval.py's run_single_query() installs the skill under a randomized command name stored in clean_name:

clean_name = f"{skill_name}-skill-{unique_id}"   # e.g. "change-delivery-skill-38eea5"

Detection then checks whether clean_name appears in the skill invocation. But Claude Code invokes the skill by its real name, not the randomized filename. Captured tool_use from a real run:

{"skill": "change-delivery", "args": "..."}

"change-delivery-skill-38eea5" is never a substring of "change-delivery", so the match is False 100% of the time. Every query — including textbook matches — scores "not triggered," making run_eval, run_loop, and the description optimizer non-functional on current Claude Code: every candidate description scores identically (100% precision / 0% recall), so the optimizer has no signal.

Fix

Add a field-scoped _skill_triggered() helper, used by both detection paths (streamed events and full assistant message):

• Skill calls: exact-match the real skill name (skill_name) — or clean_name — on the skill field.
• Read calls: match on file_path.

Field-scoping (rather than substring-matching the whole serialized input) avoids the inverse failure mode: a short, common skill name like test or pdf would otherwise match echoed argument text and over-count triggers. The streamed early-detection is preserved, but the stream path can now only early-return True — the full-message path stays authoritative, so it can't reintroduce the original false-negative.

Verification

Claude Code 2.1.140, model claude-opus-4-8, the only change being this patch:

The remaining 2 should-triggers are genuine model behavior (it self-serves those tasks), not detection misses. Additionally a topically-adjacent negative ("rename our deliveryPlan variable to plan…") stays correctly untriggered, and a unit check confirms a pdf-named skill no longer false-positives on a convert report.pdf argument.

Note for maintainers

Verified on Claude Code 2.1.140, where the model invokes via {"skill": "<skill_name>"}. The helper exact-matches that field (plus clean_name); if other CLI versions use a different invocation shape, only _skill_triggered() needs adjusting.

Refs #1338