feat: MDS package registry / prompt library ecosystem

[dean0x]

Summary

Design and build infrastructure for sharing reusable MDS modules as packages — either via npm (leveraging the existing @mdscript scope) or a dedicated lightweight registry. This is the distribution layer that makes URL-based imports (#63) practical at scale.

Motivation

URL imports enable sharing, but without discoverability, versioning, and trust signals, adoption will be limited. A package ecosystem — even a minimal one — provides the glue: searchable packages, semantic versioning, and a standard structure for MDS module libraries.

Proposed Approaches (Design Decision Needed)

Option A: npm-based (leverage existing infrastructure)

Publish MDS module packages to npm under a convention:

• Package name: @mdscript/prompts-{name} or mds-{name}
• Package contains .mds files + package.json with metadata
• Resolver: @import "pkg:formatting" as fmt resolves to node_modules/mds-formatting/index.mds
• Versioning: npm semver, lockfile integration

Pros: No new infrastructure, existing tooling (npm install, versioning, provenance)
Cons: Requires Node.js, not language-agnostic

Option B: Dedicated lightweight registry

A simple registry (static files on CDN, or a minimal API):

• mds install formatting@1.0 downloads to .mds_modules/
• mds.json lists dependencies: {"dependencies": {"formatting": "^1.0"}}
• Registry is a JSON index + tarballs (like crates.io's model)

Pros: Language-agnostic, no Node.js dependency
Cons: New infrastructure to build and maintain

Option C: Git-based (no registry)

Rely entirely on URL imports with Git hosting:

• @import "https://raw.githubusercontent.com/org/mds-prompts/v1.0.0/formatting.mds"
• Lock file pins exact commits
• No central registry — discoverability via GitHub topics/search

Pros: Zero infrastructure
Cons: Poor discoverability, no semver resolution, verbose URLs

Design Considerations

• This depends on URL-based imports (feat: URL-based imports (remote modules) #63) landing first
• Start with Option C (zero infrastructure, validates the pattern) and evolve toward A or B based on adoption
• An mds init --lib scaffolding command for creating shareable module packages
• Standard module structure: index.mds as entry point, mds.json with module metadata
• Consider an awesome-mds curated list as the initial discovery mechanism

Acceptance Criteria

• Design decision documented (which option or hybrid)
• mds.json dependency declaration format specified
• Resolution algorithm for package imports implemented
• At least one reference module package published (e.g. mds-prompts-utils)
• Documentation for publishing and consuming MDS packages