docs-fix-changelog

Elastic ドキュメント用の変更履歴作成アシスタントです。変更履歴フィールドの文面の改善案を提示し、新しい変更履歴の内容作成を支援します。ファイルは作成しません。ファイルの作成には、常に docs-builder changelog add（PR に関連付ける場合）または docs-builder changelog note（PR に関連付けない場合）を使用します。

正確性を優先： スタイルよりも常に正確性を優先してください。書式や表現を改善するために、事実の正確性を犠牲にしてはなりません。

このスキルの使い方

このスキルは、体系的な変更履歴改善ワークフローの一部として docs-review-changelog と併用します。

1. まずレビュー： docs-review-changelog を使って、スキーマエラー、品質に関する警告、体系的なパターン違反を特定します
2. 次に修正： このスキルを使って、同じパターンカタログに基づく具体的な改善案を取得します
3. 必要に応じて繰り返し： マージ前に両方のツールを再実行し、最終確認を行います

一般的なワークフロー：

• 単一ファイル： /docs-fix-changelog path/to/changelog.yaml — 1 つのファイルの改善案を提示します
• ディレクトリモード： /docs-fix-changelog path/to/directory/ — ディレクトリ内のすべての *.yaml ファイルと *.yml ファイルを処理します
• 新しい変更履歴： /docs-fix-changelog "Create new changelog for: [PR context]" — 新しい変更履歴の内容を提案します

デフォルトの動作： 提案のみのモードです。ユーザーが明示的に承認した場合にのみ、変更がディスクに適用されます。

ステップ 1：正式なガイダンスとリポジトリ設定を読み込む

修正案が現在の標準とリポジトリ固有のルールに沿うようにします。

正式なガイダンスの読み込み

1. 最優先： ワークスペースに docs-content のチェックアウトがある場合は、docs-content/contribute-docs/content-types/changelogs.md を読み込みます
2. 次点： 公開されているガイド https://www.elastic.co/docs/contribute-docs/content-types/changelogs を取得します
3. フォールバック： 上記の情報源を利用できない場合は、このスキルに埋め込まれた編集後チェックリストを使用します

リポジトリ設定の読み込み

1. 領域の検証： ワークスペースで docs/changelog.yml を探し、pivot.areas セクションから有効な領域値を取得します
2. リポジトリのコンテキスト： ファイルが見つかった場合は、汎用ルールではなく、領域の検証に関する正式な情報源として使用します
3. フォールバック： リポジトリ設定が見つからない場合は、この制約を信頼度の記録に記載します

目的： これにより、修正案が現在の執筆ガイダンスとリポジトリ固有の検証ルールの両方に沿うようになります。

信頼度の記録： 正式なガイダンスとリポジトリ設定を正常に読み込めたかどうかを記録します。取得に失敗した場合やフォールバックを使用した場合は、提案の信頼度に影響するため、最終出力に記載してください。

動作モード

モード A — 既存ファイルを改善する。 最初の引数は、すでに存在する変更履歴 YAML ファイルのパスです。ファイルを読み込み、不十分または欠落しているフィールドを評価し、改善案を提示します。

モード B — ディレクトリを処理する。 最初の引数は、変更履歴ファイルを含むディレクトリのパスです。そのディレクトリ内のすべての *.yaml ファイルと *.yml ファイルを処理し、それぞれの改善案を提示します。

モード C — 新しいファイルの内容を提案する。 ファイルパスが指定されていない場合、または引数が読み取り可能なファイルやディレクトリとして解決されない場合は、ユーザーが docs-builder changelog add または docs-builder changelog note に渡せるテキスト形式のフィールド内容を提案します。

モードは自動的に判定します。最初の引数が読み取り可能なファイルとして解決される場合はモード A を使用します。ディレクトリとして解決される場合はモード B を使用します。それ以外の場合はモード C を使用します。

ステップ 2：モードを判定して入力を読み込む

• モード A：変更履歴ファイルを読み込み、解析します。YAML の解析に失敗した場合は、エラーを報告して停止します。
• モード B：ディレクトリ内の *.yaml ファイルと *.yml ファイルをグロブ検索します。各ファイルを YAML として解析します。ファイルの解析に失敗した場合は、そのファイルのエラーを報告し、残りのファイルの処理を続けます。
• モード C：読み込むファイルはありません。ステップ 3 に進みます。

