Module skill 

MuxAPI handlers for the v1 standalone Skill primitive. skill.list / skill.get / skill.upsert / skill.delete / skill.bind / skill.unbind

Plus the Memory-level catalog (skill.catalog.): global skills only, window-scoped — no agent_id, no check_s1 (mirrors bundle. auth shape, since Memory has no agent connection context to gate on).

db_skills is authoritatively identity_store as of Phase 2 of SPEC_DURABLE_BINDINGS_2026_09_10.md (§5.1/§5.4) — mstore stays the ref-table owner (db_agent_skills_ref/db_bundle_skills_ref are not promoted until Phase 3/6). Pure single-table reads/writes (skill_get, skill_upsert_unique_global) call directly on identity_store; methods that combine a ref table with the catalog now take identity_store as an explicit catalog parameter while still being called ON mstore (the ref-owning receiver).

Functions

register

register_skill_bind 🔒

register_skill_catalog_bind 🔒

register_skill_catalog_bind_to_bundle 🔒

register_skill_catalog_delete 🔒

register_skill_catalog_list 🔒

register_skill_catalog_list_for_agent 🔒

Catalog-tier sibling of skill.list (above) — GLOBAL SKILLS ONLY, each annotated with bound_to_agent for the caller-supplied agent_id, no check_s1. AgentStashModal’s Skills tab (the per-agent Stash view) runs over the dashboard’s connection, which is never agent-authenticated, so skill.list’s gate can never be satisfied from that caller — the exact same reasoning as skill.catalog.bind above. Deliberately does NOT reuse skill.list’s full computation (global + this agent’s own private skills): with no check_s1, agent_id is unverified, and a private skill’s content/description/trigger can carry sensitive agent-authored material — returning it for an arbitrary caller-chosen agent_id would be an IDOR into every agent’s private skills. See Store::skill_list_global_for_agent’s doc comment and docs/reports/REPORT_ARMORY_ARCHITECTURE_AND_NAMING_REVIEW_2026_07_23.md §2.2.

register_skill_catalog_list_for_bundle 🔒

Bundle-scoped sibling of skill.list — GLOBAL SKILLS ONLY plus this bundle’s own referenced skills, each annotated with bound_to_bundle. No check_s1 (a bundle has no agent identity to gate on). Deliberately restricted to global + bundle-bound rows only, same IDOR reasoning as skill_list_global_for_agent’s doc comment — see bundle_skill_list’s own implementation.

register_skill_catalog_unbind 🔒

Catalog-tier sibling of skill.unbind (above) — same DB write, no check_s1. Restricted to global rows only, matching the guard register_skill_catalog_bind/register_skill_catalog_delete already apply in this file: any window connection can sever any agent’s binding to a global skill (an intentional, pre-existing trust boundary — bind and delete already have the same or larger blast radius), but a private row’s own binding must not be touchable via this no-check_s1 surface, even though skill_id is never exposed by any no-check_s1 command today — defense in depth over relying solely on UUID secrecy. reagentx P1 on PR #2329 (round 2).

register_skill_catalog_unbind_from_bundle 🔒

register_skill_catalog_upsert 🔒

register_skill_catalog_upsert_for_bundle 🔒

Creates a NEW, PRIVATE skill scoped directly to a bundle (never global) — the bundle-level analog of skill.upsert (agent-scoped). See mcp.rs’s register_mcp_catalog_upsert_for_bundle for the full reasoning (reagentx P1 review on PR #2639).

register_skill_delete 🔒

register_skill_get 🔒

register_skill_list 🔒

register_skill_unbind 🔒

register_skill_upsert 🔒