[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6DWHXWCNXWV30FS5H0NTFP5":3,"skill-same:01M6DWHXWCNXWV30FS5H0NTFP5":83},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":22,"publishedAt":43,"linkOnly":44,"markdownContent":45,"markdownBody":46,"frontMatter":47,"refName":59,"commitSha":60,"skillDirectory":61,"forksCount":62,"repositoryHtmlUrl":63,"repositoryHomepageUrl":64,"ownerHtmlUrl":65,"ownerBlogUrl":66,"ownerDescription":67,"updatedAt":68,"install":69,"resources":82},"01M6DWHXWCNXWV30FS5H0NTFP5","octomind-runtime",null,"How octomind assembles a session: tap tag resolution, capability auto-activation, skills, gating, sandbox. Use when a tool or skill did or did not appear.","Muvon\u002Foctomind-tap","Muvon","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F25336907?v=4","01M6DWA4KTRX4J73CW5CECKAD0","01M6DWA4QSWFGYE6WDMAMFF1WE",6,"Apache-2.0","https:\u002F\u002Fgithub.com\u002FMuvon\u002Foctomind-tap\u002Fblob\u002Fmaster\u002Fskills\u002Foctomind-runtime\u002FSKILL.md",[17],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42],"runtime","octomind","octomind runtime","linux","tool","session","capability","my","when","gating","domain","windows","macos","Tools","activation","why","how","capabilities","auto","tap","2026-11-10 10:12:30",false,"---\nname: octomind-runtime\ntitle: \"Octomind Runtime & Tool Surface\"\ndescription: \"How octomind assembles a session: tap tag resolution, capability auto-activation, skills, gating, sandbox. Use when a tool or skill did or did not appear.\"\nlicense: Apache-2.0\ncompatibility: \"Requires: octomind binary. macOS\u002FLinux\u002FWindows.\"\ndomains: octomind\nrules:\n  - match((?i)\\bauto.?activat)\n  - match((?i)\\b(LRU|eviction|domain gating|tool surface)\\b)\n  - match((?i)\\b(tap|capability|skill) (resolution|resolve|priority)\\b)\n  - match((?i)\\.agents\u002F(tools|skills|plugins)\\b)\n  - semantic(why is this tool or skill not available in my session)\nmetadata:\n  version: \"1.1\"\n  tags: \"octomind runtime capabilities skills taps\"\n---\n\n## Overview\n\nThis skill explains how a session's tool surface comes to exist: how a tag resolves through taps into a manifest, which tools are built in, how capabilities turn into running MCP servers, how the auto-activator decides without an LLM in the loop, and how skills, plugins, local tools, and the sandbox fit in.\n\nIt covers resolution, not authoring — writing manifests, capabilities, deps, and skills belongs to the `tap-*` authoring skills.\n\n## Mental model\n\nEvery exposed tool costs prompt tokens on every turn, and a wide tool zoo makes the model pick wrong tools. So the surface starts small and grows on demand: capabilities load when intent matches, and the least-recently-used one is evicted when the active set is full.\n\nTwo layers stack. Static comes from the role's manifest at boot; dynamic is what a capability adds at runtime. Eviction may tear down only the dynamic layer — a server the role statically owns is never killed.\n\n## Rules\n\n### Tap resolution\n\nA tap is a Git repo or local directory holding `agents\u002F\u003Cdomain>\u002F\u003Cspec>.toml`, `capabilities\u002F\u003Cname>\u002F`, `skills\u002F\u003Cname>\u002F`, `deps\u002F\u003Corg>\u002F\u003Ctool>.sh`, `workflows\u002F\u003Cname>.toml`, and optionally `plugins\u002F`. `octomind tap user\u002Frepo` clones `github.com\u002Fuser\u002Foctomind-repo` into `\u003Cdata_dir>\u002Ftaps\u002Fuser\u002Foctomind-repo`; `octomind tap user\u002Frepo \u003Cpath>` links a local directory instead. The built-in `muvon\u002Ftap` is always present as the last-priority fallback.\n\nPriority: user taps in the order added, then the built-in tap. The first tap providing a tag, skill, capability, or workflow wins. A capability can be pinned explicitly: `octomind\u002F\u003Cname>` for the baseline tap, `\u003Corg>\u002F\u003Cname>` for a connected tap.\n\nRunning a `domain:spec` tag: fetch the manifest (cached per `[registry].cache_ttl_hours`), expand `capabilities = [...]`, resolve `{{INPUT:KEY}}` (persistent store `inputs.toml`, prompted once) and `{{ENV:KEY}}` (environment, else prompted and saved to `.\u002F.env`), run `[deps] require` scripts before MCP init, inject the tag as the role name, merge into config, start the session. In non-interactive child runs a missing value is an error, not a prompt.\n\n### Bare domains and the chief\n\nA domain's orchestrator is the agent that knows the other agents of its domain and hands work to them. It is named `chief`, so its tag is `\u003Cdomain>:chief`. A TAG with no colon is looked up as a local `[[roles]]` entry first, so a local role always wins over a domain of the same name. If no role matches, the name is read as a domain and runs `\u003Cdomain>:chief`: `octomind run developer` starts `developer:chief`. If the domain has no `chief`, the run fails with an error that lists the domain's agents. `domain:spec` always runs that exact agent, and plain `octomind run` starts `assistant:chief`, the global assistant. The same rules apply to `octomind acp`, `octomind server`, and `\u002Frole`. The `tap` tool takes no role: it matches the prompt to a specialist. Workflows still need full two-part tags.\n\nTwo placeholders in a tap manifest's `system` are expanded when the manifest loads: `{{SPECIALISTS}}` and `{{USES}}`. Octomind 0.71 expands `{{SPECIALISTS}}` to the other agents of the same domain (`- \u003Ctag> — \u003CDescription>`, sorted, `(none)` when empty) and `{{USES}}` to what a `chief` declared in its `# Uses:` header comment (`- \u003Centry> — \u003CDescription>`). Newer versions expand both to one fixed sentence saying the specialist is matched automatically by `tap(action=\"run\", prompt=…)`. The header entries are a bare domain (that domain's `chief`), a full tag (that agent), or `*` (the `chief` of every other domain, global assistant only); the header is validated at load and bounds which agents the runtime can match. They change only when a tap changes, so `system` may hold them. `{{CWD}}` and `{{DATE}}` change every session, so tap manifests put them in `welcome` only.\n\n### Built-in tools\n\n| Server | Tools | Granted by |\n|--------|-------|------------|\n| `core` | `recall` (only when compression attention is enabled) | `core` capability |\n| `orchestration` | `tap`, `schedule`, `monitor` | `orchestration` capability |\n| `runtime` | `mcp`, `agent`, `skill`, `capability` | `runtime` capability |\n| `agent` | `agent_\u003Cname>` per `[[agents]]` entry | `agent` capability |\n| `local` | scripts in `.agents\u002Ftools\u002F` | always, per workdir |\n\nThere is no plan tool: planning is supervisor-owned and only displayed via `\u002Fplan`.\n\n`tap` actions: `run` (background child; `prompt`, optional `workdir`; no role is passed: the runtime compares the prompt with the `# Title:` and `# Description:` of the agents the caller may reach, which are the other agents of its own domain plus what its `# Uses:` header declares, or every installed agent when the caller is not a tap agent, and starts the closest one if it is clearly ahead. With `[decision] taps = true` in the config, off by default, a decision model confirms or overrules the pick. With no match it returns \"No specialist matches this task\" and starts nothing. The result is `{id, role, title, workdir, message}`; pass `session=\u003Cid>` to continue a run, otherwise the child starts with zero context), `list`, `stop`, `send`, `capability` (push an intent through the auto-activation path), and `workflow` (list, show, or run a tap workflow in the background). Run ids look like `tap-developer-general-a3f1c2`; results arrive in a later turn.\n\n### Capability anatomy\n\n`config.toml` carries a required non-empty `triggers = [...]` and optional `domains = [...]`; missing either file or triggers means the capability fails to resolve. `\u003Cprovider>.toml` carries `[deps]`, `[roles.mcp]`, and `[[mcp.servers]]`; the provider comes from the `[capabilities]` config map, else `default`. Its `# Title:` and `# Description:` header feed `list` and `discover`.\n\nThe `capability` tool (on `runtime`): `list`, `discover` (semantic match over triggers, keyword fallback), `enable`, `disable`. Activation registers each server with a filter computed from `allowed_tools`; a server already in the role's static config is not re-registered, the capability extends its filter instead. A capability with no servers but non-empty `[deps]` is a toolchain capability — running the installers is the activation.\n\n### Auto-activation\n\nRuns before every API request when `auto_capabilities = true`, on fresh user messages only. Steps: skip system-managed text; strip XML blocks so pasted content cannot drive matches; bail if fewer than 8 non-whitespace characters remain; drop already-active, out-of-domain, and env-unready capabilities (any `{{ENV:KEY}}` in a server's `env` or `headers` that is unset); embed the intent once; score each capability as the mean of its top-3 trigger cosines.\n\n| Constant | Value | Purpose |\n|----------|-------|---------|\n| `AUTO_ACTIVATE_THRESHOLD` | `0.65` | Minimum mean-of-top-3 cosine |\n| `AUTO_ACTIVATE_MARGIN` | `0.06` | Required gap between top-1 and top-2 |\n| `AUTO_ACTIVATE_TOP_K` | `3` | Triggers averaged per capability |\n\nThe embedding model is `muvon\u002Foctomind-embed` (int8 ONNX). The margin gate is why two near-tied capabilities cause abstention rather than a coin flip. With `[supervisor.evaluate] capabilities = true`, an evaluation model can veto a weak cosine winner or promote a pick when cosine abstained. Silent no-ops: toggle off, not a fresh user message, intent too short, embedding model still downloading, nothing eligible, or no score clearing the gate.\n\n### Domain gating\n\nThe session domain is the part before the colon of the active role. An empty `domains` list means universal; a non-empty one restricts the capability. The gate applies everywhere — `list`, `discover`, auto-activation, `enable`, and `OCTOMIND_CAPABILITIES` — with no bypass. With no domain set, only universal capabilities survive.\n\n### LRU eviction\n\nAt most four runtime-activated capabilities per session. Activating a fifth disables the least-recently-used first. Recency means successful tool use, not activation order. Eviction is the only auto-disable — no time decay. Capabilities preloaded from the manifest are static and never counted.\n\nShared servers are safe: each capability records which tools it registered per server, and the process is killed only when the role does not own the server statically and no other active capability references it.\n\n### Skills\n\nDiscovery order, first name wins: tap `skills\u002F` directories, `\u003Cworkdir>\u002F.agents\u002Fskills\u002F`, `~\u002F.config\u002Fagents\u002Fskills\u002F`, Agent Plugin skill directories, then generated skills from learning evolution.\n\nThree activation methods: `OCTOMIND_SKILLS` preloads at session start; declarative `rules:` auto-activate on fresh user messages when `[skills] auto_activation` is on and the skill's `domains:` contains the session domain (or `*`); manual `\u002Fskill \u003Cname>` or `skill(action=\"use\")`. With `[supervisor.evaluate] skills = true`, an evaluation model may pick a skill from the domain pool when every rule abstained.\n\nThe parser reads `name`, `description`, `compatibility`, `license`, `allowed-tools`, `capabilities`, `domains`, and `rules`; other keys are ignored, and a skill missing `name` or `description` is skipped. Files under `scripts\u002F`, `references\u002F`, and `assets\u002F` are listed with absolute paths in a Skill Resources section on activation. Declared `capabilities` are enabled with the skill.\n\n### Agent Plugins\n\nDirectories with a `plugin.json` (Agent Plugins 1.0.0 schema) are scanned from tap `plugins\u002F`, `\u003Cworkdir>\u002F.agents\u002Fplugins\u002F`, and `~\u002F.config\u002Fagents\u002Fplugins\u002F`. Their `skills\u002F\u003Cname>\u002FSKILL.md` join skill discovery and their `mcp.json` declares MCP servers. A bad manifest rejects the plugin; a bad skill or server skips only that part.\n\n### Local tools\n\nAn executable script at `\u003Cworkdir>\u002F.agents\u002Ftools\u002F\u003Cname>` becomes a tool on the `local` server — rediscovered every turn, role-agnostic, no config. The filename is the tool name (`[A-Za-z0-9_-]+`). The leading comment block (`#`, `\u002F\u002F`, or `--`, first 80 lines) declares `@description` and repeatable `@param NAME TYPE DESC`; prefix the name with `*` for required. Params arrive as JSON on stdin and as `OCTOMIND_PARAM_\u003CNAME>` env vars; stdout is the result, non-zero exit is an error, default timeout 300 s.\n\n### Sandbox\n\n`sandbox = true` or `--sandbox` restricts filesystem writes to the launch directory at OS level — Landlock on Linux 5.13+, Seatbelt on macOS — including child processes, shell, and MCP servers.\n\n## Examples\n\n### Example 1: \"the tool never showed up\"\n\nWork the chain in order: is the capability in the role's `capabilities` list or expected to auto-activate; does its `config.toml` have triggers; is the session domain in its `domains`; are its `{{ENV:}}` keys set; did the intent clear 0.65 with a 0.06 margin; was it evicted by the four-capability cap. Each step has a distinct fix.\n\n### Example 2: auto-activation ignores a short message\n\n❌ Bad: expecting `do it` to activate a capability.\n\n✅ Good: state the intent — `query the postgres schema`.\n\nWhat changed: messages under 8 non-whitespace characters are skipped deliberately; short acknowledgments embed noisily.\n\n### Example 3: two database capabilities, neither activates\n\nThat is the margin gate abstaining on a near tie. Name the engine, or call `capability(action=\"discover\", intent=...)` and enable explicitly.\n\n## Checklist\n\n- [ ] Symptom traced to a stage: tap resolution, placeholders, capability activation, domain or env gate, or eviction?\n- [ ] Capability has `config.toml` with non-empty `triggers`?\n- [ ] Session domain matches the capability's `domains`, or the list is empty?\n- [ ] Skill auto-activation has both `rules:` and a matching `domains:` entry?\n- [ ] Local tool executable, extensionless, and carrying an `@description` header?\n- [ ] Eviction explanation checks static ownership and refcount before claiming a server was killed?\n\n## Composition \u002F References\n\n- Pairs with `octomind-config` for `[capabilities]`, `[taps]`, `[skills]`, and `[registry]`.\n- Pairs with `octomind-cli` for `octomind tap`, `\u002Fskill`, `\u002Fmcp`, and `OCTOMIND_*` variables.\n- Octomind docs: `doc\u002Fusage\u002F16-token-efficiency.md`, `doc\u002Fusage\u002F15-skills.md`, `doc\u002Fusage\u002F17-local-tools.md`, `doc\u002Fintegration\u002F04-tap-system.md`, `doc\u002Fusage\u002F07-mcp-tools.md`\n","## Overview\n\nThis skill explains how a session's tool surface comes to exist: how a tag resolves through taps into a manifest, which tools are built in, how capabilities turn into running MCP servers, how the auto-activator decides without an LLM in the loop, and how skills, plugins, local tools, and the sandbox fit in.\n\nIt covers resolution, not authoring — writing manifests, capabilities, deps, and skills belongs to the `tap-*` authoring skills.\n\n## Mental model\n\nEvery exposed tool costs prompt tokens on every turn, and a wide tool zoo makes the model pick wrong tools. So the surface starts small and grows on demand: capabilities load when intent matches, and the least-recently-used one is evicted when the active set is full.\n\nTwo layers stack. Static comes from the role's manifest at boot; dynamic is what a capability adds at runtime. Eviction may tear down only the dynamic layer — a server the role statically owns is never killed.\n\n## Rules\n\n### Tap resolution\n\nA tap is a Git repo or local directory holding `agents\u002F\u003Cdomain>\u002F\u003Cspec>.toml`, `capabilities\u002F\u003Cname>\u002F`, `skills\u002F\u003Cname>\u002F`, `deps\u002F\u003Corg>\u002F\u003Ctool>.sh`, `workflows\u002F\u003Cname>.toml`, and optionally `plugins\u002F`. `octomind tap user\u002Frepo` clones `github.com\u002Fuser\u002Foctomind-repo` into `\u003Cdata_dir>\u002Ftaps\u002Fuser\u002Foctomind-repo`; `octomind tap user\u002Frepo \u003Cpath>` links a local directory instead. The built-in `muvon\u002Ftap` is always present as the last-priority fallback.\n\nPriority: user taps in the order added, then the built-in tap. The first tap providing a tag, skill, capability, or workflow wins. A capability can be pinned explicitly: `octomind\u002F\u003Cname>` for the baseline tap, `\u003Corg>\u002F\u003Cname>` for a connected tap.\n\nRunning a `domain:spec` tag: fetch the manifest (cached per `[registry].cache_ttl_hours`), expand `capabilities = [...]`, resolve `{{INPUT:KEY}}` (persistent store `inputs.toml`, prompted once) and `{{ENV:KEY}}` (environment, else prompted and saved to `.\u002F.env`), run `[deps] require` scripts before MCP init, inject the tag as the role name, merge into config, start the session. In non-interactive child runs a missing value is an error, not a prompt.\n\n### Bare domains and the chief\n\nA domain's orchestrator is the agent that knows the other agents of its domain and hands work to them. It is named `chief`, so its tag is `\u003Cdomain>:chief`. A TAG with no colon is looked up as a local `[[roles]]` entry first, so a local role always wins over a domain of the same name. If no role matches, the name is read as a domain and runs `\u003Cdomain>:chief`: `octomind run developer` starts `developer:chief`. If the domain has no `chief`, the run fails with an error that lists the domain's agents. `domain:spec` always runs that exact agent, and plain `octomind run` starts `assistant:chief`, the global assistant. The same rules apply to `octomind acp`, `octomind server`, and `\u002Frole`. The `tap` tool takes no role: it matches the prompt to a specialist. Workflows still need full two-part tags.\n\nTwo placeholders in a tap manifest's `system` are expanded when the manifest loads: `{{SPECIALISTS}}` and `{{USES}}`. Octomind 0.71 expands `{{SPECIALISTS}}` to the other agents of the same domain (`- \u003Ctag> — \u003CDescription>`, sorted, `(none)` when empty) and `{{USES}}` to what a `chief` declared in its `# Uses:` header comment (`- \u003Centry> — \u003CDescription>`). Newer versions expand both to one fixed sentence saying the specialist is matched automatically by `tap(action=\"run\", prompt=…)`. The header entries are a bare domain (that domain's `chief`), a full tag (that agent), or `*` (the `chief` of every other domain, global assistant only); the header is validated at load and bounds which agents the runtime can match. They change only when a tap changes, so `system` may hold them. `{{CWD}}` and `{{DATE}}` change every session, so tap manifests put them in `welcome` only.\n\n### Built-in tools\n\n| Server | Tools | Granted by |\n|--------|-------|------------|\n| `core` | `recall` (only when compression attention is enabled) | `core` capability |\n| `orchestration` | `tap`, `schedule`, `monitor` | `orchestration` capability |\n| `runtime` | `mcp`, `agent`, `skill`, `capability` | `runtime` capability |\n| `agent` | `agent_\u003Cname>` per `[[agents]]` entry | `agent` capability |\n| `local` | scripts in `.agents\u002Ftools\u002F` | always, per workdir |\n\nThere is no plan tool: planning is supervisor-owned and only displayed via `\u002Fplan`.\n\n`tap` actions: `run` (background child; `prompt`, optional `workdir`; no role is passed: the runtime compares the prompt with the `# Title:` and `# Description:` of the agents the caller may reach, which are the other agents of its own domain plus what its `# Uses:` header declares, or every installed agent when the caller is not a tap agent, and starts the closest one if it is clearly ahead. With `[decision] taps = true` in the config, off by default, a decision model confirms or overrules the pick. With no match it returns \"No specialist matches this task\" and starts nothing. The result is `{id, role, title, workdir, message}`; pass `session=\u003Cid>` to continue a run, otherwise the child starts with zero context), `list`, `stop`, `send`, `capability` (push an intent through the auto-activation path), and `workflow` (list, show, or run a tap workflow in the background). Run ids look like `tap-developer-general-a3f1c2`; results arrive in a later turn.\n\n### Capability anatomy\n\n`config.toml` carries a required non-empty `triggers = [...]` and optional `domains = [...]`; missing either file or triggers means the capability fails to resolve. `\u003Cprovider>.toml` carries `[deps]`, `[roles.mcp]`, and `[[mcp.servers]]`; the provider comes from the `[capabilities]` config map, else `default`. Its `# Title:` and `# Description:` header feed `list` and `discover`.\n\nThe `capability` tool (on `runtime`): `list`, `discover` (semantic match over triggers, keyword fallback), `enable`, `disable`. Activation registers each server with a filter computed from `allowed_tools`; a server already in the role's static config is not re-registered, the capability extends its filter instead. A capability with no servers but non-empty `[deps]` is a toolchain capability — running the installers is the activation.\n\n### Auto-activation\n\nRuns before every API request when `auto_capabilities = true`, on fresh user messages only. Steps: skip system-managed text; strip XML blocks so pasted content cannot drive matches; bail if fewer than 8 non-whitespace characters remain; drop already-active, out-of-domain, and env-unready capabilities (any `{{ENV:KEY}}` in a server's `env` or `headers` that is unset); embed the intent once; score each capability as the mean of its top-3 trigger cosines.\n\n| Constant | Value | Purpose |\n|----------|-------|---------|\n| `AUTO_ACTIVATE_THRESHOLD` | `0.65` | Minimum mean-of-top-3 cosine |\n| `AUTO_ACTIVATE_MARGIN` | `0.06` | Required gap between top-1 and top-2 |\n| `AUTO_ACTIVATE_TOP_K` | `3` | Triggers averaged per capability |\n\nThe embedding model is `muvon\u002Foctomind-embed` (int8 ONNX). The margin gate is why two near-tied capabilities cause abstention rather than a coin flip. With `[supervisor.evaluate] capabilities = true`, an evaluation model can veto a weak cosine winner or promote a pick when cosine abstained. Silent no-ops: toggle off, not a fresh user message, intent too short, embedding model still downloading, nothing eligible, or no score clearing the gate.\n\n### Domain gating\n\nThe session domain is the part before the colon of the active role. An empty `domains` list means universal; a non-empty one restricts the capability. The gate applies everywhere — `list`, `discover`, auto-activation, `enable`, and `OCTOMIND_CAPABILITIES` — with no bypass. With no domain set, only universal capabilities survive.\n\n### LRU eviction\n\nAt most four runtime-activated capabilities per session. Activating a fifth disables the least-recently-used first. Recency means successful tool use, not activation order. Eviction is the only auto-disable — no time decay. Capabilities preloaded from the manifest are static and never counted.\n\nShared servers are safe: each capability records which tools it registered per server, and the process is killed only when the role does not own the server statically and no other active capability references it.\n\n### Skills\n\nDiscovery order, first name wins: tap `skills\u002F` directories, `\u003Cworkdir>\u002F.agents\u002Fskills\u002F`, `~\u002F.config\u002Fagents\u002Fskills\u002F`, Agent Plugin skill directories, then generated skills from learning evolution.\n\nThree activation methods: `OCTOMIND_SKILLS` preloads at session start; declarative `rules:` auto-activate on fresh user messages when `[skills] auto_activation` is on and the skill's `domains:` contains the session domain (or `*`); manual `\u002Fskill \u003Cname>` or `skill(action=\"use\")`. With `[supervisor.evaluate] skills = true`, an evaluation model may pick a skill from the domain pool when every rule abstained.\n\nThe parser reads `name`, `description`, `compatibility`, `license`, `allowed-tools`, `capabilities`, `domains`, and `rules`; other keys are ignored, and a skill missing `name` or `description` is skipped. Files under `scripts\u002F`, `references\u002F`, and `assets\u002F` are listed with absolute paths in a Skill Resources section on activation. Declared `capabilities` are enabled with the skill.\n\n### Agent Plugins\n\nDirectories with a `plugin.json` (Agent Plugins 1.0.0 schema) are scanned from tap `plugins\u002F`, `\u003Cworkdir>\u002F.agents\u002Fplugins\u002F`, and `~\u002F.config\u002Fagents\u002Fplugins\u002F`. Their `skills\u002F\u003Cname>\u002FSKILL.md` join skill discovery and their `mcp.json` declares MCP servers. A bad manifest rejects the plugin; a bad skill or server skips only that part.\n\n### Local tools\n\nAn executable script at `\u003Cworkdir>\u002F.agents\u002Ftools\u002F\u003Cname>` becomes a tool on the `local` server — rediscovered every turn, role-agnostic, no config. The filename is the tool name (`[A-Za-z0-9_-]+`). The leading comment block (`#`, `\u002F\u002F`, or `--`, first 80 lines) declares `@description` and repeatable `@param NAME TYPE DESC`; prefix the name with `*` for required. Params arrive as JSON on stdin and as `OCTOMIND_PARAM_\u003CNAME>` env vars; stdout is the result, non-zero exit is an error, default timeout 300 s.\n\n### Sandbox\n\n`sandbox = true` or `--sandbox` restricts filesystem writes to the launch directory at OS level — Landlock on Linux 5.13+, Seatbelt on macOS — including child processes, shell, and MCP servers.\n\n## Examples\n\n### Example 1: \"the tool never showed up\"\n\nWork the chain in order: is the capability in the role's `capabilities` list or expected to auto-activate; does its `config.toml` have triggers; is the session domain in its `domains`; are its `{{ENV:}}` keys set; did the intent clear 0.65 with a 0.06 margin; was it evicted by the four-capability cap. Each step has a distinct fix.\n\n### Example 2: auto-activation ignores a short message\n\n❌ Bad: expecting `do it` to activate a capability.\n\n✅ Good: state the intent — `query the postgres schema`.\n\nWhat changed: messages under 8 non-whitespace characters are skipped deliberately; short acknowledgments embed noisily.\n\n### Example 3: two database capabilities, neither activates\n\nThat is the margin gate abstaining on a near tie. Name the engine, or call `capability(action=\"discover\", intent=...)` and enable explicitly.\n\n## Checklist\n\n- [ ] Symptom traced to a stage: tap resolution, placeholders, capability activation, domain or env gate, or eviction?\n- [ ] Capability has `config.toml` with non-empty `triggers`?\n- [ ] Session domain matches the capability's `domains`, or the list is empty?\n- [ ] Skill auto-activation has both `rules:` and a matching `domains:` entry?\n- [ ] Local tool executable, extensionless, and carrying an `@description` header?\n- [ ] Eviction explanation checks static ownership and refcount before claiming a server was killed?\n\n## Composition \u002F References\n\n- Pairs with `octomind-config` for `[capabilities]`, `[taps]`, `[skills]`, and `[registry]`.\n- Pairs with `octomind-cli` for `octomind tap`, `\u002Fskill`, `\u002Fmcp`, and `OCTOMIND_*` variables.\n- Octomind docs: `doc\u002Fusage\u002F16-token-efficiency.md`, `doc\u002Fusage\u002F15-skills.md`, `doc\u002Fusage\u002F17-local-tools.md`, `doc\u002Fintegration\u002F04-tap-system.md`, `doc\u002Fusage\u002F07-mcp-tools.md`\n",{"name":5,"rules":48,"title":54,"domains":24,"license":14,"metadata":55,"description":7,"compatibility":58},[49,50,51,52,53],"match((?i)\\bauto.?activat)","match((?i)\\b(LRU|eviction|domain gating|tool surface)\\b)","match((?i)\\b(tap|capability|skill) (resolution|resolve|priority)\\b)","match((?i)\\.agents\u002F(tools|skills|plugins)\\b)","semantic(why is this tool or skill not available in my session)","Octomind Runtime & Tool Surface",{"tags":56,"version":57},"octomind runtime capabilities skills taps","1.1","Requires: octomind binary. macOS\u002FLinux\u002FWindows.","master","078134db8ee9072ba54cf2173c652f424c38fbf1","skills\u002Foctomind-runtime",0,"https:\u002F\u002Fgithub.com\u002FMuvon\u002Foctomind-tap","https:\u002F\u002Foctomind.run\u002Ftap\u002F","https:\u002F\u002Fgithub.com\u002FMuvon","https:\u002F\u002Fmuvon.io","We bring ideas to life","2026-11-12 23:55:54",{"source":8,"skillName":5,"commands":70,"prompt":80,"zipAvailable":81},[71,74,77],{"tool":72,"command":73},"npx","npx skills add Muvon\u002Foctomind-tap --skill octomind-runtime",{"tool":75,"command":76},"bunx","bunx skills add Muvon\u002Foctomind-tap --skill octomind-runtime",{"tool":78,"command":79},"pnpm","pnpm dlx skills add Muvon\u002Foctomind-tap --skill octomind-runtime","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FMuvon\u002Foctomind-tap\u002Fblob\u002Fmaster\u002Fskills\u002Foctomind-runtime\u002FSKILL.md",true,[],[84,122,148,168,192,213],{"skillNo":85,"name":86,"nameZh":6,"description":87,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":88,"categories":89,"keywords":101,"publishedAt":43},"01M70SFC5CTHRKA9B97N1ARVZ2","seo-content-refresh","Finds decaying pages, picks update, merge, redirect or remove, and briefs each refresh. Use to prioritize existing content and judge whether it helped.","https:\u002F\u002Fgithub.com\u002FMuvon\u002Foctomind-tap\u002Fblob\u002Fmaster\u002Fskills\u002Fseo-content-refresh\u002FSKILL.md",[90,93,98],{"categoryNo":91,"categoryName":92,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000019","营销推广",{"categoryNo":94,"categoryName":95,"taxonomyType":96,"taxonomyTypeDesc":97},"01JBSEEDCAT000000000000035","市场营销","PROFESSION","适用职业",{"categoryNo":99,"categoryName":100,"taxonomyType":96,"taxonomyTypeDesc":97},"01JBSEEDCAT000000000000036","内容创作者",[102,103,104,105,106,107,108,109,110,111,112,113,114,115,116,117,118,119,120,121],"seo content refresh","seo","seo content","content refresh","refresh","content","posts","remove","web search","performance","search","traffic","access","drop","websearch","revamp","merge","diagnosis","update","decay",{"skillNo":123,"name":124,"nameZh":6,"description":125,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":126,"categories":127,"keywords":130,"publishedAt":43},"01M70SBWQCHGH7HGS51Y0GTKKW","marketing-review-program","Plans how to ask real customers for honest public reviews: site choice, invitation copy, incentive and disclosure rules. Use to start a review program.","https:\u002F\u002Fgithub.com\u002FMuvon\u002Foctomind-tap\u002Fblob\u002Fmaster\u002Fskills\u002Fmarketing-review-program\u002FSKILL.md",[128,129],{"categoryNo":91,"categoryName":92,"taxonomyType":20,"taxonomyTypeDesc":21},{"categoryNo":94,"categoryName":95,"taxonomyType":96,"taxonomyTypeDesc":97},[131,132,133,134,135,136,110,112,137,138,139,140,141,142,143,144,145,146,39,147],"program","review","marketing review program","marketing","reviews","get","campaign","choice","how to","only","generated","ask","plan","product","generate","customer","request",{"skillNo":149,"name":150,"nameZh":6,"description":151,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":152,"categories":153,"keywords":154,"publishedAt":43},"01M70SBB65Z2FC71Q7DEAXGJBG","geo-source-actions","Turns AI citation findings into ranked per-source actions for Reddit threads, listicles, review sites and videos. Records only. Use after a GEO audit.","https:\u002F\u002Fgithub.com\u002FMuvon\u002Foctomind-tap\u002Fblob\u002Fmaster\u002Fskills\u002Fgeo-source-actions\u002FSKILL.md",[],[155,156,157,158,159,136,110,112,160,161,140,116,132,162,163,164,144,165,166,167],"actions","geo source actions","source","geo","sources","copilot","domains","llms","threads","youtube","audit","action","data",{"skillNo":169,"name":170,"nameZh":6,"description":171,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":172,"categories":173,"keywords":177,"publishedAt":43},"01M70S99D3Y6GF097GTXWBXHPW","commerce-ai-readiness","Audits product feeds, markup and live pages for AI shopping assistants, then lists exact fixes. Use to make a store catalog readable to AI shoppers.","https:\u002F\u002Fgithub.com\u002FMuvon\u002Foctomind-tap\u002Fblob\u002Fmaster\u002Fskills\u002Fcommerce-ai-readiness\u002FSKILL.md",[174],{"categoryNo":175,"categoryName":176,"taxonomyType":96,"taxonomyTypeDesc":97},"01JBSEEDCAT000000000000031","产品经理",[178,179,180,181,182,183,184,185,186,187,112,188,160,140,114,189,190,144,165,191],"ai readiness","commerce ai readiness","commerce","readiness","feeds","ready","show","shopping","discover","checkout","up","ecommerce","documentation","recommend",{"skillNo":193,"name":194,"nameZh":6,"description":195,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":196,"categories":197,"keywords":199,"publishedAt":43},"01M6DWSX45J42KTK6XASKJRGPA","tap-model-training","Train, evaluate and publish the octomind-embed model behind capability auto-activation. Use when capability triggers or skill semantic() phrases change.","https:\u002F\u002Fgithub.com\u002FMuvon\u002Foctomind-tap\u002Fblob\u002Fmaster\u002Fskills\u002Ftap-model-training\u002FSKILL.md",[198],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},[200,201,42,202,203,188,204,205,41,206,207,208,40,209,210,39,211,212,31,120],"model","training","tap model training","scope","eval","uv","dataset","activate","api","publish","change","embedding","re",{"skillNo":214,"name":215,"nameZh":6,"description":216,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":217,"categories":218,"keywords":220,"publishedAt":43},"01M6DWSQB7NSW53Z86XM81R1W1","tap-deps-authoring","Write dep scripts for the octomind-tap registry: header comments, platform.sh, mcp vs dep types, npx\u002Fuvx pattern. Use when editing deps\u002F\u003Corg>\u002F\u003Ctool>.sh.","https:\u002F\u002Fgithub.com\u002FMuvon\u002Foctomind-tap\u002Fblob\u002Fmaster\u002Fskills\u002Ftap-deps-authoring\u002FSKILL.md",[219],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},[221,42,222,223,224,225,226,227,228,229,230,231,232,233,27,234,31,235,236,237],"deps","tap deps authoring","authoring","DEP","MCP","run","scripts","pattern","install","registry","platform","repo","editing","types","write","org","for"]