尧图网站建设 
用 Commit Message Storyteller 写出有故事的提交信息awesome-copilot 的叙事式 Conventional Commits 技能实战【免费下载链接】awesome-copilotCommunity-contributed instructions, agents, skills, and configurations to help you make the most of GitHub Copilot.项目地址: https://gitcode.com/GitHub_Trending/aw/awesome-copilot导读本篇文章聚焦 awesome-copilot 仓库中的commit-message-storyteller技能它能把原始的git diff或口头变更描述转化为遵循 Conventional Commits 规范、强调为什么改而非改了什么的叙事式提交信息。读完本文你将掌握该技能的完整调用流程、提交类型判定表、三部分提交结构主题行/正文/脚注、多提交拆分启发式与边界情况处理并了解它与仓库中gitmoji、conventional-commit等兄弟技能的分工差异。技能定位从改了文件到讲了故事commit-message-storyteller的核心主张在 skills/commit-message-storyteller/SKILL.md 开头就说得非常直白它将原始 git diff 和变更描述转化为清晰、故事驱动的提交信息目标不是产出update file.js这类流水账而是让每条提交信息传达意图intent、上下文context与影响impact。这份技能文件遵循 Agent Skills 规范docs/README.skills.md 说明每个技能是包含SKILL.md指令文件与配套资源的独立文件夹按需渐进式加载配套资源为references/conventional-commits-guide.md——一份可随时查证的 Conventional Commits 速查手册供模型在生成信息时参考完整类型示例与 scope 规范。何时启用该技能SKILL.md的 frontmatter 中定义了技能的触发条件与描述明确列出以下典型场景用户说 write a commit message、help me commit 或 generate a commit用户直接粘贴一段git diff或口头描述代码变更用户问 what should I commit this as? 或 summarize my diff用户希望为团队或开源项目维护更高质量的提交历史用户正准备提交 Pull Request需要有意义的提交信息该技能可从三种输入工作git diff或git diff --staged的输出、对改了什么以及为什么改的描述、以及修改文件列表。前置准备获取变更上下文使用前至少准备以下其中一种输入git diff或git diff --staged的输出一段对变更内容及原因的说明一份修改文件清单技能在Quick Reference中给出了获取 diff 的标准命令这是本仓库其他提交类技能如 skills/gitmoji/SKILL.md 与 skills/git-commit/SKILL.md也共同采用的习惯# 获取已暂存staged的变更粘贴给 Copilot git diff --staged # 或获取工作区中尚未提交的变更 git diff四步生成流程第一步收集变更上下文技能要求先明确三件事可由用户提供也可从 diff 中自动推断改了什么—— 受影响的文件、函数与逻辑为什么改—— bug 修复、新功能、重构、性能优化等谁/什么触发了这次改动—— issue 编号、用户请求、技术债等如果用户只提供原始git diff则应从 diff 中自动提取这些上下文而非反复追问。第二步判定提交类型将变更映射到 Conventional Commits 的类型SKILL.md给出完整判定表TypeUse WhenfeatA new feature or capability is addedfixA bug or incorrect behavior is correctedrefactorCode restructured without changing behaviorperfA change that improves performancedocsDocumentation only changesstyleFormatting, whitespace, missing semicolons (no logic change)testAdding or updating testschoreBuild process, dependency updates, config changesciCI/CD pipeline changesrevertReverting a previous commit详细示例见 references/conventional-commits-guide.md。需要注意的是该类型表与仓库中 skills/git-commit/SKILL.md 的类型表大体一致但后者额外列出了build类型构建系统/依赖变更这提醒使用者团队约定决定了类型集合引用速查手册时以项目实际采用的规范为准。第三步按三部分结构撰写提交信息生成的信息遵循如下结构type(optional scope): short imperative summary body — the story: why this change was made, what problem it solves footer — issue refs, breaking change notices主题行第一行规则使用祈使语气add、fix、remove而不是added或fixes最多 72 个字符末尾不加句号冒号后小写开头正文故事部分规则解释为什么why而不是什么what——diff 已经展示了改了什么描述变更前存在的问题如相关可提及考虑过的备选方案每行控制在 100 字符以内与主题行之间用空行分隔脚注规则引用 issueCloses #123、Fixes #456、Refs #789标记破坏性变更BREAKING CHANGE: description关于破坏性变更references/conventional-commits-guide.md 补充了两种等价写法——在类型后用!如feat(api)!: remove v1 endpoints或在脚注中写BREAKING CHANGE:段落二者可并用。第四步生成输出在可复制的代码块中产出提交信息随后用一行通俗英语说明你讲述的故事。SKILL.md给出的示例输出fix(auth): prevent token refresh loop on expired sessions When a users session expired mid-request, the auth middleware was triggering a token refresh, which itself failed validation and triggered another refresh — causing an infinite retry loop that crashed the app. This adds a recursion guard flag that aborts the refresh cycle if a refresh is already in progress, returning a clean 401 instead. Closes #312Story told:A silent infinite loop on session expiry was crashing the app; this stops the cycle early and returns a clean error.注意这个示例的精妙之处主题行fix(auth): prevent token refresh loop on expired sessions是一句完整的祈使句正文讲述之前为什么崩溃、这次如何修复脚注Closes #312关联 issue。这正是讲故事与流水账的分水岭。一个 diff 拆成多个提交当 diff 包含逻辑上彼此独立的变更时技能要求拆分成多条提交信息并明确告知用户。启发式判断如下用途无关的不同文件 → 很可能应拆成多个提交同一文件但关注点不同例如 bug 修复 重构→ 建议拆分各部分紧密耦合 → 一个提交即可这一原则与 skills/git-commit/SKILL.md 的 Best PracticesOne logical change per commit一次提交只包含一个逻辑变更相互印证也与 references/conventional-commits-guide.md 反模式表里misc changes应拆分成独立有意义的提交的建议一致。边界情况处理表SituationHow to Handle用户只给了 diff、无其他上下文从文件名和变更符号推断类型与 scope变更横跨大量文件且主题不明询问这是一个逻辑变更还是多个检测到破坏性变更自动添加BREAKING CHANGE:脚注用户说 keep it short省略正文只写一个有力的主题行没有 issue 编号完全省略脚注配套速查手册Conventional Commits 参考指南references/conventional-commits-guide.md是技能自带的验证与扩充实操素材核心内容包括格式定义type(scope): description [optional body] [optional footer(s)]完整类型示例含 scope、正文与脚注速查手册为每个类型都配了带故事正文的完整示例包括feat(payments)Apple Pay 支持、fix(api)分页偏移 off-by-one 错误、refactor(user-service)抽取共享校验工具、perf(dashboard)图表懒加载、docs(readme)、test(auth)、chore(deps)eslint 升级、ciGitHub Actions 缓存、revert等。Scope 指南scope 可选但强烈推荐应是标识代码库区域的短名词auth、api、dashboard、payments在项目内保持一致不要混用user和users当改动真正全局性时可省略。正文写作技巧写正文前自问三个问题——这次改动前什么坏了/缺失了、为什么选择这个方案而非其他、对用户或开发者来说改动后有何不同同时避免复述 diff 已展示的内容如改了个变量名、避免模糊语言various improvements以及避免将来时this will fix...应使用现在/过去时。提交信息反模式对照表❌ Bad✅ Betterfix bugfix(cart): prevent duplicate items on rapid add-to-cart clicksupdatesfeat(profile): allow users to update display nameWIPDont commit WIP — stash itmisc changesSplit into separate, meaningful commitsJohns changesDescribe what changed, not who changed it与仓库内其他提交类技能的协同在 awesome-copilot 仓库中围绕提交信息存在多个互补技能理解分工有助于按场景选择skills/gitmoji/SKILL.md按 gitmoji 约定生成带 emoji 的提交信息仅生成消息不执行 git 命令。其文档明确写道如果项目遵循纯 Conventional Commitsfeat:、fix:...而无 emoji应使用conventional-commit或commit-message-storyteller技能不确定时先让用户提供git log --oneline -10。skills/conventional-commit/SKILL.md面向一键执行提交的场景用结构化 XML 模板构造提交信息并由 Copilot 直接在集成终端运行git commit -m type(scope): description。skills/git-commit/SKILL.md可执行git commit的完整工作流技能包含 diff 分析、智能暂存与 Git 安全协议不更新 git config、不做破坏性操作、不跳过 hooks、不强制推送主干等。而commit-message-storyteller的独特价值在于叙事深度它默认不执行 git 命令产出可复制的消息 一行故事说明专精于把 diff 背后的为什么讲清楚——是四者中最适合提升开源项目与团队提交历史可读性的选择。如何安装与使用该技能依据 docs/README.skills.md 的说明该技能可通过 GitHub CLI 安装gh skills install github/awesome-copilot commit-message-storyteller需 GitHub CLI v2.90.0 及以上版本或将skills/commit-message-storyteller文件夹手动复制到本地技能目录。安装后在提示中引用技能名或让 Agent 根据上述触发场景自动发现即可。技能的结构本身也经受仓库工程化校验eng/validate-skills.mjs会检查每个技能目录的SKILL.md存在性、frontmatter 中name/description的合法性、文件夹名与技能名一致以及捆绑资源大小上限5MB。commit-message-storyteller的 frontmatter 与配套资源references/conventional-commits-guide.md正符合该校验标准可直接作为自定义技能的编写范本。实践要点速览输入即素材优先让用户粘贴git diff --staged模型自动提取改了什么、为什么、谁触发的。类型先于措辞先用上文的 10 类型判定表定基调再动笔写句子。主题行是一句话的承诺祈使语气 ≤72 字符 不带句号如perf(dashboard): lazy-load chart components。正文只讲 whydiff 已经给出 what正文聚焦之前的问题 修复思路 备选方案。脚注承载可追溯性Closes #xxx关 issueBREAKING CHANGE:标记破坏性变更。宁可拆分不可杂糅逻辑独立的变更拆成多条提交并告知用户。尊重团队约定项目若用 gitmoji 走 skills/gitmoji/SKILL.md若需一键执行走 skills/conventional-commit/SKILL.md讲故事则用本技能。【免费下载链接】awesome-copilotCommunity-contributed instructions, agents, skills, and configurations to help you make the most of GitHub Copilot.项目地址: https://gitcode.com/GitHub_Trending/aw/awesome-copilot创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 用 Commit Message Storyteller 写出有故事的提交信息：awesome-copilot 的叙事式 Conventional Commits 技能实战
用 Commit Message Storyteller 写出有故事的提交信息awesome-copilot 的叙事式 Conventional Commits 技能实战【免费下载链接】awesome-copilotCommunity-contributed instructions, agents, skills, and configurations to help you make the most of GitHub Copilot.项目地址: https://gitcode.com/GitHub_Trending/aw/awesome-copilot导读本篇文章聚焦 awesome-copilot 仓库中的commit-message-storyteller技能它能把原始的git diff或口头变更描述转化为遵循 Conventional Commits 规范、强调为什么改而非改了什么的叙事式提交信息。读完本文你将掌握该技能的完整调用流程、提交类型判定表、三部分提交结构主题行/正文/脚注、多提交拆分启发式与边界情况处理并了解它与仓库中gitmoji、conventional-commit等兄弟技能的分工差异。技能定位从改了文件到讲了故事commit-message-storyteller的核心主张在 skills/commit-message-storyteller/SKILL.md 开头就说得非常直白它将原始 git diff 和变更描述转化为清晰、故事驱动的提交信息目标不是产出update file.js这类流水账而是让每条提交信息传达意图intent、上下文context与影响impact。这份技能文件遵循 Agent Skills 规范docs/README.skills.md 说明每个技能是包含SKILL.md指令文件与配套资源的独立文件夹按需渐进式加载配套资源为references/conventional-commits-guide.md——一份可随时查证的 Conventional Commits 速查手册供模型在生成信息时参考完整类型示例与 scope 规范。何时启用该技能SKILL.md的 frontmatter 中定义了技能的触发条件与描述明确列出以下典型场景用户说 write a commit message、help me commit 或 generate a commit用户直接粘贴一段git diff或口头描述代码变更用户问 what should I commit this as? 或 summarize my diff用户希望为团队或开源项目维护更高质量的提交历史用户正准备提交 Pull Request需要有意义的提交信息该技能可从三种输入工作git diff或git diff --staged的输出、对改了什么以及为什么改的描述、以及修改文件列表。前置准备获取变更上下文使用前至少准备以下其中一种输入git diff或git diff --staged的输出一段对变更内容及原因的说明一份修改文件清单技能在Quick Reference中给出了获取 diff 的标准命令这是本仓库其他提交类技能如 skills/gitmoji/SKILL.md 与 skills/git-commit/SKILL.md也共同采用的习惯# 获取已暂存staged的变更粘贴给 Copilot git diff --staged # 或获取工作区中尚未提交的变更 git diff四步生成流程第一步收集变更上下文技能要求先明确三件事可由用户提供也可从 diff 中自动推断改了什么—— 受影响的文件、函数与逻辑为什么改—— bug 修复、新功能、重构、性能优化等谁/什么触发了这次改动—— issue 编号、用户请求、技术债等如果用户只提供原始git diff则应从 diff 中自动提取这些上下文而非反复追问。第二步判定提交类型将变更映射到 Conventional Commits 的类型SKILL.md给出完整判定表TypeUse WhenfeatA new feature or capability is addedfixA bug or incorrect behavior is correctedrefactorCode restructured without changing behaviorperfA change that improves performancedocsDocumentation only changesstyleFormatting, whitespace, missing semicolons (no logic change)testAdding or updating testschoreBuild process, dependency updates, config changesciCI/CD pipeline changesrevertReverting a previous commit详细示例见 references/conventional-commits-guide.md。需要注意的是该类型表与仓库中 skills/git-commit/SKILL.md 的类型表大体一致但后者额外列出了build类型构建系统/依赖变更这提醒使用者团队约定决定了类型集合引用速查手册时以项目实际采用的规范为准。第三步按三部分结构撰写提交信息生成的信息遵循如下结构type(optional scope): short imperative summary body — the story: why this change was made, what problem it solves footer — issue refs, breaking change notices主题行第一行规则使用祈使语气add、fix、remove而不是added或fixes最多 72 个字符末尾不加句号冒号后小写开头正文故事部分规则解释为什么why而不是什么what——diff 已经展示了改了什么描述变更前存在的问题如相关可提及考虑过的备选方案每行控制在 100 字符以内与主题行之间用空行分隔脚注规则引用 issueCloses #123、Fixes #456、Refs #789标记破坏性变更BREAKING CHANGE: description关于破坏性变更references/conventional-commits-guide.md 补充了两种等价写法——在类型后用!如feat(api)!: remove v1 endpoints或在脚注中写BREAKING CHANGE:段落二者可并用。第四步生成输出在可复制的代码块中产出提交信息随后用一行通俗英语说明你讲述的故事。SKILL.md给出的示例输出fix(auth): prevent token refresh loop on expired sessions When a users session expired mid-request, the auth middleware was triggering a token refresh, which itself failed validation and triggered another refresh — causing an infinite retry loop that crashed the app. This adds a recursion guard flag that aborts the refresh cycle if a refresh is already in progress, returning a clean 401 instead. Closes #312Story told:A silent infinite loop on session expiry was crashing the app; this stops the cycle early and returns a clean error.注意这个示例的精妙之处主题行fix(auth): prevent token refresh loop on expired sessions是一句完整的祈使句正文讲述之前为什么崩溃、这次如何修复脚注Closes #312关联 issue。这正是讲故事与流水账的分水岭。一个 diff 拆成多个提交当 diff 包含逻辑上彼此独立的变更时技能要求拆分成多条提交信息并明确告知用户。启发式判断如下用途无关的不同文件 → 很可能应拆成多个提交同一文件但关注点不同例如 bug 修复 重构→ 建议拆分各部分紧密耦合 → 一个提交即可这一原则与 skills/git-commit/SKILL.md 的 Best PracticesOne logical change per commit一次提交只包含一个逻辑变更相互印证也与 references/conventional-commits-guide.md 反模式表里misc changes应拆分成独立有意义的提交的建议一致。边界情况处理表SituationHow to Handle用户只给了 diff、无其他上下文从文件名和变更符号推断类型与 scope变更横跨大量文件且主题不明询问这是一个逻辑变更还是多个检测到破坏性变更自动添加BREAKING CHANGE:脚注用户说 keep it short省略正文只写一个有力的主题行没有 issue 编号完全省略脚注配套速查手册Conventional Commits 参考指南references/conventional-commits-guide.md是技能自带的验证与扩充实操素材核心内容包括格式定义type(scope): description [optional body] [optional footer(s)]完整类型示例含 scope、正文与脚注速查手册为每个类型都配了带故事正文的完整示例包括feat(payments)Apple Pay 支持、fix(api)分页偏移 off-by-one 错误、refactor(user-service)抽取共享校验工具、perf(dashboard)图表懒加载、docs(readme)、test(auth)、chore(deps)eslint 升级、ciGitHub Actions 缓存、revert等。Scope 指南scope 可选但强烈推荐应是标识代码库区域的短名词auth、api、dashboard、payments在项目内保持一致不要混用user和users当改动真正全局性时可省略。正文写作技巧写正文前自问三个问题——这次改动前什么坏了/缺失了、为什么选择这个方案而非其他、对用户或开发者来说改动后有何不同同时避免复述 diff 已展示的内容如改了个变量名、避免模糊语言various improvements以及避免将来时this will fix...应使用现在/过去时。提交信息反模式对照表❌ Bad✅ Betterfix bugfix(cart): prevent duplicate items on rapid add-to-cart clicksupdatesfeat(profile): allow users to update display nameWIPDont commit WIP — stash itmisc changesSplit into separate, meaningful commitsJohns changesDescribe what changed, not who changed it与仓库内其他提交类技能的协同在 awesome-copilot 仓库中围绕提交信息存在多个互补技能理解分工有助于按场景选择skills/gitmoji/SKILL.md按 gitmoji 约定生成带 emoji 的提交信息仅生成消息不执行 git 命令。其文档明确写道如果项目遵循纯 Conventional Commitsfeat:、fix:...而无 emoji应使用conventional-commit或commit-message-storyteller技能不确定时先让用户提供git log --oneline -10。skills/conventional-commit/SKILL.md面向一键执行提交的场景用结构化 XML 模板构造提交信息并由 Copilot 直接在集成终端运行git commit -m type(scope): description。skills/git-commit/SKILL.md可执行git commit的完整工作流技能包含 diff 分析、智能暂存与 Git 安全协议不更新 git config、不做破坏性操作、不跳过 hooks、不强制推送主干等。而commit-message-storyteller的独特价值在于叙事深度它默认不执行 git 命令产出可复制的消息 一行故事说明专精于把 diff 背后的为什么讲清楚——是四者中最适合提升开源项目与团队提交历史可读性的选择。如何安装与使用该技能依据 docs/README.skills.md 的说明该技能可通过 GitHub CLI 安装gh skills install github/awesome-copilot commit-message-storyteller需 GitHub CLI v2.90.0 及以上版本或将skills/commit-message-storyteller文件夹手动复制到本地技能目录。安装后在提示中引用技能名或让 Agent 根据上述触发场景自动发现即可。技能的结构本身也经受仓库工程化校验eng/validate-skills.mjs会检查每个技能目录的SKILL.md存在性、frontmatter 中name/description的合法性、文件夹名与技能名一致以及捆绑资源大小上限5MB。commit-message-storyteller的 frontmatter 与配套资源references/conventional-commits-guide.md正符合该校验标准可直接作为自定义技能的编写范本。实践要点速览输入即素材优先让用户粘贴git diff --staged模型自动提取改了什么、为什么、谁触发的。类型先于措辞先用上文的 10 类型判定表定基调再动笔写句子。主题行是一句话的承诺祈使语气 ≤72 字符 不带句号如perf(dashboard): lazy-load chart components。正文只讲 whydiff 已经给出 what正文聚焦之前的问题 修复思路 备选方案。脚注承载可追溯性Closes #xxx关 issueBREAKING CHANGE:标记破坏性变更。宁可拆分不可杂糅逻辑独立的变更拆成多条提交并告知用户。尊重团队约定项目若用 gitmoji 走 skills/gitmoji/SKILL.md若需一键执行走 skills/conventional-commit/SKILL.md讲故事则用本技能。【免费下载链接】awesome-copilotCommunity-contributed instructions, agents, skills, and configurations to help you make the most of GitHub Copilot.项目地址: https://gitcode.com/GitHub_Trending/aw/awesome-copilot创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考