Commands, skills, subagents & memory

Guides

Commands, skills, subagents & memory #

agent-connector can ship more than an MCP server. Some surfaces are static files the host loads as context or commands; others are runtime handlers. Understanding that split keeps beginner docs from treating every feature as MCP.

The surface map #

surface-map.txt

text

Static content surfaces
  commands  -> host slash-command files
  skills    -> host skill directories
  subagents -> host agent definitions
  memory    -> host rules / memory files

Runtime handler surfaces
  server     -> MCP tools/resources/prompts
  hooks      -> host lifecycle callbacks
  statusline -> host UI render callback
  actions    -> user-invoked action handlers

Static content vs runtime handlers #

Surface	Kind	Beginner mental model
`commands`	Static host files	Slash-command prompts or command definitions the host loads from disk.
`skills`	Static host files	Reusable skill instructions and resources, usually loaded by a skill-aware host.
`subagents`	Static host files	Named agent roles or prompts rendered into each host's native agent directory.
`memory`	Static managed blocks	Standing instructions written into the file that host actually reads for project/user memory.
`statusline`	Runtime UI handler	A short render callback for host HUD/statusline UI.
`actions`	Runtime user command handler	A deliberate user-invoked operation exposed by host affordances or a CLI fallback.

Memory is the easiest surface to overuse #

Memory should hold durable guidance the host should remember, not temporary task state. agent-connector writes managed blocks with markers so installs, upgrades, and uninstalls can update its own content without taking ownership of the entire file.

Put universal project behavior in memory only when every future task should see it.
Keep large tutorials in docs or skills, not memory.
Treat host-specific memory target differences as adapter concerns.

A sane expansion path #

For a new package, start with the MCP server, then add surfaces only when they solve a user-visible problem. A practical order is: one tool, one host install, one doctor pass, then commands or skills for repeated workflows, memory for durable guidance, hooks for lifecycle policy, statusline for glanceable state, and actions for user-invoked commands.