[FEATURE] Separate proactive model invocation from delegated Skill invocation

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

Claude Code currently makes no distinction between:

1. Claude proactively deciding to invoke a Skill; and
2. Claude invoking a Skill because an explicitly invoked parent Skill delegates to it.

For composable Skills, those are meaningfully different authorization paths.

Today, disable-model-invocation: true prevents proactive invocation, but it also prevents an explicitly running parent Skill from invoking the child through the Skill tool. Removing it restores composition, but also makes the child available for proactive model routing.

So there is currently no way to express:

| Invocation | Desired |
|---|---:|
| User directly invokes /child-skill | ✅ |
| User explicitly invokes /parent-skill, which delegates to child-skill | ✅ |
| Claude proactively selects child-skill | ❌ |

Put differently, an explicit user invocation cannot currently be treated as transitively authorizing the child Skills that the invoked workflow deliberately composes, without also granting Claude general proactive access to those children.

This makes it difficult to build larger Skills out of reusable, independently defined Skills while retaining operator control over which capabilities Claude may activate autonomously.

Proposed Solution

Treat user invocation, proactive model invocation, and delegated/nested Skill invocation as distinct invocation modes.

The exact configuration API is less important than the semantics. Conceptually, a Skill should be able to express something like:

invocation:
  user: true
  proactive-model: false
  delegated: true

Alternatively, delegated access could be declared by the parent or restricted to specific callers.

The important behavior is:

user → /request-critical-feedback
                         ✅

user → /resolve-issue → request-critical-feedback
                         ✅

user → /create-new-issue → request-critical-feedback
                            ✅

Claude → request-critical-feedback
         ❌

Ideally, Claude Code would preserve invocation provenance rather than treating all nesting as authorization. A Skill reached from an explicitly user-invoked workflow could be eligible for delegated invocation, while a proactively initiated model chain would not automatically gain the same authority.

This could be implemented through new frontmatter, declared Skill dependencies, caller allowlists, invocation provenance, or another mechanism. I don't have a strong preference on the API.

Alternative Solutions

Leave the child model-invocable.
This makes composition work, but also advertises the Skill for proactive routing even when we deliberately want activation of that packaged workflow to remain under operator control. It also adds the Skill to the model's discovery context.

Have the parent read the child's SKILL.md directly.
This works reasonably well for simple shared instructions, but it is not equivalent to invoking a real Skill. A child may have its own arguments, tool policy, model, forked context, agent configuration, hooks, and other execution semantics.

Prompt Claude to treat explicit invocation as transitive.
We've tried variants of this. It is inherently unreliable because the Claude Code harness still enforces disable-model-invocation, so the model cannot reliably honor that instruction through the Skill tool.

These workarounds also push orchestration behavior into prompting when it would be much more reliable as a harness-level capability.

Priority

High - Significant impact on productivity

Feature Category

Developer tools/SDK

Use Case Example

We have a reusable request-critical-feedback Skill that runs a critical-review loop.

It makes sense as a standalone command:

/request-critical-feedback

But we also reuse the same capability inside two larger workflows.

When the user invokes:

/create-new-issue

the Skill creates an issue and then delegates to request-critical-feedback to critique that plan and iterates on the issue based on the review.

When the user invokes:

/resolve-issue

the Skill performs end-to-end issue resolution: implementation, a critical-review loop using request-critical-feedback, iteration on findings, a bug hunt, and final cleanup.

So request-critical-feedback is intentionally a reusable Skill: the same review loop can refine both a plan and an implementation.

We want all three of these behaviors:

/request-critical-feedback
✅ direct user invocation

/create-new-issue → request-critical-feedback
✅ explicit parent workflow delegates to it

/resolve-issue → request-critical-feedback
✅ explicit parent workflow delegates to it

But we don't necessarily want Claude to see request-critical-feedback in normal Skill routing and autonomously activate that packaged review workflow whenever it independently decides additional criticism might be useful.

disable-model-invocation: true almost expresses the desired policy, except that it also prevents the two parent workflows from invoking the child.

Additional Context

A number of existing issues appear to cover pieces of this problem:

• #43809 — requested Skill invocation permission inheritance when an explicitly authorized parent delegates to a disable-model-invocation Skill. It was later closed for inactivity.
• #79560 — open report that disable-model-invocation prevents one Skill from composing /code-review, with a request for trusted Skill-to-Skill invocation.
• #77795 — related failure when Agent prompts delegate to disable-model-invocation Skills.
• #55989 — proposed declarative requires: / Skill allowlists for composable Skills.
• #56912 — related attempt to authorize nested Skill(...) calls through parent Skill frontmatter.
• #55187 — notably, Claude Code telemetry already distinguishes Skill activation origins such as user-slash, claude-proactive, and nested-skill.

These seem to point at the same underlying distinction: user invocation, proactive model invocation, and delegated Skill invocation are separate concepts, but the current Skill policy surface does not let users control them independently.