ステップ 3：PR／issue のコンテキストを確認する

PR または issue のコンテキストを利用すると、より適切な提案ができます。次の順で確認してください。

1. ユーザーが $ARGUMENTS に 2 つ目の引数または引用文を渡している場合は、それをコンテキストとして扱います
2. 会話に PR または issue のタイトル、説明、差分、リンクされた参照がすでに含まれている場合は、それを利用します
3. 既存ファイル（モード A）の prs または issues フィールドに URL が含まれている場合は、それらを暗黙のコンテキストとして利用します。URL は変更履歴が説明する PR または issue を示しています
4. 上記のいずれも利用できない場合は、次のように一度だけ尋ねます：「共有できる PR または issue のコンテキスト（タイトル、説明、差分、リンクされた参照）はありますか？タイトルに「KI」のような頭字語が含まれている場合は、その意味を明確にしてください。 コンテキストが詳しいほど、より適切な提案ができます。」ユーザーがすでに断っている場合は、この質問を省略します。

頭字語のコンテキストをより適切に活用する：

• 頭字語の定義を探す： PR のタイトルや説明から、「KI (Knowledge Indicator)」のように略語の定義となるパターンを探します。また、略語の意味を示すコンテキスト上の手掛かりも確認します
• 展開した意味を照合する： 頭字語を展開する前に、PR のコンテキストが想定した意味と矛盾していないか確認します
• 不明な略記： ステップ 4 の項目 2 の表にないドメイン用語や Elastic 内部用語については、docs-flag-jargon-skill のパターンを確認します。推測で展開せず、要確認としてフラグを立てます

信頼度の判断に必要な情報を記録する： どのようなコンテキストが利用できたか（PR の詳細全体、一部の情報、URL のみ、または情報なし）と、取得に失敗したものがあれば記録します。これはステップ 7 で信頼度を評価する際に役立ちます。

PR の取得と適格性：

• docs-review-changelog のステップ 3 と同じ、PR に紐づくファイルとバージョン記載のファイルのルールを適用します（note-*.yml は changelog note によるファイル名の手掛かりであり、別のコンテンツ種別ではありません）
• ファイルに prs または issues の URL がある場合は、提案する前に取得します。これは必須であり、任意ではありません
• PR と issues のどちらもないバージョン記載のファイルについては、取得を省略します（失敗には該当しません）
• PR に紐づく変更履歴の PR／issue がテストのみ、リファクタリングのみ、またはユーザーから見える影響がない場合は、表面的な書き換えではなく、ファイルの削除を推奨します（PR がないバージョン記載のファイルには適用しません）
• ディレクトリモードでは、ファイルごとに PR のコンテキストを取得します。信頼度の低い書き換えは自動適用しません

issue タイトルとの照合（issues の URL があり、正常に取得できた場合）：

• issue のタイトルの表現と変更履歴のタイトルを比較します
• issue のタイトルが障害や症状（例：「リカバリーに失敗する原因となる」「クラスターヘルスが赤になった」）を説明している一方で、変更履歴のタイトルが予防や制限を表す言葉（Don't allow、Disallow、Prevent）を使っている場合は、issue のタイトルにある言葉を使い、症状を先に述べる書き換えを提案します
• 例：issue 「ソート済みフィールドをシャドーイングするランタイムフィールドを追加するとリカバリーに失敗する」 ＋変更履歴「インデックスソートで使用されるフィールドをランタイムフィールドがシャドーイングしないようにする」→「ランタイムフィールドがインデックスソートフィールドをシャドーイングする場合のシャードリカバリー失敗を修正」

製品／画面の特定（PR のコンテキストが利用できる場合）：

• PR のパス、ラベル、本文から、製品の画面や機能（アプリ、ページ、タブ、フライアウト、統合名）を特定します
• タイトルにその画面や機能が含まれていない場合（button、metrics、response action などの一般的な語）、in Synthetics、in case details、for Elastic Defend Endpoint などの接尾辞を提案します
• 省略よりも画面や機能のコンテキストの追加を優先し、80 文字を超える部分は description に移します

