mcpField
S
service-itsm-incident-priority-configure

service-itsm-incident-priority-configure

github.com/forcedotcomクラウド・DevOps1.1k1.7k 回インストール1 日前に更新
リポジトリ

service-itsm-incident-priority-configure について

Salesforce ITSM の Incident Priority Matrix を `sf` CLI で設定するスキルです。Incident の優先度ルールを管理するチーム向けに、状態確認や変更を行い、書き込み前の読み取りと明示的な確認を必須にします。

主な機能

  1. 01優先度マトリックスの表示と切り替え
  2. 02セルの追加、変更、削除、設定
  3. 03手動優先度上書きの切り替え
  4. 04デフォルト優先度の読み取りと設定
  5. 05Incident の選択肢による値の検証

活用シーン

  1. 01Incident 優先度マトリックスの確認
  2. 02マトリックスによる優先度設定の有効化
  3. 03Impact と Urgency の対応関係の変更
  4. 04Incident のデフォルト優先度の変更

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/forcedotcom/sf-skills --skill service-itsm-incident-priority-configure

インストール後、Claude Code で/service-itsm-incident-priority-configureを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

examples/
matrix-operations.md
render-matrix.md
seed-full-matrix.md
references/
sf-cli-invocation.md

詳細

Incident Priority Matrix の設定(sf CLI)

Salesforce ITSM の Incident Priority Matrix を設定します。これは、Impact と Urgency から Incident の Priority を導き出すグリッドです。マトリックスの表示、有効化/無効化、セルの追加/変更/削除/初期設定、手動上書き設定の切り替え、デフォルト(フォールバック)優先度の読み取り/設定を扱います。

すべての読み取りと書き込みは sf CLI を介して実行されるため、このスキルは Incident Management ライセンスが有効なすべての組織で動作します。

書き込みは冪等です(現在の状態がすでに目標と一致している場合はスキップされます)。このスキルでは必ず書き込みの前に読み取りを行い、変更を実行する前に明示的な書き込み確認が必要です。

対象範囲

  • 対象範囲(Incident のみ):マトリックスの表示、有効化/無効化、マトリックスセルの追加/変更/削除/初期設定、手動上書きの切り替え、デフォルト(フォールバック)優先度の読み取り/設定。
  • 対象外:Problem および ChangeRequest のマトリックス、ITSM 以外の Priority ピッカー、SLA/マイルストーン/エンタイトルメントの設定、Incident Management 自体の有効化。ユーザーが Problem または ChangeRequest について尋ねた場合は、そこで停止してその旨を伝えてください。

前提条件

  1. sf CLI ≥ 2.60(sf --version で確認してください)。
  2. 対象組織が sf で認証済みであること。sf org list のいずれかの結果に Connected と表示されている必要があります。
  3. 組織で Incident Management が有効になっていること。これは Service Cloud ITSM Incident 機能のマスター設定(Setup Discovery apiName = service-cloud-itsm-incident)です。事前確認時に GET /services/data/v67.0/connect/setup/discovery/features で直接読み取り、apiName == "service-cloud-itsm-incident" で絞り込みます(マスター設定の setup-org-preferences エンドポイントはこのサーフェスでは公開されていません。IncidentMgmtEnabled/ITSMIncidentMgmtEnabled はどちらも 404 になります)。status != "ENABLED" の場合は、その機能を有効にするために service-itsm-incident-mgmt-configure にインラインで委任してください(このスキルは同じルートに対して独自に、書き込み前の読み取りと書き込み確認を実行します)。その後、フェーズ 1 に戻ってください。
  4. 呼び出しユーザーに CustomizeApplication(View Setup + Setup Admin)が付与されていること。

前提条件が満たされていない場合、CLI は未加工のエラーをそのまま表示します。状態を捏造せず、未加工のエラーを提示して停止してください。


ルートの概要

すべてのルートは sf CLI を通じて呼び出します。メソッド/パス/本文/レスポンスの詳細、選択リストの抽出手順、注意点は references/sf-cli-invocation.md に記載されています。

