プレイブックを書く

人やエージェントが使える手順と判断基準をまとめます。


プレイブックには、仕事の目的、必要な入力、手順、期待する成果を記述します。実行順序を細かく制御するプログラムではなく、状況に応じて使える指針としてまとめます。

{
	"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 を使います。

既存のプレイブックを試しながら直すときは、下書きを使います。何度保存しても新しいバージョンは作られず、内容が固まったら新しいバージョンとして保存します。操作はプレイブックを作成してバージョンを保存するを参照してください。