docs: add requirements template

README.md

@@ -1,4 +1,4 @@
-# OpenClaw 技能开发模板
+# 匠厂 技能开发模板
 
 这是一个**规范化的新技能模板仓库**，用于复制出新的 skill 项目；它本身**不是业务 skill**。
 

references/DEVELOPMENT.md

@@ -345,7 +345,114 @@ python scripts/main.py log-get 1
 python scripts/main.py publish
 ```
 
-## 15. 发布前检查清单
+## 15. 发布到正式环境验证
+
+当本地开发、自测和联调完成后，还需要把 skill 发布到正式环境做一次完整验证。建议技术人员严格按下面顺序执行，不要跳步。
+
+### 第一步：在 skill 根目录执行 `release.ps1`
+
+在当前 skill 仓库根目录执行：
+
+```powershell
+.\release.ps1
+```
+
+这一步会自动完成标准发布动作，包括：
+
+1. 检查当前仓库状态
+2. 自动提交尚未提交的改动
+3. 推送最新代码到远程仓库
+4. 自动创建新的语义化版本 tag
+5. 推送 tag，触发后续 CI 流程
+
+如果你只是想先预览发布动作，可以先执行：
+
+```powershell
+.\release.ps1 -DryRun
+```
+
+### 第二步：到 Gitea 仓库查看工作流
+
+发布命令执行完成后，远程仓库会自动触发 Gitea 工作流。此时应立即进入对应 skill 的仓库页面，切换到“工作流”页签查看执行状态。
+
+重点确认：
+
+- 是否已经出现最新一次发布记录
+- 是否由最新提交触发
+- 是否成功执行完 `release_skill.yaml`
+
+下面这张图演示了在仓库页进入“工作流”的位置：
+
+![Gitea 仓库工作流入口](../assets/screenshots/gitea-workflow-tab.png)
+
+下面这张图演示了工作流成功后的状态页面：
+
+![Gitea 工作流成功示例](../assets/screenshots/gitea-workflow-success.png)
+
+### 第三步：确认工作流执行成功
+
+只有当工作流状态为成功，才说明正式发布产物已经正确构建完成。
+
+如果工作流失败，不要继续做平台验证，而应该先回到代码仓库排查，例如：
+
+- 发布脚本是否正常推送
+- `SKILL.md`、`scripts/`、`references/` 是否齐全
+- 工作流文件是否存在
+- 发布包结构是否符合模板规范
+
+### 第四步：进入匠厂平台下载安装包
+
+当工作流成功后，就可以进入匠厂平台验证最终安装效果。
+
+匠厂产品下载地址：
+
+- [https://jc2009.com/product.html](https://jc2009.com/product.html)
+
+打开页面后，下载并安装匠厂客户端。下面这张图演示了下载入口位置：
+
+![匠厂客户端下载入口](../assets/screenshots/jc2009-download-page.png)
+
+匠厂产品页可从这里进入：[产品下载 - 匠厂](https://jc2009.com/product.html)
+
+### 第五步：安装匠厂后，在技能市场检查最新 skill
+
+安装并启动匠厂后，进入左侧“技能市场”，搜索或查找刚刚发布的 skill，确认以下内容：
+
+- 技能可以被正常检索到
+- 技能名称、说明、版本信息正确
+- 最新版本已经同步出来
+- 可以正常安装或更新
+
+下面这张图演示了在技能市场中查看已发布 skill 的位置：
+
+![技能市场中的已发布技能](../assets/screenshots/market-installed-skill.png)
+
+### 第六步：安装并实际启用该 skill
+
+在技能市场中找到目标 skill 后，执行安装或更新操作，确保客户端本地已经拿到最新版本。
+
+这一步建议至少确认：
+
+- 安装按钮可以正常执行
+- 安装后状态正常
+- 不会出现缺文件、缺入口或安装失败的问题
+
+### 第七步：在“新建任务”中实际使用该 skill
+
+安装完成后，不要只停留在“已安装”状态，还需要进入“新建任务”页面，真正调用一次该 skill，完成最终验证。
+
+建议至少验证：
+
+- 新任务中可以正常选择或触发该 skill
+- skill 能被正确唤起
+- 主要命令或主流程可以运行
+- 返回结果、日志和行为符合预期
+
+下面这张图演示了安装后在任务界面中实际使用 skill 的场景：
+
+![新建任务中使用技能](../assets/screenshots/new-task-usage.png)
+
+## 16. 发布前检查清单
 
 每个新 skill 发布前，建议技术人员逐条确认：
 
@@ -360,7 +467,7 @@ python scripts/main.py publish
 - [ ] `release.ps1` 存在
 - [ ] `.github/workflows/release_skill.yaml` 存在
 
-## 16. 常见错误
+## 17. 常见错误
 
 ### 错误 1：只改了目录名，没改 slug
 
@@ -413,7 +520,7 @@ python scripts/main.py publish
 - 不做旧结构兼容
 - 统一走 `references/` + `scripts/main.py`
 
-## 17. 推荐开发顺序总结
+## 18. 推荐开发顺序总结
 
 如果让一个新人照着做，我建议他按这个顺序：
 
@@ -427,7 +534,7 @@ python scripts/main.py publish
 8. 再做业务联调
 9. 最后 release
 
-## 18. 这份模板的底线要求
+## 19. 这份模板的底线要求
 
 以后新建 skill，至少要满足这几点：
 

references/REQUIREMENTS.md

@@ -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 | 张三 | 初版 |
+```