対象通信方法HTTP ステータス
Master Incident Mgmt 設定(読み取り)/services/data/v67.0/connect/setup/discovery/features に対する sf api request rest の GET。apiName == "service-cloud-itsm-incident" で status を絞り込みます200
マトリックス有効化フラグ(読み取り/書き込み)/services/data/v67.0/setup/org/preferences/IncPriorityMatrixEnabled に対する sf api request rest200
手動オーバーライド(読み取り/書き込み)/services/data/v67.0/setup/org/preferences/IncPriorityOverrideEnabled に対する sf api request rest200
マトリックス行(読み取り)ServiceOpPriorityConfig に対する sf data query --use-tooling-api200
マトリックス行(追加)/services/data/v67.0/tooling/sobjects/ServiceOpPriorityConfig に対する sf api request rest の POST201
マトリックス行(変更)/services/data/v67.0/tooling/sobjects/ServiceOpPriorityConfig/<Id> に対する sf api request rest の PATCH204
マトリックス行(削除)ServiceOpPriorityConfig に対する sf data delete record --use-tooling-api200
デフォルトのフォールバック優先度(読み取り)/services/data/v67.0/tooling/query/?q=...StandardValueSet... に対する sf api request rest の GET200
デフォルトのフォールバック優先度(書き込み)StandardValueSet:IncidentPriority に対する sf project retrieve start +編集+ sf project deploy startdeploy Succeeded
選択リスト値(Incident)/services/data/v67.0/sobjects/Incident/describe に対する sf api request rest の GET200
Salesforce Go のステップ「完了」(書き込み、変更後)/services/data/v67.0/connect/setup/discovery/feature/service-cloud-itsm-incident/configuration/step/definePriorityMatrix/progress に対する sf api request rest の PUT200

パスのプレフィックスは重要です。削除しないでください。 Setup Connect API のパスは必ず /services/data/v67.0/ で始めてください。Tooling REST のパスは必ず /services/data/v67.0/tooling/ で始めてください。


確認事項

推測できないことだけを確認してください。

  • どの組織ですか? sf CLI のエイリアスまたはユーザー名(--target-org <alias>)。デフォルト:組織のデフォルトのターゲット。
  • どの操作を行いますか? 表示、マトリックスの有効化/無効化、手動オーバーライドの切り替え、デフォルト優先度の設定、セルの追加/変更/削除、マトリックス全体の初期設定。
  • 追加/変更の場合: Impact と Urgency の座標、および適用する Priority(取得した選択リスト値と照合して検証します)。
  • デフォルト優先度を設定する場合: 対象の Priority 値。ユーザーが値を指定していない場合は、組織で有効な Incident.Priority の選択リスト値を選択肢として AskUserQuestion を実行してください。推測してはいけません。

ワークフロー

すべての手順は順番に実行します。書き込む前に必ず読み取ってください。 すべての呼び出しは sf CLI を通じて行います。

フェーズ 0 — セッションがすでに把握している情報を再利用する

以下の各フェーズ 1/フェーズ 2 の読み取りには、把握済みならスキップする条件が付いています。sf コマンドを実行する前に、このセッションの以前のターンで、現在の --target-org に紐づく sf の成功した実行から同じ情報がすでに得られていないか確認してください(このスキルの以前の実行、または同じ会話内での以前の sf 呼び出し)。ここでのセッションコンテキストは --target-org <alias> ごとに分かれているため、別のエイリアスは別のセッションです。ユーザーによる明示的な発言はキャッシュ対象になりません。選択リスト値、設定のブール値、マトリックスの行、フォールバックの優先度はすべて、フェーズ 4 の変更時にクライアント側の検証と重複防止に使用されるため、ユーザーの誤った、または古い申告を信頼すると、これらの保護を迂回し、無効な行や重複する行が作成されるおそれがあります。情報源がユーザーの発言のみの場合(または特定の以前の sf 応答を確認できない場合)は、再読み取りしてください。

  • sf --version — CLI のバージョンがこのセッションですでに報告されている場合は、手順 1 をスキップします。
  • Incident の describe(有効な Impact/Urgency/Priority の選択リスト) — 現在の --target-org に対する Incident の describe がこのセッションですでに読み取られており、3 つの選択リストがコンテキストにある場合は、手順 2 をスキップして再利用します。
  • IncPriorityMatrixEnabled/IncPriorityOverrideEnabled の設定値 — いずれかの値がこのセッションですでに読み取られており、その後 PATCH されていない場合は、そのフェーズ 2 での読み取りをスキップします。
  • ServiceOpPriorityConfig の行 — 現在の組織の Incident 行がこのセッションですでに読み取られており、その後 ServiceOpPriorityConfig に対する POST/PATCH/delete が実行されていない場合は、手順 5 をスキップして行リストを再利用します。
  • StandardValueSet:IncidentPriority のデフォルト値 — フォールバック優先度がこのセッションですでに読み取られており、その後 StandardValueSet:IncidentPriority のデプロイが実行されていない場合は、手順 6 をスキップします。

