by 安全扫描
OpenClaw
可疑
high confidence该技能基本兑现承诺（读取 GitHub Project 板并发布 Release Notes），但包元数据、运行说明与脚本对凭据来源描述不一致，且额外包含 webhook 配置，可能导致意外存储密钥或向外部发布。
评估建议
安装或运行前请注意：
- 需要具备仓库写入与项目访问权限的 GitHub Personal Access Token (PAT)，但注册元数据未声明，运行时可能要求输入或从 references/config.yaml 读取。
- 示例 references/config.yaml 可能诱导用户明文粘贴 PAT，长期令牌落地风险高；建议使用短时令牌或交互输入，避免落盘或入版本库。
- 代码与说明与功能一致（读取 ProjectV2、PR、提交、README、创建 Release），但 references/config.yaml 中未在 SKILL.md 说明的 Discord webhook 字段存在，需确认脚本是否向该地址发送数据，防止意外外泄。
- 默认以 --dry-run 运行，先完整阅读 generate_release_notes.py，确认输出目的地及是否调用 webhook。
- 限制 PAT 范围与生命周期（仅授予所需仓库最小写入权限），并监控其使用；若无法验证令牌用途或数据去向，请勿提供 PAT。
- 建议发布者更新注册元数据声明所需凭据，并明确 webhook...详细分析 ▾
⚠ 用途与能力
技能声明用途（读取 GitHub Project 板、按仓库整理发布说明并创建 GitHub Release）与所含 Python 脚本一致，脚本使用 GitHub GraphQL 与 REST API。但注册元数据未声明所需凭据，而 SKILL.md 明确需要 GitHub PAT，脚本亦期望从 references/config.yaml 读取 PAT，存在显著不一致。
ℹ 指令范围
SKILL.md 指示代理查询 Projects v2、读取 PR、提交、README 与文档，均符合声明目的。指令还引用本地参考文件 github-queries.md 与 contributor-scoring.md，文件均存在。注意：文档未提及可选 Discord webhook，但 references/config.yaml 包含 webhook_url 字段，可能引入 SKILL.md 未描述的外部端点。
✓ 安装机制
未提供安装规范（仅指令），所含脚本为纯 Python/bash。Python 脚本依赖库 'requests'，属常规需求。无任意 URL 下载或包管理器安装行为。
⚠ 凭证需求
技能需 GitHub PAT（含仓库与项目权限）才能发布 Release，SKILL.md 指定所需范围为 'repo'、'read:org'、'project'，权限合理。但注册条目未列出所需环境变量或主凭据，掩盖了对高权限令牌的需求。此外，references/config.yaml 包含可选 Discord webhook 字段；若代码调用该地址，明文存储的 PAT 或发布数据可能被外发。
✓ 持久化与权限
技能未标记 always:true，也未申请系统级持久化。附带的运行脚本默认以 --dry-run 执行，无证据表明其会修改其他技能或全局代理配置。
安全有层次，运行前请审查代码。
运行时依赖
无特殊依赖
版本
latestv1.0.12026/4/9
版本 1.0.1 - 新增 _meta.json 以提供包元数据。 - 更新 scripts/generate_release_notes.py 进行改进或修复。 - 无面向用户的工作流变更；更新主要为内部/结构层面。
● 无害
安装命令
点击复制官方npx clawhub@latest install sprint-release-notes
镜像加速npx clawhub@latest install sprint-release-notes --registry https://cn.longxiaskill.com镜像同步中
技能文档
从 GitHub Project Board（v2）读取已完成的条目，读取相关文档，评估贡献者表现，并将精美的 markdown 发布到指定仓库，生成可直接呈交给高层的 Sprint Release Notes。
必需输入
开始前请向用户收集以下信息：- GitHub Project Board URL — 例如
https://github.com/orgs/{org}/projects/{number}或https://github.com/users/{user}/projects/{number} - GitHub PAT Token — 必须具备以下权限：
repo、read:org、project（Projects v2 读取权限） - Sprint identifier（可选）——如未提供，则自动检测当前/最近完成的迭代
若缺少任何一项，请先询问用户再继续。
工作流概览
技能按 7 个阶段顺序执行：- 发现 Sprint — 查询 Project Board 获取当前 sprint 迭代
- 条目分类 — 将条目分为已完成与延期/遗留，并按仓库分组
- 深度读取已完成条目 — 读取关联仓库的文档、PR、提交
- 评估贡献者 — 为工程师打分，评选 Lead Engineer 与 MVP
- 按仓库编译发布说明 — 为每个仓库生成独立 markdown
- 发布到对应仓库 — 以 GitHub Release 形式创建或更新（按 tag），不作为 docs/ 下文件
- （可选）在项目 Issue 中贴汇总 — 在指定 issue 下评论总结链接
阶段 1：发现 Sprint
完整 GraphQL 查询请见： `` view /path/to/skill/references/github-queries.md `
使用用户 PAT 调用 GitHub GraphQL API (https://api.github.com/graphql)。 步骤 1.1：从看板 URL 获取 project ID
- 从 URL 提取 org/user 与 project number
通过organization.projectV2(number: N)或user.projectV2(number: N)查询 project node ID
步骤 1.2：获取迭代字段
查询项目字段，找到 iteration 类型字段（通常叫 "Sprint" 或 "Iteration"）- 根据日期范围选出当前迭代（包含今天）或最近完成的迭代
步骤 1.3：拉取当前 sprint 所有条目
按迭代字段值过滤项目条目- 提取：标题、状态、关联仓库、相关 PR/Issue、标签、指派人
阶段 2：条目分类 & 按仓库分组
将条目分为：
- 已完成：状态为 "Done"/"Closed" 或等效
- 遗留：sprint 内未完成（移至下一 sprint）
- 已修复 Bug：标签含 "bug" 且已完成
按仓库分组：
- 根据项目条目的关联 PR 获取仓库名
建立映射：Map>每个仓库将生成独立的 GitHub Release（同一份 sprint markdown 作为 releasebody）
同时提取元数据：
sprint 名称/编号（来自迭代字段）- sprint 起止日期
版本号格式v1.{sprint_number}.0
阶段 3：深度读取已完成条目
为每个已完成条目收集上下文。 完整 API 模式请见：
` view /path/to/skill/references/github-queries.md `
3a. PR 描述与提交
通过时间线或交叉引用找到关联 PR- 读取 PR 描述（常含最佳上下文）
- 读取合并 PR 的提交信息
3b. 文档变更
检查 PR 是否修改/docs、README.md等路径- 如有文档更新，抓取新内容以理解功能
使用 GitHub Contents API：GET /repos/{owner}/{repo}/contents/{path}
3c. README 文件
仅对每个唯一仓库抓取一次根目录README.md，并缓存
3d. 标签与元数据
收集标签用于分类：feature、bug、infrastructure、security、performance、tech-debt- 无标签时，根据 PR 标题/描述推断
发布说明章节分类启发式：
标签含 "feature"/"enhancement"/"user-facing" → 新用户功能- 标签含 "infra"/"tech-debt"/"performance"/"security"/"devops"/"scalability" → 基础设施与技术债
- 标签含 "bug"/"fix"/"hotfix" → 稳定性与 Bug 修复
- 无标签时，用 PR 标题/描述推断
阶段 4：评估贡献者
为每位完成条目的贡献者打分。评分规则见：
` view /path/to/skill/references/contributor-scoring.md ` 收集指标：
- PR 合并数 — 来自已完成条目的关联 PR
- 代码复杂度 — 用 PR 增删行数近似（additions + deletions）
- 评审贡献 — 使用 PR reviews API 统计给他人评审数
- Bug 修复 — 统计标签为 "bug" 且指派给该用户的完成条目
- 挑战分 — 根据标签（如 "complex"/"critical"）、story points 或描述长度估算难度
评分公式：
` Score = (PRs_merged × 2) + (lines_changed / 100) + (reviews_given × 3) + (bugs_fixed × 4) + (challenge_score × 5) `
Lead Engineer：总分最高（广度与深度并重）- MVP：在最难单项上得分最高，或 Bug 修复影响最大（解决最棘手问题的无名英雄）
若分差在 10% 以内，可并列提及。 阶段 5：按仓库编译发布说明
为每个仓库组生成独立文档，使用下方模板（直接作为 GitHub Release body）。 仓库映射：
- 收集所有唯一仓库名
- 为每个仓库过滤其已完成条目
- 每仓库一份 markdown
使用以下模板，替换所有 [占位符]。若某节无内容，写 "本期无变更。" 而非删除该节。
# 🚀 Sprint Release Notes: [Sprint 名称/编号] - [仓库名]
日期： [YYYY-MM-DD] | 版本： v1.[sprint_number].0 | 状态： 已发布 | 仓库： [repo_name]
🎯 摘要
[2-3 句话：本期该仓库的主要目标是什么？交付了什么？]
✨ 新功能
[Issue 标题]：[变更简述]。
🛠️ 基础设施与技术债
[Issue 标题]：[完成的工作说明]。
🐛 Bug 修复
[Issue 标题]：[修复说明]。
📊 已完成条目
- [ ] #[issue_number] [issue_title]
Generated from GitHub Project Board - Sprint [sprint_name]
阶段 6：发布到对应仓库（GitHub Releases）
对每个有已完成条目的仓库，将 sprint markdown 作为该仓库的 Release（出现在 Releases 页面 / releases/latest），而非仓库树中的文件。 步骤 6.1：根据 sprint 推导 release tag 与 name（同阶段 2）：
Tag 名 与 Release 名：v1.[sprint_number].0
步骤 6.2：检查该 tag 是否已存在 release：
` GET /repos/{owner}/{repo}/releases/tags/v1.[sprint_number].0 `
若返回 404，则创建新 release（步骤 6.3）若返回 releaseid，则更新（步骤 6.4）
步骤 6.3：创建新 release（若 tag 尚不存在，会在默认分支自动创建）：
` POST /repos/{owner}/{repo}/releases `
JSON 体（最小集）：
- tag_name
:v1.[sprint_number].0 target_commitish: 仓库默认分支（如main）name: 同tag_name（或用户指定的简短 sprint 标题）body: 阶段 5 生成的完整 markdowndraft:falseprerelease:false
步骤 6.4：更新已有 release 的说明与标题标记：
` PATCH /repos/{owner}/{repo}/releases/{release_id} `
示例（curl；使用用户 PAT 与 API 版本头）：
curl -L -X PATCH \
-H "Accept: application/vnd.github+json" \
-H "Authorization: Bearer YOUR_TOKEN" \
-H "X-GitHub-Api-Version: 2026-03-10" \
https://api.github.com/repos/OWNER/REPO/releases/RELEASE_ID \
-d '{
"name": "v1.2.3",
"body": "Updated release notes",
"draft": false,
"prerelease": false
}'
步骤 6.5：记录每个仓库的 html_url，用于阶段 7 及向用户汇总。
注意：
PAT 需具备创建 release 与推送 tag 权限（私有仓库需repo权限）。REST 调用优先使用Authorization: Bearer与Accept: application/vnd.github+json；使用日历版本 API 时加X-GitHub-Api-Version。若仓库禁止自动创建 tag，可在外部先创建 tag（或草稿 release），再仅 PATCH 其body。
阶段 7：（可选）在项目 Issue 中贴汇总
若用户指定了汇总目标 issue： 步骤 7.1：收集所有已发布 release 的 URL（来自创建/更新响应的 html_url）。
步骤 7.2：使用 GitHub Issues API 添加评论：
` POST /repos/{owner}/{repo}/issues/{issue_number}/comments `
评论模板：
## 🚀 Sprint [sprint_number] Release Notes Published Release notes have been published to each repository’s Releases:
Repository Release [repo_1] [release_link_1] [repo_2] [release_link_2] ... ...
Generated automatically from GitHub Project Board*
步骤 7.3：确认成功，并向用户返回所有已发布链接。
错误处理
- 限流：若 GitHub API 返回 403 且含限流头，等待并重试，并告知用户。
权限不足：若项目查询 404，通常 PAT 缺少project范围，提示用户所需权限。- 空 sprint：若当前迭代无条目，告知用户并询问是否检查其他 sprint。
- 无关联 PR：部分条目可能无关联 PR，使用条目标题/描述作为最佳可用上下文。
- 无关联仓库：若条目未关联仓库，使用默认仓库或询问用户。
- 大 sprint：若条目 >50，分批调用 API 并分组汇总，避免超出上下文限制。
- 发布失败：若创建/更新 release 失败（权限、tag 策略等），继续处理其他仓库，最后统一报告失败。
重要说明
- 项目看板查询始终使用 GitHub GraphQL API（REST 对 Projects v2 支持不佳）。
- 读取仓库内容、PR 详情及 Releases 创建/更新使用 REST API。
- 缓存仓库 README —— 同一 README 不重复抓取。
- PAT 为敏感信息 —— 绝不打印、回显或写入输出文件。
所有 API 调用均指向https://api.github.com` —— 确保网络可达。