Author a playbook

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

{
	"ownerId": "<account-id>",
	"acl": ["<user-or-team-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.

Once a playbook exists, save changing work as a draft rather than publishing each attempt. A draft is mutable and versionless — save it as many times as the definition needs before publishing turns it into a version.