converge-controllisted

Operate a Converge playbook end-to-end — start runs, monitor progress, narrow failures with `--select`, inspect runtime state, validate definitions, surgically reset subtrees, and stop stuck or orphaned runs. Use this skill whenever the user says "run my playbook", "execute this", "monitor the run", "converge failed", "the run is stuck", "retry failures", "babysit this playbook", "what's the status?", "show me the gantt", or asks how to use `converge run` / `--select` / `inspect` / `doctor` / `clean` / `stop`. Also use it for `HTTP 401` / `Invalid API key` failures on the first task — those are environment-not-playbook problems — and for any post-run cleanup work. Hand off to `converge-planning` if the user wants to design or restructure the playbook itself.
openplaybooks-dev/converge · ★ 3 · AI & Automation · score 76

Install: claude install-skill openplaybooks-dev/converge

# Converge Control ## When to use this skill Trigger this skill whenever the user is operating an existing playbook — not authoring a new one. Concrete signals: - A `.converge/project.yaml` + `playbooks/<name>/` already exist; the user wants the playbook to actually run, or wants to know what happened on the last run. - The user reports a failure mid-run, a stuck task, an error in the journal, or wants to retry only what failed. - The user asks operational questions: *what's running right now?*, *which tasks are blocked?*, *what did task X produce?*, *how much did the last run cost?*, *how do I re-run just the failures?* - The user hits HTTP 401 / Invalid API key — that's an environment conflict between shell `ANTHROPIC_*` vars and the project's provider config, not a playbook bug. See entry §13 in `troubleshooting/playbook.md`. If the user wants to design a new playbook, change its task tree, or factor reusable instructions into skills, **hand off to `converge-planning`**. This skill only operates what already exists. ## Current mental model Converge has three important layers: 1. **Source blueprint** — `.converge/playbooks/<name>/` - `playbook.yml` — the manifest (top-level tasks, `depends_on`, `goals`). - `tasks/**/TASK.md` — task contracts (id, inputs, outputs, checks). - `templates/<name>/TASK.md` — runtime spawn templates for dynamic children. - `skills/<name>/SKILL.md` — **playbook-scoped skills** (the *how* paired with each task's *w