Name: changelog
Author: zls3434

Prompt file imported from zls3434/quick-input (.windsurf/workflows/changelog.md). Copyright stays with the author.

/changelog — 从 Git 历史生成变更日志，按 Conventional Commits 分类为 Added/Changed/Fixed/Removed。

触发方式

在 Cascade 对话框中输入 /changelog 触发此工作流。

工作流内容

changelog — 变更日志生成

技能目的

从 Git 提交历史生成结构化变更日志，按 Conventional Commits 规范分类为 Added（新增）、Changed（变更）、Fixed（修复）、Removed（移除），为版本发布提供可追溯的技术变更记录。

参数说明

[起始版本]：可选，变更日志的起始标签（如 v1.1.0）。省略时从上一个版本标签开始。
[结束版本]：可选，变更日志的结束标签（如 v1.2.0）。省略时到当前 HEAD。

分阶段工作流

阶段 1：读取 Git 日志

输入：版本范围参数
处理：
1. 使用 Bash 执行 git tag 获取已有版本标签
2. 使用 Bash 执行 git log {起始}..{结束} --pretty=format:"%h %s" 获取提交
3. 若无标签，使用 Bash 执行 git log --since 按日期范围获取
4. 捕获全部提交哈希与消息
输出：原始提交清单

阶段 2：按 Conventional Commits 分类

输入：原始提交清单
处理：
1. 解析提交消息前缀：feat: → Added，fix: → Fixed
2. refactor: / perf: / chore: → Changed
3. revert: / BREAKING CHANGE → Removed 或 Changed
4. 使用 Grep 过滤非规范提交，标注为 Uncategorized
5. 对每条提交补充作用域（scope）与简要说明
输出：分类后的变更条目

阶段 3：生成变更日志

输入：分类后的变更条目
处理：
1. 按 Added / Changed / Fixed / Removed 分组排序
2. 每条含：提交哈希、作用域、描述
3. 标注 BREAKING CHANGES 单独成节
4. 使用 Read 读取现有 CHANGELOG.md 保留历史内容
5. 使用 Write 在文件顶部插入新版本章节
输出：更新后的 CHANGELOG.md

协作协议引用

遵循 .claude/docs/coding-standards.md 编码规范
变更日志写入项目根目录 CHANGELOG.md
遵循 Keep a Changelog 格式规范
不自动提交，需用户确认后提交

推荐下一步

使用 /patch-notes 将技术性变更日志转换为面向用户的发布说明。使用 /release-checklist 验证发布前检查清单。使用 /launch-checklist 执行最终发布验证。

Install changelog and it becomes one more candidate the router can pick - when it fits.

A listing is a routing target with a manifest: what it does, which domains it covers, what it costs and who publishes it. Once installed it sits beside your own models and tools, is scored like any other candidate for each request, and shows up in the trace when it wins. Ratings come from workspaces that installed it, one per account.

# /changelog — 从 Git 历史生成变更日志，按 Conventional Commits 分类为 Added/Changed/Fixed/Removed。 ## 触发方式在 Cascade 对话框中输入 /changelog 触发此工作流。 ## 工作流内容 # changelog — 变更日志生成 ## 技能目的从 Git 提交历史生成结构化变更日志，按 Conventional Commits 规范分类为 Added（新增）、Changed（变更）、Fixed（修复）、Removed（移除），为版本发布提供可追溯的技术变更记录。 ## 参数说明 - `[起始版本]`：可选，变更日志的起始标签（如 `v1.1.0`）。省略时从上一个版本标签开始。 - `[结束版本]`：可选，变更日志的结束标签（如 `v1.2.0`）。省略时到当前 HEAD。 ## 分阶段工作流 ### 阶段 1：读取 Git 日志 - **输入**：版本范围参数 - **处理**： 1. 使用 Bash 执行 `git tag` 获取已有版本标签 2. 使用 Bash 执行 `git log {起始}..{结束} --pretty=format:"%h %s"` 获取提交 3. 若无标签，使用 Bash 执行 `git log --since` 按日期范围获取 4. 捕获全部提交哈希与消息 - **输出**：原始提交清单 ### 阶段 2：按 Conventional Commits 分类 - **输入**：原始提交清单 - **处理**： 1. 解析提交消息前缀：`feat:` → Added，`fix:` → Fixed 2. `refactor:` / `perf:` / `chore:` → Changed 3. `revert:` / `BREAKING CHANGE` → Removed 或 Changed 4. 使用 Grep 过滤非规范提交，标注为 Uncategorized 5. 对每条提交补充作用域（scope）与简要说明 - **输出**：分类后的变更条目 ### 阶段 3：生成变更日志 - **输入**：分类后的变更条目 - **处理**： 1. 按 Added / Changed / Fixed / Removed 分组排序 2. 每条含：提交哈希、作用域、描述 3. 标注 BREAKING CHANGES 单独成节 4. 使用 Read 读取现有 `CHANGELOG.md` 保留历史内容 5. 使用 Write 在文件顶部插入新版本章节 - **输出**：更新后的 CHANGELOG.md ## 协作协议引用 - 遵循 `.claude/docs/coding-standards.md` 编码规范 - 变更日志写入项目根目录 `CHANGELOG.md` - 遵循 Keep a Changelog 格式规范 - 不自动提交，需用户确认后提交 ## 推荐下一步使用 `/patch-notes` 将技术性变更日志转换为面向用户的发布说明。使用 `/release-checklist` 验证发布前检查清单。使用 `/launch-checklist` 执行最终发布验证。