判断に迷う場合は、再確認してください。 情報がコンテキスト内に明確に存在し、--target-org のエイリアスが変わっておらず、その後のフェーズ 4 での書き込み(設定の PATCH、ServiceOpPriorityConfig への POST/PATCH/delete、または StandardValueSet:IncidentPriority のデプロイ)によって情報が無効になっていない場合に限り、スキップしてください。稼働中の組織で誤ってスキップすることは、再読み取りするよりも危険です。

フェーズ 1 — 事前確認
  1. (sf --version がこのセッションですでに報告されている場合はスキップしてください — フェーズ 0 を参照。) CLI が利用可能であることを確認するため、sf --version を実行します。
  2. Incident Management のマスター設定 — 直接読み取り (現在の --target-org に対するマスター設定がこのセッションですでに読み取られており、値が ENABLED で、セッション内の別の書き込みによって変更されていない場合に限りスキップしてください — フェーズ 0 を参照。) sf api request rest "/services/data/v67.0/connect/setup/discovery/features" --method GET --target-org <alias> を実行します。応答を解析し、features[] 配列から apiName == "service-cloud-itsm-incident" の要素を抽出して、その status フィールドを確認します。status == "ENABLED" の場合は、手順 3 に進みます。status != "ENABLED" の場合は、マスター設定を有効にするため、service-itsm-incident-mgmt-configure にインラインで処理を委任してください(このスキルは同じルートに対して、書き込み前に独自の確認を行います)。続行する前に、この手順を再実行して status == "ENABLED" であることを確認します。ユーザーが委任を拒否した場合は、処理を中止してください。マスターがオフの状態では Priority Matrix は機能しません。これはマスター設定の直接読み取りであり、続く Incident の describe 確認は二次的な整合性確認であって、マスター状態を示すシグナルではありません。
  3. (現在の --target-org に対する Incident の describe(有効な Impact/Urgency/Priority の選択リストを含む)が、このセッションですでにコンテキストにある場合はスキップしてください — フェーズ 0 を参照。) sf api request rest "/services/data/v67.0/sobjects/Incident/describe" --method GET --target-org <alias> を実行します。Impact/Urgency/Priority の選択リストフィールドを含む 200 応答は、二次的な整合性確認となります。後続の検証に使用するため、有効な選択リスト値を抽出します。describe の応答が大きい場合は、3 つの選択リストのみを抽出するよう、サブエージェント(haiku ティア)に指示します。
Phase 2 — 現在の状態を表示(読み取り専用)

以下の読み取りを実行します(すべて 200 を返す想定です)。

  1. (現在の --target-org における IncPriorityMatrixEnabled をこのセッションですでに読み取っており、その後 PATCH していない場合はスキップしてください — Phase 0 を参照。)sf api request rest "/services/data/v67.0/setup/org/preferences/IncPriorityMatrixEnabled" --method GET --target-org <alias> — マトリックスの有効化フラグです。本文:{"isPreferenceEnabled": <bool>}。
  2. (現在の --target-org における IncPriorityOverrideEnabled をこのセッションですでに読み取っており、その後 PATCH していない場合はスキップしてください — Phase 0 を参照。)sf api request rest "/services/data/v67.0/setup/org/preferences/IncPriorityOverrideEnabled" --method GET --target-org <alias> — 手動オーバーライドのフラグです。本文の形式は同じです。
  3. (現在の --target-org における Incident の ServiceOpPriorityConfig 行をこのセッションですでに読み取っており、その後この SObject に対する POST/PATCH/削除を実行していない場合はスキップしてください — Phase 0 を参照。)マトリックスの行 — sf data query --use-tooling-api --target-org <alias> --query "SELECT Id, DeveloperName, ReferenceObject, Urgency, Impact, Priority FROM ServiceOpPriorityConfig WHERE ReferenceObject = 'Incident'"。0 行以上を返します。追加手順で新しい一意のサフィックスを導出するため、DeveloperName が必要です。
  4. (StandardValueSet:IncidentPriority のデフォルトをこのセッションですでに読み取っており、その後 StandardValueSet:IncidentPriority のデプロイを実行していない場合はスキップしてください — Phase 0 を参照。)デフォルトのフォールバック優先度 — sf api request rest "/services/data/v67.0/tooling/query/?q=SELECT+Id,MasterLabel,Metadata+FROM+StandardValueSet+WHERE+MasterLabel='IncidentPriority'" --method GET --target-org <alias>。records[0].Metadata.standardValue を読み取り、default: true のエントリーを見つけて、その valueName を取得します。これがフォールバック優先度です。

