New to Claude Skills? Learn how to install them →

Blobehub on GitHub

Builtin Tool Authoring

Free

Create and manage agent-callable tools with ease.

by lobehub81.5k stars on lobehub/lobehub
1 views
Updated Aug 1, 2026
Get this skill

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 source

1. Install with the skills CLI

npx skills add lobehub/lobehub/builtin-tool --agent claude-code

2. 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 lobehub

Builtin Tool Authoring Guide

A builtin tool is a package the agent runtime can call. It ships five faces:

FaceLives inAudience
Manifest + typessrc/{manifest,types,systemRole}.tsThe LLM (tool spec + system prompt)
ExecutionRuntimesrc/ExecutionRuntime/Server / desktop / any runtime caller
Executorsrc/client/executor/Frontend (wraps stores/services)
Client UIsrc/client/{Inspector,Render,…}/Chat UI
Registry wiringpackages/builtin-tools/src/*.ts + src/store/tool/slices/builtin/executors/index.tsFramework

Read These First

QuestionDoc
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

  1. lobe-<domain> identifier is permanent. It's stored in message history. Renames need @deprecated aliases (see packages/builtin-tools/src/inspectors.ts:88-89). Get it right the first time.
  2. ApiName is an as const object, not a TS enum. It doubles as the runtime list BaseExecutor iterates over.
  3. Three result fields, three audiences:
    • content: string → the LLM reads it
    • state: Record<…> → the UI's pluginState; result-domain only, never echo all params back
    • error: { type, message, body? } → both LLM and UI; type is a stable code
  4. 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/BaseExecutor subclass that calls ExecutionRuntime (or stores/services directly when frontend-only).
  5. 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.
  6. Style with createStaticStyles + cssVar.* (zero-runtime). Fall back to createStyles + token only when you genuinely need runtime values. Use @lobehub/ui components, not raw antd.
  7. i18n keys live in packages/locales/src/default/plugin.ts. Inspector titles must come from t('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>ApiName value has: a manifest api[] entry, an executor method, an Inspector, an i18n apiName.* key.
  • Params interfaces match the JSON Schema; State interfaces 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/; the client/executor/ only wires stores/services and delegates.
  • Executor returns { success, content, state, error? } via a single toResult() funnel — content always non-empty (default to error.message).
  • Inspector handles isArgumentsStreaming, isLoading, partialArgs, missing pluginState.
  • Render returns null until 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 humanIntervention is set in the manifest.
  • All registry files updated (see architecture.md → Registry wiring).
  • i18n keys in packages/locales/src/default/plugin.ts plus dev seeds in en-US/zh-CN.
  • bunx vitest run --silent='passed-only' 'packages/builtin-tool-<name>' passes.
  • bun run type-check passes.

Reference Tools

Pick the closest neighbor and copy:

If your tool is…Read first
Pure-compute, no UI statepackages/builtin-tool-calculator/ExecutionRuntime reuses executor (mathjs/nerdamer work everywhere)
CRUD over a domain entitypackages/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 runningpackages/builtin-tool-local-system/src/client/Intervention/ — per-API approval components

Frequently asked questions about Builtin Tool Authoring

Similar skills