Model creator namespaces, requirements, and shared skillset resources

[jon-devlapaz]

Problem

Some source-authentic creator bundles are not self-contained member directories:

• members reference scripts, libraries, or references at the creator's source root;
• skill content invokes creator namespaces such as thinking-skills:* or $codex-security:*, while the Tink catalog/root name may be forced to *-skillset;
• skills may require MCP servers, plugins, binaries, or host-specific behavior.

Tink currently copies declared member directories only. Rewriting creator content would destroy source fidelity, while silently installing incomplete or mis-namespaced bundles is misleading.

Proposed direction

Add optional, explicit catalog compatibility metadata:

• creator invocation namespace and optional aliases;
• required host/plugin/MCP/binary capabilities;
• non-blocking compatibility diagnostics before installation.

For shared files, consider a narrow explicit schema such as:

{
  "shared": [
    { "source": "references", "destination": "references" }
  ]
}

Shared paths must be normalized, pinned, non-overlapping with members, copied at skillset-root scope, and covered by the receipt digest. Never infer shared files automatically and never rewrite invocation strings.

Unify remote-source parsing with the shared policy work: standalone imports are GitHub-only while skillset metadata currently accepts broader HTTPS Git syntax. Reuse the path/revision primitives from #31.

Acceptance

• Inspection can report unmet declared requirements before installation.
• Creator namespace is distinct from the catalog key/root when needed.
• Shared paths are explicit, normalized, non-overlapping, and digest-covered.
• Missing or drifting shared content fails atomically.
• Tink never rewrites source-authentic skill content.
• Flat and skillset remote source policies use one canonical parser.

Priority

P2 — contract extension; design before implementation.