experience-cms-content-generate

CMS コンテンツの作成

Salesforce CMS のコンテンツレコードを作成する汎用スキルです。タイプの検出、ワークスペースの解決、既存の ContentTypeBundle に対する create_cms_content の実行を調整します。

コンテンツの生成は常にサーバー側で行われます。 create_cms_content と update_cms_content_variant では、目標／編集指示を prompt として受け取ります。サーバーがスキーマに照らして本文を生成・検証し、永続化されたレコードを返します。エージェントはスキーマを調べたり、contentBody を組み立てたり、事前検証したり、拒否されたフィールドを再生成したりしません（原則 3）。

対象範囲

Salesforce CMS で管理されるコンテンツレコードを作成します。既存の ContentTypeBundle に対して作成するインスタンスが対象です。

ユーザーが次のことを希望する場合に使用します： 既存の CMS タイプに対して、自由形式のプロンプトからあらゆる種類のコンテンツレコード（単一または一括）を作成する。セッション内の項目を編集・調整する。managedContentVariantId／managedContentId で直接特定されたレコードを、今回のセッションで作成したものではない場合も含めて更新／編集または公開する（ステップ 0 → UPDATE／PUBLISH エントリ）。すべて、または一部を公開する。レコードを削除／除去する — このスキルが削除リクエストを処理し、ハードストップに誘導します（ステップ 0-D）。内部的な理由は決して明かしません。

ユーザーが次のことを希望する場合には使用しないでください： 新しいコンテンツタイプ／スキーマを定義する（experience-cms-content-type-generate を使用）。レコードの非公開、複製、またはバージョン管理を行う。ワークスペース／フォルダー／チャネルを管理する。画像／メディアを添付する。ブランディングを適用する。

「画像／メディアコンテンツの作成」は事前確認の対象範囲外ではありません（対象外なのは、上記の「メディアの添付」に該当する、バイナリファイルの直接添付／アップロードのみです）。画像／動画のコンテンツレコード（例：URL からの作成）は通常のフローに進みます。タイプとワークスペースを解決し、create_cms_content を実行してください。最初から拒否したり、REST／UI での回避策を提案したりしてはいけません。sfdc_cms__media はサーバーが判断します。ツールからエラーが返るまで進め、その後、原則 15（references/error-recovery.md）に従ってハードストップします。

開始前に

手順は順番どおりに実行してください。省略や並べ替えは禁止です。

実行が正常に完了するたびに、必ず create_cms_content を（1 回以上）実行し、毎回 prompt を通じて目標を渡す必要があります。

ユーザーとのやり取りは最小限にします。実行前に質問できるのはステップ 3（ワークスペース）のみです。目標の調整、モード、本文の詳細について尋ねてはいけません。ステップ 1 では質問しません。 プロンプトに FQN が含まれる場合はステップ 2 のファストパスを使用します。それ以外の場合は、途中で ask_user_tool を呼び出さずにステップ 2a に委任します。一括処理の例外： ステップ 4 では、トピックごとのプロンプトを提示して承認を得ます。

質問の逐語一致ルール — すべての ask_user_tool に適用され、例外はありません。 完全なルールは references/ux-rules.md を参照してください。すべての質問は ask_user_tool を通じて行います（通常のテキストで尋ねてはいけません）。呼び出す前に、必ず assets/questions.md を開き、question 文字列と answers 配列の両方を一字一句そのままコピーし、<placeholders> のみを埋めてください。question の言い換えや短縮、answers の追加・削除・並べ替え、リスト内容の回答への記載はしてはいけません。該当するテンプレートがない場合は、停止して assets/questions.md を読み直してください。その場で質問を作成してはいけません。

ワークフローの概要

