Skills as scope-owned, shareable artifacts (grants, org promotion, git skill packs)

[iret77]

Origin

Competitive analysis of yc-software/qm (2026-08-01).

Concept

qm treats skills as scope-owned artifacts with a full lifecycle, instead of static prompt partials bundled into plugins:

• A skill is a directory with SKILL.md (YAML frontmatter: name, description, requiredCapabilities); text-only in v1
• Lifecycle draft → reviewed → published → archived; publishing requires all required capabilities to be explicitly granted
• Each skill carries an HMAC signature over the canonical manifest; review/promote verify it (tamper evidence)
• Resolution is scope-ordered with shadowing: personal beats shared beats team beats org
• Sharing is grant-based (share = ACL grant, move = home change); skills cannot be created directly in org/team scope — they must go through admin-gated promotion
• Automations (crons) may not modify skills in shared scopes — only a live human can
• Skill packs from git repos: pinned or tracked refs, trust tiers, SSRF-guarded fetcher, imported skills tagged with pack+commit, removed ones archived not deleted

Why adopt

omadia's skills are bound to plugins (system-prompt partials in the plugin ZIP). qm's model lets end users and teams author, iterate, and share skills without touching plugin packaging — a much better growth loop for an org. The admin-gated org promotion and the trigger guard map directly onto omadia's governance story.

Reference (qm source)

• src/skills/skill-store.ts, frontmatter.ts, seed.ts, materialize.ts
• src/skills/skill-pack-store.ts, pack-fetcher.ts, skill-sync-engine.ts
• src/api/app-skills.ts, src/api/artifact-share.ts (triggerBlocksSharedSkill)