Playbooks And Authoring

The Playbooks surface is where operators and designers define reusable workflow process.

This is one of the most important ideas in Agirunner. The product is not trying to make every workflow a one-off prompt session. It is trying to let teams author process intentionally and then launch that process repeatedly with new context.

Library And Authoring

The dashboard supports both:

browsing existing playbook families and revisions
creating or editing a playbook through the authoring form
importing a community playbook from agirunner-playbooks

The authoring flow starts from process and outcome, then lets you open deeper overrides only where they are justified. That posture matters. It encourages readable process design instead of pushing authors straight into low-level control fields.

What You Configure

name, slug, and outcome
lifecycle posture such as planned or ongoing
process instructions
launch parameters
team and specialist expectations
advanced workflow controls when needed

The platform code also makes it clear that playbooks are managed as revisioned records and grouped into families in the dashboard library. That is the right mental model:

the library is where you browse and compare
the authoring form is where you shape one revision deliberately

Community Catalog Import

The playbook library also includes Add Community Playbook for the shared catalog in agirunner-playbooks.

The import flow is intentionally narrow:

browse catalog entries by search, category, and stability
preview one playbook at a time, including stages, referenced specialists, referenced skills, and README guidance
choose whether conflicts should create a new local artifact or override an existing one
import tenant-local copies instead of creating a live upstream dependency

Imported playbooks show a quiet provenance line, but after import they behave like normal local platform artifacts. In v1, the platform does not try to keep them synced to upstream automatically.

Why This Matters

The strongest message here is not “playbooks are configurable.” It is “playbooks let you author process intent clearly.” Good playbooks make it obvious what outcome the workflow is trying to reach, how the work should be staged, and where operator judgment fits in.

How It Connects To The Rest Of The System

Playbooks are upstream of nearly every other workflow-facing surface:

Workflows launch concrete runs from playbook definitions
Workflow Detail shows how one run of that playbook actually unfolded
Specialists, Skills, And Models is where imported specialist and skill copies show up after a community playbook import
Orchestrator interprets the authored process and decides how to decompose or route work
Approvals And Needs Action is where the operator-facing control moments designed into the process become visible

This page answers “what process should exist?” The workflow and runtime surfaces answer “how did that process execute this time?”