build-capability

core/build-capability

When you need an ability the bridge does not have, build it from the general tools instead of asking for a bespoke one. This skill is the map of how.

The bridge deliberately ships general primitives — processes, filesystem, HTTP, input, screen, code execution — and the machinery to compose them into named capabilities at runtime. A tool hard-wired to one application on one operating system is the wrong shape: it rots when that application changes, it is dead weight on every other platform, and it teaches nothing reusable. A composition you author out of primitives runs wherever the primitives run.

Decide first: does this need a new tool at all?

Work down this list and stop at the first that fits.

1. An existing tool already does it. 237 tools ship in the catalogue. Search before building: tool.search or tools/list, and read the namespace list — fs, exec, net, proc, desktop, browser, ocr, image, git, code_run, document, memory.
2. A short composition does it. Two or three existing calls chained with custom.create (see below). This is the common case and costs one call.
3. It needs real logic — parsing, protocol handling, state, retries. Build a project in Code Workbench and publish it with tool_foundry.publish.
4. It cannot be built yet — the primitive itself is missing. Record it with capability_gap.record so the gap is evidence rather than a memory.

Composing a capability: custom.create

Authors a NEW named tool at runtime. No arbitrary code: each hop dispatches through the normal tool chokepoint, so the risk policy and the agent HALT apply at every level. A composite inherits the MAX risk of everything it touches.

Single call — a named alias with a narrower interface:

{ "name": "read_config",
  "description": "Read the bridge config file",
  "input_schema": {"properties": {"path": {"type": "string"}}, "required": ["path"]},
  "call": {"tool": "fs.read", "args": {"path": "{path}"}} }