実際の製品を操作して、利用者が確認できる動作証拠を集め、検証計画に沿った受け入れレポートとして公開するスキルです。
- 変更後の製品動作を実地で検証したいとき
- 画面キャプチャなどの証拠を集めたいとき
- 検証計画とレポートを作成したいとき
LobeHubの組み込みエージェントツールを追加・拡張するときに、実行処理や画面表示、登録設定までの設計と実装方針を確認できるスキルです。
Use for LobeHub builtin agent tools: manifests, executors, runtimes, inspectors, renders, streaming and intervention.
実行スコア 未検証
インストール方法を見るLobeHubの組み込みエージェントツールを新規作成・拡張する際に、マニフェストや型定義、実行時処理、フロントエンド側の実行役、チャット画面の表示、中央レジストリへの登録をどう組み立てるか確認できます。Inspectorは各APIの表示に使い、結果カードや実行中の表示、承認画面などは必要な場合に追加します。識別子や結果フィールド、翻訳キー、API定義と画面の対応関係など、実装時に揃える点もまとめられています。
新しい組み込みツールのパッケージを作るとき、既存ツールにAPIを追加するとき、InspectorやRenderなどの画面を作るときに役立ちます。「ツールが見つからない」「結果が表示されない」といった登録や表示の問題を調べる際にも参照できます。
資料では、@lobehub/uiやcreateStaticStylesなど指定のライブラリ・スタイル規約を使う方針が示されています。詳細な設計資料はスキル内のreferences/にあります。
この紹介文は、公開されている SKILL.md をもとに AI(OpenAI Codex)が作成しました。正確な仕様は下の原文を確認してください。
SKILL.md の記述から、注意が要る操作と導入の前提を AI が確認しました。点数は実際に動かした結果(実行検証)だけで付けています。
点数には入れていません。 2026年10月26日 時点で AI(OpenAI Codex)が判定しました。目安なので、入れる前に原文も確認してください。
インストールする前に、エージェントに与えられる指示の中身を確認できます。
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 |
| 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/ |
packages/builtin-tool-<name>/ packagelobe-<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.as const object, not a TS enum. It doubles as the runtime list BaseExecutor iterates over.content: string → the LLM reads itstate: Record<…> → the UI's pluginState; result-domain only, never echo all params backerror: { type, message, body? } → both LLM and UI; type is a stable codesrc/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).createStaticStyles + cssVar.* (zero-runtime). Fall back to createStyles + token only when you genuinely need runtime values. Use @lobehub/ui components, not raw antd.packages/locales/src/default/plugin.ts. Inspector titles must come from t('builtins.<identifier>.apiName.<api>') so something renders while args stream.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.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"
}
Before opening the PR:
lobe-<domain> and is stable (lives in message history).<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.ExecutionRuntime/; the client/executor/ only wires stores/services and delegates.{ success, content, state, error? } via a single toResult() funnel — content always non-empty (default to error.message).isArgumentsStreaming, isLoading, partialArgs, missing pluginState.null until it has data; only created for APIs with rich results.humanIntervention is set in the manifest.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.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 |
まだレビューはありません。使ってみた感想をお寄せください。
ログインなしで書き込めます。使ってみた感想、質問、動かなかった環境などを気軽にどうぞ。
まだコメントはありません。最初のコメントを書いてみませんか。
実際の製品を操作して、利用者が確認できる動作証拠を集め、検証計画に沿った受け入れレポートとして公開するスキルです。
LobeHubにAIモデルプロバイダーを追加し、実行時連携からモデル表示、設定、ブランド表記、文書化、動作確認まで進めるスキルです。
ユーザー設定の初期値をサーバー側の環境変数で切り替えるため、型定義や設定の組み立て、ユーザーストアへの反映、環境変数の例と説明書きを追加する手順です。
エージェント実行中の各段階をフックで監視し、ツール呼び出しの模擬・制御や人の承認、圧縮、サブエージェント処理に介入する仕組みを扱います。
イベントを起点にエージェントのバックグラウンド処理を組み立て、ソース・シグナル・アクション・ポリシーの役割分担や非同期連携を実装するためのスキルです。
DiscordやSlackなどの実際のチャットアプリでボットにメッセージを送り、応答を画面で確認する受け入れテストを行うスキルです。