Capability surfaces¶
Spine distributes coordination knowledge through three distinct mechanisms. Choosing the right one prevents generated configuration from becoming a second source of truth.
Skills: reusable procedures¶
A skill is tracked instructional content that tells an agent how to perform a
repeatable workflow with tools it already has. Spine-authored skills live under
.claude/skills/; synchronization materializes compatible copies for Codex
and Cursor. Use a skill for cross-repository procedures such as releases,
status checks, drift triage, or worktree management.
MCP servers: runtime tools¶
An MCP server adds callable runtime tools or access to a service. Spine tracks
the shared recipe in .mcp.json; agent configuration sync derives the
editor-specific configuration. The recipe does not make the service available
by itself—the server and any optional dependencies still need to be active.
Plugins: packaged extensions¶
A plugin bundles capabilities and is installed through an editor's native marketplace. Plugins remain outside Spine's generated skill sync. A tracked pin or recommendation is the recipe; editor-managed installation is the materialized state.
Cortex's two roles¶
HSSMCortex provides an optional knowledge store and authors capability content that Spine can wire into agent sessions. Knowledge queries require Cortex's own setup. Capability content is synchronized through the same source-owned paths as other shared skills. Neither role makes Cortex a runtime dependency of the Python packages.
Selection rule¶
- Maintained cross-repository procedure: author a skill.
- Live tool or service: declare an MCP server.
- Externally packaged bundle: use the editor's plugin mechanism.
- Package behavior or documentation: change the owning package repository.
The sync and doctor guide verifies the materialized state. The source-ownership reference identifies the tracked recipes.