开发与工程 pull-requestgithub-actionsbranch-namingconventional-commitsissue-tracking

Engram PR 创建流程

为 Engram 仓库强制实施 issue 驱动的拉取请求工作流,确保每个 PR 都关联已批准的问题并符合严格的规范。

FollowSkills 评估 · FSRS-2.0
不推荐
54/ 100 五分制 2.7 / 5
1 2 3 4 5 6
1信任安全15 / 25 · 3.0/5

证据显示该技能为PR创建流程,不涉及敏感数据处理或高权限操作,没有发现攻击性行为。但技能依赖GitHub Actions和规则集强制执行,权限和确认机制在文件中未完整说明,例如未提及用户需要确认的内容或数据流透明度。扣分原因:缺少明确的权限和确认描述,以及数据流透明度不足。

2可靠稳定8 / 20 · 2.0/5

该技能指令自洽,但执行路径依赖外部GitHub Actions和规则集,此处为静态审查,无法验证实际执行。文件缺乏错误处理指南,例如当issue无approve标签时的处理。扣分原因:静态审查限制,且错误处理与故障反馈信息不足。

3适用触发10 / 15 · 3.3/5

该技能适用于明确的PR创建场景,触发条件清晰(创建PR时),但未明确声明不适用边界(例如非GitHub环境)。环境适应性方面,未提及中文支持或大陆网络可达性,但核心功能不依赖海外服务,GitHub本身可能受限。扣分原因:非适用边界未清晰,大陆网络可达性未考虑。

4规范维护12 / 15 · 4.0/5

文档结构清晰,有使用范围、工作流、命名规则、PR模板、自动化检查、提交规范等,信息层次分明。但缺少安装说明、参数变更历史、FAQ、已知限制和如何更新维护的说明。扣分原因:存在隐藏假设(如仓库已有模板和规则集),且版本和更新信息不完整。

5有效结果5 / 15 · 1.7/5

文档描述了完整的PR流程,但没有证据证明实际可以完成PR创建,且未提供输出样例或对比替代方案。静态审查下,无法验证是否真正有效。根据规定,静态审查有效性最高给7分,但此处缺少直接可用输出证据,故给5分。

6证据核验4 / 10 · 2.0/5

仓库内有CI工作流和测试命令,但未展示测试覆盖该技能关键路径的证据。技能本身没有版本发布记录或changelog。扣分原因:验证证据不足,仅部分间接证据支持。

证据充分度: 评估于 2026年8月7日 审查版本 509e6762fdd9
上游仓库在本次评估后已有新提交;当前评分仍对应所示审查版本,可能尚未覆盖最新改动。
使用前请注意
  • 该技能强依赖GitHub的Actions和规则集,若在非GitHub环境或无相应规则时可能无法正常工作。
  • 文档假设仓库已有PR模板和自动化检查,实际使用时需确认这些组件已配置。
  • GitHub服务在中国大陆可能无法直接访问,影响技能的环境适配性。
评估证据 [1][2][3][4][5][6][7]
查看完整评分方法 →

这个 Skill 能做什么,适合哪些场景?

此技能为 Engram 仓库定义了一套严格的 PR 创建流程,所有改动都必须先关联一个带有 'status:approved' 标签的 issue。它规定了严格的分支命名规范、PR 正文格式、类型标签以及五个必须通过的自动化检查。该技能还强制实施 Conventional Commits 提交信息格式,不匹配的提交将被 GitHub ruleset 拒绝。整个流程在 GitHub Actions 中强制执行,违反规则的 PR 会被阻止合并。

此技能指导创建符合 Engram 仓库要求的 PR:检查关联 issue 是否已批准、按规范命名分支(如 feat/*、fix/*)、运行本地单元与端到端测试、使用模板填写 PR 正文(包含链接 issue、唯一类型标签、变更表格、测试计划)、为 PR 添加一个 type:* 标签,并确保五个自动化检查全部通过。它同时强制要求 Conventional Commits 格式,其分支命名和提交信息格式由 GitHub ruleset 强制校验。

  1. 当开发者在 Engram 仓库中准备将新功能分支提交为 PR 时,此技能可确保分支名称符合规范的 feat/<description> 格式。
  2. 当开发者需要提交 bug 修复时,此技能可引导其创建 fix/ 分支并关联已批准 issue。
  3. 当贡献者首次向 Engram 提交代码时,此技能可帮助其避免因分支命名或缺少 type:* 标签而被自动化检查拒绝。
  4. 当维护者希望确保所有 PR 都遵循一致的规格时,此技能可作为团队的 PR 创建手册。

这个 Skill 有哪些优点和局限?

优点
  • 严格的自动化检查确保每个 PR 都有关联的已批准 issue,提高了变更可追溯性。
  • 规范化的分支命名和提交信息格式有助于保持仓库整洁。
  • 明确的 PR 模板和检查清单提高了协作效率。
  • 基于 GitHub Actions 和 ruleset 强制执行,一致性高。
局限
  • 流程完全针对 Engram 仓库定制,直接复用需要调整 issue 标签和检查名称。
  • 要求严格遵循规范,对于小改动或紧急修复可能显得繁琐。
  • 未提及对非 GitHub 平台的支持。
  • 文档未说明此 SKILL.md 仅适用于仓库内使用,外部项目需自行适配。

如何安装这个 Skill?

此技能是 Engram 仓库的一部分,位于 skills/branch-pr/ 目录下(实际文件为 skills/branch-pr/SKILL.md)。若要在其他项目中使用,可将此 SKILL.md 复制到项目的 .claude/skills/ 目录中,或直接用 Claude Code 引用该仓库。具体安装步骤在文档中未明确说明,但遵循标准的 Agent Skills 文件夹结构。

如何使用这个 Skill?

当需要创建 PR 时,在提示中包含类似“创建此变更的拉取请求”的触发词。技能将引导你检查 issue 批准状态、规范分支命名、本地测试、按模板填写 PR 正文并添加 type:* 标签。具体步骤:验证 issue 标签,创建分支(如 feat/my-feature),实施改动,运行 go test ./... 和 go test -tags e2e ./internal/server/...,git push,然后使用 gh pr create 并正确标注标题和正文,最后用 gh pr edit 添加标签。

常见问题

此技能可以用于非 Engram 仓库吗?
可以,但需要修改 issue 标签、分支模式、PR 模板和自动化检查的名称,以适应你的项目。
如果 PR 没有关联已批准 issue,会发生什么?
GitHub Actions 会阻止该 PR 合并,必须添加正确的 issue 引用并确保 issue 具有 'status:approved' 标签。
如何检查所有五个自动化检查是否通过?
在 PR 页面查看 CI 检查状态,每个检查必须为绿色。也可以本地运行测试以确保通过。

同仓库的其他 Skills

均来自 Gentleman-Programming/engram

相关 Skills