docs-collaborator

Docs Collaborator

monday.com のドキュメントを作成、読み取り、編集し、コメントを追加します。**このスキルは機能を提供するものであり、テンプレートエンジンではありません。**各ドキュメントは、型付きブロック（見出し、段落、リスト、表、コード、区切り線、通知ボックス、レイアウト、埋め込みボード／ウィジェット／ドキュメント／画像／動画／GIF）のストリームです。以下に示す名前付きの形式は出発点にすぎません。自由に組み合わせ、拡張できます。差別化要素（列値のライブ埋め込み、インラインメンション、通知ボックス、レイアウト）は、名前付きの形式でも独自に考案した形式でも、あらゆる形式に適用できます。

プラットフォームネイティブの機能が、生の Markdown エディターより優れている点は、ほとんどの開発者が見落とす次の3つです。ユーザー／ドキュメント／ボードへのインラインメンション、ボード項目の現在の状態を反映する列値のライブ埋め込み、そしてドキュメントのブロックグラフの破損を防ぐ閉ループ型の編集パターンです。

最重要の制約 - まずこれを読んでください

読み取っていないブロックは、絶対に編集しないでください。 monday の update_doc API はブロック ID を使います。ブロック ID を確認できるのは、include_blocks: true を指定した read_docs を実行したときだけです。読み取りを省略すると、存在しない ID を参照する操作（失敗しても通知されません）につながります。さらに悪い場合、別のドキュメントの ID を再利用してしまいます。閉ループ型の手順は必須です。

1. include_blocks: true を指定して read_docs を実行し、ブロック ID、型、位置を取得します。
2. 型と位置、または内容に基づいて対象のブロックを特定します。
3. 対象ブロックの型に合った操作で update_doc を実行します（以下のルーティング規則を参照）。

ブロック操作のルーティング - 見落としやすいポイント

ブロックの型ごとに、許可されている変更操作が異なります。誤った操作を選ぶことは、「呼び出しは成功したのにドキュメントの表示がおかしい」という不具合の最大の原因です。

対象ブロックの型	使用する操作	理由
text（サブタイプ：NORMAL_TEXT、LARGE_TITLE、MEDIUM_TITLE、SMALL_TITLE、QUOTE）	内容の編集には update_block、サブタイプの変更（例：段落を H2 に変更）には replace_block	サブタイプは作成時に設定され、update_block では変更できません
code	update_block	内容と言語をその場で編集できます
list_item（BULLETED_LIST、NUMBERED_LIST、CHECK_LIST）	内容の編集には update_block、箇条書き／番号付き／チェックリストの切り替えには replace_block	リストの種類は作成時に設定されます
divider	replace_block のみ	変更可能なプロパティはありません
table	replace_block のみ	行数／列数と列幅は変更できません。また、作成後は API で表のセルの内容を指定できません。references/rich-content.md の「Tables」を参照してください
image	画像ソースの差し替えには replace_block	作成後は URL／asset_id を変更できません
video	動画ソースの差し替えには replace_block	作成後は raw_url を変更できません
notice_box	テーマの変更には replace_block	テーマは変更できません。内容は子ブロックに格納されます（references/rich-content.md の「Notice boxes」を参照）
layout	replace_block のみ	API ではセルの内容を一切設定できません。references/rich-content.md の「Layouts」を参照してください
BOARD 埋め込み、WIDGET 埋め込み、DOC 埋め込み、GIPHY	delete_block のみ	これらのブロック型を作成または変更するための公開 API はありません

**表示上の問題 - list_item と update_block によるメンション。**それまでテキストだけだった list_item にインラインメンションを追加すると、update_block によってメンションの blot は正しく保存されている（データで確認可能）にもかかわらず、一部のクライアントではピルが表示されないことがあります（メンションの前にテキストがある場合）。回避策として、同じ delta を含む新しい list_item で replace_block を使用してください。同じパターンでも normal_text ブロックでは正しく表示されます。この問題は list_item の更新に固有のようです。

各ブロック型の詳細と具体例は references/block-operations-matrix.md に記載されています。構造を伴う編集を行う前に、必ず読んでください。

ワークフロー：ドキュメントの作成

ステップ 1：保存場所を決める

monday のドキュメントは、次の 2 か所のいずれかに保存されます。