行を「影響度 × 緊急度」のグリッドとして表示します(examples/render-matrix.md を参照)。ステップ 3〜6 を合わせて「表示」操作と変更前のスナップショットを構成します。

重複座標の検出(変更/削除に不可欠): Phase 2 の行を (ReferenceObject, Urgency, Impact) でグループ化します。いずれかのグループに複数の行がある場合、マトリックスにすでに重複が含まれています(サーバーは一意性を強制しません)。対象の座標が重複している操作については、Phase 3 を中断してください。ユーザーが明示的な Id を指定するか、統合プランを承認するまで、変更または削除の確認を求めないでください(Phase 4 → セルの変更 および Phase 4 → セルの削除 を参照)。追加には影響しません。Phase 4 の追加処理では、スナップショットにすでに存在する座標への追加を拒否します。

Phase 3 — 対象を確認(AskUserQuestion、書き込み前に必須)

意図する変更を (Concern: <before> → <after>) として提示し、AskUserQuestion で明示的な「はい」を求めます。明示的な「はい」の場合に限り、Phase 4 に進んでください。「いいえ」の場合は停止し、書き込みを行わずに現在の状態を報告します。

フェーズ 4 — 変更を適用する(表示のみの場合はスキップ)

最初に同じ設定の現在値を読み取り(フェーズ 2 で対応済み)、ユーザーに対象を確認(フェーズ 3)してから処理を実行します。各操作のペイロード形式と CLI の完全な実行例は、examples/matrix-operations.md にあります。

  • マトリックスを有効化/無効化する — IncPriorityMatrixEnabled に対して sf api request rest の PATCH を実行し、本文に {"desiredState": <bool>} を指定します。PATCH の応答には {"isPreferenceEnabled": <bool>} が返されるため、別途再読み込みする必要はありません。
  • 手動オーバーライドを切り替える — IncPriorityOverrideEnabled に対して sf api request rest の PATCH を実行し、本文に {"desiredState": <bool>} を指定します。マトリックスの行やデフォルトの優先度は変更されません。
  • セルを追加する — /services/data/v67.0/tooling/sobjects/ServiceOpPriorityConfig に対して sf api request rest の POST を実行し、本文に {"ReferenceObject": "Incident", "Urgency": "<val>", "Impact": "<val>", "Priority": "<val>", "DeveloperName": "<unique>", "MasterLabel": "<same>"} を指定します。ペイロードの ReferenceObject は "Incident" でなければなりません。この SObject は Problem/ChangeRequest と共有されており、サーバーは任意の文字列を受け付けます。まず取得した選択リストに対して、すべての Urgency/Impact/Priority の値を検証してください。Tooling エンドポイントは選択リストの検証を行いません。フェーズ 2 のスナップショットと照合して重複を排除してください。サーバーは (ReferenceObject, Urgency, Impact) の重複を拒否しないため、同じ座標に対する 2 回目の POST は 2 行目としてそのまま保存され、実行時にはどちらが選ばれるか決定論的ではありません。
  • セルを変更する — フェーズ 2 の行を読み取り、(ReferenceObject=Incident, Urgency, Impact) に一致する行を探します。一致する行がちょうど 1 行の場合、/services/data/v67.0/tooling/sobjects/ServiceOpPriorityConfig/<Id> に対して sf api request rest の PATCH を実行し、本文に {"Priority": "<new val>"} を指定します。一致する行が 0 行の場合、これは変更ではなく追加です。その旨を伝えて確認を求めます。一致する行が複数ある場合(フェーズ 2 で重複が検出されている場合)、処理を実行してはいけません。重複行の Id/DeveloperName/現在の Priority を報告し、変更する正確な Id をユーザーに指定してもらうか、統合計画(余分な行を削除してから残す行を変更する)の承認を求めます。
  • セルを削除する — フェーズ 2 の行を読み取り、(ReferenceObject=Incident, Urgency, Impact) に一致する行を探します。一致する行がちょうど 1 行の場合、sf data delete record --sobject ServiceOpPriorityConfig --record-id <Id> --use-tooling-api --target-org <alias> を実行します。一致する行が 0 行の場合、「削除するものがありません」として処理を終了します。一致する行が複数ある場合、処理を実行してはいけません。重複を報告し、削除する正確な Id をユーザーに指定してもらうか、「この座標にあるすべての行を削除する」ことを明示的に確認してもらいます。
  • マトリックス全体を設定する — examples/seed-full-matrix.md を参照してください。まず値を検証してから、各行を POST します。
  • デフォルトのフォールバック優先度を設定する — sf project retrieve start --metadata "StandardValueSet:IncidentPriority" --target-org <alias> を実行し、ファイルを編集して対象の値に <default>true</default> を設定し、その他すべての値に <default>false</default> を設定します。その後、sf project deploy start --metadata "StandardValueSet:IncidentPriority" --target-org <alias> --wait 10 を実行します。デプロイ結果に Succeeded と表示されることを確認します。