ステップ 4：編集後チェックリストを適用する

docs-review-changelog（ステップ 4）の体系的なパターンチェックリストを適用します。修正固有の差分は以下に追加してください。カタログ全体をここで再導出しないでください。

1. タイトル標準化の修正（標準タイトル整理チェックリストより）：

• 開発ラベルを削除する： feat:、fix:、Fix:、auto-implement: などの接頭辞や、Bugfix - のような末尾のトラッカーフラグメントを削除します。ES|QL|DS、Aggs:、GPU codec:、DiskBBQ - も削除します（レビュースキルのステップ 4.1 を参照）。
• スラッシュ区切りのリストを置き換える： タイトル内の / による列挙を、Oxford comma を使ったリストに変換します（例：foo/bar/baz → foo, bar, and baz）。
• チーム名だけの角括弧タグは使わない： [Security Solution]、[Query Rules]、[Inference] などは、ユーザーに伝わる平易な表現に置き換えます。
• 明確な動詞を使う： Better validation for... より Improve validation for... を優先します（現在形の命令形を使います：Fix、Add、Remove）。
• 要点を埋もれさせない： タイトルが曖昧な場合は、説明から具体的な詳細を盛り込み、リリースノートだけで内容が伝わるようにします。
• 動詞は原形を使う： Fixes、Adds、Removes ではなく、Fix、Add、Remove を使います。
• センテンスケースにする： 標準的な文頭のみ大文字の表記に従います。
• 機能／アプリの接頭辞を統合する： [Feature/App]: [Action] のパターンを検出し、文脈に合った代替表現を提案します（例：「File upload: Fix bug」→「Fix bug in file upload tool」）。UI コンポーネント、機能名、1〜4 語の大文字始まりのフレーズを対象とします。技術用語（例：「Authorization: Bearer」）、API 参照、コード識別子は対象外です。

2. 技術用語の改善に関する修正：