• ワークスペース（最も一般的）。workspace_id が必要です。doc_kind は省略可能で、public（デフォルト）、private（作成者のみ）、share（特定のユーザー）を指定できます。フォルダー内に配置する場合は、folder_id を省略可能で指定できます。
• アイテムに添付。ドキュメントは、特定のボードアイテムにあるドキュメント型カラムに保存されます。item_id が必要です。ユーザーが特定のドキュメントカラムを選択した場合は column_id を省略可能で指定できます。指定しない場合、ツールがカラムを自動作成します。

アイテムに添付するドキュメントのセル上限の事前確認。 ドキュメント型のセルには 1 セルにつき 1 つのドキュメントしか保存できません。これは API の厳格な上限です。create_doc location=item を呼び出す前に、get_board_items_page に columnIds: [<doc_col_id>] を指定して対象のカラムを事前確認し、セルにすでに値が設定されていないか調べてください。値が設定されている場合は、作成を試みないでください。CellLimitExceededException が発生して失敗します。代わりに、ワークスペースレベルのドキュメントを作成し、新しいドキュメントと既存の添付ドキュメントの間に双方向の DOC メンションによる相互リンクを追加してください。既存のドキュメントを自動的に切り離さないでください。

ユーザーがワークスペースを指定しない場合は、get_user_context を使ってユーザーのプライマリワークスペースを選択してください。それでも曖昧な場合は一度だけ確認し、複数のワークスペースから推測で選ばないでください。

ステップ 2：4 件目のドキュメントを作成する前にプランの上限を確認する

Free プランと Basic プランでは、1 アカウントにつきドキュメントは 3 件までです。 Free プランまたは Basic プランのアカウントで create_doc を呼び出す前に、今回の作成が 4 件目に当たるか確認してください。ドキュメント数を直接確認するツールはありません。そのため、実用的な確認方法として、ユーザーが以前この上限に達したことがある場合や、「ドキュメントを 3 件以上作成できますか？」と尋ねた場合は、Standard 以上にアップグレードすると上限がなくなることを伝えてください。プランの上限は未確認事項として扱い、作成の呼び出しを妨げないでください。上限に達している場合は、プラットフォーム自体が作成を拒否します。

ステップ 3：本文を作成する - 形は例であり、制約ではありません

create_doc は、インポート時にブロックへ解析される markdown パラメーターを受け取ります。セクションは数個にとどめ、長い本文は add_markdown_content で追加してください（references/errors.md を参照）。ユーザーがユースケースを指定した場合は、次の一般的な形式を出発点として使い、その後は自由に拡張してください。

• 議事録： タイトル、日付、出席者（@mentions を含む）、議題の箇条書き、決定事項、アクションアイテムの表、フォローアップ。
• 週次報告： 主なハイライト、主要な指標、リスク、翌週の計画。
• RFC： 問題、提案する解決策、検討した代替案、未解決の質問、決定ログ。
• ランブック： トリガー、前提条件、番号付き手順、ロールバック手順、エスカレーション経路。
• ポストモーテム： インシデントの概要、タイムライン、根本原因、うまくいったこと、うまくいかなかったこと、アクションアイテム。

ユーザーが「パートナー向けイネーブルメントページ」「AI 対応状況のスナップショット」「第 3 四半期のオンボーディング情報」のような形式を指定した場合、名前付きテンプレートに無理に当てはめず、セクション、表、通知ボックス、埋め込みなどを適切に組み合わせて作成してください。差別化要素はどの形式にも適用できます。

パッシブモードとアクティブモード。 デフォルトでは、埋め込みやメンションを配置する場所に、見えるスロットマーカー（_[embed: ...]_、_[mention: ...]_）を入れて下地を作ります。ユーザーが項目、ボード、人を名前で指定した場合は、アクティブモードに切り替えて実際の埋め込みやメンションを設定します。名前を ID に解決し（名前が曖昧な場合は、候補上位 3 件を示して一度だけ確認してください）、選択したものを伝えます。何かを設定する前に references/create-modes.md を読んでください。マーカーフォーマット、エスカレーションのトリガー、名前から ID への解決手順、コミュニケーション上の取り決めが記載されています。

重要な Markdown の注意点：

• Markdown の見出し（#、##、###）は、それぞれ LARGE_TITLE / MEDIUM_TITLE / SMALL_TITLE ブロックに対応します。
• Markdown の表を使用できます。セルには指定した値が入力されます。事前入力された表の内容を作成する唯一の方法です。 作成後に API でセル単位の値を入力することはサポートされていません。
• Markdown の画像とリンクを使用できます。アセットベースの画像（monday にアップロードされたファイル）には、作成後に create_block および block_type: "image" と asset_id を指定して update_doc を使ってください。Markdown からアセットを参照することはできません。
• Markdown には、notice_box、layout、embed、余白付きの区切り線、mention、ライブの列値を記述する構文がありません。ドキュメント作成後に update_doc を使って追加してください。