フェーズ 5 — 検証と提示
  1. 変更した項目を再度読み取ります(Tooling SOQL によるマトリックスの行、StandardValueSet クエリによるデフォルトの優先度、PATCH レスポンスでエコーされる設定)。観測された状態が要求された状態と一致しない場合は、書き込み失敗として扱い、生のサーバーレスポンスをそのまま報告します。
  2. フェーズ 4 で機能する書き込みが実際に反映された場合に限り、Salesforce Go のステップを完了済みにします。「Define Priority Matrix」ステップはユーザーによる上書きが可能です。チェックマークは組織の状態から導出されないため、マトリックスを設定しただけでは切り替わりません。完了状態を書き込む必要があります。ステップ 7 で書き込みを検証した後、完了状態を PUT で一度だけ送信します(references/sf-cli-invocation.md のルート 10、本文 {"isComplete": true}、フラグは必須)。これはフェーズ 3 の確認に含まれるため、別途 AskUserQuestion は不要です。参照のみの読み取りと冪等な変更なしの場合は、完全にスキップします。
  3. 変更前と変更後(Impact × Urgency のグリッドは examples/render-matrix.md を使用)に加えて、1 行の要約を提示します(例:インシデントマトリックス:High/High → Critical を追加)。マトリックスの変更が適用されるのは、書き込み後に作成されたインシデントのみです。マトリックスを無効にしても、保存済みの行やデフォルトの優先度はクリアされません。

ルール/制約

制約理由
すべての操作を sf CLI 経由で実行するIncident Management が有効な任意の組織で動作し、追加のセットアップは不要です
常に API v67.0 以上を使用するSetup Connect API の設定ルートには v67+ が必要です
書き込み前にライブ状態を読み取るフェーズ 2 のスナップショットは、確認プロンプト、冪等性チェック、フェーズ 5 の検証の基準となります
変更前に必ず確認して書き込むチェックポイントを設ける設定の切り替えやマトリックス行の変更は組織の状態を変更するため、ユーザーが具体的な計画を承認する必要があります
冪等にする — 現在の状態が要求された状態とすでに一致している場合は書き込みをスキップする変更のない書き込みを避けます。項目ごとの厳密な一致ルールについては references/sf-cli-invocation.md を参照してください
すべての Impact、Urgency、Priority を、実行前に組織のライブの選択リストと照合して検証するTooling REST エンドポイントは選択リストの検証を行いませんが、ランタイムのマトリックス評価機能は行います。この検証を省略すると、無効な行がマトリックスに追加されます
追加前に、フェーズ 2 のスナップショットと照合してクライアント側で行を重複排除するサーバーは (ReferenceObject, Urgency, Impact) の一意性を保証しません。同じ座標への 2 回目の POST は別の行として保存されます。重複セルを防ぐ唯一の手段はクライアント側の重複排除です。
Incident 以外の ReferenceObject(Problem、ChangeRequest、その他)は拒否するServiceOpPriorityConfig はワイヤーレベルで Problem/ChangeRequest のマトリックスと共有されるため、サーバーは任意の ReferenceObject 文字列を受け付けます。Incident へのスコープ制限はスキル側でのみ強制されます。
変更/削除時に、対象座標に複数の行が該当する場合は実行せず、明示的な Id または確認済みの統合計画を求めるサーバーは (ReferenceObject, Urgency, Impact) が重複する行を許可します。任意に「行の Id」を選ぶと、重複行の片方だけが変更され、もう片方が残るため、マトリックスが非決定的な状態のままになります。
CLI レスポンスのエラーテキストを正確に報告するCLI は基盤となるエラーメッセージをそのまま表示します
機能する書き込みの後に、Salesforce Go のステップ進捗完了状態を PUT する(ルート 10)。参照のみ/変更なしの場合はスキップする「Define Priority Matrix」ステップはユーザーによる上書きが可能です。チェックマークは組織の状態から導出されないため、設定の書き込みだけでは Go チェックリストは未完了のままです