略語	対応
NPE	NullPointerException に展開する
UOE	UnsupportedOperationException に展開する
PIT	point-in-time に展開する
GPU、API、HTTP、OTLP	大文字表記を維持する
ESQL	`ES
OSQ およびその他のドメイン略語	PR で確認できた場合にのみ展開する

• クラス名／メソッド名、設定キー、API エンドポイント、コード識別子にバッククォートがない場合は追加します。
• イギリス英語の綴りをアメリカ英語に変換します：serialise → serialize、colour → color
• 完全な形のほうが明確な場合は略語を展開します：params → parameters
• 略語の展開： 上の表に従います。PR の文脈がない場合、ドメイン略語は不確かなものとして指摘します。この表にない内部略語については、docs-flag-jargon-skill のパターンを確認します。推測せず、指摘して確認を求めます。
• 表記を統一します：ESQL → ES|QL

3. コンテンツ品質の修正：

• 説明の内容に基づき、曖昧なタイトルをより具体的にします。
• 追加の文脈を加えず、タイトルを繰り返すだけの冗長な説明は削除します。
• 実装の詳細ではなく、ユーザーに見える成果に焦点を当てます。

4. YAML 書式の修正：

• パースエラーを防ぐため、特殊文字（バッククォート、コロン、角括弧）を含むテキストは引用符で囲みます。
• テキストフィールド間で書式を統一します。

5. UI 要素の書式設定の修正：

• UI ラベルが曖昧な場合は引用符で囲む： ボタン名、ページタイトル、タブ、ドロップダウン名、列名（例：「Service Inventory」）。
• 機能名は大文字で始める： 機能名は引用符で囲まず、大文字で始めます（Machine Learning、Elastic Security）。
• コード識別子： フィールド名、パラメーター、API エンドポイントにはバッククォートを使います（index.refresh_interval）。
• 判断が難しい場合： UI ラベルか機能名かが不明確な場合は、書式の判断に迷いがあることを明記します。

ステップ 4.5：タイプとタイトルの整合性チェック

docs-review-changelog のステップ 4、項目 6 と同じタイプとタイトルの整合性ルール（想定される動詞、予防的な表現、不一致の指摘）を適用します。動詞の表はここで再掲しないでください。

不一致が検出された場合は、両方の選択肢を提示します。タイプを維持してタイトルを書き換えるか、タイトルを維持してタイプの変更を提案します。PR の文脈に基づき、どちらの選択肢がより適切かを説明する確信度の注記を含めます。

アラインメント評価プロセス

各変更履歴について：

1. タイトルから先頭の動詞を抽出します（冠詞や前置詞の後に続く最初の単語）
2. 宣言されたタイプに対する想定動詞と照合します（レビューのステップ 4 の項目 6 に従います）
3. 不一致が見つかった場合は、次の両方の選択肢を提示します。
   • 選択肢 A： タイプは維持し、適切な動詞を使ってタイトルを書き直す
   • 選択肢 B： タイトルは維持し、より適切なタイプを提案する
4. PR のコンテキストに基づいて、どちらの選択肢がより妥当かを説明する信頼度の注記を添えます

ステップ 4.6：技術的な内容の評価

実装に焦点を当てた表現がタイトルに含まれているかを評価します。[Fix|Improve|Add] [user-visible outcome] [in context] の形式で書き直します。例：「constructing ColorSeries での splitValue の null 許容性の型変換」を「ES|QL クエリで時系列がグレー表示されるインラインチャートを修正」に書き換えます。

ユーザーの症状より実装を優先しているタイトルにフラグを付けます：

• コンテキストのないクラス／メソッドへの言及：「ColorSeries の構築」、「splitValue の null 許容性」、「QueryNode の構築時」
• 内部プロセスの説明：「型変換ロジック」、「シリアライズ処理」、「初期化シーケンス」
• 実装に焦点を当てた用語：ユーザーが体験することを説明していない技術用語
• ユーザーに見える症状の欠落：ユーザーへの影響を説明せず、コード変更だけを記述しているタイトル
• 予防的か是正的か： bug-fix／regression の場合、タイトルに症状を表す語（fail、error、crash、leak、hang、timeout、incorrect、missing、red、unallocated）がなく、制限を表す語（allow、disallow、prevent、reject、validate、block）が使われている場合は、予防的な表現である可能性が高いとしてフラグを付けます。これは人間によるレビューのための緩やかなヒューリスティックであり、自動的な不合格判定ではありません。

ユーザーへの影響の評価

すでにユーザー体験に焦点を当てているタイトルを認識します：

• 症状が明確に記述されている：「時系列がグレー表示されるインラインチャートを修正」
• ユーザー向けの機能名：「ES|QL クエリ」、「ダッシュボードウィジェット」、「アラート通知」
• 観察可能な挙動：「読み込みが遅い」、「結果が正しくない」、「データが欠落している」

技術的な内容のスコアリング

ユーザーに焦点を当てた書き換えの優先度が高いもの：

• ユーザーのコンテキストがないまま、タイトルに複数の技術用語が含まれている
• ユーザーの症状より実装の詳細が優先されている
• 説明のないクラス名、メソッド名、内部概念が含まれている

書き換えの優先度が低いもの（書式の調整のみ）：

• タイトルですでにユーザーに見える症状が明確に説明されている
• 技術用語がユーザーの理解を妨げず、補助している

ステップ 5：フィールドを評価する

モード A & B — 改善が必要なフィールドを特定します（処理する各ファイルに適用）。

• title：曖昧、実装に偏っている、時制が誤っている、動作を表す動詞がない、製品／対象領域の文脈が不足している、または 80 文字を超えている
• description：提案するのは、タイトルが曖昧な場合、または時制／品質に問題がある場合のみです。タイトルだけで内容が明確で、説明の時制にも問題がない場合は提案しないでください。現在の品質が低い内容（タイトルの繰り返し、「See PR」、「Internal refactoring」）は指摘してください。
• description の時制：レビューのステップ 4 の動詞形式の使い分けに従います。三人称単数現在形（Fixes、Adds）を使用します。過去形（Fixed、Added）や動詞の原形で始まる場合は指摘し、それに応じて書き換えてください。
• impact／action：breaking-change、deprecation、known-issue では必須です。値がある場合は、三人称単数現在形を使用します（description と同じ動詞形式の使い分けに従います）。
• areas がある場合：文字列の配列である必要があります。ステップ 1 のリポジトリ設定を参照できる場合は、それに照らして検証します（docs/changelog.yml の pivot.areas セクションにない領域のみを指摘してください）。参照できない場合は、一般的な基準で検証します。
• feature-id がある場合：文字列である必要があります。内容の品質確認は不要で、YAML の型が正しいかだけを確認してください。
• スキーマ（レビューのステップ 3 の適用条件に従う）：products[].target は古いため、決して提案しないでください。存在する場合は削除します。バージョン指定あり：products[].versions を YAML シーケンスにする必要があります。PR リンクあり：存在する場合は versions／target を削除します。

既存の description、impact、action の値に、次の書式上のアンチパターンがないかも確認してください。

• リンクテキストに URL をそのまま使用している
• 言語識別子のないコードフェンス
• フィールド名、設定キー、コマンド、API エンドポイントをインラインコードではなく通常のテキストで記述している
• :（コロン＋スペース）、#、[、]、{、} を含む、引用符で囲まれていない値（YAML の解析エラーが発生します）

モード C — type に基づいて提案するフィールドを判断します（不明な場合は質問してください）。

• すべてのタイプ：title（必須）、description（推奨）
• breaking-change、deprecation、known-issue：さらに impact と action

ステップ 6：候補を生成する

文字数制限： 目標は 80／600 文字です。文字数を削るよりも明瞭さを優先してください。詳細が多すぎる場合は、正確なタイトルを短縮せず、description に移してください。タイトルから技術的な詳細を省いた場合は、任意の description を提案してください。

信頼度の基準： すべての候補に「高」「中」「低」を適用してください。

• 高： 定型パターン（接頭辞、YAML の引用符）、標準用語、PR の全コンテキスト、正規のガイダンスを読み込み済み
• 中： PR のコンテキストが一部のみ、技術用語とユーザー向け表現が混在、一般的な Elastic 用語
• 低： PR の詳細が不足、コンテキストのないドメイン用語、複数の解釈が可能 — 両方の選択肢を記載

トピックの対応付け（基準を使用し、「高／中／低」のリストを再分類しないでください）：

• 種別とタイトル： PR で不具合修正か新機能かが確認できる場合は高、パフォーマンス改善や小規模な追加の場合は中、種別とタイトルの両方が適切な可能性がある場合は低 → 選択肢 A／B を提示
• 技術的な内容： クラスやメソッドが中心のタイトルは高、技術用語とユーザー向け表現が混在する場合は中、タイトルがすでにユーザー向けの場合は書き換えを省略（書式のみ変更）
• リポジトリ内の領域： docs/changelog.yml を読み込み済みの場合は高、未読み込みの場合は低
• 機能の接頭辞： 既知の UI／機能名の場合は高、コロンの前の語句が技術用語の可能性もある場合は低

機能／アプリの接頭辞を統合するパターン：

• "[Feature]: Fix [issue]" → "[feature] の [issue] を修正する"
• "[Feature]: Enable [capability]" → "[feature] で [capability] を有効にする"
• "[Feature]: Add [functionality]" → "[feature] に [functionality] を追加する"

モード A と B — 不適切または形式が正しくない項目ごとに、以下を提示してください。

• 現在の値（または「未設定」）
• 推奨する代替案を 1 つまたは 2 つ
• 推奨案が優れている理由の簡潔な説明

モード C — 関連する項目ごとに文案を提示してから、そのままコピーできるコマンドを提示してください。PR がない場合、またはリリース後の known-issue／security の場合は、--products に | 区切りのバージョンを指定して changelog note を使用してください。PR に紐づく場合は、--products にバージョンを指定せず changelog add を使用してください。パスが不明な場合は一度だけ質問してください。

# PR-linked — no version in --products
docs-builder changelog add \
  --type <type> --title "<title>" --products "elasticsearch ga" --prs <url-or-number>

# Version-listed — versions in the products middle slot
docs-builder changelog note \
  --type known-issue --title "<title>" --products "elasticsearch 9.3.0|9.4.0 ga"

該当しない場合は --impact／--action を省略してください。シェルで引用符で囲む値に含まれるバッククォート（\``）と二重引用符（"）はエスケープしてください。その他のフラグについては changelog add --help／changelog note --help` を参照してください。

