You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Recurring multi-worktree jobs are the same shape every time — "upgrade a dependency across packages", "add an IPC channel end-to-end (types → handler → preload → renderer)", "release checklist" — but each run means re-typing the same subtask breakdown, prompts, and ordering into the fan-out flow (#137).
Proposal
Playbooks: saved, parameterized orchestration recipes — structurally "fancy hooks", and deliberately built on the same architecture as the hooks system.
A playbook defines:
name, description, and parameters (e.g. packageName) substituted into prompts at run time
Running one instantiates the fan-out flow (#137) — prompt-filled dialog first, so the user can tweak before spawning.
Storage & trust — mirror the hooks design
Local:.sproutgit/local-playbooks.json — machine-local, freely editable in the app, always trusted.
Repo:sproutgit.playbooks.json in the worktree — travels with clone/pull, read-only in the app, "repo" badge.
Trust is security-critical: a repo playbook's prompts are instructions executed by agents holding real tools (worktree creation, PR actions via Wire SproutGit's MCP server into every integrated agent session #145) — a hostile repo could ship a prompt-injection playbook. Reuse the per-item content-hash trust model from hooks-trust.ts: a repo playbook must be explicitly trusted per content-hash before it can run, and editing one invalidates only its own trust.
Agent access
Expose list/inspect/run as MCP tools (#145) so a planner can say "this repo ships a release playbook — run it with version=1.2.0". Running remains gated by the same trust + permission settings as everything else.
Problem
Recurring multi-worktree jobs are the same shape every time — "upgrade a dependency across packages", "add an IPC channel end-to-end (types → handler → preload → renderer)", "release checklist" — but each run means re-typing the same subtask breakdown, prompts, and ordering into the fan-out flow (#137).
Proposal
Playbooks: saved, parameterized orchestration recipes — structurally "fancy hooks", and deliberately built on the same architecture as the hooks system.
A playbook defines:
name,description, and parameters (e.g.packageName) substituted into prompts at run timedependsOnordering (Subtask dependencies in fan-out: run the plan as a pipeline #148), per-subtask role hints (worker vs orchestrator defaults from Role defaults: default orchestrator and worker agent+model #151, overridable agent/model)Running one instantiates the fan-out flow (#137) — prompt-filled dialog first, so the user can tweak before spawning.
Storage & trust — mirror the hooks design
.sproutgit/local-playbooks.json— machine-local, freely editable in the app, always trusted.sproutgit.playbooks.jsonin the worktree — travels with clone/pull, read-only in the app, "repo" badge.hooks-trust.ts: a repo playbook must be explicitly trusted per content-hash before it can run, and editing one invalidates only its own trust.Agent access
Expose list/inspect/run as MCP tools (#145) so a planner can say "this repo ships a release playbook — run it with version=1.2.0". Running remains gated by the same trust + permission settings as everything else.
Related: #134 (epic), #137 (fan-out), #148 (dependencies), #151 (role defaults).