commit-message-generator

コミットメッセージ生成ツール

Datex Studio の機能ブランチで保留中の変更を確認し、ブランチへの記録に適した質の高いコミットメッセージを作成します。このスキルは dxs を介してサーバー側でブランチを読み取ります。git commit は実行しません。Datex Studio には独自のコミットフローがあり、ここで作成するメッセージはブランチのコミット UI（またはユーザーが選んだ後続の配信先）に貼り付けることを想定しています。

書き込みは1回だけ行い、それ以外は行いません。ブランチが Project Task に解決された場合、ブランチ URL をそのタスクの cr0c5_commit フィールドに記録し、どちらからでもリンクをたどれるようにします（Phase 5c）。それ以外は何も変更しません。ブランチ、設定、リポジトリはいずれも変更しません。

すべてのメッセージには、変更の根拠となった作業項目への参照を含める必要があります。この追跡可能性の確認は、書式上の細部ではなく、独立した主要フェーズです。references/traceability.md を参照してください。

参考資料

• ../datex-studio-shared/branch-setup.md — ブランチの選択（Branch ID Policy が適用されます。決して推測しないでください）
• references/traceability.md — チケット参照の検出、プロバイダーアダプター（CRM Project Task / Case / Project Request、Azure DevOps）、コンプライアンス判定、および Ref: の出力欄

前提条件

• Datex Studio リポジトリの機能ブランチの Branch ID
• 対象環境（既定値は prod。ユーザーが明示的に指示した場合に限り、--target qa または --target dev を指定してください）

実行モード

このスキルは2つのモードで実行されます。既定では対話型を使用してください。 プロンプトに「ワンショットモード」「このリクエストは自動化システムからのもの」「ユーザーはいない」などの明示的な合図がある場合、または名前を指定したツール経由で結果を届けるよう指示された場合に限り、ワンショットに切り替えてください。

	対話型	ワンショット
ユーザーがいる	はい	いいえ
出力先	メッセージとユーザーへの要約	メッセージのみ
曖昧な点がある場合	質問する	下記のルールに従って判断し、決して質問しない

重要な違いは品質ではなく、出力先です。対話型では、コミットメッセージと、メッセージに含めるべきでない内容をすべて伝える会話形式の要約という、2つの出力先があります。ワンショットでは1つだけです。そのため、ユーザーに伝えるはずだった所見は、メッセージに含めるか、失われることになります。そして所見が失われることこそ、コンプライアンス確認を形骸化させる結果です。

ワンショットのルール

1. 質問しないでください。処理を止めないでください。 必ずメッセージを作成してください。回答する人はいないため、質問は何も返さない失敗と同じです。

2. ユーザーに見せるべき観察事項をメッセージに含めてください。 Description に ⚠ 行として記載します。チケットがすでにクローズされている、チケットが兄弟ブランチを主張している、解決されたタイトルが commitTitle と一致しない、メッセージが事後に作成された、といった内容です。対話型ではこれらはサマリーに残しますが、ワンショットではメッセージに含めるか、記載しないかのどちらかです。

3. 参照は慎重に扱ってください。 確認が必要だった参照を引用してはいけません。具体的には、次のとおりです。

   • 逆方向の関連検索またはチケット番号検索で候補が 2 件以上 返された場合 → UNVERIFIED。どれかを選んではいけません。⚠ 行に候補を記載し、Ref: 行は出力しません。
   • キーワード検索でヒットした項目を、対話型なら確認のために提示する場合 → 採用しないでください。判定は MISSING です。人間が作業を完了できるよう、⚠ 行に類似候補を記載してください。
   • 自ら参照を明示しているものだけを採用してください。つまり、プロンプトまたはコミットフィールドに明示された ID やディープリンク、または逆方向の関連検索で単一の候補が見つかった場合です。

   間違ったリンクを確認なしでコミットすることは、正直に MISSING とするよりも悪いことです。誰も再確認しない監査証跡に、推測が事実として残ってしまいます。

4. ブランチ ID はプロンプトから取得してください。 Branch ID Policy の「質問する」という指示は適用できません。ブランチ ID が指定されていない場合は、何も出力せず、依頼を処理できないことを報告してください。文脈から推測してはいけません。

5. プロンプトで指定されたツールを使って処理してください（例：SaveCommitMessage）。指定されたツールをこのセッションで利用できない場合は、メッセージを最終出力として返し、ツールがなかったことを伝えてください。結果を破棄してはいけません。

⚠ 行を読みやすく保つ

注意事項が複数重なることもありますが、開発者が実際に読むセクションは Description です。有用な内容にしてください。

• ⚠ 行は最大 3 行にしてください。 それを超える場合は、参照への信頼性に最も影響する 3 件を残し、残りは 1 行にまとめてください。
• 影響の大きい順に並べてください。 まず追跡可能性の問題（参照の欠落／未検証／相違）、次にブランチ状態の警告（空、事後）、最後にコードレビューの行です。
• 関連する観察事項は自然にまとめ、ほぼ同じ内容を重複して出さないでください。「チケットはクローズされており、ブランチ 83001 も主張している」は 2 行ではなく 1 行にします。

ワークフロー

[Phase 0: Mode]
Interactive (default) or one-shot? One-shot = explicit signal in the prompt.
One-shot: never ask, never block, promote observations into the message,
be conservative about references, deliver via the named tool.
        |
[Phase 1: Setup]
Get branch ID from user (branch-setup.md rules; one-shot: from the prompt)
Confirm target environment (default: prod)
        |
[Phase 2: Gather]
dxs source branch show <id>        → metadata (author, status, app, commit title/description)
  └─ GUARD: is this a feature branch? If isCommit/isRelease/isMainBranch, STOP and ask.
