Skip to content
cccskills
FreePublished on GitHubEnglish overview

builtin-tool

Use this guide when adding or extending a LobeHub builtin agent tool. It covers the tool manifest and types, runtime and frontend executor, chat interface surfaces, and registry wiring, with conventions for connecting them consistently.

OriginalShow the original description

Use for LobeHub builtin agent tools: manifests, executors, runtimes, inspectors, renders, streaming and intervention.

lobehub/lobehub83,504 stars(GitHub 83,504 + cccskills 0)

Run score Not tested

See how to install

Good for

  • Creating a new builtin tool package
  • Adding an API method to an existing tool
  • Building an Inspector or result view
  • Tracing a tool registration or rendering issue

Overview

What it does

This guide explains how to create or extend a LobeHub builtin agent tool. It covers the manifest and types, runtime behavior, the frontend executor, chat interface surfaces, and registration in the central registries. The Inspector is used to display each API. Add result cards, execution or streaming indicators, and approval screens when the tool needs them. The guide also describes details to keep aligned, including identifiers, result fields, translation keys, and the relationship between API definitions and interface surfaces.

When it helps

Use it when creating a package for a new builtin tool, adding an API to an existing tool, or building an Inspector, Render, or other tool interface surface. It can also help investigate registration and display problems, such as a tool that cannot be found or a result that does not appear.

Example requests

  • “Show me how to structure a builtin file operation tool.”
  • “List the work needed to add a new API method to this tool.”
  • “Find out why the tool's result view is not appearing.”

Notes

The guide specifies libraries and styling conventions, including @lobehub/ui and createStaticStyles. Detailed design references are in the skill's references/ directory.

This overview was written by AI (OpenAI Codex) from the public SKILL.md. Check the original below for the exact behavior.

Document check

AI checked the SKILL.md for operations that need care and for setup requirements. The score comes only from actually running the skill (hands-on test).

SafetyAre sending data, deleting files, and running commands disclosed?
AGoodIt gives implementation guidance and specifies no external sending or deletion actions.
Easy setupDoes it need few tools or API keys, and are they documented?
BPartly lackingIt names libraries and bun commands but does not provide installation steps.

Not counted in the score. Rated by AI (OpenAI Codex) as of Oct 26, 2026. Treat it as a guide and read the original before installing.

Disagree? Request a re-evaluation

Tell us which point is wrong and why. No login needed. We will check it against the SKILL.md, redo the evaluation, and show the result here.

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

Files included (14)

  • SKILL.md9.4 KB
  • references/architecture.md17.7 KB
  • references/tool-design.md20.6 KB
  • references/ui/composition.md1.9 KB
  • references/ui/diagnostics.md2.4 KB
  • references/ui/inspector.md5.5 KB
  • references/ui/intervention.md3.9 KB
  • references/ui/placeholder.md3.1 KB
  • references/ui/portal.md2.5 KB
  • references/ui/principles.md4.6 KB
  • references/ui/README.md3.2 KB
  • references/ui/render.md4.1 KB
  • references/ui/shared-rules.md5.4 KB
  • references/ui/streaming.md2.7 KB

SKILL.md (original)

Review the instructions the agent will receive before you install.

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 legacy aliases kept alongside the new name (see the // Legacy aliases entries in packages/builtin-tool-local-system/src/client/Inspector/index.ts, kept after listLocalFiles/searchLocalFiles were renamed to listFiles/searchFiles). 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.
  8. A failed long-running call should be continuable, not just inspectable. Example: when callSubAgent stops halfway, the user says "keep going". So the fix was an optional subAgentId on callSubAgent that appends a new instruction to the same sub-agent thread — not a new "look up that run" API the model has to remember to call before retrying from scratch. Add a new API only when a user would ask for it on its own.

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-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

Reviews

No reviews yet. Tell others what you thought.

Comments

No login needed. Share how it worked for you, ask a question, or note where it did not run.

No comments yet. Be the first to write one.

Comments are published right away. Do not include personal information such as email addresses or phone numbers. Up to 2 URLs.

0 / 1,000 characters

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

More skills from this repository

acceptance

FreeSummary

Use this skill to verify a delivery by exercising the real product through a suitable surface such as a CLI, web app, desktop app, or iOS Simulator. It helps create or find a verification plan, capture evidence, and publish an acceptance report.

  • Verifying a completed product change
  • Collecting screenshots or other evidence
  • Creating a verification plan and report
lobehub/lobehub83.5KUpdated Oct 26, 2026

Use this skill to add an AI model provider to LobeHub across runtime integration, model cards, settings, branding, documentation, and acceptance checks. It also covers provider documentation updates and distinguishes new providers from models added to an existing provider.

  • Integrating a new AI model provider into LobeHub
  • Updating setup or usage documentation for a provider
  • Checking whether a model needs a new provider integration
lobehub/lobehub83.5KUpdated Oct 26, 2026

add-setting-env

FreeSummary

Use this skill to add a server-side environment variable that sets a default for a user setting. It walks through validation, server configuration and store merging, plus updating the example environment file and self-hosting documentation.

  • Adding an environment variable for a setting default
  • Wiring a new setting domain into server config
  • Documenting a new variable for self-hosting
lobehub/lobehub83.5KUpdated Oct 26, 2026

Provides guidance for registering hooks around an agent’s execution steps, tool calls, human approvals, context compression, and sub-agent calls. Hooks can observe events, supply local mock tool results, or use webhooks to allow or deny tool results under configured policies.

  • Observing agent steps and tool errors
  • Mocking tool results during local execution
  • Requiring webhook decisions before or after a tool call
lobehub/lobehub83.5KUpdated Oct 26, 2026

agent-signal

FreeSummary

Build event-driven background workflows for agents by defining sources, interpreting them as signals, and running actions through policies. It also guides asynchronous handoffs, deduplication, scoped execution, completion receipts, and observability.

  • Adding a new event source to an agent workflow
  • Routing interpreted signals to concrete background actions
  • Enqueuing work for asynchronous processing
lobehub/lobehub83.5KUpdated Oct 26, 2026

Use this skill to run end-to-end acceptance checks for bot channels in real desktop chat apps. It drives apps such as Discord, Slack, Telegram, WeChat, Lark, and QQ to send a message, wait for a response, and capture the result.

  • Checking a bot response in a real Discord channel
  • Testing chat behavior through Slack or Telegram
  • Capturing a bot interaction in a native macOS app
lobehub/lobehub83.5KUpdated Oct 26, 2026

See all skills by lobehub

Report a problem with this skill