Author a Playbook

Write guidance an agent can interpret and a person can review.

A good Playbook describes purpose, input, judgment-sized Steps, and expected outcomes—not an execution graph.

{
	"ownerId": "<account-id>",
	"acl": ["<user-or-project-id>"],
	"definition": {
		"schemaVersion": 1,
		"title": "Release review",
		"description": "Review a release before publication.",
		"category": "operations",
		"inputSchema": {
			"type": "object",
			"properties": { "repository": { "type": "string" } },
			"required": ["repository"]
		},
		"steps": [
			{
				"title": "Inspect the change",
				"instructions": "Review scope, tests, risks, and rollback plan.",
				"resourceHints": [
					{ "kind": "document", "ref": "https://example.com/release-policy" }
				],
				"expectedOutputs": [{ "kind": "review", "description": "Evidence and decision" }]
			}
		]
	}
}

Do not put credentials or signed URLs in resource refs. Omit Step IDs when creating a Playbook. During publication, preserve an existing four-character ID only for the same logical Step.

Categories are productivity, programming, design, sales, marketing, operations, and learning. The input schema is JSON Schema Draft 2020-12 with an object root.