[Bug] Skills with disable-model-invocation: true are silently ignored when invoked via agent prompts

# Slash-command references in Agent prompts silently no-op (esp. disable-model-invocation: true skills)

Version: 2.1.210 (Claude Code)
Platform: macOS 26.5.2, arm64

## Summary

Referencing a skill as /skill-name inside a prompt passed to the Agent tool
does nothing. The subagent receives it as ordinary prose. There is no warning, no
error, and no signal to the spawning agent or the user that the intended workflow
never loaded.

This is especially sharp for skills with disable-model-invocation: true in their
frontmatter: those are user-invocable only, so a subagent cannot load them via the
Skill tool even if it correctly infers that it should. The reference is inert by
construction, and nothing says so.

## Repro

1. Create a personal skill ~/.claude/skills/my-workflow/SKILL.md with:

```yaml
---
name: my-workflow
description: "Implement a piece of work based on a PRD or set of issues."
disable-model-invocation: true
---
Use /tdd where possible. Run the full test suite at the end. Then use /review.

1. From a main-loop session, spawn a subagent whose prompt begins:

/my-workflow <task description>

1. Inspect the subagent's transcript for Skill tool invocations.

Expected: either the skill loads, or something surfaces that it can't —
a warning to the spawner, an error to the subagent, or a note in the tool result.

Actual: the subagent silently treats /my-workflow as plain text and proceeds
on its own judgment. The transcript shows the skill was never invoked. Nobody is told.

Impact

This bites hardest in the orchestration pattern the Agent tool is built for. A user
writes one brief and reuses it across many subagents. If that brief opens with a
slash command, the user reasonably believes every subagent is running that workflow.
In my case the brief was the sole mechanism intended to enforce a TDD-first workflow
across a six-part sequence of delegated work. It was inert for all of them, and the
failure was invisible until someone manually grepped a subagent's raw JSONL transcript.

The failure mode is quiet and directional: work still gets done, gates still pass, and
the output can look fine — so there's no natural moment where the gap announces itself.
It surfaces only if you go looking, and only if you know to look.

Contributing gap: no supported way to see which skills a subagent used

There's no supported way for a spawning agent to inspect which skills a subagent
actually invoked. Verifying this required grepping the raw transcript JSONL — which is
also explicitly discouraged, since reading that file can overflow the parent's context.
So the one available check is both unsupported and unsafe, and it's easy to draw a
confidently wrong conclusion from a fragile grep (I did, in both directions, before
reading the skill file itself).

Suggested fixes (any one would have prevented this)

1. Resolve slash commands in Agent prompts, the same way they resolve in user input.
2. If that's not intended, fail loudly. When an Agent prompt starts with /name

matching a known skill, return a warning in the tool result — especially when the
skill is disable-model-invocation: true and therefore unreachable to a subagent.

1. Document the constraint on both the Agent tool and the skill frontmatter field:

disable-model-invocation: true should state plainly that the skill cannot be
invoked by a subagent, and slash syntax in a prompt is not a supported invocation path.

1. Expose invoked skills in the Agent tool result — a short list of skills the

subagent loaded would make delegated workflows verifiable without transcript grepping.

Note on the frontmatter field name

disable-model-invocation reads as "the model can't invoke this," which is accurate,
but its practical consequence — no subagent can ever run this skill — isn't obvious
from the name or from anything at the call site. A user who authors such a skill for
their own interactive use may not realize it can't be delegated.