Compare commits
10 Commits
| Author | SHA1 | Date | |
|---|---|---|---|
| 07fa0b0038 | |||
| b1e93a323f | |||
| f214598470 | |||
| 5abe67f340 | |||
| 599d7cff48 | |||
| f1060f2a26 | |||
| 864c1a5e2b | |||
| 3e3d8c79ad | |||
| ba3d86553f | |||
| a5b56c09f5 |
@@ -1,4 +1,4 @@
|
|||||||
# OpenClaw 技能开发模板
|
# 匠厂 技能开发模板
|
||||||
|
|
||||||
这是一个**规范化的新技能模板仓库**,用于复制出新的 skill 项目;它本身**不是业务 skill**。
|
这是一个**规范化的新技能模板仓库**,用于复制出新的 skill 项目;它本身**不是业务 skill**。
|
||||||
|
|
||||||
@@ -17,9 +17,12 @@
|
|||||||
4. 在 `scripts/service/` 中补业务 service 与真正的发布/执行逻辑。
|
4. 在 `scripts/service/` 中补业务 service 与真正的发布/执行逻辑。
|
||||||
5. 用 `python scripts/main.py health` 和 `python scripts/main.py version` 做最小验证。
|
5. 用 `python scripts/main.py health` 和 `python scripts/main.py version` 做最小验证。
|
||||||
|
|
||||||
|
如果你的技能在平台里默认是非公开的(`access_scope = 0`),建议在 `SKILL.md` 的 `metadata.openclaw.developer_ids` 中填写开发者用户 ID 列表。这样发布后,平台会自动给这些开发者补可见权限,避免“技能已发布但开发者自己在市场中看不到”。
|
||||||
|
|
||||||
开发教程入口:
|
开发教程入口:
|
||||||
|
|
||||||
- [开发教程](references/DEVELOPMENT.md):给技术人员的完整开发步骤说明
|
- <a href="references/REQUIREMENTS.md" target="_blank" rel="noopener noreferrer">需求文档模板</a>:给技术人员编写和查看研发需求的标准模板
|
||||||
|
- <a href="references/DEVELOPMENT.md" target="_blank" rel="noopener noreferrer">开发教程</a>:给技术人员的完整开发步骤说明
|
||||||
|
|
||||||
## 目录说明
|
## 目录说明
|
||||||
|
|
||||||
@@ -45,3 +48,4 @@ python scripts/main.py version
|
|||||||
|
|
||||||
- 不要再往模板里引入旧式 `docs/` 或 `optional/` 目录。
|
- 不要再往模板里引入旧式 `docs/` 或 `optional/` 目录。
|
||||||
- 新技能若不需要某些目录,也建议先保留结构,再按实际业务填充内容。
|
- 新技能若不需要某些目录,也建议先保留结构,再按实际业务填充内容。
|
||||||
|
- `metadata.openclaw.developer_ids` 是发布元数据,不是用户展示文案。它的作用是让发布后的非公开技能自动授权给指定开发者查看。
|
||||||
|
|||||||
8
SKILL.md
8
SKILL.md
@@ -1,13 +1,16 @@
|
|||||||
---
|
---
|
||||||
name: 技能开发模板(复制后请修改)
|
name: 技能开发模板(复制后请修改)
|
||||||
description: "这是 OpenClaw 技能开发模板仓库,不直接作为业务技能发布。复制为新技能仓库后,按本模板替换 slug、名称、说明、CLI 子命令与 service 实现。"
|
description: "这是 OpenClaw 技能开发模板仓库,不直接作为业务技能发布。复制为新技能仓库后,按本模板替换 slug、名称、说明、CLI 子命令与 service 实现。"
|
||||||
version: 1.0.0
|
version: 1.0.13
|
||||||
author: 深圳匠厂科技有限公司
|
author: 深圳匠厂科技有限公司
|
||||||
metadata:
|
metadata:
|
||||||
openclaw:
|
openclaw:
|
||||||
slug: your-skill-slug
|
slug: your-skill-slug
|
||||||
emoji: "📦"
|
emoji: "📦"
|
||||||
category: "通用"
|
category: "通用"
|
||||||
|
developer_ids:
|
||||||
|
- 10032
|
||||||
|
- 12428
|
||||||
allowed-tools:
|
allowed-tools:
|
||||||
- bash
|
- bash
|
||||||
---
|
---
|
||||||
@@ -39,4 +42,7 @@ python {baseDir}/scripts/main.py version
|
|||||||
|
|
||||||
- 复制后请同步修改 `scripts/util/constants.py` 中的 `SKILL_SLUG` / `SKILL_VERSION`。
|
- 复制后请同步修改 `scripts/util/constants.py` 中的 `SKILL_SLUG` / `SKILL_VERSION`。
|
||||||
- 如技能无需持久化,可保留 `db/` 目录但不主动调用。
|
- 如技能无需持久化,可保留 `db/` 目录但不主动调用。
|
||||||
|
- `metadata.openclaw.developer_ids` 用于声明技能发布后的默认开发者可见用户 ID 列表。
|
||||||
|
- 当技能在平台中 `access_scope = 0`(不公开)时,发布流程会把 `developer_ids` 中的用户自动补写到 `skill_user_access`,使这些开发者仍可在技能市场中查看该技能。
|
||||||
|
- `developer_ids` 建议写为正整数数组;第一个 ID 会作为主开发者同步到 `skills.developer_id`。
|
||||||
- 面向用户与编排的文档写在 `references/`,不要再新增旧式 `docs/` / `optional/` 结构。
|
- 面向用户与编排的文档写在 `references/`,不要再新增旧式 `docs/` / `optional/` 结构。
|
||||||
|
|||||||
BIN
assets/screenshots/gitea-workflow-success.png
Normal file
BIN
assets/screenshots/gitea-workflow-success.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 32 KiB |
BIN
assets/screenshots/gitea-workflow-tab.png
Normal file
BIN
assets/screenshots/gitea-workflow-tab.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 69 KiB |
BIN
assets/screenshots/jc2009-download-page.png
Normal file
BIN
assets/screenshots/jc2009-download-page.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 49 KiB |
BIN
assets/screenshots/market-installed-skill.png
Normal file
BIN
assets/screenshots/market-installed-skill.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 79 KiB |
BIN
assets/screenshots/new-task-usage.png
Normal file
BIN
assets/screenshots/new-task-usage.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 26 KiB |
@@ -11,6 +11,68 @@
|
|||||||
|
|
||||||
如果你开发的是发布型 skill,这个模板就是直接可用的起点。
|
如果你开发的是发布型 skill,这个模板就是直接可用的起点。
|
||||||
|
|
||||||
|
## 推荐 AI 开发工具
|
||||||
|
|
||||||
|
当前 skill 开发建议尽量配合 AI 编程工具使用。这样做不是为了替代技术人员,而是为了提升以下环节的效率:
|
||||||
|
|
||||||
|
- 搭建标准目录结构
|
||||||
|
- 生成样板代码
|
||||||
|
- 理解旧项目代码
|
||||||
|
- 批量补文档、注释和测试
|
||||||
|
- 辅助排查报错与重构代码
|
||||||
|
|
||||||
|
建议团队统一选择 1 到 2 个主力工具长期使用,避免每个人工具链差异太大,导致协作方式不一致。
|
||||||
|
|
||||||
|
下面先列国外主流工具,再列国内主流工具。链接优先使用官方站点、官方文档或官方安装入口。
|
||||||
|
|
||||||
|
### 国外主流工具
|
||||||
|
|
||||||
|
| 工具 | 类型 | 适合场景 | 官方入口 |
|
||||||
|
|------|------|----------|----------|
|
||||||
|
| Cursor | 独立 AI IDE | 代码编辑、Agent 开发、整仓理解 | <a href="https://www.cursor.com/" target="_blank" rel="noopener noreferrer">官网</a> / <a href="https://www.cursor.com/downloads" target="_blank" rel="noopener noreferrer">下载</a> |
|
||||||
|
| Windsurf | 独立 AI IDE | Agent 编程、项目生成、连续开发流 | <a href="https://docs.codeium.com/windsurf" target="_blank" rel="noopener noreferrer">文档</a> / <a href="https://windsurf.com/download" target="_blank" rel="noopener noreferrer">下载</a> |
|
||||||
|
| GitHub Copilot | IDE 插件 / 编程助手 | 日常补全、解释代码、生成函数、配合 VS Code 或 JetBrains 使用 | <a href="https://github.com/copilot" target="_blank" rel="noopener noreferrer">官网</a> |
|
||||||
|
| Claude Code | 终端 / IDE 编程代理 | 命令行开发、代码库分析、自动改代码、运行命令 | <a href="https://www.anthropic.com/claude-code" target="_blank" rel="noopener noreferrer">官网</a> / <a href="https://docs.anthropic.com/en/docs/claude-code/" target="_blank" rel="noopener noreferrer">文档</a> |
|
||||||
|
| Codex | 终端 / IDE / Web 编程代理 | OpenAI 官方编码代理,适合代码生成、理解、调试、评审 | <a href="https://developers.openai.com/codex/" target="_blank" rel="noopener noreferrer">官网</a> / <a href="https://developers.openai.com/codex/quickstart" target="_blank" rel="noopener noreferrer">快速开始</a> |
|
||||||
|
| Aider | 终端 AI 编程工具 | 已有代码仓库的增量开发、终端协作、快速提交 | <a href="https://www.aider.chat/" target="_blank" rel="noopener noreferrer">官网</a> / <a href="https://aider.chat/docs/" target="_blank" rel="noopener noreferrer">文档</a> |
|
||||||
|
| Cline | VS Code / JetBrains 插件 | 编辑器内 Agent 开发、命令执行、浏览器联动调试 | <a href="https://cline.bot/" target="_blank" rel="noopener noreferrer">官网</a> / <a href="https://docs.cline.bot/introduction/welcome" target="_blank" rel="noopener noreferrer">文档</a> / <a href="https://marketplace.visualstudio.com/items?itemName=saoudrizwan.claude-dev" target="_blank" rel="noopener noreferrer">VS Code 插件</a> |
|
||||||
|
|
||||||
|
### 国内主流工具
|
||||||
|
|
||||||
|
| 工具 | 类型 | 适合场景 | 官方入口 |
|
||||||
|
|------|------|----------|----------|
|
||||||
|
| Trae | 独立 AI IDE | AI 辅助写代码、项目搭建、对话式开发 | <a href="https://www.trae.ai/home" target="_blank" rel="noopener noreferrer">官网</a> / <a href="https://www.trae.ai/download" target="_blank" rel="noopener noreferrer">下载</a> |
|
||||||
|
| 通义灵码 | 独立 IDE / IDE 插件 | 国内团队日常编码、问答、补全、代码生成 | <a href="https://tongyi.aliyun.com/lingma/?channel=yy_AiBot" target="_blank" rel="noopener noreferrer">官网</a> / <a href="https://tongyi.aliyun.com/lingma/download" target="_blank" rel="noopener noreferrer">下载</a> |
|
||||||
|
| CodeGeeX | IDE 插件 / 开源助手 | 代码补全、生成、注释、跨语言辅助 | <a href="https://github.com/zai-org/CodeGeeX" target="_blank" rel="noopener noreferrer">GitHub</a> / <a href="https://marketplace.visualstudio.com/items?itemName=aminer.codegeex" target="_blank" rel="noopener noreferrer">VS Code 插件</a> |
|
||||||
|
| 腾讯 CodeBuddy | IDE 插件 | 代码补全、测试生成、智能问答、腾讯云开发体系协作 | <a href="https://www.codebuddy.ai/" target="_blank" rel="noopener noreferrer">官网</a> / <a href="https://www.tencentcloud.com/document/product/1256" target="_blank" rel="noopener noreferrer">文档</a> / <a href="https://marketplace.visualstudio.com/items?itemName=Tencent-Cloud.coding-copilot" target="_blank" rel="noopener noreferrer">VS Code 插件</a> |
|
||||||
|
| 百度文心快码(Baidu Comate) | IDE 插件 | 国内研发团队辅助编码、解释、测试、优化 | <a href="https://comate.baidu.com/zh" target="_blank" rel="noopener noreferrer">官网</a> |
|
||||||
|
|
||||||
|
### 选型建议
|
||||||
|
|
||||||
|
如果你们团队主要做这类 Python skill 开发,我建议这样选:
|
||||||
|
|
||||||
|
- 想要一体化最强体验:优先试 `Cursor` 或 `Windsurf`
|
||||||
|
- 想要命令行深度协作:优先试 `Claude Code` 或 `Aider`
|
||||||
|
- 想继续基于 VS Code 插件体系:优先试 `GitHub Copilot`、`Cline`、`通义灵码`、`CodeBuddy`
|
||||||
|
- 想优先使用国内生态与中文支持:优先试 `Trae`、`通义灵码`、`CodeGeeX`、`CodeBuddy`、`文心快码`
|
||||||
|
|
||||||
|
### 团队落地建议
|
||||||
|
|
||||||
|
为了减少培训成本,建议内部至少统一一套主工具方案:
|
||||||
|
|
||||||
|
- 国外方案:`Cursor` + `Claude Code`
|
||||||
|
- 国内方案:`Trae` + `通义灵码`
|
||||||
|
- VS Code 插件方案:`GitHub Copilot` + `Cline`
|
||||||
|
|
||||||
|
不建议每位技术人员完全自由发挥,否则后续在:
|
||||||
|
|
||||||
|
- 提示词写法
|
||||||
|
- 代码修改习惯
|
||||||
|
- 调试方式
|
||||||
|
- 提交节奏
|
||||||
|
|
||||||
|
这些方面会越来越不统一。
|
||||||
|
|
||||||
## 1. 先理解模板的定位
|
## 1. 先理解模板的定位
|
||||||
|
|
||||||
`skill-template` 不是业务 skill,它只是一个**新 skill 仓库模板**。
|
`skill-template` 不是业务 skill,它只是一个**新 skill 仓库模板**。
|
||||||
@@ -124,6 +186,8 @@ scripts/
|
|||||||
- 平台内部键
|
- 平台内部键
|
||||||
- 日志 logger 名
|
- 日志 logger 名
|
||||||
|
|
||||||
|
此外,如果该技能发布后默认不公开(`access_scope = 0`),建议一开始就把 `SKILL.md` 中的 `metadata.openclaw.developer_ids` 配好。这样后续发布到平台时,开发者本人仍能在技能市场中看到并验证该技能。
|
||||||
|
|
||||||
## 5. 哪些占位内容必须替换
|
## 5. 哪些占位内容必须替换
|
||||||
|
|
||||||
复制后,至少要全局检查并替换下面这些内容:
|
复制后,至少要全局检查并替换下面这些内容:
|
||||||
@@ -150,9 +214,23 @@ scripts/
|
|||||||
|
|
||||||
- 技能名称
|
- 技能名称
|
||||||
- 技能描述
|
- 技能描述
|
||||||
- slug
|
- `slug`
|
||||||
- category
|
作用:技能的唯一英文标识,通常用于仓库名、发布包名、运行时目录名、平台主键匹配等
|
||||||
- dependencies
|
示例:`weibo-publisher`、`douyin-publisher`、`xiaohongshu-publisher`
|
||||||
|
- `category`
|
||||||
|
作用:技能在平台中的分类,用于市场展示与归类,不是代码内部键
|
||||||
|
示例:`通用`、`内容`、`办公协作`、`物流`、`抖音`、`小红书`
|
||||||
|
- `developer_ids`(如需给非公开技能自动补开发者可见权限)
|
||||||
|
作用:声明发布后默认拥有可见权限的开发者用户 ID 列表
|
||||||
|
- `dependencies`
|
||||||
|
作用:声明该技能依赖的兄弟技能或运行前置能力,便于平台或编排层识别依赖关系
|
||||||
|
示例:
|
||||||
|
```yaml
|
||||||
|
dependencies:
|
||||||
|
required:
|
||||||
|
- account-manager
|
||||||
|
- content-manager
|
||||||
|
```
|
||||||
- 何时使用本技能
|
- 何时使用本技能
|
||||||
- 对用户的引导话术
|
- 对用户的引导话术
|
||||||
- CLI 使用原则
|
- CLI 使用原则
|
||||||
@@ -164,6 +242,33 @@ scripts/
|
|||||||
- 代码注释
|
- 代码注释
|
||||||
- `service/` 实现里
|
- `service/` 实现里
|
||||||
|
|
||||||
|
### 关于 `metadata.openclaw.developer_ids`
|
||||||
|
|
||||||
|
这是一个平台发布元数据字段,用于解决下面这个问题:
|
||||||
|
|
||||||
|
- 技能发布后若平台记录中的 `access_scope = 0`,技能默认不公开
|
||||||
|
- 如果不额外授权,连开发者自己也可能在技能市场里看不到这个技能
|
||||||
|
|
||||||
|
因此可以在 `SKILL.md` 中声明:
|
||||||
|
|
||||||
|
```yaml
|
||||||
|
metadata:
|
||||||
|
openclaw:
|
||||||
|
slug: your-skill-slug
|
||||||
|
category: 通用
|
||||||
|
developer_ids:
|
||||||
|
- 1032
|
||||||
|
- 12428
|
||||||
|
```
|
||||||
|
|
||||||
|
约定如下:
|
||||||
|
|
||||||
|
- 只允许填写正整数用户 ID
|
||||||
|
- 推荐使用数组,即使当前只有 1 个开发者
|
||||||
|
- 发布时平台会把这些用户自动补写到 `skill_user_access`
|
||||||
|
- 第一个 ID 会同步到 `skills.developer_id`
|
||||||
|
- 一期只做“补授权”,不会因为你 later 修改数组而自动撤销旧授权
|
||||||
|
|
||||||
## 7. `references/` 应该放什么
|
## 7. `references/` 应该放什么
|
||||||
|
|
||||||
`references/` 是当前规范 skill 的文档中心,建议至少有这些:
|
`references/` 是当前规范 skill 的文档中心,建议至少有这些:
|
||||||
@@ -288,27 +393,27 @@ scripts/
|
|||||||
3. 用子进程调用
|
3. 用子进程调用
|
||||||
4. 机器可读输出优先 JSON
|
4. 机器可读输出优先 JSON
|
||||||
|
|
||||||
## 13. 如何开发发布型 skill
|
## 13. 如何开发一个新 skill
|
||||||
|
|
||||||
如果你开发的是 publisher 类 skill,建议按这个顺序做:
|
不管你开发的是发布类、采集类、分析类还是知识库类 skill,建议都先按下面这个顺序推进:
|
||||||
|
|
||||||
1. 先把目录结构搭完整
|
1. 先把目录结构搭完整
|
||||||
2. 先让 `health` / `version` 跑通
|
2. 先让 `health` / `version` 跑通
|
||||||
3. 再让 `publish_service.py` 的骨架跑通
|
3. 再把核心 `service` 骨架跑通
|
||||||
4. 再接 `sibling_bridge.py`
|
4. 再接兄弟技能桥接、数据库或外部系统
|
||||||
5. 最后再写 `*_playwright.py`
|
5. 最后再补浏览器自动化、复杂流程编排或高风险集成
|
||||||
|
|
||||||
不要一开始就直接写页面选择器。
|
不要一开始就直接写页面选择器、复杂接口编排或深层业务逻辑。
|
||||||
|
|
||||||
推荐先确保这些基础能力正常:
|
推荐先确保这些基础能力正常:
|
||||||
|
|
||||||
- 能取到账号
|
- CLI 入口能跑通
|
||||||
- 能取到文章
|
- 基础命令输出稳定
|
||||||
- 能写日志
|
- 关键依赖能取到
|
||||||
- CLI 子命令通了
|
- 日志或本地状态能落下来
|
||||||
- 错误返回值格式定好了
|
- 错误返回值格式定好了
|
||||||
|
|
||||||
然后再进浏览器自动化。
|
如果你的 skill 恰好是 publisher 类,可以把上面的“核心 `service`”具体落成 `publish_service.py`,再逐步接 `sibling_bridge.py`、`*_playwright.py`。但这只是示例,不代表模板只适合发布类技能。
|
||||||
|
|
||||||
## 14. 本地开发的最小验证顺序
|
## 14. 本地开发的最小验证顺序
|
||||||
|
|
||||||
@@ -325,12 +430,19 @@ python scripts/main.py version
|
|||||||
|
|
||||||
```bash
|
```bash
|
||||||
python scripts/main.py -h
|
python scripts/main.py -h
|
||||||
python scripts/main.py publish -h
|
python scripts/main.py <your-command> -h
|
||||||
```
|
```
|
||||||
|
|
||||||
### 3. 验证本地日志与数据库
|
### 3. 验证本地日志与数据库
|
||||||
|
|
||||||
如果是发布型 skill,再继续:
|
如果你的 skill 需要本地日志或数据库,再继续:
|
||||||
|
|
||||||
|
```bash
|
||||||
|
python scripts/main.py <your-log-command>
|
||||||
|
python scripts/main.py <your-detail-command> <id>
|
||||||
|
```
|
||||||
|
|
||||||
|
如果你沿用了模板中的发布型骨架,那么这里可以具体对应成:
|
||||||
|
|
||||||
```bash
|
```bash
|
||||||
python scripts/main.py logs
|
python scripts/main.py logs
|
||||||
@@ -342,10 +454,119 @@ python scripts/main.py log-get 1
|
|||||||
比如:
|
比如:
|
||||||
|
|
||||||
```bash
|
```bash
|
||||||
python scripts/main.py publish
|
python scripts/main.py <your-command>
|
||||||
```
|
```
|
||||||
|
|
||||||
## 15. 发布前检查清单
|
## 15. 发布到正式环境验证
|
||||||
|
|
||||||
|
当本地开发、自测和联调完成后,还需要把 skill 发布到正式环境做一次完整验证。建议技术人员严格按下面顺序执行,不要跳步。
|
||||||
|
|
||||||
|
### 第一步:在 skill 根目录执行 `release.ps1`
|
||||||
|
|
||||||
|
在当前 skill 仓库根目录执行:
|
||||||
|
|
||||||
|
```powershell
|
||||||
|
.\release.ps1
|
||||||
|
```
|
||||||
|
|
||||||
|
如果你的技能使用了 `metadata.openclaw.developer_ids`,那么这一步触发的发布工作流除了同步 `skills` / `skill_versions` 外,还会在平台侧自动补开发者可见权限。测试非公开技能时,建议重点验证这部分是否生效。
|
||||||
|
|
||||||
|
这一步会自动完成标准发布动作,包括:
|
||||||
|
|
||||||
|
1. 检查当前仓库状态
|
||||||
|
2. 自动提交尚未提交的改动
|
||||||
|
3. 推送最新代码到远程仓库
|
||||||
|
4. 自动创建新的语义化版本 tag
|
||||||
|
5. 推送 tag,触发后续 CI 流程
|
||||||
|
|
||||||
|
如果你只是想先预览发布动作,可以先执行:
|
||||||
|
|
||||||
|
```powershell
|
||||||
|
.\release.ps1 -DryRun
|
||||||
|
```
|
||||||
|
|
||||||
|
### 第二步:到 Gitea 仓库查看工作流
|
||||||
|
|
||||||
|
发布命令执行完成后,远程仓库会自动触发 Gitea 工作流。此时应立即进入对应 skill 的仓库页面,切换到“工作流”页签查看执行状态。
|
||||||
|
|
||||||
|
重点确认:
|
||||||
|
|
||||||
|
- 是否已经出现最新一次发布记录
|
||||||
|
- 是否由最新提交触发
|
||||||
|
- 是否成功执行完 `release_skill.yaml`
|
||||||
|
|
||||||
|
下面这张图演示了在仓库页进入“工作流”的位置:
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
下面这张图演示了工作流成功后的状态页面:
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
### 第三步:确认工作流执行成功
|
||||||
|
|
||||||
|
只有当工作流状态为成功,才说明正式发布产物已经正确构建完成。
|
||||||
|
|
||||||
|
如果工作流失败,不要继续做平台验证,而应该先回到代码仓库排查,例如:
|
||||||
|
|
||||||
|
- 发布脚本是否正常推送
|
||||||
|
- `SKILL.md`、`scripts/`、`references/` 是否齐全
|
||||||
|
- 工作流文件是否存在
|
||||||
|
- 发布包结构是否符合模板规范
|
||||||
|
|
||||||
|
### 第四步:进入匠厂平台下载安装包
|
||||||
|
|
||||||
|
当工作流成功后,就可以进入匠厂平台验证最终安装效果。
|
||||||
|
|
||||||
|
匠厂产品下载地址:
|
||||||
|
|
||||||
|
- [https://jc2009.com/product.html](https://jc2009.com/product.html)
|
||||||
|
|
||||||
|
打开页面后,下载并安装匠厂客户端。下面这张图演示了下载入口位置:
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
匠厂产品页可从这里进入:[产品下载 - 匠厂](https://jc2009.com/product.html)
|
||||||
|
|
||||||
|
### 第五步:安装匠厂后,在技能市场检查最新 skill
|
||||||
|
|
||||||
|
安装并启动匠厂后,进入左侧“技能市场”,搜索或查找刚刚发布的 skill,确认以下内容:
|
||||||
|
|
||||||
|
- 技能可以被正常检索到
|
||||||
|
- 技能名称、说明、版本信息正确
|
||||||
|
- 最新版本已经同步出来
|
||||||
|
- 可以正常安装或更新
|
||||||
|
|
||||||
|
下面这张图演示了在技能市场中查看已发布 skill 的位置:
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
### 第六步:安装并实际启用该 skill
|
||||||
|
|
||||||
|
在技能市场中找到目标 skill 后,执行安装或更新操作,确保客户端本地已经拿到最新版本。
|
||||||
|
|
||||||
|
这一步建议至少确认:
|
||||||
|
|
||||||
|
- 安装按钮可以正常执行
|
||||||
|
- 安装后状态正常
|
||||||
|
- 不会出现缺文件、缺入口或安装失败的问题
|
||||||
|
|
||||||
|
### 第七步:在“新建任务”中实际使用该 skill
|
||||||
|
|
||||||
|
安装完成后,不要只停留在“已安装”状态,还需要进入“新建任务”页面,真正调用一次该 skill,完成最终验证。
|
||||||
|
|
||||||
|
建议至少验证:
|
||||||
|
|
||||||
|
- 新任务中可以正常选择或触发该 skill
|
||||||
|
- skill 能被正确唤起
|
||||||
|
- 主要命令或主流程可以运行
|
||||||
|
- 返回结果、日志和行为符合预期
|
||||||
|
|
||||||
|
下面这张图演示了安装后在任务界面中实际使用 skill 的场景:
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
## 16. 发布前检查清单
|
||||||
|
|
||||||
每个新 skill 发布前,建议技术人员逐条确认:
|
每个新 skill 发布前,建议技术人员逐条确认:
|
||||||
|
|
||||||
@@ -360,7 +581,7 @@ python scripts/main.py publish
|
|||||||
- [ ] `release.ps1` 存在
|
- [ ] `release.ps1` 存在
|
||||||
- [ ] `.github/workflows/release_skill.yaml` 存在
|
- [ ] `.github/workflows/release_skill.yaml` 存在
|
||||||
|
|
||||||
## 16. 常见错误
|
## 17. 常见错误
|
||||||
|
|
||||||
### 错误 1:只改了目录名,没改 slug
|
### 错误 1:只改了目录名,没改 slug
|
||||||
|
|
||||||
@@ -413,7 +634,7 @@ python scripts/main.py publish
|
|||||||
- 不做旧结构兼容
|
- 不做旧结构兼容
|
||||||
- 统一走 `references/` + `scripts/main.py`
|
- 统一走 `references/` + `scripts/main.py`
|
||||||
|
|
||||||
## 17. 推荐开发顺序总结
|
## 18. 推荐开发顺序总结
|
||||||
|
|
||||||
如果让一个新人照着做,我建议他按这个顺序:
|
如果让一个新人照着做,我建议他按这个顺序:
|
||||||
|
|
||||||
@@ -427,7 +648,7 @@ python scripts/main.py publish
|
|||||||
8. 再做业务联调
|
8. 再做业务联调
|
||||||
9. 最后 release
|
9. 最后 release
|
||||||
|
|
||||||
## 18. 这份模板的底线要求
|
## 19. 这份模板的底线要求
|
||||||
|
|
||||||
以后新建 skill,至少要满足这几点:
|
以后新建 skill,至少要满足这几点:
|
||||||
|
|
||||||
|
|||||||
@@ -17,10 +17,26 @@ description: "这是规范化的新技能模板说明,不直接作为业务技
|
|||||||
## 复制后你需要改什么
|
## 复制后你需要改什么
|
||||||
|
|
||||||
- `SKILL.md` 中的名称、描述、slug、触发说明
|
- `SKILL.md` 中的名称、描述、slug、触发说明
|
||||||
|
- `SKILL.md` 中 `metadata.openclaw.developer_ids`(如需让非公开技能默认授权给开发者查看)
|
||||||
- `references/CLI.md` 里的命令示例
|
- `references/CLI.md` 里的命令示例
|
||||||
- `scripts/util/constants.py` 中的 slug / 版本 / logger 名
|
- `scripts/util/constants.py` 中的 slug / 版本 / logger 名
|
||||||
- `scripts/service/` 下的真实业务实现
|
- `scripts/service/` 下的真实业务实现
|
||||||
|
|
||||||
|
## `developer_ids` 是做什么的
|
||||||
|
|
||||||
|
`metadata.openclaw.developer_ids` 是平台发布元数据,不是终端用户文案。
|
||||||
|
|
||||||
|
它用于声明:当技能发布后,如果平台侧将该技能设置为 `access_scope = 0`(不公开),哪些开发者用户仍应自动获得可见权限。
|
||||||
|
|
||||||
|
约定如下:
|
||||||
|
|
||||||
|
- 字段位置:`SKILL.md` -> `metadata.openclaw.developer_ids`
|
||||||
|
- 推荐格式:正整数数组,例如 `[1032, 12428]`
|
||||||
|
- 发布效果:发布接口会把这些用户补写到 `skill_user_access`
|
||||||
|
- 第一个 ID 会作为主开发者同步到 `skills.developer_id`
|
||||||
|
|
||||||
|
如果你的技能本来就是公开技能,或暂时不需要开发者专属可见性,这个字段可以留空数组。
|
||||||
|
|
||||||
## 不建议再保留的旧结构
|
## 不建议再保留的旧结构
|
||||||
|
|
||||||
- 旧模板里的 `docs/`
|
- 旧模板里的 `docs/`
|
||||||
|
|||||||
338
references/REQUIREMENTS.md
Normal file
338
references/REQUIREMENTS.md
Normal file
@@ -0,0 +1,338 @@
|
|||||||
|
# 技能需求文档模板
|
||||||
|
|
||||||
|
这份文档用于给技术人员、产品人员和实施人员统一描述某个 skill 的研发需求。
|
||||||
|
|
||||||
|
建议原则:
|
||||||
|
|
||||||
|
- 一个 skill 对应一份主需求文档
|
||||||
|
- 需求先写清楚,再进入开发
|
||||||
|
- 文档描述“要做什么”和“做到什么程度”,不要在这里堆实现细节
|
||||||
|
- 实现方式、代码结构、发布流程,分别放到 `DEVELOPMENT.md`、`CLI.md`、`SCHEMA.md`、`RUNTIME.md`
|
||||||
|
|
||||||
|
如果你是从 `skill-template` 复制新技能,请复制本文件后,把下面所有占位内容替换成你的真实项目内容。
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# REQUIREMENTS
|
||||||
|
|
||||||
|
## 1. 文档目标
|
||||||
|
|
||||||
|
说明这份需求文档的作用,以及它解决什么问题。
|
||||||
|
|
||||||
|
模板写法:
|
||||||
|
|
||||||
|
- 本文档用于明确 `【技能名称】` 的研发范围、交付标准、依赖关系和验收要求。
|
||||||
|
- 技术人员应以本文件作为开发范围依据,以避免实现偏差、范围蔓延或理解不一致。
|
||||||
|
|
||||||
|
示例:
|
||||||
|
|
||||||
|
- 本文档用于明确 `weibo-publisher` 的研发需求,约束该 skill 的功能边界、输入输出和验收标准,作为开发、测试和上线验证的统一依据。
|
||||||
|
|
||||||
|
## 2. 业务背景
|
||||||
|
|
||||||
|
说明为什么要做这个 skill,它服务什么业务场景,解决什么实际问题。
|
||||||
|
|
||||||
|
模板写法:
|
||||||
|
|
||||||
|
- 当前业务场景中,用户需要在 `【目标平台】` 完成 `【业务动作】`。
|
||||||
|
- 现有流程主要依赖人工处理,存在 `【效率低 / 容易出错 / 不可批量 / 不可追踪】` 等问题。
|
||||||
|
- 因此需要开发 `【技能名称】`,将该流程标准化、自动化,并接入匠厂技能体系中。
|
||||||
|
|
||||||
|
示例:
|
||||||
|
|
||||||
|
- 当前内容运营团队需要将内容库中的文章批量发布到微博平台,但人工登录后台、复制文章、填写标题和确认发布的流程效率较低,且不便于统一记录发布历史。
|
||||||
|
- 因此需要开发 `weibo-publisher`,用于把内容库文章按规范发布到微博平台,并记录发布结果,支持后续排查与复用。
|
||||||
|
|
||||||
|
## 3. 开发目标
|
||||||
|
|
||||||
|
说明本次开发希望最终交付什么结果。
|
||||||
|
|
||||||
|
模板写法:
|
||||||
|
|
||||||
|
- 完成 `【技能名称】` 的标准目录结构搭建
|
||||||
|
- 完成 CLI 入口与基础命令
|
||||||
|
- 完成核心业务流程
|
||||||
|
- 完成与兄弟技能或外部系统的必要集成
|
||||||
|
- 完成正式环境发布验证
|
||||||
|
|
||||||
|
示例:
|
||||||
|
|
||||||
|
- 完成 `weibo-publisher` 的标准 skill 结构建设
|
||||||
|
- 提供 `health`、`version`、`publish`、`logs`、`log-get` 等命令
|
||||||
|
- 支持从兄弟技能读取账号与文章,并执行微博发布流程
|
||||||
|
- 支持记录发布日志,并可在正式环境中安装验证
|
||||||
|
|
||||||
|
## 4. 功能范围
|
||||||
|
|
||||||
|
说明这次开发明确要实现哪些功能。
|
||||||
|
|
||||||
|
模板写法:
|
||||||
|
|
||||||
|
- 支持 `【命令1】`
|
||||||
|
- 支持 `【命令2】`
|
||||||
|
- 支持读取 `【数据来源】`
|
||||||
|
- 支持执行 `【核心业务动作】`
|
||||||
|
- 支持记录 `【日志 / 状态 / 结果】`
|
||||||
|
|
||||||
|
建议将功能拆成“必须实现”和“可后续扩展”。
|
||||||
|
|
||||||
|
示例:
|
||||||
|
|
||||||
|
### 必须实现
|
||||||
|
|
||||||
|
- 支持 `python scripts/main.py health`
|
||||||
|
- 支持 `python scripts/main.py version`
|
||||||
|
- 支持 `python scripts/main.py publish`
|
||||||
|
- 支持从 `account-manager` 获取可用账号
|
||||||
|
- 支持从 `content-manager` 获取待发布文章
|
||||||
|
- 支持执行微博后台发布流程
|
||||||
|
- 支持写入发布日志
|
||||||
|
|
||||||
|
### 可后续扩展
|
||||||
|
|
||||||
|
- 支持定时发布
|
||||||
|
- 支持失败自动重试
|
||||||
|
- 支持多账号轮询发布
|
||||||
|
|
||||||
|
## 5. 非功能要求
|
||||||
|
|
||||||
|
说明除功能外,对稳定性、可维护性、目录规范、日志、编码等方面的要求。
|
||||||
|
|
||||||
|
模板写法:
|
||||||
|
|
||||||
|
- 目录结构必须符合当前 skill 模板规范
|
||||||
|
- 入口必须统一为 `scripts/main.py`
|
||||||
|
- 输出格式应尽量机读友好
|
||||||
|
- 错误前缀统一为 `ERROR:`
|
||||||
|
- Windows 环境下需保证 UTF-8 输出兼容
|
||||||
|
- 必须具备基本日志能力
|
||||||
|
|
||||||
|
示例:
|
||||||
|
|
||||||
|
- 项目结构必须对齐 `skill-template`
|
||||||
|
- CLI 入口统一使用 `scripts/main.py`
|
||||||
|
- 关键执行结果应可通过 JSON 或固定文本结构返回
|
||||||
|
- 发布日志必须可追踪
|
||||||
|
- 不允许重新引入旧模板中的 `docs/`、`optional/` 或 `scripts/skill_main.py`
|
||||||
|
|
||||||
|
## 6. 输入输出要求
|
||||||
|
|
||||||
|
说明这个 skill 接收什么输入,产出什么输出。
|
||||||
|
|
||||||
|
模板写法:
|
||||||
|
|
||||||
|
### 输入
|
||||||
|
|
||||||
|
- `【输入参数1】`
|
||||||
|
- `【输入参数2】`
|
||||||
|
- `【依赖系统返回的数据】`
|
||||||
|
|
||||||
|
### 输出
|
||||||
|
|
||||||
|
- `【标准输出】`
|
||||||
|
- `【错误输出】`
|
||||||
|
- `【数据库记录】`
|
||||||
|
- `【日志文件】`
|
||||||
|
|
||||||
|
示例:
|
||||||
|
|
||||||
|
### 输入
|
||||||
|
|
||||||
|
- `account_id`:可选,指定发布账号
|
||||||
|
- `article_id`:可选,指定发布文章
|
||||||
|
- `account-manager` 返回的账号信息
|
||||||
|
- `content-manager` 返回的文章信息
|
||||||
|
|
||||||
|
### 输出
|
||||||
|
|
||||||
|
- 发布成功时返回成功结果
|
||||||
|
- 发布失败时返回 `ERROR:` 或 `FAIL:` 前缀的错误信息
|
||||||
|
- 在本地数据库中写入 `publish_logs`
|
||||||
|
- 在日志目录中写入执行日志
|
||||||
|
|
||||||
|
## 7. 依赖的兄弟技能或外部系统
|
||||||
|
|
||||||
|
说明开发该 skill 时依赖哪些内部技能或外部平台。
|
||||||
|
|
||||||
|
模板写法:
|
||||||
|
|
||||||
|
### 兄弟技能依赖
|
||||||
|
|
||||||
|
- `【skill-a】`:作用是 `【用途】`
|
||||||
|
- `【skill-b】`:作用是 `【用途】`
|
||||||
|
|
||||||
|
### 外部系统依赖
|
||||||
|
|
||||||
|
- `【平台名】`:作用是 `【用途】`
|
||||||
|
- `【浏览器 / API / 第三方服务】`:作用是 `【用途】`
|
||||||
|
|
||||||
|
示例:
|
||||||
|
|
||||||
|
### 兄弟技能依赖
|
||||||
|
|
||||||
|
- `account-manager`:提供账号信息
|
||||||
|
- `content-manager`:提供文章数据
|
||||||
|
|
||||||
|
### 外部系统依赖
|
||||||
|
|
||||||
|
- 微博后台:目标发布平台
|
||||||
|
- Chromium / Chrome / Edge:用于浏览器自动化
|
||||||
|
- Gitea:用于代码托管和发布工作流
|
||||||
|
- 匠厂客户端:用于正式环境安装与验证
|
||||||
|
|
||||||
|
## 8. 不在本次范围内的内容
|
||||||
|
|
||||||
|
这一节非常重要,用来明确本次“不做什么”,避免研发越做越散。
|
||||||
|
|
||||||
|
模板写法:
|
||||||
|
|
||||||
|
- 本次不实现 `【功能A】`
|
||||||
|
- 本次不处理 `【平台B】`
|
||||||
|
- 本次不做 `【高级能力】`
|
||||||
|
- 本次不兼容 `【旧结构 / 旧逻辑】`
|
||||||
|
|
||||||
|
示例:
|
||||||
|
|
||||||
|
- 本次不实现多平台统一发布
|
||||||
|
- 本次不实现定时任务调度
|
||||||
|
- 本次不实现自动重试机制
|
||||||
|
- 本次不兼容旧模板中的历史目录结构
|
||||||
|
|
||||||
|
## 9. 验收标准
|
||||||
|
|
||||||
|
说明什么情况下才算真正开发完成。
|
||||||
|
|
||||||
|
模板写法:
|
||||||
|
|
||||||
|
- 代码结构符合模板规范
|
||||||
|
- 最小命令可运行
|
||||||
|
- 核心命令可运行
|
||||||
|
- 正式环境可安装
|
||||||
|
- 匠厂中可看到最新版本
|
||||||
|
- 可以在新建任务中实际使用
|
||||||
|
|
||||||
|
示例:
|
||||||
|
|
||||||
|
- `health`、`version` 命令执行正常
|
||||||
|
- `publish` 主流程可运行
|
||||||
|
- 发布后 Gitea 工作流成功
|
||||||
|
- 匠厂技能市场能看到最新版本
|
||||||
|
- skill 可以正常安装
|
||||||
|
- 安装后可在“新建任务”中调用
|
||||||
|
|
||||||
|
## 10. 开发注意事项
|
||||||
|
|
||||||
|
说明研发过程中必须特别注意的事项。
|
||||||
|
|
||||||
|
模板写法:
|
||||||
|
|
||||||
|
- 不要修改无关 skill
|
||||||
|
- 不要破坏现有模板规范
|
||||||
|
- 优先遵守目录和分层约定
|
||||||
|
- 不要在 CLI 层堆业务逻辑
|
||||||
|
- 发布前必须先做本地最小验证
|
||||||
|
|
||||||
|
示例:
|
||||||
|
|
||||||
|
- 只允许修改当前 skill 仓库,不要改动其他兄弟项目
|
||||||
|
- 如使用浏览器自动化,优先复用已验证过的定位器和流程
|
||||||
|
- `cli` 只做参数解析,核心逻辑统一放到 `service`
|
||||||
|
- 发布前必须完成本地验证、工作流验证和正式环境安装验证
|
||||||
|
|
||||||
|
## 11. 变更记录
|
||||||
|
|
||||||
|
这一节用于记录需求文档本身的变化,不是 git 提交记录的替代,而是给技术人员看“需求范围怎么变了”。
|
||||||
|
|
||||||
|
模板写法:
|
||||||
|
|
||||||
|
| 日期 | 版本 | 变更人 | 变更内容 |
|
||||||
|
|------|------|--------|----------|
|
||||||
|
| 2026-04-13 | v1.0 | 张三 | 初版需求文档 |
|
||||||
|
| 2026-04-14 | v1.1 | 李四 | 增加正式环境验收要求 |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 建议使用方式
|
||||||
|
|
||||||
|
建议每个新 skill 开发时,按下面顺序使用文档:
|
||||||
|
|
||||||
|
1. 先写 `references/REQUIREMENTS.md`
|
||||||
|
2. 再按 `references/DEVELOPMENT.md` 进入开发
|
||||||
|
3. 开发过程中补充 `CLI.md`、`SCHEMA.md`、`RUNTIME.md`
|
||||||
|
4. 发布前回到 `REQUIREMENTS.md` 对照验收标准逐项检查
|
||||||
|
|
||||||
|
## 最小模板示例
|
||||||
|
|
||||||
|
下面给出一个可直接参考的简化版示例:
|
||||||
|
|
||||||
|
```md
|
||||||
|
# REQUIREMENTS
|
||||||
|
|
||||||
|
## 1. 文档目标
|
||||||
|
|
||||||
|
本文档用于明确 `weibo-publisher` 的研发需求、范围和验收标准,作为开发与测试的统一依据。
|
||||||
|
|
||||||
|
## 2. 业务背景
|
||||||
|
|
||||||
|
运营团队需要将内容库中的文章发布到微博平台,现有人工操作效率低,且缺少统一的发布记录。
|
||||||
|
|
||||||
|
## 3. 开发目标
|
||||||
|
|
||||||
|
- 完成 `weibo-publisher` 的标准 skill 结构
|
||||||
|
- 支持文章发布主流程
|
||||||
|
- 支持发布日志记录
|
||||||
|
|
||||||
|
## 4. 功能范围
|
||||||
|
|
||||||
|
- 支持 `health`
|
||||||
|
- 支持 `version`
|
||||||
|
- 支持 `publish`
|
||||||
|
- 支持查询发布日志
|
||||||
|
|
||||||
|
## 5. 非功能要求
|
||||||
|
|
||||||
|
- 入口统一为 `scripts/main.py`
|
||||||
|
- 保持 UTF-8 输出
|
||||||
|
- 结构符合 skill 模板规范
|
||||||
|
|
||||||
|
## 6. 输入输出要求
|
||||||
|
|
||||||
|
### 输入
|
||||||
|
|
||||||
|
- `account_id`
|
||||||
|
- `article_id`
|
||||||
|
|
||||||
|
### 输出
|
||||||
|
|
||||||
|
- 成功结果
|
||||||
|
- 错误信息
|
||||||
|
- 发布日志记录
|
||||||
|
|
||||||
|
## 7. 依赖的兄弟技能或外部系统
|
||||||
|
|
||||||
|
- `account-manager`
|
||||||
|
- `content-manager`
|
||||||
|
- 微博后台
|
||||||
|
|
||||||
|
## 8. 不在本次范围内的内容
|
||||||
|
|
||||||
|
- 不实现定时发布
|
||||||
|
- 不实现自动重试
|
||||||
|
|
||||||
|
## 9. 验收标准
|
||||||
|
|
||||||
|
- 命令可运行
|
||||||
|
- 能完成正式环境安装验证
|
||||||
|
- 能在新建任务中使用
|
||||||
|
|
||||||
|
## 10. 开发注意事项
|
||||||
|
|
||||||
|
- 不修改无关项目
|
||||||
|
- 不引入旧模板结构
|
||||||
|
|
||||||
|
## 11. 变更记录
|
||||||
|
|
||||||
|
| 日期 | 版本 | 变更人 | 变更内容 |
|
||||||
|
|------|------|--------|----------|
|
||||||
|
| 2026-04-13 | v1.0 | 张三 | 初版 |
|
||||||
|
```
|
||||||
@@ -1,5 +1,5 @@
|
|||||||
"""技能标识与版本(复制后请修改)。"""
|
"""技能标识与版本(复制后请修改)。"""
|
||||||
|
|
||||||
SKILL_SLUG = "your-skill-slug"
|
SKILL_SLUG = "your-skill-slug"
|
||||||
SKILL_VERSION = "1.0.0"
|
SKILL_VERSION = "1.0.13"
|
||||||
LOG_LOGGER_NAME = "openclaw.skill.your_skill_slug"
|
LOG_LOGGER_NAME = "openclaw.skill.your_skill_slug"
|
||||||
|
|||||||
Reference in New Issue
Block a user