- [ ] Step 1: Understand intent (silent — domain, count, FQN if present)
- [ ] Step 2: Resolve content type — fast-path (Buckets 1/2/3) or delegate → contentTypeFqn
- [ ] Step 3: Resolve workspace — UIBundle options or manual ID
- [ ] Step 4: Build payload — single or bulk (topic approval if bulk)
- [ ] Step 5: Dispatch create_cms_content (parallel for bulk)
- [ ] Step 6: Display content body + summary
- [ ] Step 7: Post-action loop — Edit / Publish / End
- [ ] Step 8: Edit — update_cms_content_variant
- [ ] Step 9: Publish — publish_content
- [ ] Step 10: Post-publish — Create more / Render (if UIBundle) / End

Step 0: 意図を判定してルーティングする（常に最初に実行）

Step 1 の前に、意図を必ず1つだけに分類してルーティングしてください。 更新／公開／削除は独立した最初のエントリーポイントであり、作成フローの末尾だけではありません。これらの動詞で始まる場合は、独自の判断で進めないでください（直感でツールを選ぶ、SOQL を実行する、バリアント ID を推測するなど）。冒頭の動詞を読み、ルーティングしてください。

ユーザーの意図（冒頭の動詞）	ルーティング先
作成、生成、執筆、下書き作成、執筆者として作成、投稿、追加、構成、「N 個の <things> を作成」	CREATE — Step 1 に進む
既存レコードの更新、編集、変更、修正、改訂	UPDATE entry — Step 0-U
既存レコードの公開	PUBLISH entry — Step 0-P
レコードの削除、除去、破棄	DELETE — Step 0-D（即時終了）
曖昧（作成／更新／公開のどれか判別できない）	ask_user_tool で明確化（新規作成／既存レコードを更新／既存レコードを公開／キャンセル）し、回答に基づいてルーティング

ルート逸脱を防ぐ STOP ルール（すべてのルートに適用）。 そのルートで必要な content-write ツール（create_cms_content／update_cms_content_variant／publish_content）がこのブリッジで利用できない場合は、停止し、ユーザー向けの対応方法を示すメッセージを表示して、ターンを終了してください。SOQL、sf data、CLI、同類の別ツール、contentBody チャネルで代用してはいけません。ツールが利用できない場合や未対応の操作は、フォールバックのきっかけではなく、処理を終了する条件です。正確なメッセージ、ルートごとの値、発言してよい内容／いけない内容 → references/intent-routing.md § ルート逸脱を防ぐ STOP ルール。

Step 0-U（UPDATE）および Step 0-P（PUBLISH）— 直接エントリーパス

手順の詳細 → references/intent-routing.md。 セッション内の Step 8（編集）／Step 9（公開）に対応する直接エントリーパスです。前のセッションや別のユーザーによって特定されたレコードも対象です（編集／公開はセッション内に限りません）。必ず守るべき不変条件：

• 識別子の厳格な確認 — ツールを呼び出す前に実施。 対象の managedContentVariantId は、(a) セッションレジストリ、または (b) ユーザーが入力した識別子（MC…／20Y…／9Ps）からのみ取得します。名前だけで ID がなく、レジストリにもない場合は、停止して ask_user_tool で質問してください（質問は「どのレコードを操作すればよいですか？」をそのまま正確に使用し、回答は ["Cancel"]）。自分でレコードを探してはいけません — search_content、検出／一覧表示ツール、SOQL、ID の推測は禁止です。
• プレフィックスで解決し、操作前に検証する → references/identifier-resolution.md（9Ps→get_content_variant、MC…／20Y…→get_content）。読み取りに失敗した場合は停止し、確認せずに編集／公開してはいけません。
• 0-U → Step 8c（必須の全文表示と編集指示の確認後）に進み、Step 7 の対話で終了します。0-P → Step 9b に進み、公開確認を行ってターンを終了します（Step 10 は実行しません — セッションコンテキストがないため）。どちらも Step 1〜5 は実行しません。

Step 0-D: DELETE（即時終了）

削除は利用できません（削除機能はありません — これは内部情報であり、ユーザーに伝えてはいけません）。次のメッセージを正確に、これだけ表示してください。