dxs -b <id> source changes         → inventory of added/updated/deleted configs
dxs -b <id> source changes --with-diffs → actual diffs for analysis
dxs -b <id> source deps            → dependency surface (optional, when diffs are ambiguous)
        |
[Phase 3: Trace]  ← traceability compliance check
Scan prompt + commitTitle/commitDescription for a ticket ref, AND ask CRM which
Project Task claims this branch (reverse edge on cr0c5_commit) — always both.
Resolve it against its provider (CRM Project Task / Case / Project Request, Azure DevOps).
Verdict: COMPLIANT | UNVERIFIED | MISSING. Keep the resolved ticket's description —
it feeds Phase 4's analysis and its divergence check. Warns, never blocks.
        |
[Phase 4: Analyze]
Read each diff, informed by the ticket's stated requirement. Identify the dominant
theme (feature / bug fix / refactor / chore).
Flag anything that looks like a significant issue (bug, security concern, dead code) —
do NOT list the issues in the commit message; note that a review is recommended instead.
        |
[Phase 5: Draft Message]
Build the title + body per the "Output Format" section, including the Ref: lines.
        |
[Phase 5b: Deliver]  ← one-shot only
Call the delivery tool the prompt named (e.g. SaveCommitMessage).
        |
[Phase 5c: Stamp reverse edge]  ← both modes, only when a Project Task resolved
dxs crm commit-ref append <task> <branch-url> --label <app>  (idempotent)
        |
[Phase 6: (optional) Persist to knowledge base]
If CreateKnowledgeNode is available in this session, save the message as an Article
under CommitMessages/<Org>/<App>/<BranchId>_<yyyyMMdd>_<hhmm>.md. Otherwise print
the intended path and skip.
        |
Return the message to the user.

フェーズの詳細

フェーズ 1：セットアップ

0. モードを判断します（「実行モード」を参照）。プロンプトでワンショットが指定されていない限り、以下はすべて対話型を前提としています。
1. ユーザーからブランチ ID を取得します。branch-setup.md の Branch ID Policy に従ってください。以前のセッションでブランチ ID が示されていても、推測せず必ず質問します。 ワンショット： ブランチ ID はプロンプトから取得します。指定されていない場合は停止し、依頼を処理できないことを報告します。推測してはいけません。
2. 対象環境を判断します。ユーザーから別の指定がない限り、デフォルトは prod です。dxs では --target prod|qa|dev を受け付けます。指定がない場合は prod が使用されます。

フェーズ 2：情報収集

読み取り専用で相互に独立しているため、可能な場合は 4 つのコマンドを並列で実行します。

dxs source branch show <BRANCH_ID>
dxs -b <BRANCH_ID> source changes
dxs -b <BRANCH_ID> source changes --with-diffs
dxs -b <BRANCH_ID> source deps

さらに 4 つのコマンドも把握しておくと便利です。上記の 4 つだけでは判断が難しい場合に使用してください。

# Confirm a single config really is unchanged (cheap second opinion on a no-op)
dxs source diff --from <BASE_BRANCH_ID> --to <BRANCH_ID> --config <referenceName>

# Upstream changes in base not yet pulled into this branch (proves drift)
dxs source diff --branch <BRANCH_ID>

# Dependency deltas WITH direction — `source deps` alone has no notion of it
dxs source deps-diff --from <BASE_BRANCH_ID> --to <BRANCH_ID>

# Linked Azure DevOps work items (note: -b, not positional)
dxs -b <BRANCH_ID> source workitems --description

--from 引数に指定する base_branch_id は、source changes の応答から取得します。

source workitems は、ブランチ単位の DevOps リンクが設定されていないテナントでは、空のリストと devops_organizations: [] を返します。ここでテストしたすべてのブランチが該当し、そのうち 1 つは ADO 作業項目で明示的に指定されています。フェーズ 3 で確認してください。ただし、結果が空の場合は「データなし」として扱い、「作業項目が存在しない」と解釈してはいけません。

ガード：本当にフィーチャーブランチか確認する

何かを分析する前に、branch show を確認してください。このスキルは、まだコミットされていない作業についてメッセージを作成します。他の種類のブランチは、すでにコミット済みであるか、そもそも開発作業ではありません。

フラグ	内容	対応
isFeatureBranch: true、isCommit: false	フィーチャーブランチ、作業が保留中	続行する
isCommit: true（ステータスが WorkspaceHistory）	コミットのスナップショット — すでにコミット済みで、commitTitle と commitDescription が付いています	停止して確認する
isRelease / isCurrentRelease / isMainBranch	リリースまたはメイン	停止して確認する

フィーチャーブランチ以外の場合は、そのブランチが実際に何であるかを伝え、既存の commitTitle と commitDate を引用して、ユーザーが別のブランチを意図していたのか、それとも遡及的なメッセージを本当に求めているのか確認してください。黙って続行してはいけません。すでにコミット済みのスナップショット向けに作成したメッセージは貼り付ける場所がなく、作業がまだ保留中であるかのように読めてしまいます。

ユーザーがそれでも作成することを確認した場合は、通常どおり続行し、要約に（メッセージには含めず）遡及的な内容であることを記載してください。

一度限りの実行： 確認する相手がいないため、続行します。ただし、その旨をメッセージに記載してください。既存の commitTitle と commitDate を含む遡及的な ⚠ 行（出力形式を参照）を追加して、受け取り側のシステムが、コミット待ちの作業ではなく、すでにコミット済みの作業について述べたものだと判別できるようにしてください。

目的：

