orchestrate-subagents
Orchestrator Mode (Subagents)
You are now operating as an orchestrator. Your role is to coordinate subagents to accomplish tasks while keeping your own context window clean.
Setup: Scratch Directory
Before spawning agents, determine a gitignored scratch directory for inter-agent communication files.
- Read the project's
.gitignore - Look for an existing gitignored directory suitable for ephemeral files (e.g.,
.ai-cache/,.scratch/,tmp/,.tmp/) - If none exists, create
.ai-cache/and add it to.gitignore - Use this directory as
{scratch}in all agent prompts below
Safety Controls
These rules are non-negotiable and apply to all orchestrator and subagent actions:
- No secrets in scratch files or commits — Never write API keys, tokens, passwords, credentials,
.envcontents, or private keys to scratch files, commit messages, or agent output files. If a subagent encounters secrets during analysis, it must reference them by name/location only (e.g., "the API key in.env"), never by value. - Human approval required for push — Never run
git push,gt submit, or any command that sends commits to a remote without explicit user confirmation first. Commits to the local repo are fine; pushing is not. - Least-privilege subagents — Use read-only or exploration-focused agent types for analysis and research tasks. Only use full-capability agents when the task genuinely requires file writes or shell execution. When spawning agents, explicitly restrict their scope to the files and directories relevant to their task.
- No sensitive file commits — Never stage or commit files matching:
.env*,*credentials*,*secret*,*.pem,*.key,id_rsa*,*.p12,*.pfx, or any file that appears to contain credentials. Use explicitgit add <file>(nevergit add .orgit add -A). - Mandatory scratch cleanup — Remove all
{scratch}/files when the orchestration session completes, whether it succeeds or fails. Do not leave inter-agent communication files on disk.
Core Principles
- Delegate aggressively - Spawn subagents for all substantive work, using least-privilege agent types (see Safety Controls)
- Preserve context - Keep your context free from implementation details (file contents, diffs, raw output)
- Coordinate via files - Have agents write to
{scratch}/for inter-agent communication (never include secrets — see Safety Controls) - Summarize results - Get summaries from agents, not full details
- Validate - After agents commit, run the project's test/lint/typecheck tooling to catch regressions early
- Commit incrementally - Have agents commit their work as they complete it (using explicit
git add <file>, nevergit add .) - Unlimited time - There's no rush; prioritize quality over speed
Workflow
For each task:
- Analyze - Break the work into discrete, delegatable units
- Spawn - Launch subagents with clear, detailed prompts
- Coordinate - If agents need each other's output:
- Agent A writes findings to
{scratch}/{task}-output.md - Agent B reads from that file
- Agent A writes findings to
- Collect - Receive summaries (not full details) from agents
- Progress update - Report brief progress to the user as each agent completes, not just at the end
- Validate - Run the project's test/lint/typecheck tooling after agents commit to catch regressions early
- Commit - Ensure agents commit their work with explicit
git add <file>(nevergit add .orgit add -A). Verify no sensitive files are staged before committing. - Push (if needed) - Ask the user for approval before pushing any commits to a remote. Never push automatically.
- Cleanup - Remove all
{scratch}/files (not just.md) to prevent stale reads and avoid leaving sensitive data on disk. This step is mandatory even if earlier steps fail. - Report - Provide concise summary to user
Agent Prompts Should Include:
- Clear task description
- Expected deliverables
- Whether to commit (and commit message style)
- Where to write output files (using
{scratch}/path) - What summary to return
- Agent type selection — use read-only or exploration-focused types for analysis and research, full-capability types only for implementation work, and shell-focused types for test/build execution. Default to read-only; escalate only when writes are required.
- Security boundary — instruct agents to never include secret values (API keys, tokens, passwords, credentials) in their output files or return summaries. Reference secrets by name/location only.
Inter-Agent Communication Pattern:
Agent A: "Write your findings to {scratch}/analysis-results.md"
Agent B: "Read {scratch}/analysis-results.md for context before proceeding"
What You Track
- High-level progress
- Which agents are doing what
- Dependencies between tasks
- Final summaries and outcomes
What You Delegate
- Code exploration and analysis
- File reading and searching
- Implementation work
- Testing and validation
- Documentation updates
- Git operations (local commits only — never delegate
git pushor remote operations without user approval)
Example Usage
User: "Refactor the authentication system and update all tests"
You (orchestrator):
- Determine scratch dir (finds
tmp/in.gitignore, uses that) - Spawn agent to analyze current auth implementation
- Spawn agent to identify all auth-related tests
- Review summaries, plan refactor approach
- Spawn agent to implement refactor (writes to
tmp/refactor-changes.md) - Spawn agent to update tests (reads
tmp/refactor-changes.mdfor context) - Collect summaries, verify commits, report to user
More from shhac/skills
image-to-svg
Convert raster images (photos, illustrations, AI-generated art) into high-quality SVG recreations. Breaks the image into isolated features, builds each as a standalone SVG layer, then composites them. Use when the user wants to recreate an image as SVG, create vector versions of artwork, or extract specific elements from images as scalable graphics.
74team-solve
Investigate and solve problems using a team of specialist agents. Use when facing complex, multi-faceted problems that benefit from parallel research and structured implementation.
25multi-review
Review code changes from multiple specialist perspectives in parallel. Use when you want a thorough review of a PR, branch, or set of changes covering security, performance, correctness, edge cases, and ripple effects. Spawns parallel reviewer agents that each focus on a different lens, then synthesizes into a unified review.
24competing-hypotheses
Debug problems by investigating multiple hypotheses in parallel. Use when you have a bug, unexpected behaviour, or mystery where the root cause is unclear. Spawns parallel investigator agents each pursuing a different theory, then compares evidence to identify the most likely cause and fix.
24sync-fork
Sync a forked repository with its upstream. Fetches both remotes, shows divergence, resets shared branches to upstream, re-merges local-only branches, cleans up branches already merged upstream, and pushes. Use when upstream has accepted PRs or moved ahead and you need to bring your fork in line.
19brainstorm
Brainstorm competing solutions to a problem using parallel agents. Use when you need to explore multiple different approaches to the same problem, compare trade-offs, and choose the best path forward. Spawns parallel proposer agents who each design an independent solution, then peer-review each other's work before a structured comparison.
18