Deleting content isn't supported here. To delete this content, open it in Salesforce CMS and use the Delete option there.

前後に何も言ってはいけません — 前置き、理由説明、ルールの言い換え、ツール／サーバー名、メタ的な説明はすべて禁止です。ユーザーに表示するのは、このプレーンテキストのメッセージだけです。ターンを終了してください。代わりに unpublish_content、SOQL、CLI を提案してはいけません — ユーザーに案内できる唯一の方法は CMS UI です。

Step 1: 意図を把握する

サイレントステップ — ここでは絶対に質問しないでください。 エージェント内部で抽出し、そのまま Step 2 に進みます。「確認させてください……」というやり取りや、ask_user_tool、コンテンツタイプのメニューは不要です。曖昧なプロンプト（generate new content for Q4 launch）にも、Step 2 に必要な情報はすべて含まれています。Step 1 で質問しようとしていませんか（確認、コンテンツタイプのメニュー、「思い当たるものはありますか？」、「いくつ必要ですか？」など）？ それが問題です — Step 2 に進んでください。メッセージを解析して、以下を抽出します。

• コンテンツの領域（記事、ブログ、ニュース、FAQ、……）— そのまま推定します。領域が明示されていなくても問題ありません。
• 数量 — 明示的な数がある場合はその数、「複数」／「いくつか」／「少し」／「いくつかの」などの場合はエージェントが4～5件を選び、数量の指定がない場合は1件です。
• コンテンツタイプの参照 — コンテンツタイプ名と思われるトークン（完全なFQN、アンダースコア1つの類似表記、開発者名のみ、自然言語名）をそのまま記録します。ここでは分類しないでください — どの分類に該当するかは Step 2 で決定します。

メッセージを削除したり書き換えたりしないでください — 元のメッセージは Step 4 のトピックプロンプトに使う創作上の指針であり、Step 2a で intent としてそのまま兄弟エージェントに渡すものです。

複数タイプのゲート — Step 1 で質問してよい唯一のケースです。 プロンプトに2つ以上の異なるコンテンツタイプが含まれる場合（各タイプが独自の ContentTypeBundle を持つ場合。例：grooming packages と service area coverage）、Step 2 の前にユーザーに1つ選んでもらう必要があります（1回の実行につき1タイプです。2つ指定すると委譲の契約が破綻します）。Step 1 の複数タイプ用プロンプトをそのまま送信し（回答の選択肢 = ユーザーの言葉で表した異なる領域 + Cancel）、選ばれた領域のみを intent として引き継ぎます。「質問しない」の唯一の例外です — 2つ以上の異なるタイプがある場合にのみ該当し、目標／モード／数量には該当しません。1つのタイプに対する複数のトピック（5 blog posts）では該当しません（一括処理）。ルールと例 → references/content-type-classification.md § 複数タイプのゲート。

Step 2: コンテンツタイプを解決する

Step 1 で記録したコンテンツタイプの参照を、4つの分類のいずれかに分類します — 検出ルール、例、ルーティングの詳細 → references/content-type-classification.md。概要：

• 分類1 — 正確なFQN。 ^[a-zA-Z_][a-zA-Z0-9_]*__[A-Za-z][A-Za-z0-9_]*$（c__BlogPost）に一致します。contentTypeFqn を記録し、Step 3 に進みます。サイレント。
• 分類2 — 自動修正可能な類似表記。 既知の名前空間と名前の間がアンダースコア1つの場合（c_news→c__news）。自動修正し、チャットで通知して（ask_user_tool は使用せず）、Step 3 に進みます。
• 分類3 — 信頼度の低いFQN風の表記。 名前のみ（BlogPost→c__BlogPost を提案）または不明な名前空間のアンダースコア1つの表記です。Step 2 のFQN修正プロンプトを送信し、回答に応じてルーティングします。
• 無効なFQNのゲート。 FQNとして意図されたトークン（__ を含む）が不正な形式で、分類2の類似表記でもない場合（c__、__Foo、c__Blog Post、c__123）は、自由記述として委譲しないでください。FQN修正プロンプト（Let me provide a different FQN／Cancel）を送信し、新しい文字列で Step 2 をやり直します。
• 分類4 — 自然言語またはトークンなし（blog post）。委譲します — Step 2a に進みます。