ステップ 4：create_doc を呼び出す

create_doc({
  doc_name: "<title>",
  location: "workspace",
  workspace_id: <id>,
  doc_kind: "public" | "private" | "share",  // optional
  folder_id: <id>,                            // optional
  markdown: "<full markdown body>"
})

項目に添付する場合（事前確認後）：

create_doc({
  doc_name: "<title>",
  location: "item",
  item_id: <id>,
  column_id: "<doc_column_id>",  // optional
  markdown: "<full markdown body>"
})

返された doc_id、object_id、doc_url を記録してください。ユーザーが共有または開くために必要なのは URL です。以降の編集では doc_id が主キーになります。

ステップ 5：リッチコンテンツの追加要素を重ねる

メンション、ライブの列値の埋め込み、通知ボックス、レイアウト、アセット画像には、後続の update_doc 呼び出しが必要です。アクティブモードでは、ステップ 3 で解決した ID を使って、ここで設定してください。パッシブモードではスロットマーカーをそのまま残し、ユーザーが後から項目を指定してスロットを埋められるようにします。references/delta-format-cheatsheet.md の「Common patterns」を参照してください。

ステップ 6：確認して次のステップを提案する

平易な言葉で、名前、ワークスペース、ドキュメント URL を伝えて完了を確認します。使用したモード（パッシブな下地作成またはアクティブモード）も伝えてください。そのうえで、形式に応じたフォローアップを 2～3 件提案します。

• 「出席者に @mentions を付けましょうか？」
• 「プロジェクトボードの最新ステータスを埋め込みますか？」
• 「会議の結論を記載した通知ボックスを上部に追加しましょうか？」
• 「ドキュメント URL を Slack チャンネルで共有しますか？」

ワークフロー：ドキュメントを読む

ステップ 1：ドキュメント ID を解決する

ユーザーがドキュメントを指定する方法は 3 つあります。

• doc_id（例：41302579）- API の主キーです。create_doc と read_docs が返します。
• object_id（例：18411484379）- ドキュメント URL https://monday.monday.com/docs/{object_id} の数値部分です。
• ドキュメント名または曖昧な参照（「第 3 四半期の振り返りドキュメント」など）- type: "workspace_ids" を指定して read_docs を使い、ワークスペース内のドキュメントを一覧表示してから、名前で照合します。

read_docs は柔軟です。type: "ids" を指定して、実際には object_id である値を渡すと、object_ids として自動的に再試行します。推測するより、この動作を活用してください。

ステップ 2：読み取る内容を決める

2 つのモードがあります。

• content（デフォルト）- ドキュメントのブロックや Markdown 投影を返します。
  • 後続で編集を行う場合は、include_blocks: true が必須です。省略しないでください。
  • すべてのコメントと返信を取得するには、include_comments: true を指定します。comments_limit で上限を設定します（デフォルトは 50）。
• version_history - ドキュメントの編集履歴（復元ポイント）を返します。id ではなく object_id を渡します。「直近 N 件の変更」のリクエストでは version_history_limit を設定し、変更内容を確認するには include_diff: true を設定します（処理が遅くなります）。

ステップ 3：プレースホルダーではなく、解決済みのメンションと埋め込みを使って表示する

API の blocks_as_markdown 投影では、メンションは @{USER-XXX} というプレースホルダーとして表示され、ライブの列値の埋め込みは空白になります。「このドキュメントの内容を見せて」というプロンプトに対して、この表示は適切ではありません。ユーザーがドキュメントを開くと、ピルやライブチップが表示されるため、テキスト表示もそれを反映する必要があります。

「見せて／内容を教えて／このドキュメントを読んで」というプロンプトでは、すべてのメンションを表示名に解決し、埋め込みは簡単に取得できる場合は現在の値に解決して、インラインの非テキスト要素を ID 付きの一覧表に追加します。正確なルールについては references/read-rendering.md を参照してください。

ドキュメントの内容に show-table を使用しないでください。ドキュメント自体が UI です。チャット上では Markdown で表示してください。

ワークフロー：ドキュメントを編集する

ステップ 1：まず読み取る

include_blocks: true を指定して read_docs を実行します。これは閉ループの前提条件です。すべてのブロックの id、type、位置を記録します。