• branch show — 作成者、ステータス、および上記のガードで確認するブランチ種別フラグを取得します。また、Phase 3 のチケット参照を探す主な手掛かりとなる commitTitle / commitDescription も取得します。name や description は返しません。referenceName はアプリケーション定義名（例：FootprintManager）であり、applicationDefinitionId はリポジトリ ID です。

• source changes — 保留中の設定の一覧です。

  changes_by_type は常に空です。無視してください。 created / updated / deleted の各バケットは、実質的な設定更新が3件あるブランチでも空で返されます。all_changes を読み取ってください。各バケットからは何も分かりません。

  all_changes の行は、作業がある証拠ではありません。 エントリごとに --with-diffs で取得する has_changes を確認してください。これが正式な判定基準です。

  シグナル	意味
  has_changes: true	実際の内容変更です。作業があります。
  has_changes: false	変更なし。チェックアウト時の生成物またはメタデータのみで、設定はベースと同一です。
  has_changes: null（modificationTypeId: "add" の場合）	新しい設定で、比較対象のベースがありません。作業として扱ってください。

  modificationTypeId は参考情報としては弱いものです。"unspecified" は常に has_changes: false（チェックアウト済みだが、編集されていない）を意味していましたが、"update" でも has_changes: false になることがあります。タイプではなく、has_changes を信頼してください。

  すべてのエントリに変更がなければ、そのブランチは空です — 以下の「空のブランチ」を参照してください。

• source changes --with-diffs — 分析対象となる実際のコード／設定の内容と、エントリごとの has_changes フラグを取得します。

Guard：空のブランチ

機能ブランチが正当に開かれていて、設定が all_changes に列挙されていても、作業がまったくないことがあります。開発者がデザイナーで設定をチェックアウトしたものの、編集内容を一度も保存していないケースです。すべてのエントリーで has_changes: false が返されます。

これは明示的に確認するだけの頻度で発生するため、このようなブランチについて伝えるべき最も重要なことです。この場合は、次のようにします。

1. 主張する前に、確認してください。--with-diffs で has_changes: false と報告されることが一つの手がかりです。dxs source diff --from <baseBranchId> --to <BRANCH_ID> --config <referenceName> が unchanged を返すことも、手軽な第二の確認方法です。 ベースブランチ ID は source changes のレスポンスにある base_branch_id です。
2. 事実を明確に伝え、変更を捏造しないでください。 実際には存在しない作業を無理に説明するのではなく、空のブランチとしてタイトルを付けます。命令形は当てはまりません。名前を付けるべきアクションがないためです。したがって、ここでは説明的なタイトルが適切であり、Conventional Commits のヒントよりも優先されます。
3. チケットが解決済みの場合（出力形式を参照）、分岐の警告行ではなく「作業なし」の⚠行を使います。正しく関連付けられたチケットがある空のブランチは、参照先が間違っているのではなく、作業が保存されていない状態です。
4. コードレビューの⚠行は追加しないでください。このフラグは、差分内で見つかった問題に使います。差分がなければレビューするものもありません。空のブランチに関する警告には、すでにタイトルの先頭に⚠が付いています。
5. どの設定をチェックアウトしたかを記録してください。チケットが示すものとまったく同じ設定であれば、作業が始まったものの失われた可能性があり、最初から始まっていなかったわけではないと推測できるため、ユーザーに伝える価値があります。

• source deps — 外部依存関係（このブランチが参照するコンポーネントパッケージ）です。差分にブランチ外の型やフローが含まれている場合や、依存関係の更新が変更の大部分を占める場合に役立ちます。行は unique_identifier と version の組み合わせで識別されます（単一の整数行 ID はありません）。branch_id はパッケージを保持するブランチで、解決できなかった場合は null です。version_info には version_name、commit_title、created_date、is_latest が含まれます。--tree を付けると children と depth が追加されます。is_direct は常にこのブランチの直接依存関係を意味するため、ネストされたノードではすべて false になります。--tree の使用には dxs ≥ 0.5.4 が必要です。それより古いビルドでは、終了コード 0 で空のツリーが返されていました。

フェーズ 3：トレース（追跡可能性のコンプライアンスチェック）

このブランチがどの作業項目に紐づいているかを特定します。完全なルール、プロバイダーアダプター、コマンド構文については references/traceability.md を参照してください。流れは次のとおりです。

1. 検出 — 優先順位に従ってスキャンします。まずユーザーのプロンプト、次にフェーズ 2 の commitDescription と commitTitle です（この 2 つのフィールドが対象のすべてです。ブランチに名前や説明はありません）。候補にはいくつかの形式があります。CRM のディープリンク（…&etn=msdyn_projecttask&id=<guid>）、ケース番号（C260612_0005）、プロジェクトリクエスト（PR-260610_003）、ADO の作業項目（AB#118432）、または単独の GUID です。解決に進む前に、候補をすべて収集します。
2. 逆方向の関連検索 — このブランチを関連付けている Project Task を検索します。 dxs crm odata msdyn_projecttasks -f "contains(cr0c5_commit,'/<BRANCH_ID>/')" 1 件だけ見つかった場合は、それを確定情報として扱います。チケットがリンクを明示しているため、タイトルからの推測より優先されます。手順 1 で見つかった場合も、必ず実行してください。あるチケットがブランチを指し、別のチケットがそのブランチを関連付けている状況を検出できる唯一の方法です。 0 件でも何も証明されません（このフィールドは手動で管理されており、値がないことも多いため）。その場合は次に進みます。詳細とスラッシュによる境界指定のルールについては references/traceability.md を参照してください。 ワンショットの場合： 2 件以上見つかった場合は UNVERIFIED とし、候補を示して Ref: は出力しません。
3. 検索 — 手順 1 と 2 のどちらでも見つからなかった場合に限り、コミットタイトルを使った CRM キーワード検索を最大約 2 回行い、ADO の作業項目については dxs devops search を実行します。 見つかった候補はユーザーに確認を求めます。検索結果を黙って採用してはいけません。 ワンショットの場合： 検索結果は決して採用しません。確認を得る手段がないためです。 判定は MISSING とし、人が作業を完了できるよう、⚠ 行に近似候補を示します。
4. 解決 — プロバイダーアダプターを介してレコードを取得します。説明フィールド（msdyn_descriptionplaintext、ケースの description、ADO の description）は保持してください。これらには「依頼された内容」が記されており、フェーズ 4 の精度向上に役立ちます。
5. 判定 — COMPLIANT（発見して解決済み）、UNVERIFIED（発見したが、検索に失敗したかアダプターがない）、または MISSING（何も見つからない）です。

