本文へ移動
cccskills
無料GitHub で公開日本語紹介

builtin-tool

LobeHubの組み込みエージェントツールを追加・拡張するときに、実行処理や画面表示、登録設定までの設計と実装方針を確認できるスキルです。

原文原文の説明を見る

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

lobehub/lobehubスター 83,502(GitHub 83,502 + cccskills 0)

実行スコア 未検証

インストール方法を見る

こんなときに便利

  • 組み込みツールを新規作成したいとき
  • 既存ツールにAPIを追加したいとき
  • 実行中や結果の画面を設計したいとき
  • ツールの登録・表示エラーを調べたいとき

日本語での紹介

できること

LobeHubの組み込みエージェントツールを新規作成・拡張する際に、マニフェストや型定義、実行時処理、フロントエンド側の実行役、チャット画面の表示、中央レジストリへの登録をどう組み立てるか確認できます。Inspectorは各APIの表示に使い、結果カードや実行中の表示、承認画面などは必要な場合に追加します。識別子や結果フィールド、翻訳キー、API定義と画面の対応関係など、実装時に揃える点もまとめられています。

こんなときに便利

新しい組み込みツールのパッケージを作るとき、既存ツールにAPIを追加するとき、InspectorやRenderなどの画面を作るときに役立ちます。「ツールが見つからない」「結果が表示されない」といった登録や表示の問題を調べる際にも参照できます。

使い方の例

  • 「ファイル操作の組み込みツールを追加する構成を確認して」
  • 「このツールに新しいAPIメソッドを加えるための作業項目を整理して」
  • 「ツールの結果画面が出ない原因を調べて」

注意点

資料では、@lobehub/uiやcreateStaticStylesなど指定のライブラリ・スタイル規約を使う方針が示されています。詳細な設計資料はスキル内のreferences/にあります。

この紹介文は、公開されている SKILL.md をもとに AI(OpenAI Codex)が作成しました。正確な仕様は下の原文を確認してください。

資料チェック

SKILL.md の記述から、注意が要る操作と導入の前提を AI が確認しました。点数は実際に動かした結果(実行検証)だけで付けています。

安全面送信・削除・コマンド実行などの扱いが明示されているか
A良好主に実装指針で、外部送信や削除などの操作は指定されていません。
導入のしやすさ必要なツールや API キーが少ないか、書かれているか
B一部不足利用ライブラリやbunコマンドは示されていますが、導入手順はありません。

点数には入れていません。 2026年10月26日 時点で AI(OpenAI Codex)が判定しました。目安なので、入れる前に原文も確認してください。

評価が違うと思ったら、見直しを依頼する

どの項目が、なぜ違うと思うかを書いてください。ログインは不要です。内容を SKILL.md と照らし合わせて評価を作り直し、この欄に反映します。

このフォームは reCAPTCHA で保護されており、Google のプライバシーポリシーと利用規約が適用されます。

含まれるファイル(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(原文)

インストールする前に、エージェントに与えられる指示の中身を確認できます。

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

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

コメント

ログインなしで書き込めます。使ってみた感想、質問、動かなかった環境などを気軽にどうぞ。

まだコメントはありません。最初のコメントを書いてみませんか。

送信するとすぐに公開されます。メールアドレスや電話番号などの個人情報は書かないでください。URL は 2 つまでです。

0 / 1000 文字

このフォームは reCAPTCHA で保護されており、Google のプライバシーポリシーと利用規約が適用されます。

同じリポジトリのスキル

acceptance

無料概要あり

実際の製品を操作して、利用者が確認できる動作証拠を集め、検証計画に沿った受け入れレポートとして公開するスキルです。

  • 変更後の製品動作を実地で検証したいとき
  • 画面キャプチャなどの証拠を集めたいとき
  • 検証計画とレポートを作成したいとき
lobehub/lobehub8.4万2026年10月26日 更新

add-model-provider

無料概要あり

LobeHubにAIモデルプロバイダーを追加し、実行時連携からモデル表示、設定、ブランド表記、文書化、動作確認まで進めるスキルです。

  • 新しいAIモデルプロバイダーを追加したいとき
  • プロバイダーの設定手順や説明文を更新したいとき
  • 既存プロバイダーへのモデル追加要件を見極めたいとき
lobehub/lobehub8.4万2026年10月26日 更新

add-setting-env

無料概要あり

ユーザー設定の初期値をサーバー側の環境変数で切り替えるため、型定義や設定の組み立て、ユーザーストアへの反映、環境変数の例と説明書きを追加する手順です。

  • 設定の初期値を環境変数で変えたいとき
  • 設定項目をサーバー設定に追加したいとき
  • 環境変数の例と説明を更新したいとき
lobehub/lobehub8.4万2026年10月26日 更新

agent-runtime-hooks

無料概要あり

エージェント実行中の各段階をフックで監視し、ツール呼び出しの模擬・制御や人の承認、圧縮、サブエージェント処理に介入する仕組みを扱います。

  • エージェントの実行状況を記録したいとき
  • ツール結果をテスト用に模擬したいとき
  • Webhookでツール実行を許可・拒否したいとき
lobehub/lobehub8.4万2026年10月26日 更新

agent-signal

無料概要あり

イベントを起点にエージェントのバックグラウンド処理を組み立て、ソース・シグナル・アクション・ポリシーの役割分担や非同期連携を実装するためのスキルです。

  • イベント起点の処理を追加したいとき
  • バックグラウンド処理を非同期化したいとき
  • 重複実行を防ぐ仕組みを整えたいとき
lobehub/lobehub8.4万2026年10月26日 更新

agent-testing-bot

無料概要あり

DiscordやSlackなどの実際のチャットアプリでボットにメッセージを送り、応答を画面で確認する受け入れテストを行うスキルです。

  • 実際のDiscordでボット応答を確かめたいとき
  • SlackやTelegramの会話経路をテストしたいとき
  • macOSアプリ上の操作結果を画面で記録したいとき
lobehub/lobehub8.4万2026年10月26日 更新

lobehub のスキルをすべて見る

このスキルの問題を報告する