高速経路の不変条件（分類1/2/3）： FQNを取得したら、組織内で検証したり、委譲したり、contentTypes/ をスキャンしたり、metadata-grounding を送信したり、取得したり、schema.json を読み取ったりしないでください。不正なFQNは Step 5 で INVALID_TYPE として確定的に失敗します。委譲する経路では、スキャン、グラウンディング、選択の質問、新規作成とデプロイ、FQNの構築、取得と照合は兄弟エージェントが担当します。

2a–2d. 兄弟スキルへの委譲（Bucket 4 のみ）

完全なプロトコル → references/delegation-protocol.md。 要約すると：2a まずワークスペースを解決し（Step 3 → contentSpaceOrFolderId）、バナー Resolving the content type for your request… を出力し、mcp__skill_bridge__load_skill("experience-cms-content-type-generate") を介して呼び出し（組み込みの Skill は使用しない — Unknown skill を返します）、{ intent: "<user message verbatim>", suppressCreateContentPrompt: true, <scope> } を渡します（<scope> = spaceId 0Zu または folderId 9Pu のいずれか一方のみ、baseType は決して使用しない）。委譲前の質問は行いません。2b — 兄弟スキルの実行中、このスキルは PAUSED です（終端結果が出るまで Step 4 以降の呼び出しは行いません。割り込みはそのステートマシンを破壊します）。{ status, fqn, message } を消費し（schema は無視）、status に厳密に従ってルーティングします：

status	このスキルでのアクション
success（fqn あり）	兄弟スキルの message をそのまま出力（type と deploy の行を含みます）。空の場合は Using content type \`.` を出力。その後 Step 2c へ。
not_deployed（fqn あり）	STOP。 message をそのまま出力。Step 3 に進まないこと — create_cms_content はローカルのみのバンドルに対して INVALID_TYPE で失敗します。
cancelled	静かに STOP。 Session ended. を出力して終了。兄弟スキルにループバックしないこと。
error	STOP。 message をそのまま出力（reason と recovery hint を含みます）。再試行や回避を行わないこと。
load failed（ブリッジの Unknown skill/エラー — 兄弟スキルは実行されなかった）	references/delegation-protocol.md § 2b に従い STOP（終端であり、フォールバックではありません — ローカルスキャン、グラウンディング、ワークスペース呼び出しは行いません）。まず search_skills→load_skill で一度だけ再試行してください。

2c（success の場合のみ）— fqn が FQN 正規表現に一致することを検証します。欠落/不正な場合は再実行メッセージ + ask_user_tool（Retry with an explicit FQN/Cancel）を表示し、その後 contentTypeFqn をキャプチャして Step 3 へ。2d — metadata-grounding、sf project retrieve、再提示/再選択、フォルダ名からの FQN 構築を決して行わないこと（これらはすべて兄弟スキルが所有します）。5 つのドリフトシグナル → load failed 行へのハードストップ。not_deployed を success にダウングレードしないこと。手動スペースの場合、2a の呼び出しが Layer-2 の確認です — 無効/見つからない → HARD STOP、invalid-ID テンプレートで再質問します。

ステップ 3：ワークスペースを解決する — 質問 1

ステップ 3 を実行するタイミングは、ステップ 2 でタイプをどのように解決したかによって異なります： ファストパス（バケット 1/2/3）→ ステップ 2 の後、ここで実行します。委任パス（バケット 4）→ 早い段階で実行します。兄弟エージェントをディスパッチする前に、ステップ 2a の最初のアクションとして実行し、contentSpaceOrFolderId が兄弟エージェントによる検出のスコープを指定するようにします。兄弟エージェントの応答後に再実行したり、再質問したりしないでください。どちらの場合も同じ解決手順です。

