claude-code - 💡(How to fix) Fix Skill tool's forked execution describes plugin skills instead of running them; ignores `context` frontmatter field [1 participants]

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

1. Define a plugin skill at plugins/<plugin>/skills/<name>/SKILL.md whose body instructs the agent to call an MCP tool and render the result. (No commands/ directory — only skills/.)
2. 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 via Skill(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. Call mcp__… 3. Render results… Testing: Test coverage in test_list_assets_skill.py validates…"

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

1. 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.

2. Editing SKILL.md from the parent agent to remove context: fork. The forked subagent then re-added context: fork itself (treating my edit as "a failing test to fix") and wrote a "summary of what was done" — still without ever calling the MCP.

3. Removing context: fork permanently from the frontmatter. The Skill tool still reported (forked execution) in its result header and the subagent still described instead of executed. So context in plugin SKILL.md frontmatter appears to be a no-op for the Skill tool — it always forks.

4. 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

1. 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."
2. Either honor context: fork / its absence in plugin skill frontmatter, or document that plugin skills always fork regardless.
3. 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.