What problem does it solve? Creating a new agent-callable builtin tool in the LobeHub codebase requires coordinating five separate faces — manifest, ExecutionRuntime, frontend executor, client UI surfaces, and registry wiring — and missing any one causes silent failures like "tool not found" or blank result cards. This Skill provides the complete authoring guide, conventions, and checklists to build these packages correctly. ## Core Features & Use Cases - Five-face architecture guidance: Covers manifest/types/systemRole, pure ExecutionRuntime with service injection, BaseExecutor subclass wiring, six optional client UI surfaces (Inspector, Render, Placeholder, Streaming, Intervention, Portal), and central registry registration. - Design rules and pitfalls: Enforces stable lobe-<domain> identifiers, as const ApiName objects, the mandatory toResult() funnel, result-domain-only pluginState, and i18n key conventions, with a symptom-to-cause diagnostics table. - Use Case: When adding a new packages/builtin-tool-<name>/ package or a new API to an existing tool, follow the authoring checklist and copy the closest reference tool (calculator, task, web-browsing, or local-system) to ship a working tool with correct Inspector, Render, and registry wiring. ## Quick Start Ask the agent to scaffold a new builtin tool package named lobe-notes with a manifest, ExecutionRuntime, executor, and Inspector following the builtin-tool conventions.