ローカルプロジェクトをサイレントにスキャンして UIBundle ディレクトリを探し、すべての選択肢を含む単一の ask_user_tool 質問を提示します。検出 + ルーティング + 検証の全手順 → references/workspace-resolution.md。 概要：

• 検出（サイレント）： 各 sfdx-project.json パッケージパス内の uiBundles/ をスキャンします（フォールバック：再帰検索）。各 <name>.uibundle-meta.xml の <masterLabel> を読み取り、{ developerName, masterLabel } を取得します。0 件の場合 →「ローカル UIBundle なし」バリアント。ワークスペースを捏造したり、SOQL を実行したり、ui-bundle.json を読み取ったりしないでください。
• 質問（単一の質問）： assets/questions.md の「Step 3 — Workspace resolution」テンプレートを ask_user_tool でディスパッチします（通常のテキストは使用しないでください）。question + answers をそのままコピーし、言い換えたり、名前を変えたり、削除したりしないでください。UIBundle なしバリアントは固定文面です — question："Which content space or folder should I create the content in? Provide the ID (Content Space IDs start with 0Zu; Folder IDs start with 9Pu)."、answers：["Cancel"]。 UIBundle 検出、手動 ID、無効 ID の各バリアント → assets/questions.md。
• UIBundle を選択 → get_or_create_cms_workspace_and_web_app_channel(developerName, masterLabel) を実行します。返された spaceId = contentSpaceOrFolderId。workspaceMethod=uibundle + channelId を記録し、channelId を uiBundles/<developerName>/public/content-metadata.json に（マージして）保存します。ツールが失敗した場合 → 再試行を促すプロンプト。
• 手動 ID → workspaceMethod=manual を記録します（channelId なし → ステップ 10 のレンダリングで非表示）。「Go back」を含む手動 ID プロンプトを使用します。検証（プレフィックスと長さは必要条件であり、十分条件ではありません）： L1 0Zu→spaceId / 9Pu→folderId、15/18 文字の英数字。L2 はスペースに触れる最初の呼び出しで実行します（委任パス：get_content_types_for_workspace、ファストパス：create_cms_content）。無効または見つからない場合 → 停止し、メッセージをそのまま表示して、無効 ID テンプレートを使って再質問します。組織ピッカーはありません。

ステップ 4：コンテンツ作成ペイロードを作成する

厳格な開始条件 — contentTypeFqn はステップ 2 から取得しなければなりません（バケット 1/2/3 のファストパスで取得するか、兄弟エージェントの結果が status: success であること）。ステップ 2 を実行していない場合（バケット 4 で委任している場合も含む）？ 停止して、ステップ 2 に戻ります。タイプを捏造、推測、またはデフォルト設定しないでください — ステップ 2 を経ずに sfdc_cms__news やその他の基本／標準タイプを選ぶのは、後退です。 FQN がない場合 → バケット 4 → まず委任します。ステップ 2 の前に ToolSearch で作成ツールを先行取得するのも、同じ不具合です。

ゴールは prompt として渡され、サーバーが本文を生成して検証します。エージェントはペイロードの構成とタイトルの生成のみを行います。入力：contentType = ステップ 2 の contentTypeFqn；contentSpaceOrFolderId = ステップ 3；prompt = [USER GOAL]（単一の場合はメッセージをそのまま、または一括の場合はステップ 4.B.2 で承認されたトピックプロンプト）。タイトルはエージェント側で作成します — 簡潔で、トピックに即し、顧客向けであり、[USER GOAL] を反映させます。

