Crear un playbook

Un buen playbook describe el propósito, los aportes, los pasos a considerar y los resultados esperados, no un gráfico de ejecución.

{
	"ownerId": "workspace-uuid",
	"teamIds": ["team-uuid"],
	"definition": {
		"schemaVersion": 1,
		"title": "Revisar una versión",
		"description": "Revise una versión antes de publicarla.",
		"category": "operations",
		"inputSchema": {
			"type": "object",
			"properties": { "repository": { "type": "string" } },
			"required": ["repository"]
		},
		"steps": [
			{
				"title": "Inspeccionar el cambio",
				"instructions": "Revise el alcance, las pruebas, los riesgos y el plan de reversión.",
				"resourceHints": [
					{ "kind": "document", "ref": "https://example.com/release-policy" }
				],
				"expectedOutputs": [{ "kind": "review", "description": "Pruebas y decisión" }]
			}
		]
	}
}

El ejemplo de teamIds concede edición restringida a un Equipo al que pertenece en el Espacio propietario activo. Use private: true para acceso directo al creador o access para la configuración inicial completa; elija exactamente una opción. Consulte Acceso e identidad.

No coloque credenciales ni URL firmadas en las referencias de recursos. Omita los ID de pasos al crear un playbook. Durante la publicación, conserve una identificación de cuatro caracteres existente solo para el mismo paso lógico.

Los valores admitidos de categoría son productivity, programming, design, sales, marketing, operations y learning. El esquema de entrada es JSON Schema Draft 2020-12 con una raíz de objeto.

Una vez que exista un playbook, guarde el trabajo modificado como un borrador en lugar de publicar cada intento. Un borrador es mutable y no tiene versión: guárdelo tantas veces como necesite la definición antes de que su publicación lo convierta en una versión.