astro-pr-writer

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 ...>

変更内容

動作、実装方法、影響に焦点を当てます。

以下を含めます。

• 以前はできなかったことで、現在できるようになったこと
• 修正／機能の仕組み（レビュアーに役立つ程度の詳しさ）
• ユーザー向けの信頼性／互換性／パフォーマンスに関する動作の変更

以下は含めないでください。

• 「テストを追加した」「フィクスチャを更新した」（Testing に記載します）
• 「changeset を追加した」
• 動作に影響しない内部プロセスに関するメモ

テスト

追加または変更したテストコードと、その理由を列挙します。レビュアーがこのセクションで知りたいのは、テストカバレッジの変更内容です。テストスイートを実行したという報告ではありません。

以下を含めます。

• 追加した新しいテストファイルやテストケースと、その対象を簡潔に説明した内容
• 変更した既存テストと、アサーションを変更した理由

以下は含めないでください。

• テストが成功したこと（CI で確認できるため、不要です）
• 実行したコマンド
• 合格したテスト数

ドキュメント

ドキュメントへの影響を明確に説明します。

• ドキュメントが不要な場合は、その理由を一文で述べます。
• ドキュメントが必要な場合は、ドキュメントの PR へのリンクを記載します。

簡潔さに関するガイダンス

基本は短くします。各セクションは通常 1〜2 個の箇条書きにし、変更が本当に複雑な場合に限り追加します。一般的なパッチなら、レビュアーが PR キューをざっと見て、本文全体を 30 秒以内に読めるようにします。

冗長すぎる例：

• base.ts と relative.ts の両方で、server 設定プロパティの .optional().prefault({}) を z.preprocess() の外に移動し、#16531 の integrations の修正に合わせます。Zod 4.4.0 では、z.preprocess() でラップされたプロパティが存在しない場合、プリプロセッサや内部のデフォルト値が実行される前に拒否されます。.optional().prefault({}) を preprocess 呼び出しの外に移動することで、この問題を解決します。@rururux が報告した server プロパティの問題を修正します。
• Zod 4.4.0 との互換性のため、Astro と DB の両方のエラーマップに、invalid_key、invalid_element、判別可能なユニオンの options ハンドラーを追加します。Zod 4.4.0 では、レコードのキーに対するリファインメントの失敗（環境変数のスキーマの変数名など）が、平坦なメッセージではなく、ネストされたエラーを含む構造化された invalid_key イシューとして提示されます。ハンドラーは実際のリファインメントメッセージを抽出し、ユーザー向けにわかりやすいエラーを表示します。
• すべての変更は Zod 4.3.x と後方互換性があります。新しいエラーマップの分岐は、4.4.0 で出力されるようになったイシューコードに対してのみ有効になります。

より良い例：

• server 設定の .optional().prefault({}) を z.preprocess() の外に移動し、#16531 の integrations の修正に合わせます。@rururux が報告した問題を修正します。
• Zod 4.4.0 との互換性のため、両方のエラーマップに invalid_key、invalid_element、判別可能なユニオンの options ハンドラーを追加します。
• 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 ファイルが存在する。ない場合は投稿前に作成する