• 単一（quantity = 1）： assets/payloads/create-content-single.json。必須：contentType、contentSpaceOrFolderId、title、prompt（そのまま）。任意（urlName、contentKey、externalId、apiName）は、ユーザーが指定した場合に限ります。contentBody は絶対に含めないでください — prompt と相互排他です。
• 一括（quantity > 1）： 異なるトピックプロンプトを N 個生成して承認を求め（2 部構成：Markdown リスト + ask_user_tool）、その後、独立した 1 要素のペイロードを N 個作成します（contentType/contentSpaceOrFolderId は共通、title + prompt はアイテムごと）。1 つの inputs 配列にまとめないでください — アイテムごとに 1 回呼び出します。 フロー → references/bulk-batching.md。

スキーマ全体 → references/content-write-tool.md；ペイロードの手順例 → examples/create-content-call.md。

Step 5：Create 呼び出しを実行する

Step 4 のペイロードを使って create_cms_content をディスパッチします。サーバーがレコードを生成・検証して返します。複雑な型は時間がかかる場合があります。

一括コンテンツ

5a. ディスパッチ前の確認（一括承認） — すべての項目に対して確認を 1 回行います（呼び出しごとの確認を防ぎます）。チャットに Ready to create all **<N>** content items in your org. Proceed? と表示し、Step 5a の承認プロンプトをディスパッチします。Yes, create all → 5b、Cancel → セッションを終了します。

5b. N 件の単一項目呼び出しを並列ディスパッチ references/bulk-batching.md に従い、create_cms_content を正確に N 回呼び出します。それぞれの inputs 配列には 1 件の要素を指定し、すべてを 1 ターンで並列実行します。一部失敗した場合は、成功分を登録し、失敗分（トピック＋エラー）を提示して、再試行プロンプトをディスパッチします（再試行では失敗した項目を新しい並列呼び出しとして再ディスパッチします）。すべて失敗した場合は、まず references/error-recovery.md の「一括処理の全件失敗時の再試行ガード」を適用します（一括処理の全件失敗時の分岐のみ）。

Step 6：コンテンツ本文と概要を表示する

