Feature: path-based Skill tool invocation for non-discovered skills

Problem

The Skill tool only supports invoking skills by their discovered name. Skills that are intentionally excluded from auto-discovery (e.g., stored in subdirectories outside the discovery path) can only be loaded via the Read tool, which injects the full skill.md content into the main conversation context permanently.

This creates an asymmetry:

| | Discovered Skills | Non-discovered Skills |
|---|---|---|
| System prompt cost | Name + description always present | None (the whole point) |
| Loading mechanism | Skill tool — harness-managed, scoped injection | Read tool — raw file content enters main context |
| Context after execution | Managed by harness | Persists for entire session |

The Read approach means non-discovered skills add more context pollution than discovered skills once loaded, undermining the benefit of keeping them out of the system prompt.

Use Case

Teams with large skill libraries benefit from a two-tier structure: a small set of frequently-used skills in the system prompt, and a larger set of internal/niche skills loaded on demand. This keeps the system prompt lean for the majority of messages that don't need those skills.

However, when an internal skill is needed, loading it via Read permanently adds its full content to the conversation context. Over a multi-skill session, this accumulates and erodes the context savings that motivated the split.

Proposed Solution

Allow the Skill tool to accept a file path in addition to a skill name:

Skill: "path/to/skill.md"

This would:

1. Parse the skill.md frontmatter (description, allowed-tools, model, etc.)
2. Inject the skill prompt using the same scoped mechanism as discovered skills
3. Not add the skill to the system prompt or discovery registry

The two-tier distinction would then be purely about system prompt visibility, with no penalty on the loading/execution side.

Alternatives Considered

• Load internal skills in subagents — Works for self-contained tasks (analysis, reports) but not for skills that need to modify files or maintain conversational state in the main context.
• Keep all skills discoverable — Defeats the purpose; adds significant always-on system prompt overhead that scales with skill count.
• Shorter skill files — Helps but doesn't solve the fundamental issue of unmanaged context injection via Read.