mcpField
A
astro-pr-writer

astro-pr-writer

github.com/withastro开发63.6k341 次安装今天更新
代码仓库

关于 astro-pr-writer

用于撰写 Astro Pull Request 标题和说明的技能，面向希望让评审者快速了解变更、实现方式及验证内容的贡献者。它规定 Changes、Testing 和 Docs 等内容的组织方式，并提供提交前检查项。

主要功能

  1. 01撰写简洁且易评审的 PR 标题
  2. 02按 Changes、Testing 和 Docs 组织正文
  3. 03区分行为变更与测试代码说明
  4. 04检查 Changeset 与提交前要求

适用场景

  1. 01为 Astro 功能或修复撰写 PR 说明
  2. 02更新现有 PR 标题或正文
  3. 03检查 PR 正文是否包含文档与 Changeset 信息

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/withastro/astro --skill astro-pr-writer

安装后在 Claude Code 中输入/astro-pr-writer确认已加载。

附带文件evals/evals.json

详细介绍

Astro PR 撰写

撰写 Astro 拉取请求描述，帮助审阅者快速了解意图、行为变化和验证情况。

每当用户提出任何 PR 撰写任务时，都使用此技能，包括：

  • 创建／打开拉取请求
  • 创建／打开草稿拉取请求
  • 更新 PR 标题
  • 更新 PR 正文／描述
  • 撰写 PR 备注／摘要

核心原则

描述变更内容、实现方式以及变更的意义。

  • Changes 说明修复／功能的作用。
  • Testing 列出新增或修改了哪些测试代码。
  • Docs 说明是否需要修改面向用户的文档。

不要把 PR 各部分写成任务日志。

PR 标题规则

使用自然、便于审阅的标题。

  • 用通俗语言描述结果。
  • 保持简洁、具体。
  • 优先采用审阅队列中自然易读的表述。

不要使用：

  • PR 标题中的 Conventional Commits 前缀（fix:、feat:、docs: 等）
  • 带作用域的提交风格标题（fix(cloudflare): ...）

正文规则

使用以下结构：

## Changes

- <Behavior change and why it matters>
- <Implementation detail and impact>

## Testing

- <New or changed test and what it covers>
- <Why an existing assertion changed>

## Docs

- <No docs update needed, because ...>
Changes

聚焦行为、实现方式和影响。

包括：

  • 现在可以正常工作的内容（之前无法正常工作）
  • 修复／功能的实现方式（对审阅者有用的细节）
  • 面向用户的可靠性／兼容性／性能变化

不要包括：

  • “添加了测试”或“更新了 fixture”（应放在 Testing 中）
  • “添加了 changeset”
  • 不影响行为的内部流程备注
Testing

列出新增或修改了哪些测试代码，以及原因。审阅者阅读此部分是为了了解测试覆盖范围的变化，而不是了解你是否运行了测试套件。

包括：

  • 新增的测试文件或测试用例，并简要说明其覆盖内容
  • 修改过的现有测试，以及断言变更的原因

不要包括：

  • 测试通过了（CI 会显示，这属于噪音）
  • 运行了哪些命令
  • 通过了多少项测试
Docs

清楚说明文档方面的影响。

  • 如果不需要修改文档，用一句话说明原因。
  • 如果需要修改文档，请链接文档 PR。

简洁性指南

默认保持简短。每个部分通常写 1～2 个要点；只有变更确实复杂时才增加内容。对于常见补丁，审阅者扫读 PR 队列时应能在 30 秒内读完整篇正文。

过于冗长：

  • 将 server 配置属性的 .optional().prefault({}) 从 z.preprocess() 中移出，修改涉及 base.ts 和 relative.ts，与 #16531 中针对 integrations 的修复一致。Zod 4.4.0 会在预处理器或内部默认值执行前，拒绝由 z.preprocess() 包装的缺失属性；将 .optional().prefault({}) 移到 preprocess 调用之外即可解决此问题。修复了 @rururux 在该问题中报告的 server 属性问题。
  • 在 Astro 和 DB 错误映射中添加 invalid_key、invalid_element 和判别联合 options 处理程序，以兼容 Zod 4.4.0。Zod 4.4.0 会将记录键精炼失败（例如环境变量架构中的变量名）作为包含嵌套错误的结构化 invalid_key 问题，而不是扁平消息抛出。处理程序会提取实际的精炼错误消息，以提供清晰、面向用户的错误信息。
  • 所有变更均向后兼容 Zod 4.3.x。新的错误映射分支仅在 Zod 4.4.0 开始发出的问题代码上启用。

更佳：

  • 将 server 配置的 .optional().prefault({}) 移到 z.preprocess() 之外，与 #16531 中针对 integrations 的修复一致。修复了 @rururux 在该问题中报告的问题。
  • 在两种错误映射中添加 invalid_key、invalid_element 和判别联合 options 处理程序，以兼容 Zod 4.4.0。
  • 向后兼容 Zod 4.3.x。

Changesets

每个修改软件包的 PR 都需要包含一个 changeset。只有对 examples/* 的修改可以豁免。

加载 changeset 技能来创建 changeset 文件并编写说明。该技能涵盖文件创建、格式、版本升级类型和说明约定。

编写 PR 正文时：

  • 发布前，检查是否存在 changeset。如果 PR 修改了软件包，但没有 changeset，请立即使用 changeset 技能创建一个——不要在没有 changeset 的情况下发布 PR。
  • 不要在 Changes 部分提及“已添加 changeset”——这是流程噪音，不是行为变更

发布前自检

  • 标题便于审阅（而非提交信息风格）
  • Changes 条目描述行为、实现或影响
  • Testing 列出新增或修改的测试代码，而非测试运行结果
  • 明确说明 Docs 的决定
  • 对于修改软件包的 PR，.changeset/ 中必须存在 changeset 文件——如果缺少，请在发布前创建

评论

支持 Markdown