Define one authority path for Skill discovery and instruction injection

[Astro-Han]

Context

Skills currently have two different entry paths:

• model-driven discovery through the advertised SkillSearch and Skill tools;
• explicit /skill invocation, which Runtime Host resolves and injects before model execution.

Treating skill loading as an ordinary tool-catalog problem may obscure the important distinction between choosing a skill and injecting durable instructions at the correct host-controlled stage. The broader tool discovery refactor should therefore not silently decide the future of Skills.

Questions to settle

1. Which component owns skill selection, and which component owns validated instruction injection?
2. Should autonomous model discovery remain SkillSearch + Skill, become part of a broader search surface, or use a dedicated host-mediated mechanism?
3. How should explicit /skill invocation and autonomous discovery converge after selection so they share one injection path?
4. At what stage should selected skill instructions enter the turn, and how do we ensure they cannot grant tools or override higher-priority policy?
5. What metadata may be searched without injecting full skill instructions into the prompt?
6. Should a selected skill persist beyond one turn, and if so, what explicit user/session state owns that persistence?

Boundary

Until this is decided, keep the existing Skill behavior out of the direct/deferred tool-surface refactor. We can simplify ordinary tool availability without coupling it to a premature Skill architecture decision.

AI assistance disclosure: Maka helped audit the existing skill paths and draft these questions. I reviewed the scope and boundaries.