Using One Connect

Skills and connectors

Skills are versioned instructions agents load on demand. Connectors give agents and you tools from local MCP servers, code hosts and infrastructure, with every call approved.

Skills#

Project skills are reusable, versioned SKILL.md instructions. Agents see only each skill's one-line description in their assignment until they call get_skill for the full text, which keeps prompts small.

Draft, publish, assign#

1. Draft. Write a skill in Settings → Skills, start from a template, or import one. Drafts are validated and secret-scanned, and never run code or make network calls.
2. Publish. Publishing freezes the saved draft as an immutable version. It requires the latest version number and the exact draft hash you reviewed, so you never publish something you have not seen.
3. Assign. Add published skills to an agent in the agent builder (up to 24), or plug a Skill node into an agent or step on the canvas. Assignments freeze the exact version and hash at creation.

When a run starts, its frozen skills are written into the worktree under the harness's own folder, for example .claude/skills or .agents/skills. Files the repository already tracks, foreign files, symlinks and hard links are never overwritten.

Templates#

Three original templates load as new drafts; they are never published or assigned automatically:

• Evidence-first review: independent review with cited evidence.
• Local Docker and database work: approved local Compose and database changes within scope.
• Cited Dictionary research: search_context, read_note and the graph tools, with citations.

Import and export#

Import skill accepts:

• a SKILL.md file with YAML frontmatter (name and description only) plus optional references/<name>.md or .txt files;
• a One Connect JSON bundle (format: one-connect-skill-bundle);
• a GitHub repository or folder URL, read as a bounded archive in memory, never extracted or executed, with its license detected;
• the Anthropic skills catalog (github.com/anthropics/skills).

The preview validates paths, sizes, secrets, YAML safety and hashes, and shows the source's license. Previewing creates nothing, and an import cannot shadow a built-in skill. Export downloads a published version as JSON with exact file bytes and a SHA-256 per file. Hashes prove integrity, not trust.

Built-in skills#

The pinned design skills are verified by hash with their license notices, and cannot be edited or exported.

Connectors#

Settings → Connectors manages per-project connections. Saving a connection never contacts anything or starts a process.

Remote connections stay off until you activate them with a host and reviewed token scopes. Keys go only into the connection key store (the macOS Keychain), never into settings, prompts, skills or tracker comments. Editing a connection voids its earlier approvals.

Local MCP tools#

One Connect connects to a local MCP server through its stdio protocol. Install and review the server yourself: One Connect never downloads one, extracts another app's login or supplies API keys.

Two separate approvals#

1. Add a draft with the exact executable (an absolute path), its arguments one per line, the allowed tool names and the read roots. Request approval for its tool inventory and review it in Decisions. Approving makes that exact configuration eligible; it does not start the server or authorize any call.
2. Request action for one call: choose the tool and enter JSON arguments. This creates a Decision for that one call, showing the command, arguments, roots, configuration, requester, expiry and a program-access warning. Approval needs a fresh second confirmation.

The approved call starts a fresh server process, checks its tool inventory and invokes the reviewed tool once. Agents use the same path with list_connector_tools, call_connector_tool and get_connector_tool_result; their requests are bound to that agent, run, assignment and issue, and nothing runs until you approve the exact arguments.

You can also start a draft from the official MCP registry, at an exact version. Registry metadata is untrusted and still goes through both approvals.

Receipts#

Polling a receipt never runs the call again. On restart, unexecuted requests need a fresh confirmation, and calls whose completion was not recorded become uncertain; nothing is replayed.

Boundaries#

• The launcher uses separate executable and argument fields, an isolated plugin home and a minimal environment. It never expands a shell command or passes on your API keys.
• Arguments must be bounded, ordinary JSON, and are checked for credentials before execution and when results are displayed.
• External billing is controlled by that program and unknown to One Connect. Approving a plugin never changes an agent's billing.
• Stopping the requesting run closes its active calls; the kill switch closes every active call the project owns. Stopping cannot undo an external action that already happened.