
Builtin Tool Authoring
FreeCreate and manage agent-callable tools with ease.
Free · Opens the source repo
What Builtin Tool Authoring does
The Builtin Tool Authoring skill provides a structured framework for developers to create agent-callable tool packages within the LobeHub ecosystem. This skill is essential for those looking to build new tools or enhance existing ones, as it outlines the necessary components and architecture required for seamless integration. It includes clear guidelines on where to place files, how to name tools, and the design principles that should be followed to ensure consistency and reliability across the platform.
At the core of this skill are five distinct faces that serve different purposes: the Manifest + types, ExecutionRuntime, Executor, Client UI, and Registry wiring. Each face has its own specific location and audience, allowing developers to focus on the relevant aspects of their tool without confusion. This modular approach facilitates easier debugging and enhances maintainability, making it straightforward to address common issues such as API not found or render failures.
For developers and designers, this skill is particularly useful when creating new packages or adding features to existing tools. It provides comprehensive documentation on how to implement various UI components, such as Inspectors and Renderers, as well as how to wire these components into the central registries. By following the guidelines laid out in the accompanying documentation, users can ensure that their tools are not only functional but also adhere to the design principles established by the LobeHub framework.
In summary, the Builtin Tool Authoring skill is a vital resource for anyone involved in developing tools for the LobeHub platform. It streamlines the process of tool creation and management, making it easier to deliver robust and user-friendly solutions that enhance the capabilities of agent-based applications.
When to use it
Use this skill when you need to create or modify agent-callable tools within the LobeHub framework.
When not to use it
This skill is not suitable for general-purpose coding tasks or for projects outside the LobeHub ecosystem.
What you can build with it
Creating a New Tool Package
When starting a new project, use this skill to set up the necessary structure for your builtin tool package.
Adding API Methods
If you need to extend the functionality of an existing tool, this skill guides you through adding new API methods.
Debugging Tool Issues
Utilize this skill's documentation to troubleshoot and resolve common issues related to tool execution and rendering.
How to install Builtin Tool Authoring
View source1. Install with the skills CLI
npx skills add lobehub/lobehub/builtin-tool --agent claude-code2. Or install it manually
Download the skill folder and drop it into ~/.claude/skills/ for all projects, or .claude/skills/ to scope it to one repo. Restart Claude Code so it picks up the new skill.
Anthropic's agentic coding CLI, and the reference implementation of Agent Skills. Drop a skill folder into ~/.claude/skills and Claude Code loads it automatically whenever a task matches the skill's description. Claude Code docs
Inside SKILL.md
Written by lobehubBuiltin Tool Authoring Guide
A builtin tool is a package the agent runtime can call. It ships five faces:
| Face | Lives in | Audience |
|---|---|---|
| Manifest + types | src/{manifest,types,systemRole}.ts | The LLM (tool spec + system prompt) |
| ExecutionRuntime | src/ExecutionRuntime/ | Server / desktop / any runtime caller |
| Executor | src/client/executor/ | Frontend (wraps stores/services) |
| Client UI | src/client/{Inspector,Render,…}/ | Chat UI |
| Registry wiring | packages/builtin-tools/src/*.ts + src/store/tool/slices/builtin/executors/index.ts | Framework |
Read These First
| Question | Doc |
|---|---|
| Where do files live? What does each face do? Wiring? | architecture.md |
| How do I name the tool, design APIs, write the manifest, executor, ExecutionRuntime? | tool-design.md |
| How do I build Inspector / Render / Placeholder / Streaming / Intervention / Portal? | ui/ |
When to Use This Skill
- Creating a new
packages/builtin-tool-<name>/package - Adding a new API method to an existing builtin tool
- Building or restyling any of the 6 client surfaces for a tool
- Wiring a tool into the central registries
- Debugging "tool not found / API not found / render not showing / placeholder stuck" errors
Top-Level Design Principles
lobe-<domain>identifier is permanent. It's stored in message history. Renames need@deprecatedaliases (seepackages/builtin-tools/src/inspectors.ts:88-89). Get it right the first time.- ApiName is an
as constobject, not a TS enum. It doubles as the runtime listBaseExecutoriterates over. - Three result fields, three audiences:
content: string→ the LLM reads itstate: Record<…>→ the UI'spluginState; result-domain only, never echo all params backerror: { type, message, body? }→ both LLM and UI;typeis a stable code
- Split execution from frontend wiring.
src/ExecutionRuntime/— pure runtime, no React, no Zustand, accepts services via constructor. The default place for new logic.src/client/executor/—BaseExecutorsubclass that callsExecutionRuntime(or stores/services directly when frontend-only).
- UI defaults to "do nothing". Inspector is required (the header strip). Render/Placeholder/Streaming/Intervention/Portal are added only when there's something specific to show — empty registries are fine.
- Style with
createStaticStyles + cssVar.*(zero-runtime). Fall back tocreateStyles + tokenonly when you genuinely need runtime values. Use@lobehub/uicomponents, not raw antd. - i18n keys live in
packages/locales/src/default/plugin.ts. Inspector titles must come fromt('builtins.<identifier>.apiName.<api>')so something renders while args stream.
Package Layout (preferred, post-2026 convention)
packages/builtin-tool-<name>/
├── package.json
└── src/
├── index.ts # exports manifest + types + systemRole + Identifier (no React, no stores)
├── manifest.ts # BuiltinToolManifest with JSON Schema for every API
├── types.ts # ApiName const + Params/State interfaces per API
├── systemRole.ts # System prompt teaching the model when/how to use the APIs
├── ExecutionRuntime/ # ✅ Default home for runtime logic (server- or anywhere-callable)
│ └── index.ts
└── client/
├── index.ts # Re-exports for the registries
├── executor/ # ✅ Frontend executor — extends BaseExecutor, often delegates to ExecutionRuntime
│ └── index.ts
├── Inspector/ # required — header chip per API
├── Render/ # optional — rich result card
├── Placeholder/ # optional — skeleton during streaming/execution
├── Streaming/ # optional — live output renderer (e.g. RunCommand, WriteFile)
├── Intervention/ # optional — approval / edit-before-run UI
├── Portal/ # optional — full-screen detail view
└── components/ # shared subcomponents used by the surfaces above
Older packages (builtin-tool-task, builtin-tool-calculator, etc.) still have src/executor/ as a sibling of src/client/. That's grandfathered; don't relocate without a deliberate refactor. New packages and new APIs added to existing packages should follow the layout above.
package.json exports map:
"exports": {
".": "./src/index.ts",
"./client": "./src/client/index.ts",
"./executor": "./src/client/executor/index.ts",
"./executionRuntime": "./src/ExecutionRuntime/index.ts"
}
Authoring Checklist
Before opening the PR:
- Identifier follows
lobe-<domain>and is stable (lives in message history). - Every
<Name>ApiNamevalue has: a manifestapi[]entry, an executor method, an Inspector, an i18napiName.*key. -
Paramsinterfaces match the JSON Schema;Stateinterfaces match what the executor returns and what the UI surfaces read. - System prompt disambiguates confusable APIs and points to batch variants.
- Runtime logic lives in
ExecutionRuntime/; theclient/executor/only wires stores/services and delegates. - Executor returns
{ success, content, state, error? }via a singletoResult()funnel —contentalways non-empty (default toerror.message). - Inspector handles
isArgumentsStreaming,isLoading,partialArgs, missingpluginState. - Render returns
nulluntil it has data; only created for APIs with rich results. - Placeholder added if the API has a perceivable execution lag (search, list, crawl).
- Streaming added for APIs that emit incremental output (run command, write file, code execution).
- Intervention added if
humanInterventionis set in the manifest. - All registry files updated (see architecture.md → Registry wiring).
- i18n keys in
packages/locales/src/default/plugin.tsplus dev seeds inen-US/zh-CN. -
bunx vitest run --silent='passed-only' 'packages/builtin-tool-<name>'passes. -
bun run type-checkpasses.
Reference Tools
Pick the closest neighbor and copy:
| If your tool is… | Read first |
|---|---|
| Pure-compute, no UI state | packages/builtin-tool-calculator/ — ExecutionRuntime reuses executor (mathjs/nerdamer work everywhere) |
| CRUD over a domain entity | packages/builtin-tool-task/ — full Inspector + Render set, batch variants |
| Heavy UI (Inspector/Render/Placeholder/Portal) | packages/builtin-tool-web-browsing/ — search-style result UI, Portal for detail view |
| Desktop / filesystem with all surfaces (incl. Streaming + Intervention) | packages/builtin-tool-local-system/ — ExecutionRuntime injects an ILocalSystemService, executor calls it |
| Server-side pure (no client executor) | packages/builtin-tool-web-browsing/ — only ExecutionRuntime is exported; the chat client doesn't run it |
| Needs human approval before running | packages/builtin-tool-local-system/src/client/Intervention/ — per-API approval components |
Frequently asked questions about Builtin Tool Authoring
Similar skills
WinMD API Search
Easily find and explore Windows desktop APIs.
WebMCPify
Transform any web app into an agent-ready platform.
Phoenix Tracing
Instrument LLM applications with OpenInference tracing.
Foundry Hosted Agent CopilotKit
Guidance for developing agentic web apps on Azure.
Power Automate Foundation
Connect AI agents to Power Automate seamlessly.
Power Automate Flow Builder
Efficiently build and deploy Power Automate flows programmatically.
