…ol#2/modelcontextprotocol#3 write-up

Adds Scenario modelcontextprotocol#3 — `hf-train-with-monitoring` — testing whether the
host's <available_skills> catalog drives multi-skill activation when
one skill mentions another by topic without an explicit skill:// URI
reference. Also documents Scenario modelcontextprotocol#2 (hf-jobs dry-run) and modelcontextprotocol#3 in
docs/experimental-findings.md.

Plan evaluator changes
- expected_skill_uris (list) supersedes expected_skill_uri (singular,
  still accepted via backward compat)
- skill-read-before-plan passes only when EVERY listed skill's
  SKILL.md was read before the gate; banner note carries
  read=[...] missed=[...] for diagnostics
- raw payload gains skill_md_indices + missed_skills

Scenario validator
- Either expected_skill_uri or expected_skill_uris must be present
  (was: expected_skill_uri required as a base field)

New tests (45 total)
- Multi-skill happy path, partial activation (one skill missed),
  ordering (one skill after gate), backward-compat for legacy
  single-URI YAML

Findings (docs/experimental-findings.md)
- Scenario modelcontextprotocol#2 — four-client matrix on hf-mcp-server, all PASS;
  documents the prompt/skill conflict that surfaced in early runs
  (later fixed by reframing) and the goose gate_tools fix
- Scenario modelcontextprotocol#3 — cross-skill composition works for fast-agent / codex
  / goose; gemini-cli misses cross-skill activation across both flash
  and pro tiers, even when the model would otherwise cover the
  prescriptions via training-data synthesis. Suggests host-side
  ranking of <available_skills> rather than model capability is the
  constraint

Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>

…rotocol#3/modelcontextprotocol#4 as N=1 samples

Adds a one-line note under each scenario header so readers don't
mistake single-trial outcomes for stable behavioral claims. Re-running
flipped haiku from FAIL to PASS on the dispose-rule criterion in
Scenario modelcontextprotocol#4, which is exactly the noise the caveat warns about.

Pass-rate replication (N=3+ per cell) is the proper fix and pending
in a follow-up — N-trial wrapper in each client harness, then re-run
the matrix and rewrite the findings to report rates rather than
single-sample binaries.

Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>

Drop the "Scenarios modelcontextprotocol#2/modelcontextprotocol#3/modelcontextprotocol#4 are N=1, replication pending" snapshot —
that fact rots as findings get re-run. Keep just the principle:
treat individual outcomes as samples, not stable behavior.

Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>

…extprotocol#3/modelcontextprotocol#4

Three new YAMLs that exercise the plan-kind evaluator path:

- hf-jobs-plan.yaml (modelcontextprotocol#2): probes structured plan output (PEP 723 UV
  script + HF_TOKEN secret forwarding + Trackio instrumentation) on
  hf-mcp-server with HF_JOBS_DRY_RUN=true, so submissions are
  intercepted server-side and graded from the call args
- hf-train-with-monitoring.yaml (modelcontextprotocol#3): cross-skill composition --
  agent must independently activate both huggingface-llm-trainer
  and huggingface-trackio from the catalog, with required phrases
  drawn from both skills' references
- transformers-js-demo.yaml (modelcontextprotocol#4): code-output domain (browser HTML/JS
  artifact). No tool execution; phrase-grep checks @huggingface/transformers
  package + pipeline API + dispose() rule

All three use gate_tools to anchor skill-read-before-plan against
meaningful actions instead of housekeeping calls (todo writes,
catalog enumeration), so agentic planners aren't penalized.