このチェックは警告を出すだけで、処理をブロックすることはありません。 UNVERIFIED と MISSING の場合は、タイトルに ⚠ の接頭辞を付け、本文に 1 行追加します。メッセージ全体は通常どおり生成します。

健全性チェックの所見は、出力先ごとに分けます。相違 — チケットの説明と差分の内容が明らかに異なる場合 — はメッセージに ⚠ 行として含めます。コミットを読む人が誤ったリンクに気づけるためです。それ以外（チケットがすでにクローズされている、別のブランチがチケットを関連付けている、解決したタイトルが commitTitle と一致しない場合）は、要約でのみユーザーに伝えます。references/traceability.md の「健全性チェック」を参照してください。

フェーズ 4：分析

差分を読みます。ブランチの意図を1文で説明できる程度に理解し、レビュー担当者が知っておくべき点がないか確認します。

フェーズ 3 でチケットを解決した場合は、まずその説明を読み、判断の枠組みとして使います。チケットには依頼内容が書かれ、差分には実装内容が示されています。実装された内容を説明します。ただし、要件の用語と「理由」を説明に活用します。

乖離の確認。 チケットに記載された要件と、差分が実際に行っている内容を比較します。両者が明らかに異なる作業を示している場合、コミットメッセージでは必ずチケットではなく差分を説明し、乖離を示す ⚠ 行を追加します（「出力形式」を参照）。乖離は、人が確認すべき次のいずれかを意味します。ブランチが誤ったチケットに紐づいている、または依頼された内容とは別の作業がブランチで行われた、ということです。

該当する基準は具体的に判断してください。これは、請求フィルターのチケットに対して依存関係のバージョンを同期している場合や、ピッキングの不具合チケットに対してブランチが空の場合など、対象分野が一致しないときに適用します。ブランチが部分的な実装である場合、途中でリファクタリングを行っている場合、または隣接する不具合を修正している場合だけでは適用しません。それらは通常のことです。判断に迷う場合は適用せず、代わりに概要でその旨を述べてください。

変更された設定ごとに、次の点を簡潔に評価します。

• 変更は一貫したテーマ（機能 X、不具合修正 Y、リファクタリング Z など）に沿っていますか？
• ロジックエラー、未処理のエッジケース、エラーハンドリングの不足はありませんか？
• セキュリティ上の懸念事項はありませんか？式での未サニタイズ入力、動的フィルターのインジェクション経路、パラメーター内の機密データなど。
• 設計上の問題はありませんか？デッドコード、設定間で重複するロジック、明らかに壊れたパターンなど。

重大な問題を見つけた場合、コミットメッセージに列挙してはいけません。代わりに、タイトルに警告フラグを付け、本文にコードレビューを推奨する1行を追加します（「出力形式」を参照）。問題の列挙には branch-code-reviewer スキルを使用します。このスキルの目的は変更内容を説明することです。

フェーズ 5：メッセージの作成

3つのセクションからなるメッセージを作成します。後続のパーサーは、空行で出力を分割します。

1. タイトル — 1行目。Conventional Commits 形式で、約72文字にします。フェーズ 3 が MISSING／UNVERIFIED を返した場合、またはフェーズ 4 でレビューが必要な事項が見つかった場合は、先頭に ⚠ を付けます。懸念事項の数にかかわらず、接頭辞は1つだけです。
2. 説明 — 2段落目（次の空行まで）。人が読める簡潔な概要を記載し、その後に ⚠ の行、続けて Ref: の行を記載します。開発者が Datex Studio のコミットダイアログで確認・編集するのはこの部分だけなので、内容を絞り込み、参照情報も必ずこの段落内に含めます。Ref: の前に空行を入れると、リリースノートに移動して表示されなくなります。
3. リリースノート — 3段落目以降のすべて。詳細な本文です。対話形式の場合、開発者には表示されず、後続のリリースノートツールのみが使用します。既存の SaveCommitMessage による一括配信では、別個のパラメーターがないため、内容はツールの description フィールドに含まれます。そのため、ツール専用のメモ書きではなく、人が読んでも自然な文章にしてください。

正確な形式は、以下の「出力形式」を参照してください。各セクションは適切な行幅で折り返してください。

CLI によるコミットノートの受け渡し

Studio のコミットに詳細セクションを保存する場合は、commit-release-notes を使用します。このスキルでは、簡潔な説明と UTF-8 のノートファイルを分離し、実装済みの CLI による転送および読み戻しについて説明しています。メッセージの作成依頼だけでは、コミットの実行は許可されません。この CLI 経路を使っても、以下に定める一括配信の契約は変更されません。