ステップ 2：適切な操作を選ぶ

目的を達成できる最も簡単な操作を選びます。

• 新しい内容を末尾に追加する： add_markdown_content（ブロック ID は不要です。テキスト、リスト、表、コードに対応しています）。
• アセットベースの画像を追加する： block_type: "image" と asset_id を指定して create_block を使います（Markdown はアセット画像に対応していません）。
• 既存のテキスト／コード／list_item の内容をその場で編集する： 一致する block_content_type（text、code、または list_item）を指定して update_block を使います。
• ブロックのサブタイプを変更する（段落 -> H2、箇条書き -> 番号付き、INFO 通知 -> WARNING 通知）：replace_block を使います。サブタイプは作成時にのみ設定できます。
• 正確な位置にブロックを挿入する： after_block_id を指定して create_block を使います。before_block_id による操作はありません。ドキュメントの最上部に挿入するには、先頭ブロックの後に挿入するしかありません。
• 削除する： delete_block を使います。BOARD／WIDGET／DOC 埋め込み／GIPHY ブロックで使える操作はこれだけです。
• コメントする： add_comment を使います（本文は HTML）。本文中に @ を書くのではなく、mentions_list でユーザーをタグ付けします（references/rich-content.md の「Comments」を参照）。
• ドキュメント名を変更する： set_name を使います。

タイプごとの操作の対応表は references/block-operations-matrix.md にあります。

Step 3：delta_format を作成する（text / code / list_item 用）

コンテンツブロックに対する update_block と create_block では、挿入オペレーションの配列である delta_format を指定します。すべてのデルタには、次の3つのルールが適用されます。

1. 最後のオペレーションは必ず {insert: {text: "\n"}} にします。例外はありません。
2. プレーンテキストには、任意の attributes（太字、斜体、下線、取り消し線、コード、リンク、色、背景色）を指定できる {insert: {text: "..."}} を使います。
3. 次の2種類の非テキスト挿入によって、独自の機能を利用できます。
   • メンション：{insert: {mention: {id: <numeric-id>, type: "USER" | "DOC" | "BOARD"}}}。list_users_and_teams を使ってユーザーIDを解決します（呼び出しの対象を絞り込むため、必ず name を渡してください）。
   • ライブ列値の埋め込み：{insert: {column_value: {item_id: <id>, column_id: "<column_id>"}}}。ドキュメントを開くたびに、そのアイテムの列の現在の値がライブで表示されます。

例と属性の完全な一覧は references/delta-format-cheatsheet.md にあります。

Step 4：バッチ操作を慎重に行う

update_doc は1回の呼び出しで最大25件のオペレーションを受け付け、順番に実行し、最初の失敗時点で停止します。次の4点に注意してください。

• 通知ボックスのネストには2回の呼び出しが必要です。 同じ呼び出し内で作成した通知ボックスは、同じ呼び出し内の後続オペレーションで parent_block_id として参照できません。通知ボックスを作成して返されたIDを取得してから、2回目の update_doc 呼び出しで子要素をネストしてください。
• 位置の依存関係。 オペレーションBがオペレーションAで作成したブロックの位置を参照する場合は、2回に分けて呼び出すことを推奨します。配列の途中で失敗すると、ドキュメントは部分的に更新された状態になります。
• 同一ブロックの競合検出。 同じ呼び出し内（または同じユーザーターン内）で複数のオペレーションが同じ block_id を対象にする場合は、実行前に競合についてユーザーに伝えてください。確認されている動作は「後の書き込みが優先」です。例：update_block で段落Xにメンションを追加し、その後の update_block で段落X全体を置き換える場合、後者が優先され、メンションは失われます。
• コメントのアンカーはデルタ内にあります。 ブロックにアンカー付きコメントがある場合、読み取り応答では該当するテキスト挿入の attributes.comments: [<update_id>, ...] に表示されます。update_block は delta_format 全体を置き換えるため、内容をそのまま書き直すとコメントはブロックから切り離されます（コメント自体はバックエンドのアイテムに残りますが、ブロックとのリンクは失われます）。編集後もアンカー付きコメントを維持するには、新しいデルタの対応するテキスト挿入に comments 属性を含めてください。

Step 5：確認して伝える

重要な編集を行った後は、include_blocks: true を指定して再読み込みし、ブロックが意図したとおりに反映されたことを確認してください。平易な言葉で、変更内容とドキュメントのURLを伝えてください。API呼び出しについて説明する必要はありません。

