プレイブックを書く
人やエージェントが使える手順と判断基準をまとめます。
プレイブックには、仕事の目的、必要な入力、手順、期待する成果を記述します。実行順序を細かく制御するプログラムではなく、状況に応じて使える指針としてまとめます。
{
"ownerId": "workspace-uuid",
"teamIds": ["team-uuid"],
"definition": {
"schemaVersion": 1,
"title": "リリースのレビュー",
"description": "公開前にリリース内容をレビューします。",
"category": "operations",
"inputSchema": {
"type": "object",
"properties": { "repository": { "type": "string" } },
"required": ["repository"]
},
"steps": [
{
"title": "変更内容を確認する",
"instructions": "変更範囲、テスト結果、リスク、ロールバック計画を確認します。",
"resourceHints": [
{ "kind": "document", "ref": "https://example.com/release-policy" }
],
"expectedOutputs": [{ "kind": "review", "description": "根拠と判断" }]
}
]
}
}teamIds の例は、選択中の所有元ワークスペースで所属するチームに非公開の編集権限を付与します。作成者への直接共有には private: true、初期設定全体の指定には access を使い、必ず1つだけ選びます。詳細はアクセスと権限を参照してください。
各手順は、成果を確認できる単位に分けます。ツールや資料の参照先に、認証情報や期限付きの署名 URL を含めないでください。新しい手順の ID は省略し、既存の手順を編集するときは同じ4文字の ID を使います。
カテゴリは productivity、programming、design、sales、marketing、operations、learning から選びます。入力項目の定義(inputSchema)には、最上位がオブジェクトの JSON Schema Draft 2020-12 を使います。
既存のプレイブックを試しながら直すときは、下書きを使います。何度保存しても新しいバージョンは作られず、内容が固まったら新しいバージョンとして保存します。操作はプレイブックを作成してバージョンを保存するを参照してください。