フェーズ 5b（ワンショットのみ）：送信する

ワンショットモードでは、メッセージを依頼元のシステムに届ける必要があります。文章として返すだけでは送信になりません。

プロンプトで指定されたツールを呼び出します。既知の送信ツールは SaveCommitMessage です。

パラメーター	型	渡す値
branch_id	整数	ブランチ ID — 文字列ではなく数値
title	文字列	タイトル行。該当する場合は ⚠ の接頭辞を含めます
description	文字列	メッセージ全体 — タイトル、空行、説明の段落、空行、リリースノート
environment	列挙型	production | qa | dev — CLI の prod ではありません

4 つすべてが必須です。environment にはデフォルト値がありますが、それでも渡す必要があります。

正しく行うべき点は 3 つあります。

1. description はメッセージの中間部分だけではなく、全文です。 その仕様は「最初の行は簡潔にし、その後に空行を置き、追加情報を続ける」というものです。標準的な件名と本文の形式です。そのため、タイトル行は title と description の最初の行に、1 回ずつ記載します。この重複は意図されたものなので、削除しないでください。
2. 3 つのセクションは 2 つのフィールドにまとめます。 リリースノート専用のパラメーターはないため、リリースノートは説明の段落の後に description に含めます。セクションを後続処理で分割できるよう、空行による区切りは正確に保ってください。
3. 環境名をマッピングします。 dxs は --target prod を使いますが、このツールでは production が必要です。qa と dev はそのまま使えます。prod を送るとスキーマ検証に失敗します。

title の ⚠ 接頭辞は残してください。 これは確定事項であり、見落としではありません。非 ASCII 文字だから、あるいは後続の UI での表示を懸念して削除しないでください。この接頭辞は人による確認が必要であることを示します。黙って削除されるタイトルより、表示が多少崩れるタイトルのほうが適切です。

指定されたツールがセッションで利用できない場合、結果を黙って破棄しないでください。メッセージ全体を最終出力として返し、送信ツールが見つからなかったことを明確に伝えてください。そうすれば呼び出し元は、生成ではなく送信に失敗したと判断できます。ツールを呼び出す場合も、メッセージを最終出力として返してください。コストはかからず、トランスクリプトから失敗を診断しやすくなります。

対話モードでは、このフェーズ全体を省略してください。

Phase 5c：逆方向のエッジを記録する（両方のモード）

Phase 3 でProject Taskが解決された場合は、このブランチの Studio URL をそのタスクの cr0c5_commit に書き込み、チケット側からもリンクを確認できるようにします。これにより、 次のブランチで Phase 3 の逆方向エッジ検索が機能します。現在、このフィールドが手動で 管理されているタスクは約 145 件にすぎません。

dxs crm commit-ref append <TASK_GUID> \
  "https://wavelength.host/studio/application/<BRANCH_ID>/home" \
  --label <ApplicationDefinitionName>

これは、以下の条件を満たす場合に、対話モードとワンショットモードの両方で自動的に実行されます。

• 判定結果が COMPLIANT であること。推測を記録しないため、UNVERIFIED または MISSING の場合は記録しません。また、
• 解決されたレコードが Project Task であること。Cases、Project Requests、Internal Datex Tickets、ADO の作業項目には cr0c5_commit フィールドがないため、対象外です。

重要な詳細：

• 冪等性があります。 URL がすでに存在する場合、コマンドは何も書き込まず、 changed: false と reason: "value already present" を返します。 ブランチでスキルを再実行しても安全です。ガードが無効になり、フィールドが際限なく 増えるため、--allow-duplicate は渡さないでください。
• --label はアプリケーション定義名（branch show の referenceName。例： FootprintManager）です。ラベル行が URL の上に置かれる、フィールド内ですでに 使われている規則に準拠しています。
• 書き込みに失敗してもメッセージは無効になりません。 失敗を報告して処理を続けて ください。成果物はコミットメッセージであり、記録は副作用です。
• 対話モードの要約では、結果（changed: true / false）を報告してください。 ワンショットモードでは、書き込みに失敗した場合に限り言及してください。成功した記録は ⚠ 行にするほどのものではありません。

無人実行でも安全な理由。 ワンショットモードでは、明示的な ID またはリンク、あるいは 逆方向エッジが 1 件だけ見つかった場合に限り参照を採用するため、キーワード検索から 推測しただけのタスクを記録することはありません。書き込みにも独自のルールを設ける 必要はなく、保守的な解決ルールがそのまま適用されます。

Phase 6（任意）：ナレッジベースに保存する

このセッションで CreateKnowledgeNode ツールが利用可能か確認してください。利用可能な場合は、 作成したメッセージを、タイプが Article のナレッジプロダクトとして保存します。

• パス： CommitMessages/<Organization>/<ApplicationDefinitionName>/<BranchId>_<yyyyMMdd>_<hhmm>.md
  • 例：CommitMessages/Colorado Cold Connect/Footprint Cloud/67388_20260127_1419.md
  • フォルダ階層が存在しない場合は作成してください。
• タグ： キー branch、値はブランチ ID。
• スキーマ： CreateKnowledgeNode を呼び出す前に、article アーティファクトタイプのスキーマを確認してください。 ナレッジベースのバージョンによってフィールド名が異なる場合があります。

2 つの名前はそれぞれ別のコマンドから取得します。branch show だけでは両方を取得できません。

名前	取得元
<Organization>	dxs auth status → active_identity.organization（例：Datex）。dxs source repo list の各行では organization.name としても確認できます。
<ApplicationDefinitionName>	dxs source branch show → referenceName（例：FootprintManager）。これはリポジトリの name と同じで、applicationDefinitionId はリポジトリの id と同じです。