{ "prompt": "# /changelog — 从 Git 历史生成变更日志，按 Conventional Commits 分类为 Added/Changed/Fixed/Removed。\n\n## 触发方式\n在 Cascade 对话框中输入 /changelog 触发此工作流。\n\n## 工作流内容\n# changelog — 变更日志生成\n\n## 技能目的\n\n从 Git 提交历史生成结构化变更日志，按 Conventional Commits 规范分类为 Added（新增）、Changed（变更）、Fixed（修复）、Removed（移除），为版本发布提供可追溯的技术变更记录。\n\n## 参数说明\n\n- `[起始版本]`：可选，变更日志的起始标签（如 `v1.1.0`）。省略时从上一个版本标签开始。\n- `[结束版本]`：可选，变更日志的结束标签（如 `v1.2.0`）。省略时到当前 HEAD。\n\n## 分阶段工作流\n\n### 阶段 1：读取 Git 日志\n\n- **输入**：版本范围参数\n- **处理**：\n 1. 使用 Bash 执行 `git tag` 获取已有版本标签\n 2. 使用 Bash 执行 `git log {起始}..{结束} --pretty=format:\"%h %s\"` 获取提交\n 3. 若无标签，使用 Bash 执行 `git log --since` 按日期范围获取\n 4. 捕获全部提交哈希与消息\n- **输出**：原始提交清单\n\n### 阶段 2：按 Conventional Commits 分类\n\n- **输入**：原始提交清单\n- **处理**：\n 1. 解析提交消息前缀：`feat:` → Added，`fix:` → Fixed\n 2. `refactor:` / `perf:` / `chore:` → Changed\n 3. `revert:` / `BREAKING CHANGE` → Removed 或 Changed\n 4. 使用 Grep 过滤非规范提交，标注为 Uncategorized\n 5. 对每条提交补充作用域（scope）与简要说明\n- **输出**：分类后的变更条目\n\n### 阶段 3：生成变更日志\n\n- **输入**：分类后的变更条目\n- **处理**：\n 1. 按 Added / Changed / Fixed / Removed 分组排序\n 2. 每条含：提交哈希、作用域、描述\n 3. 标注 BREAKING CHANGES 单独成节\n 4. 使用 Read 读取现有 `CHANGELOG.md` 保留历史内容\n 5. 使用 Write 在文件顶部插入新版本章节\n- **输出**：更新后的 CHANGELOG.md\n\n## 协作协议引用\n\n- 遵循 `.claude/docs/coding-standards.md` 编码规范\n- 变更日志写入项目根目录 `CHANGELOG.md`\n- 遵循 Keep a Changelog 格式规范\n- 不自动提交，需用户确认后提交\n\n## 推荐下一步\n\n使用 `/patch-notes` 将技术性变更日志转换为面向用户的发布说明。使用 `/release-checklist` 验证发布前检查清单。使用 `/launch-checklist` 执行最终发布验证。", "variables": [], "notes": "从 Git 提交历史生成结构化变更日志，按 Conventional Commits 规范分类为 Added（新增）、Changed（变更）、Fixed（修复）、Removed（移除），为版本发布提供可追溯的技术变更记录。", "metadata": { "source": { "provider": "github-windsurf-workflows", "repository": "https://github.com/zls3434/quick-input", "path": ".windsurf/workflows/changelog.md", "ref": "4f48bbd849b63514812e8ef32a94a4fe19b9c7fd", "url": "https://github.com/zls3434/quick-input/blob/4f48bbd849b63514812e8ef32a94a4fe19b9c7fd/.windsurf/workflows/changelog.md", "key": "zls3434/quick-input/.windsurf/workflows/changelog.md" } } }

changelog

About