
チームの経験をSkillにまとめれば、次のエージェントに同じ説明を繰り返さずに済みます。資料、フィールド、検証、最後の「自動承認してマージ」まで手順に残したとします。別の仕事でそのSkillが見つかった時、この一文は作業方法なのか、今回の操作への許可なのかが問題になります。
悪意ある外部資料だけの問題ではありません。自分たちの古い手順でも、別のBaseや以前の承認約束を参照したり、今回は原稿だけという依頼を超えたりします。方法が見つかりやすくなるほど、手順と現在の委任を分ける必要があります。
Agent Playbooksの仕様では現在のユーザー指示が優先され、保存された方法はキーの能力やマージ許可を増やしません。選んだSkill、今回の依頼、実効権限を同じ変更へ対応させることが、経験を安全に再利用する条件です。
検索で見つかったことの意味
Skillとノードのカスタムシナリオがplaybookに当たります。エージェントは依頼を複数の表現に言い換え、名前、説明、シナリオから探します。キーが読めないノードの方法は検索結果に現れません。
名前が近いことは発見の助けであり、すべての操作の適用確認ではありません。方法の名前、置かれたノード、命中理由、全文を確認します。今回は待審原稿だけを依頼されているなら、正式内容を書き込む通常手順をその範囲に狭めます。別部署のBase名も、そのまま転用しません。

三つの根拠を対応させる
方法は、何を読み、どの項目を使い、どう検証するかを示します。対話での依頼は、今回の対象、範囲、成果物、人が判断する操作を定めます。認証情報とスペースのロールは、システムが許す操作を定めます。
Skillには合意済みの手順を残せますし、ユーザーが一定範囲の継続的な許可を与えることもあります。ただし実行時には、その許可が今回も適用されるかを確認します。Skillの一般的な「自動承認」という一文を、新しい委任として扱うことはできません。Writeキーも編集上の承認の代わりにはなりません。
操作を決めてから書き込み方を選ぶ
事実の説明だけなら、レコード変更は不要かもしれません。変更提案が許可されているなら、対象Base、レコード、フィールドを明確にします。マージまで許可されている場合も、今回の範囲と実効権限を確認し、近隣のレコードへ広げません。
APIキー仕様はRead、Change Request、Write、Manageを区別しています。提案専用キーは自分の提案をマージできず、Writeは既定で即時マージできます。人のレビューが必要なら、実際のリクエストでautoMerge: falseを明示するか、適切な提案専用キーを使います。「待って」と文章に書くだけでは、サーバーの設定にはなりません。

via playbookは出典の記録
エージェントは使った方法の名前とリンクを示します。ChangeRequestやInboxのvia playbook表示から、その方法へ戻れます。書き込み側が出典を宣言し、Busabaseは存在と読み取り可能性を確認して名称を記録します。
これは承認証明でも、手順を正しく理解した証明でもありません。出典の検証に失敗しても、書き込み自体は成功し表示だけが付かないことがあります。表示がないから未変更、表示があるから業務承認済み、と判断せず、差分と実際の状態を確認します。
変更から根拠へさかのぼる
まず対象レコードの変更前後を読みます。引用された方法を開き、今回の仕事に合うかを確認します。依頼された範囲と、実際に変更した対象・項目・マージ操作を照合します。最後にCR状態と、マージ済みなら正式レコードの値を読み戻します。
引き継ぎには方法のリンク、今回の範囲、対象レコード、CR、未決事項を残します。キーの値や無関係な私的対話を含める必要はありません。この確認手順を、すべてのプロンプトインジェクションを自動防止する仕組みとして説明しないことも大切です。

手順が依頼と衝突したら
SkillがLeadsを指定し、現在の依頼がPartnersなら、仕様どおり現在の指示を優先します。未許可の公開、削除、マージが関わるなら、準備済み成果を保ち、必要な判断を具体的に示します。再利用できる手順は説明を減らせますが、新しい範囲判断を人に代わって行うものではありません。
パッケージのインストール境界は何が有効になるか、検索範囲と古い抽出結果は何を見つけられるかを扱います。発見、導入、利用、マージの許可は別々の操作です。
よくある質問
Writeキーなら許可の確認は不要?
必要です。キーは能力を定め、現在の依頼は今回許された仕事を定めます。レビューが必要ならリクエスト側にもその設定を残します。
表示がなければ方法を読んでいない?
断定できません。宣言の省略や出典検証の失敗も考えられます。何を使ったかを確認し、出典と差分を照合します。
方法を見つけやすくするには?
チームが実際に使う仕事名と説明にし、キーがノードを読めることを確認して、Playbooksの検索プレビューを試します。正確に見つかった後も範囲と権限は別に確認します。