現在のローカル時刻を yyyyMMdd_hhmm（24 時間表記）に変換してファイル名に使用してください。

CreateKnowledgeNode が利用できない場合（CLI のみのセッションの多くが該当します）は、この手順を スキップしてください。手動で保存できるよう、保存先となるパスを出力してください。

出力形式

<Title — single line. Conventional commits style. Prefix with ⚠ when Phase 3 or
Phase 4 surfaced something that warrants attention.>

<Description — one paragraph, ~1-3 sentences, summarizing the change in
human terms. This is what the developer sees and edits in the commit dialog,
so keep it focused on the "what" and "why" at a high level. Then, still inside
this same paragraph and in this order:
  ⚠ lines, when applicable — use these four templates verbatim:
    "⚠ Recommend running a code review before merging — <one-line reason>."
    "⚠ No ticket reference found — this commit is untraced. Add a Project Task,
     Case, or work item link before committing."
    "⚠ Ticket reference <ID> could not be verified — <one-line reason>."
    "⚠ Referenced ticket describes different work than these changes — <ticket
     subject> vs <what the diffs do>. Verify the reference before committing."
    "⚠ Branch contains no changes — <n> config(s) are checked out but identical
     to base. The work described by the referenced ticket does not appear to
     have been saved."

  One-shot only — promoted from what would have been the chat summary. Use only
  in one-shot mode; interactively these belong in your summary:
    "⚠ Referenced ticket is <state> — verify it is the right reference."
    "⚠ Ticket reference is ambiguous — <n> candidates matched (<ids or
     subjects>); none adopted. Add an explicit link before committing."
    "⚠ No ticket reference found; closest matches were <candidates>. Not adopted
     without confirmation — add a link before committing."
    "⚠ This message is retroactive — the branch was already committed on <date>
     as \"<existing commitTitle>\"."
  Ref: lines, when a reference resolved — two lines per reference:
    "Ref: <record type> — <resolved title>"
    "<full deep link, bare and unwrapped>">

<Release Notes — the detailed body, never shown to the developer. Typically
two paragraphs:
(1) what was added/changed/deleted at the config level — counts and notable
    config names;
(2) how it works at a high level — one or two sentences explaining the
    mechanism, not individual line changes.>

3つのセクションは空行で区切られています。パーサーはこの空行を境界として使うため、省略したり、セクション内に余分な空行を入れたりしないでください。

例（クリーンなブランチ、トレース済み）：

feat(mobile): add Mobile Configurator hub for per-warehouse settings

Adds a new Mobile Configurator hub with sub-tabs for warehouses, owners,
order classes, and equipment types, so Settings exposes per-warehouse
configuration to mobile users.
Ref: Project Task — Mobile Configurator for Warehouse Settings
https://datexcorp.crm.dynamics.com/main.aspx?appid=ee829a66-fb63-ea11-a811-000d3a37800e&forceUCI=1&pagetype=entityrecord&etn=msdyn_projecttask&id=52c6bf79-36d5-49e7-9657-5426b2c68c0f

Adds 29 new configs: one hub (mobile_configurator_hub), four sub-tabs
(Warehouses, Owners, Order Classes, Equipment Types), and the grids/editors/
flows that back them. Existing Settings navigation is updated to expose the
hub.

The hub reads/writes warehouse-scoped settings via a new storage collection
and a pair of crud flows; per-owner and per-equipment-type overrides are
layered on top in the respective sub-tabs.

例（フラグ付きブランチ — レビュー上の懸念 + ケースへのトレース済み）：

⚠ fix(udf): correct TypeId remap in custom_field_editor

Fixes a UDF type-remap bug where Text fields rendered as Selection lists,
with a small refactor that inlines a datasource and refreshes three hubs
after the editor closes.
⚠ Recommend running a code review before merging — the save flow has
duplicated error handling that can show two dialogs on failure.
Ref: Case C260612_0005 — Text UDFs render as Selection list
https://datexcorp.crm.dynamics.com/main.aspx?appid=ee829a66-fb63-ea11-a811-000d3a37800e&forceUCI=1&pagetype=entityrecord&etn=incident&id=6364eb8e-6266-f111-a825-000d3a3037d2

Updates custom_field_editor to remap TypeId 5→1 so "Text" UDFs no longer
render as "Selection list". Inlines ds_get_custom_field_options into
custom_field_options_grid (deletes the standalone datasource) and adjusts
three hubs to await the editor dialog and refresh on close.

例（トレース済みだが、チケットが作業内容と一致しない場合）：

⚠ chore(deps): sync Carriers, Manifesting, and PackVerification packages

Pulls in the 2026-07-30 builds of three component packages — Carriers,
Manifesting, and PackVerification — with no application configuration changes
of its own.
⚠ Referenced ticket describes different work than these changes — "Billing
Queries" (custom billing contract line filters) vs a dependency version sync.
Verify the reference before committing.
Ref: Project Task — Billing Queries
https://datexcorp.crm.dynamics.com/main.aspx?appid=ee829a66-fb63-ea11-a811-000d3a37800e&pagetype=entityrecord&etn=msdyn_projecttask&id=5ed1a581-9d40-4c05-87ef-a12902234fc5

Updates 1 config: appConfig, a metadata-only change recording the new
dependency versions. No configs added or deleted.

Dependency versions move from the 2026-07-29 afternoon builds to the
2026-07-30 morning builds. The other 56 dependencies are unchanged.

メッセージが説明しているのはチケット（請求フィルター）ではなく、差分（パッケージの同期）です。これらを結び付けるのが ⚠ 行です。

