Orchestration
Portable Agent Skills for coding agents, including Svelte/SvelteKit and workflow tooling skills.
npx -y skills add spences10/skills --skill orchestrationAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
- 13 stars13 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Coordinate parallel agent work. Use when decomposing complex tasks, running review/implementation in parallel, managing task lists, or choosing shared vs isolated workspaces.
SKILL.md
3.2 KB, as published. Nobody here has run it
Orchestration
Coordinate multi-agent or multi-session coding work without duplicated effort, context loss, or unnecessary integration overhead. Stay harness-agnostic: use whatever task, teammate, subagent, or mailbox primitives are available, and keep git worktrees as an explicit isolation choice rather than the default.
When to Use
- Complex work that can split by domain, file area, or risk level
- Parallel review, research, testing, or documentation passes
- Background investigation while the lead preserves high-value context
- Risky changes where isolation may be worth the setup and merge cost
Core Rules
- Assign clear ownership: one agent/session owns each file or subsystem.
- Keep the lead session responsible for synthesis, review, and final decisions.
- Prefer one mutating worker in the shared cwd/current branch unless parallel edits are clearly independent.
- Use parallel workers freely for read-only research, review, logs, CI, or test investigation.
- Create a shared task list with dependencies and acceptance criteria.
- Require concise handoff notes: files touched, decisions made, validation run, blockers.
- If the harness supports read-only/mutating flags, mark file-editing workers as mutating.
Workspace Choice
Default to the current shared workspace for small, sequential, or tightly-coupled changes. It keeps local env, ignored files, ports, databases, and devcontainers intact.
Use isolated workspaces — git worktrees, cloned checkouts, containers, VMs, or cloud previews — only when the isolation benefit beats setup/runtime/integration cost.
Before choosing a worktree, answer:
- How are ignored files, dependencies,
.env, generated files, and package caches handled? - Are ports, databases, queues, and local services isolated?
- Who integrates the branch/patch and resolves semantic conflicts?
- How is cleanup handled after review?
Decomposition Patterns
| Pattern | Use when |
|---|---|
| Fan-out | Same operation across independent areas |
| Pipeline | Research → implement → test → docs |
| Reviewer/implementer | One session changes, another critiques |
| Speculative branches | Trying competing approaches safely |
| Background monitor | Long-running CI, logs, or investigation |
References
- patterns.md - Orchestration patterns
- domains.md - Domain-specific decomposition
- task-management.md - Dependencies, task graphs, file partitioning
- worktree-commands.md - Git worktree command reference
- session-strategies.md - Multi-session patterns
- cleanup.md - Worktree removal and maintenance