Plugin Config

Configuration for the plugin system lives in three files, each with a distinct job:

agent.json — agent definitions

Each agent lives in its own directory under ~/.nebflow/agents/<name>/:

my-agent/
├── agent.json     # definition (required)
└── system.md      # system prompt (recommended)

{
  "name": "general",
  "description": "General-purpose executor — capabilities come from assigned plugins"
}

Notes:

• The built-in general agent — the base every task node runs on — carries just an identity: a name and a description. It declares no tools or skills of its own: what a node knows how to do comes from the plugins assigned to it, not from this file
• A task node does not need its own agent.json: nodes run on the built-in base, and specialization is a per-node assignment — see Specialized Agents
• Agents that coordinate rather than execute declare a role-level toolkit instead: the built-in project dispatcher's tools hold the graph tools it plans with (NodeEdit, NodeList, NodeCancel) plus the read tools it inspects the graph with
• system.md beside agent.json holds the agent's system prompt

plugin.json — plugin manifests

A plugin is a directory under ~/.nebflow/plugins/<name>/:

explorer-toolkit/
├── plugin.json                          # manifest (required)
└── skills/                              # injected instructions
    ├── exploration-method/SKILL.md
    └── solution-planning/SKILL.md

Anything a SKILL.md refers to — reference files, assets, scripts — lives inside that skill's own folder and ships with the plugin.

The manifest follows the Agent Plugins 1.0.0 format:

{
  "$schema": "https://agent-plugins.org/schemas/1.0.0/plugin.schema.json",
  "name": "explorer-toolkit",
  "version": "1.0.0",
  "description": "Codebase exploration and solution-planning methodology."
}

Every shipped plugin carries an author block, and the manifest's description is its single description source. The older capability line is retired: it is not a field in the Agent Plugins 1.0.0 schema, and no shipped manifest writes one.

Validation rules:

• A plugin must provide at least one skill (skills/<name>/SKILL.md); a folder with no skill is rejected at load
• Skills carry their own supporting files: whatever a SKILL.md references sits inside that skill's folder and travels with the plugin
• The protocol is closed to tool extension: no mcp.json, no tool-grant extension, no mounting of external tool servers. A plugin cannot add, request, or enable tools — the node's tool face is fixed by the engine, per role
• Unknown manifest fields and unknown folders are ignored with a warning — forward compatibility by default

Top-level config — global plugin settings

In nebflow's top-level configuration file ~/.nebflow/nebflow.json, the plugins section looks like:

{
  "plugins": {
    "enabled": true,
    "trust": {
      "explorer-toolkit": {
        "sha256": "6769131e38df1799…",
        "approvedAt": 1788881067,
        "scope": "all",
        "files": {
          "plugin.json": "c72a9b490fc1bcba…",
          "skills/exploration-method/SKILL.md": "…"
        }
      }
    }
  }
}

The plugins section covers enablement and install records only. What a plugin contains lives in the plugin folder itself (~/.nebflow/plugins/<name>/) — the config file never describes it.

Where an agent's tools come from

A node's tool face is fixed by the engine, per role. Plugins do not change it: a node runs with the same tool set whether it carries no plugin or five. What a plugin adds is knowledge and resources, not tools — injecting a methodology changes how the node approaches the work, never what it is able to touch.

The plugin protocol page covers how plugins are installed and assigned.