例（空のブランチ — 設定はチェックアウトされたが、編集されていない場合）：

⚠ chore(manufacturing): no changes to commit — branch is empty

Two configurations are checked out on this branch —
manufacturing_order_lines_grid and order_line_manufacturing_confirmation_editor
— but both are identical to base, so there is nothing to commit.
⚠ Branch contains no changes — 2 configs are checked out but identical to base.
The work described by the referenced ticket does not appear to have been saved.
Ref: Case C260714_0012 — Manufacturing orders only look at the Staging Location when consuming materials
https://datexcorp.crm.dynamics.com/main.aspx?appid=ee829a66-fb63-ea11-a811-000d3a37800e&pagetype=entityrecord&etn=incident&id=a670499b-947f-f111-9b47-7ced8d70177e

Updates 0 configs. Both entries in the pending list report has_changes: false;
the only difference from base is the branch-local config row id assigned at
checkout. No configs added or deleted.

The two checked-out configs are exactly the ones the referenced case implicates,
which suggests the work was started in the designer but never saved.

これは、チケットの参照先は正しく、作業が単に存在しないため、分岐の ⚠ 行ではなく「変更なし」の ⚠ 行を使っている点に注意してください。レビュー対象の差分がないため、コードレビュー行もありません。

例（ワンショット — 観察事項をメッセージに反映）：

上記のトレース済みの例と同じブランチですが、無人で生成されています。クローズ済みチケットと兄弟ブランチに関するメモは、通常ならチャットでユーザーに伝えられますが、ワンショットの場合はここに記載するか、どこにも記載されません。

⚠ feat(pallet-build): accept tote ID alongside cart and job IDs

Extends pallet build with serials so a tote barcode works anywhere a cart or
job number does, moving toward a single barcode carrying the whole flow.
⚠ Referenced ticket is Inactive (closed) and also claims branch 83001 — verify
it is the right reference.
⚠ Recommend running a code review before merging — widening the job lookup in
reset_pickJob_fields makes its silent multi-match early-return more reachable.
Ref: Project Task — Update to use tote ID instead of job ID
https://datexcorp.crm.dynamics.com/main.aspx?appid=ee829a66-fb63-ea11-a811-000d3a37800e&pagetype=entityrecord&etn=msdyn_projecttask&id=3e6b6a20-b38b-4265-b34a-8578f7f53329

Updates 3 configs: two flows (get_orderJob_by_cart, reset_pickJob_fields) and
one hub (pallet_build_with_serials_hub). No configs added or deleted.

Both flows widen their jobs_header predicates to match on toteId in addition to
jobId and cartId, and reset_pickJob_fields now normalizes its inparam to the
real jobId so downstream lookups are unaffected by which barcode was scanned.

クローズ済みチケットと兄弟ブランチに関する2つの観察事項が、2行ではなく1つの ⚠ 行にまとめられている点と、トレーサビリティがコードレビュー行より先に記載されている点に注意してください。

SaveCommitMessage 経由で配信すると、そのメッセージは次のように対応付けられます。

{
  "branch_id": 82931,
  "title": "⚠ feat(pallet-build): accept tote ID alongside cart and job IDs",
  "description": "⚠ feat(pallet-build): accept tote ID alongside cart and job IDs\n\nExtends pallet build with serials so a tote barcode works anywhere a cart or\njob number does, moving toward a single barcode carrying the whole flow.\n⚠ Referenced ticket is Inactive (closed) and also claims branch 83001 — verify\nit is the right reference.\n⚠ Recommend running a code review before merging — widening the job lookup in\nreset_pickJob_fields makes its silent multi-match early-return more reachable.\nRef: Project Task — Update to use tote ID instead of job ID\nhttps://datexcorp.crm.dynamics.com/main.aspx?...&etn=msdyn_projecttask&id=3e6b6a20-b38b-4265-b34a-8578f7f53329\n\nUpdates 3 configs: two flows (get_orderJob_by_cart, reset_pickJob_fields) and\none hub (pallet_build_with_serials_hub). No configs added or deleted.\n\nBoth flows widen their jobs_header predicates to match on toteId in addition to\njobId and cartId, and reset_pickJob_fields now normalizes its inparam to the\nreal jobId so downstream lookups are unaffected by which barcode was scanned.",
  "environment": "production"
}

branch_id は数値です。タイトルは title と description の1行目の2か所に表示されます。3つのセクションはすべて description 内にあり、後で再び分割できるよう、空行で区切られています。

例（未トレースのブランチ — MISSING 判定）：

⚠ refactor(shipping): consolidate rate lookup into a single flow

Collapses three near-duplicate rate-lookup flows into one parameterized flow
and repoints the four callers at it.
⚠ No ticket reference found — this commit is untraced. Add a Project Task,
Case, or work item link before committing.

Deletes ds_rate_lookup_ltl, ds_rate_lookup_parcel, and ds_rate_lookup_ftl;
adds ds_rate_lookup with a carrier-mode parameter. Four callers updated.

The consolidated flow branches on carrier mode internally, so callers pass a
mode instead of choosing a flow.

ヒント

