Summary
Implement a first-class skill manager for Capsem. Skills should become a profile-owned capability with VM-specific runtime state, not loose files or UI theater. Users and admins need to add, remove, enable, disable, inspect, and search skills through the same profile/VM contract used by rules, MCP, plugins, assets, and credentials.
Why
Capsem profiles are the ledger for what a VM is allowed to run and expose. Skills are becoming a real user-facing surface, so they need the same discipline:
- profile owns configured/default skills
- VM can have runtime/additional skills when allowed
- corp can constrain what profiles/VMs may use
- UI/TUI/API reflect the contract instead of inventing labels or states
- security/event telemetry records skill use and changes
- users can discover skills from approved skill repositories
Required capabilities
Acceptance criteria
- Skills are represented by typed/profile-backed data, not ad hoc paths.
- Profile validation fails if a declared skill payload is missing, malformed, or hash-mismatched.
- VM skill routes are profile-aware and do not use global shortcut state.
- UI and TUI can enable/disable/add/delete skills through routes.
- Global and per-VM telemetry show skill use and errors.
- Debug output includes skill inventory, source, version/hash, enabled state, and recent failures.
- Skill repository search works against at least one local/hermetic test repository.
- Tests cover profile-only skills, VM-local skills, corp-denied skills, malformed skill metadata, hash mismatch, and telemetry emission.
Notes
This is an epic, not a small patch. It should follow the same architecture contract as plugins/MCP/rules: profile first, VM effective state second, corp constraints above both, and no compatibility/fallback path that lets loose files bypass validation.
Summary
Implement a first-class skill manager for Capsem. Skills should become a profile-owned capability with VM-specific runtime state, not loose files or UI theater. Users and admins need to add, remove, enable, disable, inspect, and search skills through the same profile/VM contract used by rules, MCP, plugins, assets, and credentials.
Why
Capsem profiles are the ledger for what a VM is allowed to run and expose. Skills are becoming a real user-facing surface, so they need the same discipline:
Required capabilities
Profile skill management:
VM skill management:
UI/TUI:
Telemetry and ledger:
Skill repository interface:
Acceptance criteria
Notes
This is an epic, not a small patch. It should follow the same architecture contract as plugins/MCP/rules: profile first, VM effective state second, corp constraints above both, and no compatibility/fallback path that lets loose files bypass validation.