builtin-tool

Build builtin tool packages and wire them into LobeHub registries.

Updated Aug 23, 2026
One-click install
npx skills add https://github.com/kingheu0818-sketch/lobehub_yu --skill builtin-tool-kingheu0818-sketch
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: builtin-tool
Source: https://github.com/kingheu0818-sketch/lobehub_yu/tree/main/.agents/skills/builtin-tool
Command: npx skills add https://github.com/kingheu0818-sketch/lobehub_yu --skill builtin-tool-kingheu0818-sketch

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

This Skill provides a practical end-to-end guide for authoring and wiring builtin tool packages so your agent tools are discoverable, executable, and correctly rendered across all chat UI surfaces.

Core Features & Use Cases

  • New builtin tool scaffolding: Design and implement a new package under packages/builtin-tool-<name>/ with the correct structure for manifest, runtime logic, executor wiring, and UI surfaces.
  • API surface design: Define stable identifiers and ApiName contracts, write JSON-schema manifests for LLM tool specs, and align Params/State so pluginState is result-domain only.
  • Execution architecture & correctness: Split pure runtime logic (ExecutionRuntime) from frontend wiring (client/executor) and enforce the result contract (success/content/state/error) with safe fallbacks.
  • UI surface integration: Add or update Inspector, Render, Placeholder, Streaming, Intervention, and Portal components only when needed, then register them in the central registries.
  • Registry wiring & debugging: Resolve common issues like “tool not found”, missing chips, blank render cards, stuck placeholders, or missing intervention dialogs by updating the required registry files.
  • Governed conventions: Follow conventions for stable lobe-<domain> identifiers, ApiName const objects, i18n keys, styling, and class-field executor methods to avoid runtime dispatch bugs.

Quick Start

Use the builtin-tool skill to create a new packages/builtin-tool-<name>/ package by first writing SKILL.md-aligned files (manifest, types, systemRole), implementing ExecutionRuntime and a class-field executor, and then wiring Inspector/Render/placeholder surfaces into the registries while updating i18n keys for builtins.<identifier>.apiName.<api>.

Frequently Asked Questions about builtin-tool

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I create a new builtin tool package for LobeHub agents?

To create a builtin tool package, scaffold a directory under packages/builtin-tool-<name>/ with manifest, runtime logic, executor wiring, and UI surfaces, then register them centrally. This ensures your agent tools are discoverable and correctly rendered.

Why does my agent tool show as not found or render a blank card in the chat UI?

A blank render card or tool not found error occurs when registry files are mismatched. You must update central registries and align the manifest, ExecutionRuntime, executor, and client surfaces to resolve UI and runtime dispatch bugs.

How do execution runtime and executor components split logic in agent tools?

Execution runtime separates pure runtime logic from frontend wiring by enforcing a result contract with success, content, state, and error fields. The class-field executor handles dispatch using stable ApiName const objects for safe fallbacks.

What is the correct manifest schema for defining LLM tool specs?

The correct manifest schema uses JSON-schema formats to define stable identifiers and ApiName contracts. You must align Params and State so pluginState remains result-domain only, ensuring proper LobeHub agent execution and UI rendering.

Do I need to update i18n keys when adding a new API method to an existing tool?

Yes, extending existing tools with new methods requires updating i18n keys under builtins.<identifier>.apiName.<api>. This governed convention ensures discoverability and prevents runtime dispatch bugs across all chat UI surfaces.

Can I use this builtin tool approach for TypeScript APIs outside of LobeHub?

This approach is specifically designed for LobeHub agent execution environments. It enforces lobe-<domain> identifier conventions, manifest schemas, and registry wiring that are tightly coupled to the LobeHub UI and runtime architecture.