• タイトルの文体 — Conventional Commits のスタイルに従い、命令形にします （feat(scope): add X、fix(scope): correct Y、refactor(scope): simplify Z）。 スコープは省略可能です。1つの領域が明らかに大部分を占める場合に使用してください。
• 差分を行ごとに言い換えない — 差分がすでに信頼できる情報源です。メッセージの役割は、人が30秒で要点をつかめるようにすることです。
• 依存関係のみのコミット — 同期コミットは、実質的な設定変更がなく、依存関係のバージョンが変わった場合に該当します。「依存関係の更新を取り込む：」と記述します。まず方向を確認してください — dxs source deps-diff --from <baseBranchId> --to <BRANCH_ID> は、バージョンがどちらの方向に移動しても「updated」と報告します。バージョンが下がっている場合、ブランチを作成してからベースブランチが進んだことを意味します。これは上流のドリフトであり、このブランチが行った作業ではないため、メッセージに含めてはいけません。同期に該当するのは前方向への変更だけです。dxs source diff --branch <BRANCH_ID> は、まだ取り込まれていない上流の変更を一覧表示し、ドリフトを確認できます。
• トレーサビリティは警告であり、ゲートではありません — MISSING 判定でも、メッセージが抑止されることはありません。⚠ 行を付けて出力し、判断は開発者に委ねてください。
• チケット参照を決して捏造しない — 実際に解決したレコード、またはユーザーから提供されたレコードのみを記載してください。自信満々に間違ったリンクを示すより、正直に ⚠ を付ける方がよいです。
• プロジェクトタスクには人が読みやすい番号がありません — 識別子は GUID なので、共有可能な形式はディープリンクのみです。ケース（C260612_0005）とプロジェクトリクエスト（PR-260610_003）には読みやすい ID があるため、利用できる場合はそちらを優先してください。
• 作成者の表記 — ブランチの作成者は branch show の出力に含まれます。メッセージに作成者の行を追加する必要はありません（Datex Studio はブランチ自体に作成者を記録します）。
• git commit は決して実行しない — Datex Studio でのコミットは git 経由ではなく、プラットフォームの UI から行います。このスキルによる書き込みは Phase 5c の cr0c5_commit トレーサビリティスタンプのみであり、ブランチ、その設定、リポジトリを変更することはありません。
• commit-ref append に --allow-duplicate を決して渡さない — 重複防止機能により、ブランチ上でこのスキルを安全に再実行できます。

よくある間違い

間違い	修正方法
セッション中に以前表示されたブランチ ID を、確認せずに使う	ブランチ ID ポリシーに従ってください。明示的に選択された ID だけを再利用し、それ以外の場合は確認します（ワンショットの場合はプロンプトから取得し、決して推測しません）
ワンショットモードで質問する	回答する人はいません。質問は、気づかれないまま失敗するだけです。ワンショットのルールに従って判断してください
ワンショットで要約の所見を記載し忘れる	⚠ 行に昇格させてください。ワンショットには第 2 の伝達経路がありません
検索結果を確認なしで採用する	ワンショットでは、確認が必要だったものは決して採用しません。近似候補を明記し、判定は MISSING とします
ワンショットで生成したのに、配信用ツールを呼び出さない	文章を返すだけでは配信になりません。指定されたツールを呼び出し、利用できない場合はその旨を伝えてください
environment: "prod" を SaveCommitMessage に送る	ツールの列挙値は production | qa | dev です。prod を使うのは dxs --target だけです
中間部分だけを description として渡す	description はメッセージ全体です。タイトル、空行、本文を含みます。タイトルが繰り返されるのは意図的です
ツールに入力欄がないからといって、リリースノートを省く	リリースノートは description 内の説明段落の後に含めます。空行もそのまま保持してください
コミットスナップショットやリリースのメッセージを作成する	分析の前に Phase 2 のガードを実行し、isFeatureBranch / isCommit を確認してください
all_changes の行を作業の証拠として扱う	エントリごとに has_changes を確認してください。false は、設定がベースと同一であることを意味します
changes_by_type を読む	実際の更新があるブランチでも常に空です。all_changes を使ってください
変更のないブランチを、何か作業をしたかのように説明する	空であることを伝え、「変更なし」の ⚠ 行を使い、コードレビューの行は省いてください
依存関係が後退した移動を同期として報告する	後退は、ブランチ作成後にベースが進んだことを意味します。これはドリフトなので含めないでください
差分に別の内容が示されているのに、チケットの内容を説明する	メッセージでは常に差分を説明します。両者を関連付けるため、乖離を示す ⚠ 行を追加してください
チケットと差分の不一致をチャットの要約に埋もれさせる	乖離はメッセージに記載してください。誤った関連付けに気づくのは、コミットを読む人です
git commit を実行する、またはリポジトリの状態を編集する	認められている書き込みは Phase 5c の cr0c5_commit スタンプだけです。ブランチにもリポジトリにも一切手を加えません
UNVERIFIED または MISSING の判定で cr0c5_commit をスタンプする	解決済みの Project Task だけにスタンプしてください。チケットに推測を書き込んではいけません
コミット本文にレビューの指摘事項を列挙する	テーマだけを記載してください。詳細は branch-code-reviewer に委ね、⚠ で示すだけにしてください
正規表現に一致したものを有効なチケット参照として扱う	アダプターを通じてレコードを解決してください。形式が正しい ID でも、参照先が存在しない場合があります
チケットが見つからなかったため、メッセージを出力しない	チェックは警告するだけで、処理をブロックしません。⚠ のトレーサビリティ行を付けて出力してください
空行の後に Ref: を置く	リリースノートに入って開発者から見えなくなります。説明段落内に記載してください
あいまい検索の結果から、確認せずにチケットを推測する	候補をユーザーに提示し、確認されたものだけを採用してください
利用可能かどうか確認せずに CreateKnowledgeNode を呼び出す	ツールが利用可能な場合に限り Phase 6 に進みます。見つからない場合は問題なくスキップしてください
デフォルトで --target dev / qa を使う	デフォルトは prod です。ユーザーが環境を明示的に指定した場合に限り、上書きしてください