リッチコンテンツ：テーブル、通知ボックス、レイアウト、メンション、ライブ埋め込み、コメント

ライブ列値の埋め込みは、ドキュメントを実際のボードデータと同期させる独自機能です。これらの要素を追加する前に、references/rich-content.md を読んでください。テーブルの制約、通知ボックスのネスト、レイアウト、メンションの種類、ライブ列値の埋め込み、コメントについて説明しています。

スマートなデフォルト

ユーザーがすべての値を指定していない場合：

• ワークスペース：get_user_context で取得したユーザーのメインワークスペースを使います。デフォルトを明示してください。複数のワークスペースが候補になる場合は、一度だけ確認してください。
• doc_kind：public（プラットフォームのデフォルト）。
• フォルダー：なし（ワークスペースのルート）。
• ドキュメントの形式：ユーザーが用途（「議事録」「RFC」「週次報告」など）を指定した場合は、対応する形式を出発点としてひな形を作成し、ユーザーの具体的な要望に合わせて拡張してください。ユーザーが独自の形式を考案した場合は、判断に基づいて構成し、テンプレートを用意する必要はありません。
• モード：デフォルトでは受動的なひな形（スロットマーカー）を使います。名前に基づく意図が示されている場合に限り、アクティブモード（実際の埋め込み／メンション／相互リンク）に切り替えてください。
• アクティブモードでの埋め込みとメンション：設定する前に、解決した内容とその理由を伝えてください。変更できることも案内してください。

ユーザーが変更できるように、すべてのデフォルトを回答に明記してください。

書き込み前に前提条件を検証する

• ドキュメントの存在： 書き込みを行う前に、対象 ID に対する read_docs が成功していること。
• ブロック ID が有効： operations 配列内のすべての block_id が、直近の read_docs 呼び出しから取得したものであること。
• メンション用のユーザー ID： list_users_and_teams を使って解決する（必ず name または userIds フィルターを指定する）。
• 埋め込み用のアイテム ID と列 ID： 書き込み前に、get_board_info と get_board_items_page で両方を確認する。Status 列 ID は常にボード固有の値（例：color_mm2x25ey）とし、汎用のリテラル "status" は使用しない。
• ワークスペースの存在： ユーザーがワークスペース名を指定したものの ID を提示していない場合は、list_workspaces を呼び出す。
• アイテムに添付するドキュメントのセル容量： create_doc location=item の前に、対象ドキュメント列を get_board_items_page で事前確認する（手順 1 を参照）。
• アクティブモードでデータが空の場合のフォールバック： ユーザーの意図が値の設定されていない列（例：「最優先事項」と指定されたが、Priority 列の値がすべて null）を参照している場合、黙って選択してはいけません。空の状態を検出し、その旨（「どのアイテムにも Priority の値が設定されていません」）をユーザーに伝え、明確な理由を添えて代替の判断基準を提示し（「代わりに Status と Due Date までの近さで選びます」）、変更の希望も尋ねてください。

書き込み前の重複検出

create_block、add_markdown_content、add_comment、または内容を置き換える update_block を実行する前に、提案する内容とドキュメント内の既存ブロックを比較してください。 一致した場合は、既定でスキップして報告し、ユーザーに選択肢を提示してください。重複を黙って作成してはいけません。

ブロックの種類ごとの一致判定基準：

ブロックの種類	一致判定基準
テキスト／見出し／引用／コード	差分テキストが完全一致し、サブタイプも同じ
list_item	テキストが完全一致し、リストの種類が同じで、隣接している（複数の箇条書きからなるセクションはグループとして判定）
notice_box	テーマと子テキストが同じ
テーブル	寸法とすべてのセル内容が同じ
メンション	同じブロック位置に同じ user_id がある
column_value 埋め込み	同じブロック位置に同じ item_id と column_id がある
コメント	本文とアンカーが同じ（既定では除外。以下を参照）

一致が見つかった場合のスキルの動作：

1. 既定：スキップして報告する。 「<位置> に X がすでにあります。重複を避けるためスキップします。」
2. 選択肢を提示する（黙って選択しない）：
   • (a) スキップ - 既存の内容を維持し、何もしない
   • (b) 複製 - 冗長性を承知のうえで、依頼どおりに進める
   • (c) 置換 - 既存の内容を削除し、新しく作成する
   • (d) 移動 - 新しい依頼に明確な位置の指定（「先頭に／末尾に／X の後に」）があり、既存の一致項目の位置と競合する場合にのみ提示する

重複が通常の動作であり、検出対象にしてはいけないケース：

