name: dot-ai-changelog-fragment description: 为发布说明创建变更日志片段。在/PRD完成工作流中的首次推送至PR时调用。 user-invocable: true

创建变更日志片段

当完成PRD工作时，为发布说明创建towncrier变更日志片段。这应包含在PR中，以便片段与代码更改一起审查。

工作流程

步骤1: 识别PRD

如果上下文未明确，询问：“我应该为哪个PRD创建发布说明？”

寻找：

最近对话中提到的PRD
当前分支名称中引用的PRD（例如，feature/prd-320-*）
用户提供的PRD文件路径

步骤2: 彻底阅读PRD

阅读整个PRD文件以提取：

问题陈述：解决了什么用户痛点，为什么重要
解决方案概述：该功能做什么，如何工作
用户影响：具体好处，用户现在可以做什么
关键能力：添加的个别功能、选项或模式
技术细节：配置选项、环境变量、命令
文档更新：添加或更新了哪些文档（检查里程碑部分）

步骤3: 确定片段类型

阅读pyproject.toml以查看可用的片段类型。每个[[tool.towncrier.type]]部分有：

上面的注释描述何时使用该类型
一个directory字段（用于文件名的类型标识符，例如feature对应.feature.md）

根据描述选择最适合PRD的类型。

步骤4: 编写片段

创建文件：changelog.d/[issue-id].[type].md

重要：使用扁平结构，而非子目录！

✅ 正确：changelog.d/329.feature.md
❌ 错误：changelog.d/feature/329.md

命名约定：

issue-id：PRD的GitHub问题编号（例如320）
type：步骤3中的类型标识符（例如feature、bugfix、misc）

内容格式：

## [功能标题]

[开场句：该功能是什么以及解决的问题]

[关键能力段落：用户现在可以做的具体事情，带有具体示例]

[配置/使用段落，如果适用：如何启用或使用该功能]

[文档链接，如果更新了文档]

文档链接： 如果PRD包括文档更新，链接到devopstoolkit.ai上的相关页面。URL模式是：

https://devopstoolkit.ai/docs/{project}/{path}
其中{project}是：mcp（dot-ai）、controller（dot-ai-controller）、ui（dot-ai-ui）或stack（dot-ai-stack）
而{path}从文档文件夹映射（例如docs/guides/mcp-recommendation-guide.md → guides/mcp-recommendation-guide）

示例：changelog.d/142.feature.md

## 多集群管理

从单个dot-ai实例管理多个Kubernetes集群。以前，每个集群需要自己的dot-ai部署，使得跨环境比较配置或应用一致模式变得困难。

`query`工具现在接受`--cluster`标志以针对特定集群，结果指示每个资源属于哪个集群。`recommend`工具可以生成针对不同集群的清单，带有环境特定的自定义。跨集群搜索让您可以同时在所有连接的集群中查找资源——对追踪特定工作负载部署位置很有用。集群健康聚合在`version`输出中显示所有集群的统一视图。

通过将kubeconfig上下文添加到`ADDITIONAL_KUBECONFIGS`（逗号分隔的路径）来配置额外集群。每个上下文成为可用的集群目标。未指定`--cluster`标志时，默认集群保持为当前kubeconfig上下文。

有关配置详情和示例，请参阅[多集群设置指南](https://devopstoolkit.ai/docs/mcp/setup/multi-cluster-setup)。

步骤5: 确认创建

向用户显示：

创建的片段文件路径
写入的内容
提醒在PR中提交和推送

指南

以用户为中心：描述用户获得什么，而非实现细节
具体：包括每个能力做什么的具体示例
完整：涵盖所有主要添加功能，而不仅仅是标题
现在时：“工具现在返回…”而非“添加了对…的支持”
非日记风格：“多集群管理”而非“添加了多集群支持”
包括配置：提及环境变量、命令或设置步骤
链接到文档：如果PRD更新了文档，链接到devopstoolkit.ai上的具体页面