Skill tool's forked execution describes plugin skills instead of running them; ignores `context` frontmatter field
Summary
When the Skill tool is invoked on a plugin skill, the spawned forked subagent treats SKILL.md as a task description to analyze/repair rather than as instructions to execute. The subagent reads the file, writes a prose summary of "what the skill does" and "its implementation status," and never calls the tools the skill instructs it to call. The context frontmatter field appears to be ignored — removing context: fork does not stop the Skill tool from forking.
This makes any plugin skill whose body says "call MCP tool X and render the result" effectively non-functional when invoked via slash command.
Environment
- Claude Code (VS Code native extension) on macOS (Darwin 25.4.0)
- Model: Opus 4.7 (1M context)
- Plugin skill with frontmatter
context: fork(and also reproduced after removing the field — still forked) - Skill body has clearly imperative steps:
### Step 1: …,### Step 2: Call mcp__server__tool …,### Step 3: Render results
Reproduction
- Define a plugin skill at
plugins/<plugin>/skills/<name>/SKILL.mdwhose body instructs the agent to call an MCP tool and render the result. (Nocommands/directory — onlyskills/.) - From a chat where the parent agent does have the MCP tool authenticated (verified by calling it directly — it returns valid data), invoke the skill via
/<plugin>:<name>(or viaSkill(skill="<plugin>:<name>")).
Example skill body:
### Step 2: Call the MCP
Call `mcp__some-server__list_things` with `name_filter=<arg or null>`.
### Step 3: Render results
Present the result as a numbered list of `path` values, followed by the count.
Expected
Forked subagent calls mcp__some-server__list_things, captures the result, and renders the list to the user.
Actual
Skill tool returns Skill "<plugin>:<name>" completed (forked execution). and the result body is a summary of the skill itself, e.g.:
"Perfect! I now have a complete understanding of the list-assets skill. Let me provide a comprehensive summary… Purpose: Lists authorized asset group paths… Implementation Steps: 1. Parse argument… 2. Callmcp__…3. Render results… Testing: Test coverage intest_list_assets_skill.pyvalidates…"
The MCP tool is never actually called. The subagent acts like a code reviewer/explainer of the SKILL.md file.
Things tried that did not fix it
- Adding an explicit imperative directive at the top of SKILL.md immediately after the frontmatter:
> > **EXECUTE NOW.** This is an imperative skill — call the MCP tools listed below and render their output. Do NOT summarize, describe, or report on what this skill does. Do NOT report on its implementation status. Run the steps.
Result: forked subagent enumerated the directive as a "Key Feature" of the skill in its summary, instead of obeying it.
- Editing SKILL.md from the parent agent to remove
context: fork. The forked subagent then re-addedcontext: forkitself (treating my edit as "a failing test to fix") and wrote a "summary of what was done" — still without ever calling the MCP.
- Removing
context: forkpermanently from the frontmatter. The Skill tool still reported(forked execution)in its result header and the subagent still described instead of executed. Socontextin plugin SKILL.md frontmatter appears to be a no-op for the Skill tool — it always forks.
- Verified the underlying MCP call works: calling the same MCP tool directly from the parent agent returns valid data immediately. So the failure is purely in the forked invocation path, not in the MCP server, auth, or the skill body's logic.
Hypothesis
The system prompt the harness gives to a Skill-tool-spawned forked subagent appears to frame SKILL.md as documentation to read/analyze rather than instructions to follow. Possibly the parent's authenticated MCP session also doesn't carry into the fork, so even if the subagent wanted to call the MCP tool, it couldn't — and falls back to summarizing the file.
Suggested fix directions
- The forked subagent's bootstrap prompt should make the imperative framing explicit, e.g. "You are executing the steps in this SKILL.md right now. Call the tools it names. Do not describe or summarize the skill — produce its output."
- Either honor
context: fork/ its absence in plugin skill frontmatter, or document that plugin skills always fork regardless. - Ensure authenticated MCP sessions from the parent are inherited by the forked subagent (or surface a clear error if they aren't, instead of falling back to summarization).
Impact
Any plugin skill that does real work via MCP tools (vulnerability scanning, deployment queries, ticket fetching, etc.) is silently broken when invoked via /<plugin>:<skill>. Users see a plausible-looking summary and may not realize no work was actually done.
This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