• コメントは、短時間の連続投稿を除いて対象外です。 同じ本文のコメントが同じ範囲（ドキュメントまたはブロック）に 60 秒以内に投稿された場合、ほぼ間違いなく二重送信またはネットワークリトライです。それより後であれば、正当な再レビューや感情の反復として扱います。
• リスト内で隣接する同じスタイルのブロック - 重複ではなく、意図された構造です。
• 異なる親の下にある同じセクション名の繰り返し（例：異なる H2 の下にある 2 つの「Action Items」H3）。

この重複検出ルールを、スキル内のすべての書き込み経路に適用してください。

エラーと修正方法を伝える

呼び出しに失敗した場合は、何が問題だったのか、どう修正すればよいのかをユーザーに伝えてください。よくある失敗とその修正方法（不正な形式または古いブロック ID、スキーマの不一致、1 回の呼び出しでのネスト、セル数の上限、空の埋め込み、プランの上限、未対応のブロックタイプ、孤立したコメントアンカー）については、references/errors.md に記載されています。

破壊的な操作は慎重に行う

次の場合は、明示的な確認を求めてください。

• 1 回の呼び出しで 3 個以上のブロックを削除する場合。
• 親に含まれる唯一のコンテンツであるブロックを削除する場合（親の唯一のコンテンツが削除され、親は空の状態で残ります）。
• notice_box、テーブル、またはレイアウトを削除する場合（子要素は自動的に削除されず、孤立します）。先に子要素を削除するか、孤立した状態を受け入れてください。
• 複数の replace_block 操作をまとめて行う場合（各置換は削除と作成を伴い、元に戻せません）。
• 外部から参照されているドキュメント（Slack のメッセージ、他のドキュメント、アイテムの更新）を改名する場合。

単一ブロックの編集、単一ブロックの作成、単一コメントには、追加の確認は不要です。ユーザーはすでに依頼しています。

MCP UI ウィジェットを使う場面

ドキュメント自体が UI です。ドキュメントの内容を表示するために show-table や show-chart をレンダリングしないでください。確認にはプレーンテキスト、要約には Markdown を使ってください。

生の JSON ではなく平易な言葉で伝える

「read_docs を呼び出してから、update_block 操作で update_doc を実行しました」とユーザーに伝えないでください。何が変更されたかを平易な言葉で伝えてください。例：「ランブックの 2 番目の段落に、新しいエスカレーション連絡先を追加しました。」必ずドキュメントの URL を含めてください。

使用するツール

• get_user_context - ユーザーのプライマリワークスペースを特定
• list_workspaces - ワークスペース名が指定されていない場合に、名前からワークスペースを検索
• create_doc - ワークスペース内、またはアイテムに添付してドキュメントを作成。作成時に Markdown 本文をブロックとしてインポート
• read_docs - 1 つ以上のドキュメント（コンテンツモード）またはバージョン履歴を取得。編集前には include_blocks: true が必須。コメントスレッドには include_comments: true
• update_doc - 順次実行する操作：set_name、add_markdown_content、update_block、create_block、delete_block、replace_block、add_comment
• list_users_and_teams - メンションおよび mentions_list 用のユーザー ID を特定（対象を絞るため、必ず name または userIds を指定）
• get_board_info - ライブ列値埋め込みを書き込む前に列 ID を検証。アクティブモードで埋め込みを設定する前にボード構造を確認
• get_board_items_page - ライブ列値埋め込みを書き込む前にアイテム ID を検証。アイテムに添付して作成する場合はドキュメント列のセルを事前確認。アクティブモードではアイテム名から ID を特定
• search - アクティブモードで、名前からドキュメントまたはボードをあいまい検索

追加リソース

• references/block-operations-matrix.md - ブロックタイプごとに許可される操作、注意点、ペイロードの例。
• references/create-modes.md - パッシブスキャフォールドのスロットマーカー、アクティブモードのトリガー、名前から ID を特定する方法、コミュニケーションに関する取り決め。
• references/rich-content.md - テーブル、通知ボックス、レイアウト、メンション、ライブ列値埋め込み、コメント。
• references/read-rendering.md - ドキュメントの読み取り時に、メンション、埋め込み、インライン要素をレンダリングする方法。
• references/errors.md - よくあるエラーとその修正方法。
• references/delta-format-cheatsheet.md - delta_format の挿入操作、属性、メンション、column_value 埋め込み、終端ルール、一般的なパターン、パッシブモードのスロットマーカー形式。