Skip to content

plugins.md

Latest commit

 

History

History
91 lines (64 loc) · 5.56 KB

plugins.md

File metadata and controls

91 lines (64 loc) · 5.56 KB
Raw

MeshMind plugins

Plugins extend specialist nodes with shared prompts, optional knowledge files, and optional tool (functions) implementations.

Specialists and capabilities

Multi-specialist meshes work best when each node has a clear role (review, security, documentation, research, and so on). Keep capabilities in plugin.yaml and in node YAML focused so routing and aggregation stay meaningful: the coordinator and operators can tell which specialist should own a given kind of task.

  • Overlapping capability labels are fine if prompts, plugins, or knowledge still differentiate behavior.
  • If every specialist advertises the same broad skill list and the same generalist prompt, you mostly pay mesh overhead without gaining division of labor.

The default preset is different on purpose: a single assistant is meant to be broad. For several specialists, prefer distinct profiles instead of cloning one mega-generalist on every node. How plugin and YAML capabilities merge at runtime is described under Merge order (runtime) below.

Node domain and plugin

  • domain (optional string on each node in meshmind.yaml): the node’s primary routing role. The coordinator matches a routed capability if it appears in capabilities or equals domain. Use one short token consistent with your mesh (e.g. security, code_review).
  • plugin: an extension pack (prompts, optional knowledge, optional functions). It equips the node; it does not replace declaring a domain when you want a stable routing identity.
  • knowledge_domains: labels for knowledge loading (topics tied to project/plugin content). They are not the same as domain, which is for orchestration routing.

To go from “plugin on disk” to “node in the mesh”, either edit meshmind.yaml by hand or use meshmind plugin add-node (bundled ids only): it installs the stub if needed and appends a specialist block with plugin:, capabilities from the stub, and an optional domain (defaults to the first stub capability). plugin: remains equipment; the new YAML stanza defines topology.

Presets vs project data/

  • meshmind init … --preset default generates a general assistant + coordinator and writes data/knowledge.json with example fields; your YAML knowledge: list should point at files under data/ (see the generated meshmind.yaml).
  • --preset code uses a multi-specialist template and, unless --skip-bundled-plugins, installs bundled stubs demo_review and demo_security into your plugin directory. Run meshmind plugin sync -c meshmind.yaml if the CLI reports missing plugins.
  • Domains declared in knowledge_domains and paths in knowledge: feed the knowledge loader: project JSON/MD/TXT files are merged with plugin knowledge when plugin: is set.

Install location

By default plugins live under:

~/.meshmind/plugins/<plugin-id>/

Override with environment variable:

MESHMIND_PLUGIN_DIR

Directory layout

<plugin-id>/
  plugin.yaml           # required: metadata (id, capabilities, optional functions)
  prompts/
    system_prompt.txt   # optional: appended after the node's YAML system_prompt
  knowledge/            # optional: .json, .md, .txt (injected into prompt context)
  functions/            # optional: .py modules implementing tool handlers

Merge order (runtime)

When meshmind.yaml sets plugin: "<plugin-id>" on a node:

  1. system_prompt — text from YAML first, then the plugin's system_prompt.txt and inlined knowledge.
  2. capabilities — union of YAML and plugin capabilities (stable unique order).
  3. functions — plugin tool schemas first; YAML functions entries override by name.
  4. function_handlers — plugin handlers merged; YAML handlers override by name.

CLI

  • meshmind plugin list — plugins already installed under MESHMIND_PLUGIN_DIR
  • meshmind plugin list --available — bundled ids that ship with MeshMind (same as meshmind plugin catalog)
  • meshmind plugin catalog — alias for plugin list --available
  • meshmind plugin show <id> — print plugin.yaml
  • meshmind plugin install <path> — copy a plugin directory into the user plugin folder
  • meshmind plugin install <bundled-id> — copy a packaged stub (see catalog) without typing a repo path
  • meshmind plugin sync -c meshmind.yaml — install any missing bundled plugins referenced by plugin: in the config (--strict exits with an error if a referenced plugin is missing and not bundled)
  • meshmind plugin add-node <bundled-id> -c meshmind.yaml — install the bundled plugin if needed and append a specialist node (optional --name, --port, --domain, --dry-run)
  • meshmind plugin remove <id> — remove an installed plugin (--yes to skip prompt)
  • meshmind plugin validate <path-or-id> — validate plugin.yaml

Bundled demos

The repo ships stub plugins demo_review, demo_security, demo_documentation, and demo_research under meshmind/cli/plugin_stubs/. meshmind init <name> --preset code can copy demo_review and demo_security into your plugin directory (default unless --skip-bundled-plugins). If you skipped that step or moved machines, run meshmind plugin sync -c meshmind.yaml before meshmind up.

meshmind.yaml

Example specialist node:

nodes:
  myapp-reviewer:
    type: specialist
    port: 8401
    plugin: demo_review
    system_prompt: |
      You are the team reviewer.
    capabilities:
      - review