Documentation
¶
Overview ¶
Package playbooks owns clawtool's read-only ingestion of external workflow / playbook formats. Phase 1 carries one entrant: the Archon YAML workflow loader (coleam00/Archon, MIT). Phase 2 will wire execution; today the loader only parses + surfaces.
Targeted Archon schema: the v2 DAG-workflow format used by `.archon/workflows/*.yaml`, as documented at https://archon.diy/guides/authoring-workflows/ and observed in upstream's defaults at .archon/workflows/defaults/ on the `dev` branch (commit set as of 2026-04-29). Archon does not version-tag its schema; we pin behaviour to that snapshot. Unknown / future node kinds are tolerated (tagged "unsupported:<name>") so a schema bump won't crash the loader.
Index ¶
Constants ¶
This section is empty.
Variables ¶
var ErrArchonYAMLParse = errors.New("playbooks: archon yaml parse error")
ErrArchonYAMLParse wraps a yaml.v3 decode failure for a single workflow file. Tests pin this typed error via errors.Is.
Functions ¶
This section is empty.
Types ¶
type ArchonLoop ¶
type ArchonLoop struct {
Prompt string
Until string
MaxIterations int
FreshContext bool
Interactive bool
}
ArchonLoop is the projection of an Archon `loop:` block. Phase 2 will translate Until / MaxIterations / FreshContext / Interactive into clawtool TaskWait + SendMessage primitives.
type ArchonNode ¶
type ArchonNode struct {
// ID is the node's `id:` field. Empty IDs are tolerated for
// hand-edited drafts (Archon itself rejects them at run time).
ID string
// Kind is one of:
// "prompt" — `prompt: ...` (AI step)
// "bash" — `bash: ...` (deterministic shell step)
// "loop" — `loop: { prompt, until, max_iterations, ... }`
// "command" — `command: archon-<slug>` (slash-command dispatch)
// "unsupported:<original-key>" — recognised but not yet supported
// (e.g. "unsupported:parallel"). Phase 2 wires these.
Kind string
// Prompt is populated when Kind == "prompt".
Prompt string
// Bash is populated when Kind == "bash".
Bash string
// Loop is populated when Kind == "loop". Pointer so the zero
// value is unambiguously "not a loop".
Loop *ArchonLoop
// Command is populated when Kind == "command".
Command string
// DependsOn mirrors the YAML `depends_on:` list. Phase 2 uses
// this for DAG traversal; phase 1 only carries it through.
DependsOn []string
}
ArchonNode is the discriminated-union view of one workflow node. Kind selects which of Prompt / Bash / Loop / Command is populated; the others are zero. Unknown kinds are tagged "unsupported:<orig>" so phase 2 can wire them without re-parsing.
type ArchonWorkflow ¶
type ArchonWorkflow struct {
// Name is the workflow's `name:` field. Defaults to the file's
// basename (sans .yaml) when missing so list output stays
// useful for unnamed drafts.
Name string
// Description is `description:` (often a multi-line block scalar
// in upstream defaults). May be empty.
Description string
// Path is the absolute path the workflow was loaded from.
// Surfaced so phase 2 can re-open the file for execution.
Path string
// Nodes preserves source order. DAG topology lives in the YAML
// (`depends_on` per node); we don't resolve it at parse time.
Nodes []ArchonNode
}
ArchonWorkflow is the projected view of one .archon/workflows/<f>.yaml file. We deliberately only carry Name, Description, and the node list — fields like top-level `inputs`, `outputs`, and adapter hints are out of phase-1 scope.
func LoadFromDir ¶
func LoadFromDir(dir string) ([]ArchonWorkflow, error)
LoadFromDir walks <dir>/.archon/workflows/*.yaml (non-recursive, matching upstream's flat layout), parses each, and returns a slice sorted by workflow Name for stable list output. The upstream `defaults/` subdirectory is intentionally excluded — those are bundled samples, not the operator's playbooks.
A malformed file aborts the load and returns ErrArchonYAMLParse wrapped with the offending path. Callers that want best-effort loading can filter to the un-malformed entries themselves.
func (ArchonWorkflow) Summary ¶
func (w ArchonWorkflow) Summary() string
Summary returns a one-line human banner describing the workflow. Format: `<name> — <node-count> nodes`. CLI list output uses this directly; phase 2 may extend it with status indicators.