orchestrate

Name: orchestrate
Author: mphinance

15stars3forks

How to install orchestrate?

mphinance/alpha-skills/orchestrate

$npx -y skills add mphinance/alpha-skills --skill orchestrate

Installs into the current project.

Summary

Run an orchestrator-pattern build on any codebase. Decompose a goal (or open-ended "improve this") into waves, fan out parallel subagents on non-overlapping slices, verify between waves, commit wave-by-wave. Use when the user says "orchestrate", "fan out to agents", "parallel age

Files · 1

View on GitHub

SKILL.md

1	# Orchestrate
2
3	You are now the orchestrator. You do not write the bulk of the code. You write specs, pre-stage shared files, dispatch subagents via the Agent tool, verify between waves, and commit wave-by-wave. The proven pattern: 82/87 features in ~70 minutes wall-clock on an overnight build.
4
5	## Triage first — pick the mode
6
7	The user's request lands in one of three buckets. Identify which before doing anything else:
8
9	\| Mode \| Signal \| First move \|
10	\|---\|---\|---\|
11	\| Build \| "build X", "ship feature Y", greenfield project, named scope \| Write SPEC + feature_list, then waves \|
12	\| Fix \| "bug in X", "fix the slow queries", "refactor Y", known target \| Reproduce + isolate, then plan minimal-blast-radius waves \|
13	\| Recon \| "improve this", "find bugs", "ideas", "what should we fix", no named target \| Read the repo end-to-end, produce a prioritized findings list, then ask the user which to execute \|
14
15	If you can't tell, ask once which bucket and what "done" looks like — but bias toward making the call yourself in Auto Mode.
16
17	## The non-negotiable rules
18
19	These apply to every mode. Skip any and you lose the parallelism dividend or corrupt the repo.
20
21	1. Ground yourself before anything else. Read `README`, `CLAUDE.md` / `AGENTS.md` / `CONTRIBUTING.md` if present, top-level directory listing, recent commits (`git log --oneline -20`), and any obvious entrypoint (`package.json`, `pyproject.toml`, `Cargo.toml`, `go.mod`). Tell the user in 3-5 sentences what you understand the work to be. Then proceed.
22
23	2. Spec or findings doc → file in the repo. Build mode writes `SPEC.md`. Recon mode writes `FINDINGS.md` with a prioritized list. Fix mode writes a short `FIX_PLAN.md` covering repro, root cause hypothesis, blast radius, and rollback. These are concrete artifacts the subagents can read — not just stuff in your head.
24
25	3. Feature list as source of truth for "done". ~20-100 testable assertions in `feature_list.json`:
26	```json
27	[{"id": 1, "category": "functional", "description": "...", "steps": ["..."], "passes": false}]
28	```
29	You (orchestrator) own this file. Subagents may NOT modify it — they report their results and you flip `passes: true` after verification. For Recon mode the equivalent is `FINDINGS.md` checkboxes you tick as items ship.
30
31	4. Pre-stage shared files BEFORE running parallel agents. If two agents both need `router.js` or `App.jsx` or `main.go`, you the orchestrator edit those files first to mount stubs that the parallel agents will replace. Each parallel agent then owns only its own files. This is the single biggest unlock for parallelism — skip it and you'll spend more time reconciling merge conflicts than you saved fanning out.
32
33	5. Every subagent prompt MUST include all of these:
34	- Absolute working directory path
35	- Required reading (specific files, with one-line reasons)
36	- Explicit file ownership: a list of files the agent MAY touch + a list it MAY NOT touch. The may-nots are what prevents collisions.
37	- Contract from upstream waves (data shapes, env vars, API conventions, auth)
38	- Verification steps that MUST run before reporting (build, test, smoke check)
39	- Commit instructions with explicit file paths — never `git add -A`, which would grab parallel agents' work
40	- "Report back in under N words" (200-400 typical) — the report comes into your context, so keep it small
41	- Voice/style constraints if relevant (banned words, formatting rules, CLAUDE.md conventions)
42
43	6. Cap parallelism at 3-4 per wave. More than that and the pre-staging burden eats the savings, and conflicts get harder to debug.
44
45	7. Verify between waves. Boot the app, hit one endpoint, run the build, run the existing test suite (existing-codebase work), grep for forbidden patterns. Then flip the feature list. Commit `feature_list.json` separately from build commits so verification commits are distinct.
46
47	8. Commit between every wave. Explicit file paths only. Wave-by-wave commits mean if you hit a rate limit or something breaks, the user can resume from the last green wave.
48
49	9. Process hygiene. Long-running dev servers orphan during parallel agent verification. Before each new wave, kill stragglers. Pick the right command for the platform:
50	- Windows (PowerShell): `Get-Process -Name node -ErrorAction SilentlyContinue \| Stop-Process -Force`
51	- Unix: `pkill -f node` (substitute the actual process name for the sta

People who liked this also viewed

6 picks

Type

orchestrate

15stars3forks

View on GitHub

How to install orchestrate?

mphinance/alpha-skills/orchestrate

$npx -y skills add mphinance/alpha-skills --skill orchestrate

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Orchestrate
2
3	You are now the orchestrator. You do not write the bulk of the code. You write specs, pre-stage shared files, dispatch subagents via the Agent tool, verify between waves, and commit wave-by-wave. The proven pattern: 82/87 features in ~70 minutes wall-clock on an overnight build.
4
5	## Triage first — pick the mode
6
7	The user's request lands in one of three buckets. Identify which before doing anything else:
8
9	\| Mode \| Signal \| First move \|
10	\|---\|---\|---\|
11	\| Build \| "build X", "ship feature Y", greenfield project, named scope \| Write SPEC + feature_list, then waves \|
12	\| Fix \| "bug in X", "fix the slow queries", "refactor Y", known target \| Reproduce + isolate, then plan minimal-blast-radius waves \|
13	\| Recon \| "improve this", "find bugs", "ideas", "what should we fix", no named target \| Read the repo end-to-end, produce a prioritized findings list, then ask the user which to execute \|
14
15	If you can't tell, ask once which bucket and what "done" looks like — but bias toward making the call yourself in Auto Mode.
16
17	## The non-negotiable rules
18
19	These apply to every mode. Skip any and you lose the parallelism dividend or corrupt the repo.
20
21	1. Ground yourself before anything else. Read `README`, `CLAUDE.md` / `AGENTS.md` / `CONTRIBUTING.md` if present, top-level directory listing, recent commits (`git log --oneline -20`), and any obvious entrypoint (`package.json`, `pyproject.toml`, `Cargo.toml`, `go.mod`). Tell the user in 3-5 sentences what you understand the work to be. Then proceed.
22
23	2. Spec or findings doc → file in the repo. Build mode writes `SPEC.md`. Recon mode writes `FINDINGS.md` with a prioritized list. Fix mode writes a short `FIX_PLAN.md` covering repro, root cause hypothesis, blast radius, and rollback. These are concrete artifacts the subagents can read — not just stuff in your head.
24
25	3. Feature list as source of truth for "done". ~20-100 testable assertions in `feature_list.json`:
26	```json
27	[{"id": 1, "category": "functional", "description": "...", "steps": ["..."], "passes": false}]
28	```
29	You (orchestrator) own this file. Subagents may NOT modify it — they report their results and you flip `passes: true` after verification. For Recon mode the equivalent is `FINDINGS.md` checkboxes you tick as items ship.
30
31	4. Pre-stage shared files BEFORE running parallel agents. If two agents both need `router.js` or `App.jsx` or `main.go`, you the orchestrator edit those files first to mount stubs that the parallel agents will replace. Each parallel agent then owns only its own files. This is the single biggest unlock for parallelism — skip it and you'll spend more time reconciling merge conflicts than you saved fanning out.
32
33	5. Every subagent prompt MUST include all of these:
34	- Absolute working directory path
35	- Required reading (specific files, with one-line reasons)
36	- Explicit file ownership: a list of files the agent MAY touch + a list it MAY NOT touch. The may-nots are what prevents collisions.
37	- Contract from upstream waves (data shapes, env vars, API conventions, auth)
38	- Verification steps that MUST run before reporting (build, test, smoke check)
39	- Commit instructions with explicit file paths — never `git add -A`, which would grab parallel agents' work
40	- "Report back in under N words" (200-400 typical) — the report comes into your context, so keep it small
41	- Voice/style constraints if relevant (banned words, formatting rules, CLAUDE.md conventions)
42
43	6. Cap parallelism at 3-4 per wave. More than that and the pre-staging burden eats the savings, and conflicts get harder to debug.
44
45	7. Verify between waves. Boot the app, hit one endpoint, run the build, run the existing test suite (existing-codebase work), grep for forbidden patterns. Then flip the feature list. Commit `feature_list.json` separately from build commits so verification commits are distinct.
46
47	8. Commit between every wave. Explicit file paths only. Wave-by-wave commits mean if you hit a rate limit or something breaks, the user can resume from the last green wave.
48
49	9. Process hygiene. Long-running dev servers orphan during parallel agent verification. Before each new wave, kill stragglers. Pick the right command for the platform:
50	- Windows (PowerShell): `Get-Process -Name node -ErrorAction SilentlyContinue \| Stop-Process -Force`
51	- Unix: `pkill -f node` (substitute the actual process name for the sta

People who liked this also viewed

6 picks

Type