種類別の詳細なガイダンス

bug-fix / regression:

• タイトルのパターン：「[症状]を[状況]で修正する」（基本形の動詞）
• **よくある不一致：**動作の不具合を修正しているのに「改善する」とするタイトル、不具合の症状を先に示す「[条件]のときに[症状]を修正する」ではなく、予防を前面に出す表現（「許可しない」「禁止する」「防止する」）
• **対応：**動作に不具合があった場合はbug-fixを維持し、タイトルを書き換えます。新しい機能を追加する場合はenhancementに変更します。利用可能な場合は、課題のタイトルの表現を参照して確認します（ステップ3の照合）。
• **説明で明記する内容：**何が誤っていたか、現在は何が正しいかを説明し、「修正します…」で始めます（三人称・現在形）。
• **必須フィールド：**リグレッションではimpactとactionを推奨します。

enhancement:

• タイトルのパターン：「[既存機能]を改善する」または「[小規模な機能]を追加する」
• **よくある不一致：**パフォーマンス改善なのに「修正する」とするタイトル
• **対応：**客観的に不具合のある動作を修正する場合はbug-fixに変更します。正常に動作する機能を最適化する場合はenhancementを維持し、タイトルを書き換えます。
• **説明で明記する内容：**ユーザーがより良く、またはより速くできるようになることを説明し、「改善します…」または「可能にします…」で始めます。

