Proposal: portable Skill contribution surface

[Tanramisu]

Motivation

Community v0.15 can already make a portable component publish Tools, Commands, Model resources, browser UI, etc., but there is no portable Skill surface.

This leaves otherwise-portable plugins partly tied to a product adapter. A concrete example is a bounded cognitive plugin whose lsd_explore / lsd_converge tools can already be standard tools.dsh/v1alpha1 Tool extensions, while its let-me-lsd guidance still has to live in DSH's product-specific skill registry. Skill-only plugins have no standard migration path at all.

Minimal scope

I think the useful first version is deliberately small:

• one package-local, declarative Skill resource;
• stable name + short description for catalog discovery;
• a package-relative body/entry asset loaded lazily when the host requests the skill;
• activation-instance ownership: unload retracts the Skill automatically;
• composition detects conflicting effective owners for the same Skill name;
• no AgentLoop changes, no durable state, no memory, no trigger state machine, no requirement that the full body be injected eagerly.

Conceptually:

{
  "apiVersion": "skills.dsh/v1alpha1",
  "kind": "Skill",
  "name": "let-me-lsd",
  "spec": {
    "title": "let me lsd",
    "description": "Bounded divergent cognition followed by normal convergence.",
    "entry": "skills/let-me-lsd/SKILL.md"
  }
}

The exact content format / coordinate naming can of course follow the project's conventions; the important property is that the manifest points to an inert package-local asset and the host adapter owns discovery, lazy reading, scope projection, and lifecycle cleanup.

DSH adapter mapping

For @dsh-std/adapter-dsh, the natural mapping seems to be the existing DSH skill registry/provider seam:

1. active standard Skill extensions appear in the merged skill catalog;
2. catalog exposure uses only the small metadata surface;
3. loading the Skill reads the package-local entry only on demand;
4. unload removes the registration;
5. no standard component imports Cordis or @deepseek-ai/dsh-skill-*.

This would unlock full standardization of mixed Tool+Skill plugins and simple Skill-only plugins without broadening the standard into product cognition internals.

[Yan-Zero]

This hits a very real blind spot in the current ecosystem. Many practical plugins are a combination of Tools and Skills (e.g. specialized exploration/convergence tools paired with structured guidance prompts). Without a standard Skill surface, these plugins remain half-portable and still have to depend on DSH's proprietary skill registry.

I fully agree with the minimal declarative scope you proposed (name, description, package-relative entry with lazy on-demand reading and activation-scoped lifecycle).

However, I'd like to discuss the architectural placement of the runtime/provider side:

Currently, @dsh-std/adapter-dsh hosts almost all protocol mappings. While that was an intentional reference bundle during the experimental stage, it has understandably drawn criticism (e.g., #5 and #6) for becoming an oversized, monolithic object or creating ambiguous boundaries. If we keep stuffing new capabilities (like Skill handling) directly into adapter-dsh, it only worsens that bloat and reinforces the perception that adapter-dsh is trying to be a centralized runtime that absorbs everything.

Your proposal actually opens up a great opportunity to demonstrate a much cleaner architectural pattern: a standard plugin serving as a protocol provider.

Instead of embedding Skill execution inside adapter-dsh:

1. Pure Protocol: skills.dsh/v1alpha1 defines the implementation-neutral Skill contribution and discovery contract;
2. Decoupled Skill Provider: We can implement a dedicated dsh-skill plugin. This plugin is itself a standard DSH-STD component, but it declares and provides runtime support for skills.dsh/v1alpha1, serving as the upstream capability provider for any downstream plugins that contribute skills.

This keeps adapter-dsh from growing into an unwieldy monolith, addresses the concerns raised in #5 and #6, and proves that DSH-STD protocols can be powered by modular, composable plugins rather than a single monolithic adapter.

What do you think about separating the Skill runtime into a standalone composable provider plugin like this?