成功した場合は、assets/display-formats.md の 概要＋コンテンツ本文の表を表示します（実際の Markdown で、すべてのフィールドを含めます。作成／編集とも同様です）。1 行の title · status · id にまとめることは絶対に避けてください — 概要の表には Content Key と Managed Content ID を必ず含めます（レスポンスにないフィールドのみ省略します）。失敗した場合は references/error-recovery.md を使用し、エラーをそのまま提示して、ask_user_tool で Retry / Refine goal and retry / Cancel と尋ねます — ただし type-class-unsupported（sfdc_cms__media / image / video）の場合は、処理を中止します（原則 15）。次の定型文だけをそのまま表示し（前置きや言い換えはしない）、ターンを終了します：Content generation isn't supported for content type \` (type class: ``). This skill can't author that type class. To create or edit this content, use the Salesforce CMS UI directly.` 検証はサーバーが担当します。

Step 7：アクション後のループ

コンテンツ本文を表示した後（作成または編集）、assets/questions.md の Step 7 プロンプトをディスパッチします（件数に応じて単一または一括のバリアントを使用します）。次のように振り分けます。

• Edit content → Step 8
• Publish content / Publish all → すべてのバリアント ID を指定して Step 9
• Publish subset → assets/questions.md の publish-subset テンプレートを使い、番号で対象項目を尋ねてから、選択したバリアント ID を指定して Step 9
• End session → Session ended. Content saved as draft. を 1 行で表示して終了します。

ステップ 8、9、10：編集／公開／公開後

手順の詳細全体 → references/edit-publish-workflow.md。 3 つすべて MCP のみ — SOQL も CLI も使用しません（読み取りは content-readonly、書き込みは content-write）。重要な要約：

• ステップ 8 — 編集（update_cms_content_variant）。8a 対象範囲（単一、または一括の場合はステップ 8a のプロンプト）→ 8b 編集指示プロンプト（そのまま適用し、選択したすべての項目に適用）→ 8c ペイロード（variantId は対象項目の最新のレスポンス、またはステップ 0-U の ID を使用。prompt はそのまま使用。名称変更の場合にのみ title を再出力）→ 8d 実行（一括の場合は N 件を並列実行）→ ステップ 6 に戻り、更新後の本文全体とすべてのフィールドを表示（差分テーブルは不可。レスポンスに含まれていない場合は get_content_variant で再取得）、続いて ステップ 7。失敗時 → Retry / Refine edit instruction and retry / Cancel。一括処理がすべて失敗した場合 → エラー回復ガード。
• ステップ 9 — 公開（variantIds を使用して publish_content）。9a 対象範囲（すべて／一部／既定ですべて）→ 9b 実行（セッション内の ID、またはステップ 0-P で検証済みの ID — 直接入力の場合は確認後にターンを終了し、ステップ 10 には進まない）→ 9c 成功時、公開した各項目のレジストリの publishStatus を draft から published に変更（必須 — ステップ 10 でこれをフィルタリングします）。assets/display-formats.md の公開確認メッセージを そのまま出力（Content published successfully. + Title/Managed Content ID/Variant ID）— Content is live やデプロイ ID に関する文言に言い換えないでください。続いて ステップ 10。一部またはすべてが失敗した場合 → エラー回復ガード + 再試行プロンプト。
• ステップ 10 — 公開後。 ステップ 10 のプロンプトを実行します。オプションは workspaceMethod によって異なります（uibundle にはレンダリングが含まれ、manual では表示されません）。セッション内での公開後は、どちらの方法でも必ずこれを実行します — Session ended. に進むのは不具合です。Create more content → ステップ 1 からフロー全体を再開（何も表示せず、「次に何をしますか？」とは尋ねず、ユーザーの次のメッセージを待ちます）→ ステップ 2 → ステップ 3。この実行で使用したワークスペースを再利用しないでください。Render… → experience-cms-content-render に channelId、contentKeys（publishStatus=published のみ）、contentTypeFqn、uiBundleDeveloperName、uiBundleMasterLabel を渡します。公開済みの項目が 0 件の場合は「公開済みの項目がありません」という行を出力してから再実行します。End session → Session ended.

エラー処理

references/error-recovery.md — エラーシグナルから応答へのマッピング全体：create_cms_content／update_cms_content_variant／publish_content のサーバー側エラー、一括処理の部分的な失敗、兄弟項目の終端状態、対象範囲外のリクエスト。

スキル間の連携

• ContentTypeBundle の検出／定義（ステップ 2 の委譲経路のみ。高速経路ではありません）→ experience-cms-content-type-generate（ステップ 2a～2d のペイロードと status によるルーティング）。
• 公開済みコンテンツを UIBundle にレンダリング（ステップ 10）→ experience-cms-content-render（ステップ 10 の引き継ぎパラメーターと workspaceMethod=uibundle の条件）。

主要原則

15 項目すべての全文 → references/principles.md（正式な一覧。それぞれは上記の各ステップの本文でも適用されます）：(1) ワークフローを順番どおりに進める、(2) 実行こそが作業、(3) サーバー側でのみ生成する、(4) ユーザーの目標をそのまま使用する、(5) 委譲時は兄弟スキルが型を担当する、(6) ワークスペースはユーザー／UIBundle から取得 — 推測／SOQL は使用しない、(7) キャンセルで終了する、(8) 表示を一貫させる、(9) セッションレジストリ + 安定したバリアント ID、(10) アクション後のループ、(11) 一括処理は項目ごとに 1 回の呼び出しを並列実行、(12) 公開対象は既定ですべて、(13) 意図を最初に判定 + 識別子の確認、(14) ドリフトがあれば停止、(15) サポート対象外の型クラスは必ず停止。識別子 → references/identifier-resolution.md。