temps-plugin

创建并交付 Temps 插件

对于 TypeScript/Bun 项目，交付一个可用的外部插件、可安装的源代码仓库，以及已验证内容的证据。提供现有项目时，继续在该项目基础上开发；保留其标识、存储和用户更改。发布是独立于构建或安装的另一项成果。

此处的 Rust 支持仅限开发和本地模拟器测试。Rust 分发需要单独的签名原生 npm 包/目录流水线，本技能不涉及该流程。不要通过 TypeScript GitHub 安装器处理 Cargo 仓库，也不要建议将二进制文件复制或创建符号链接到主机插件目录。如果用户要求发布 Rust 插件，应先明确受支持的原生发布流程，再声称可以提供端到端方案；不要擅自更改用户所选的实现语言。

1. 明确契约

记录插件的用途、目标用户、在 Temps 中的入口、输入/输出、持久化数据、所需的主机权限、资源限制，以及支持的主机/SDK 版本。只解决会影响实现的未定事项。对于新的、可通过 GitHub 安装的插件，优先选择 TypeScript + Bun；现有 Rust 插件或用户明确选择 Rust 时则保留 Rust。

阅读适用的仓库说明。检查已安装 CLI 的 plugin --help 和 SDK 导出内容，不要假设其他版本中的命令也存在。TypeScript 官方起始模板是 gotempsh/temps-plugin-template。 使用该模板当前的 README、清单、锁文件和 CI。模板可能比 npm CLI 更新；CLI 缺少某个命令并不意味着可以凭空编造一个命令。

Temps 代码库中的当前证据来源：

• apps/temps-cli/src/commands/plugin/：init、build、install、update、grants 和开发模拟器。
• crates/temps-external-plugins/src/repository.rs：实际的源码安装器构建契约。
• crates/temps-core/src/external_plugin/：协议、权限、清单和事件。
• sdks/node/packages/plugin-sdk/src/ 和 crates/temps-plugin-sdk/src/：SDK API。
• 根目录下的 DESIGN.md、web/src/components/ui/ 和 web/src/globals.css：当前控制台设计。

搭建脚手架或更改运行时行为时，请阅读 development.md；开发 UI 时，请阅读 design.md；准备可分发仓库前，请阅读 publishing.md。

2. 搭建可独立构建的项目

使用 GitHub 模板，或者在已安装的 CLI 支持时使用：

bunx --bun @temps-sdk/cli plugin init my-plugin --name @your-scope/my-plugin

此命令只会搭建本地文件，不会发布。继续之前请检查生成的文件。替换占位的标识、作者、仓库、版本和描述；保持包元数据与运行时清单一致。只添加经过测试的平台。提交锁文件。不要将凭据、本地数据库、日志、身份验证资料和模拟器会话文件纳入 Git。

对于 GitHub 安装，可选择仓库根目录，或使用 --path 指定独立的插件子目录。使用 --ref 指定分支、标签或提交。验证干净检出的代码能通过主机安装器路径编译：不会自动运行生命周期脚本和自定义 UI 构建命令。嵌入资源相关影响请参阅发布参考文档。

3. 构建产品

使用 SDK 处理协议握手和传输。确保协议标准输出保持干净； 将诊断信息写入标准错误。使用经过验证的调用方上下文进行授权，使用类型化错误， 并将插件自有数据存储在分配给它的数据目录中。主机数据和由主机代理的 AI 均通过 SDK 获取，绝不要复制主机上的数据库或提供商凭据。

声明所需的最低主机权限，并明确处理配置缺失和授权被撤销的情况。 清单声明会申请权限；管理员负责授予权限。权限用于保护主机 API：原生插件仍以主机操作系统帐户的权限运行。 不要将已安装的插件描述为沙箱化插件。

为 UI 插件注册可发现的导航入口。采用选定的 Temps 设计规范， 嵌入资源，并测试其真实代理路径。对于部署自动化，订阅 deployment.succeeded，快速处理回执，并使用有界的持久化任务、 幂等性、取消机制以及明确的环境／项目设置。

4. 在三个层面验证 TypeScript 生命周期

1. 单元和集成检查： 成功、验证、失败、持久化／重启、 有界工作量以及相关安全场景。进行类型检查并编译实际二进制文件。
2. 本地插件模拟器： 实际二进制文件 + SDK 协议 + 模拟主机。测试侧边栏 UI、 事件传递、重复事件、权限被拒绝／授予／撤销以及角色限制。
3. 已安装的 Temps 实例： 安装经过审核的仓库版本，通过 Temps 打开插件，触发预期的用户工作流，更改权限，并更新 同一来源。验证持久化，并在支持的情况下验证相关的操作者／审计归属信息。

请阅读 development.md 了解模拟器命令。独立的 未经身份验证的 UI 预览只能证明布局正常。模拟器／模拟 AI 结果并不代表真实的提供商调用，也不代表完整的主机安装。收到事件并不能证明任务已完成。除非实际测试了已安装的工作流，否则不要声称端到端验证已完成； 如果无法使用该环境，请记录具体限制。

5. 分发、列出和维护 TypeScript 插件

默认工作流是 GitHub 仓库 → 审核后的源代码安装 → 目录 PR。 此路径不需要发布到 npm、云发布者令牌或注册表签名密钥。 请阅读 publishing.md 了解准确的元数据和安装示例。 plugin publish 是独立的原生 npm／签名目录流程，并非列出 GitHub 仓库的简写；仅在明确要求使用该分发渠道时才使用。

在执行外部发布步骤前，准备并验证所有构件。尊重用户现有的授权范围： 创建技能或构建插件本身并不表示用户要求公开发布到 npm、创建发布标签或安装到生产环境。当用户要求发布时，展示具体的仓库／版本／权限，并且仅执行该范围内的操作。切勿要求用户在聊天中粘贴凭据。

最后提供源代码位置、预览／安装说明、声明的权限、 验证证据、分发／目录状态以及剩余限制。更新时，保留稳定身份，审慎设置版本，安全迁移存储，并测试同一来源的升级。推送提交不会自动更新已安装的插件。