検証チェックリスト

変更を完了したと報告する前に、以下の項目をすべて確認してください。未確認の項目がある場合は、成功を報告せず、不足している内容を明示してください。

  • フェーズ 1 の事前確認(Incident の describe に対する sf api request rest)で、Impact/Urgency/Priority の有効な選択リストが返され、ステータスが 200 であること。404 の場合は、未加工のエラーを提示して処理を停止したこと。
  • フェーズ 2 で、書き込みが対象とするすべての懸念事項を読み取った結果が 200 であること(または未加工のエラーを提示したこと)。観測した各値を「変更前」の状態として記録したこと。Change/Remove の場合は、フェーズ 2 の行を (ReferenceObject, Urgency, Impact) ごとにグループ化し、変更対象に重複する座標があればユーザーに提示したこと。明示的な Id または確認済みの統合計画によって重複が解消されるまで、Change/Remove を実行していないこと。
  • フェーズ 3 の書き込み前の確認で、AskUserQuestion を使って (<concern>: <current> → <requested>) を提示し、ユーザーが明示的に「yes」と返答したこと。それ以外の応答(無応答、「maybe」、「looks good」、暗黙の承認)では書き込みを実行していないこと。
  • 冪等性:現在の状態がすでに要求された状態と一致している場合、その懸念事項についてフェーズ 4 をスキップし、冪等な変更なしとして報告したこと。書き込みを実行していないこと。
  • 追加/変更のペイロードに含まれるすべての Impact、Urgency、Priority を、実行前にフェーズ 1 の選択リスト値に照らして検証したこと。(ReferenceObject, Urgency, Impact) の重複を、フェーズ 2 のスナップショットに対してクライアント側で検出したこと。サーバーは重複を拒否しません。すべての追加ペイロードで ReferenceObject == "Incident" としたこと。
  • フェーズ 4 の書き込みで、references/sf-cli-invocation.md に記載された CLI 呼び出しを正確に使用したこと。4xx/5xx(または Succeeded 以外のデプロイ)が発生した場合、未加工のレスポンスを提示して処理を停止したこと。
  • フェーズ 5 の検証で、影響を受けた懸念事項を再読み込みしたこと。差分があった場合は、未加工のレスポンスとともに write FAILED — server state differs from request と報告したこと。
  • フェーズ 4 で機能上の書き込みが反映された場合、検証後に Go のステップ進捗完了 PUT(ルート 10)を送信したこと。表示のみの読み取りと冪等な変更なしの場合は、完了 PUT を実行していないこと。
  • 最終報告に、Impact × Urgency グリッドを含む変更前/変更後の状態と、1 行の要約を記載したこと。

参照ファイル一覧

ファイル読み込むタイミング
references/sf-cli-invocation.md正確な sf CLI 呼び出し、レスポンスのエンベロープ、選択リストの抽出、冪等性のルール、注意事項
examples/render-matrix.mdImpact × Urgency グリッドのレイアウト
examples/matrix-operations.md有効化、オーバーライド、デフォルト、追加/変更/削除の CLI 呼び出しテンプレート一式
examples/seed-full-matrix.mdマトリックス全体の初期データ投入(先に選択リスト値を検証)

コメント