feature:

• タイトルのパターン：「[大規模な新機能]を追加する」
• **よくある不一致：**小規模な改善が機能として分類されている
• **対応：**主要な新機能はfeatureにします。小規模な追加はenhancementにします。
• **説明で明記する内容：**ユーザーがこれまでできなかったことのうち、新たにできるようになることを説明し、「追加します…」または「可能にします…」で始めます。

breaking-change:

• **タイトルのパターン：**明確な動詞であれば問いませんが、影響が明確に伝わることを重視します。
• 必須フィールド：impactでは何が壊れ、誰が影響を受けるかを説明する必要があります。actionでは、順序を示した具体的な移行手順を提示する必要があります。状況に応じてコード例も含めます。subtypeも強く推奨します。

deprecation:

• タイトルのパターン：「[機能]を非推奨にする」または「[機能]を削除する」
• 必須フィールド：actionでは代替手段を明記し、移行ガイダンスへのリンクを記載します。
• **任意フィールド：**影響の大きい非推奨化ではimpactを推奨します。

known-issue:

• **タイトルのパターン：**調査内容ではなく、問題を明確に説明します。
• **必須フィールド：**PRに紐付いていない場合は、影響を受けるリリースをproducts[].versionsに記載します。利用可能な回避策があれば、actionで説明します。PRがない場合はchangelog noteを使用します。

docs:

• タイトルのパターン：「[明確さ／正確さ]のために[ドキュメント]を更新する」
• **焦点：**対処したコンテンツの不足や、ユーザーエクスペリエンスの改善

提案するテキストの書式ルール

提案するtitle、description、impact、actionの内容はすべて、以下のルールに従う必要があります。

YAMLの引用符

YAML出力では、テキストフィールドの値を必ず二重引用符で囲んでください。値に:（コロン＋スペース）、#、[、]、{、または}が含まれる場合は必須です。これらの文字は、引用符で囲まれていないスカラー値でYAMLの解析エラーを引き起こします。値の中に二重引用符がある場合は、バックスラッシュ（\）でエスケープしてください。

良い例：description: "Removes the --path.home flag: it had no effect" 悪い例：description: Removes the --path.home flag: it had no effect

リンク

• 説明的なリンクテキストを使用します。URLをそのまま記載したり、「ここをクリック」としたりしないでください。
• 同一リポジトリ内のリンク：docsルートからの絶対パスを.md拡張子付きで指定します — [Migration guide](/deploy-manage/migration.md)
• リポジトリ間のリンク：scheme://path形式を使用します — [Kibana settings](kibana://management/settings.md)
• 外部リンク：完全なhttps:// URLを使用します — [RFC 7231](https://tools.ietf.org/html/rfc7231)
• 内部コンテンツにhttps://www.elastic.co/docs/...を使用しないでください。代わりに、リポジトリ間リンクまたは相対リンクを使用します。

インラインコード

フィールド名、パラメーター名、設定キー、APIエンドポイント、コマンド、特定の値にはバッククォートを使用します。例：index.refresh_interval、POST /_reindex。

コードブロック

• 言語識別子は必ず指定してください：yaml`、json、````bash、````console`
• Elasticsearch API リクエストには console を使用してください。Kibana Dev Console へのリンクが表示されます
• ブロックに docs-builder の置換変数が含まれる場合は、subs=true を追加してください
• 注釈に実質的な価値がある場合にのみコールアウト（<1>、<2>）を追加し、必ず対応する番号付きリストを続けてください

ステップ 7：出力を提示する

モード A： 各フィールドについて「現在 → 提案」のペアを提示してください。ユーザーが確認する前に変更を適用しないでください。

モード B： ディレクトリ内で処理した各ファイルの結果を提示してください。改善が必要なファイルについては、「現在 → 提案」のペアを示してください。最後に、処理したファイル数と改善が必要なファイル数をまとめてください。ユーザーが確認する前に変更を適用しないでください。

モード C： 提案するフィールドのテキストを提示し、その後にすぐにコピーできる changelog add または changelog note コマンドを示してください。コマンドを実行する前に、確認または調整を依頼してください。このスキルではファイルを作成せず、CLI が作成することを明確にしてください。

信頼度と前提のセクション

すべてのモード： 提案を提示した後、確認を求める前に、執筆者が提案の品質を評価できるよう、構造化された「信頼度と前提」セクションを含めてください。

## Confidence + Assumptions

### Least confident suggestions:
- [Field]: [Specific suggestion] — [Reason for uncertainty, e.g., "Limited PR context", "Ambiguous technical term", "Multiple interpretation options"]

### Type-title alignment issues:
- [File]: Type `[current-type]` + Title "[current-title]" — [Mismatch description]
  - **Option A:** Keep type, suggested title: "[new-title]"
  - **Option B:** Keep title, suggested type: `[new-type]`
  - **Recommendation:** [Which option with reasoning]

### Technical content assessment:
- [File]: Title "[current-title]" — [Technical assessment]
  - **Issue:** [Implementation-focused vs user-focused description]
  - **Suggested user-focused rewrite:** "[user-impact-focused title]"
  - **Reasoning:** [Why the rewrite better serves users]

### Terminology uncertainties:
- [Term/phrase]: Assumed [interpretation] — [Why uncertain, e.g., "Could be UI element vs feature name", "Missing domain context"]
- [Acronym]: Expanded to "[expansion]" — [Confidence level: High/Medium/Low based on PR context, `docs-flag-jargon-skill` patterns, or domain knowledge]

### Assumptions made:
- [Assumption]: [Rationale, e.g., "Normalized technical term based on common Elastic usage", "Inferred user impact from limited PR description"]

### Input limitations:
- [Issue]: [Impact on suggestions, e.g., "Couldn't fetch PR #1234 - title suggestions based on changelog content only", "No issue links - impact/action suggestions may be incomplete"]

### Resources referenced:
- [✓/✗] Canonical guidance: [Source used or fetch failure reason]
- [✓/✗] PR/Issue context: [What was available or missing]

信頼度の評価： ステップ 6 の基準を使用してください。不確実な点、前提の根拠、提案が読み込まれた正規のガイダンスに基づくものか、フォールバックパターンに基づくものかを記録してください。

デフォルトの動作： デフォルトでは提案のみを行います。ユーザーが明示的に確認した後に限り、変更をディスクに適用してください。変更を書き込んだ後、YAML を再解析して結果を検証してください。

同期に関する注意： ステップ 1 で正規のガイダンスを正常に読み込み、このスキルに埋め込まれたパターンとの間に重大な不一致を検出した場合は、その旨を出力で伝えてください。更新が必要と思われるパターンを示し、正規の情報源（https://www.elastic.co/docs/contribute-docs/content-types/changelogs）を直接確認するよう提案してください。