orchestrator

Name: orchestrator
Author: minghinmatthewlam

34stars4forks

How to install orchestrator?

minghinmatthewlam/agent-guards/orchestrator

$npx -y skills add minghinmatthewlam/agent-guards --skill orchestrator

Installs into the current project.

Summary

Coordinate complex work across workers while keeping product context and final judgment in the main session. Use when the user asks to orchestrate, delegate, parallelize, supervise workers, or coordinate multi-agent implementation, research, review, or verification from Codex App

Files · 1

View on GitHub

SKILL.md

1	# Orchestrator
2
3	Read `~/dev/agent-guards/AGENTS.md`.
4
5	The main session owns product context, task decomposition, supervision, integration, verification, and final reporting. Workers own bounded research, implementation, cleanup, or review. Do not turn the orchestrator into another implementation worker.
6
7	## Select The Host Path
8
9	Keep host mechanisms separate:
10
11	- Codex App: use native Codex App worker threads. Read [references/codex-app.md](references/codex-app.md) before spawning.
12	- Claude Code: use headless Pi workers. Read [references/claude-pi.md](references/claude-pi.md) before spawning.
13	- Cursor: use Cursor's native worker/subagent capabilities from the IDE or agent window, with Grok 4.5 High as the default worker model. Trust Cursor's built-in orchestration rather than adding CLI wrappers.
14
15	Do not mix host mechanisms unless the user explicitly wants cross-host work.
16
17	If edit isolation is needed, read [references/worktrees.md](references/worktrees.md) before creating or reusing a worktree.
18
19	## Shared Workflow
20
21	1. Define the goal and evidence required for acceptance.
22	2. Split separable outcomes into bounded worker tasks; keep dependent decisions in the main session.
23	3. Choose the host-native worker mechanism and the least-isolated safe checkout.
24	4. Give each worker the task contract below.
25	5. Arm supervision immediately after spawning.
26	6. Review the result and claimed evidence; follow up on the same worker when context should be preserved.
27	7. Independently verify in proportion to risk, integrate centrally, and report with `/concise-report`.
28
29	Continue until the requested outcome is accepted or a real blocker requires the user. Creating workers is not completion.
30
31	## Worker Task Contract
32
33	Tell the worker:
34
35	- the specific goal and why it matters;
36	- allowed edits and forbidden actions;
37	- success criteria and the highest-signal self-test surface;
38	- required proof artifacts and where they should live;
39	- the expected result: outcome, important evidence, changed files, blockers, decisions, and residual risk;
40	- to use `/use-loop` and wrap up before context exhaustion.
41
42	Trust workers to choose implementation details. Split work when outcomes can run independently or one worker would accumulate unrelated deliverables. Use one integrated `/explain-report` or `/explain-diff` owner only when its trigger policy applies; other workers return evidence.
43
44	## Supervision Contract
45
46	Every worker must have a supervision path established immediately after spawn:
47
48	- Codex App: heartbeat automation wakes the orchestrator and checks the worker with `read_thread`.
49	- Claude/Pi: `/loop` checks process state and `hb.json`, not the transcript.
50	- Cursor: use native agent-window status and completion signals. Add fallback monitoring only for detached shell work.
51
52	Keep checks cheap and adaptive. Report only meaningful changes, blockers, or final completion. Do not repeatedly ingest worker histories or streams. Stop and delete fallback supervision after every tracked result is accepted.
53
54	Treat a quiet active worker as working unless status, heartbeat age, process state, or a task-specific timeout shows otherwise. Steer only for new user context, an explicit blocker, incorrect scope, or concrete stall evidence.
55
56	## Acceptance
57
58	Worker output is evidence, not an automatic final answer.
59
60	- Check every success criterion and distinguish verified facts from inference.
61	- Inspect or rerun the highest-signal proof before using a result to drive consequential work.
62	- Require durable screenshots or recordings when visual state, focus, timing, or interaction matters.
63	- Re-derive methodology-critical claims from raw evidence with an independent probe; do not validate measurement, accounting, schema, comparability, or security claims only against worker-authored tests.
64	- Resolve overlap and conflicts centrally.
65	- Preserve contributor credit and verify no live process is using a checkout before merging into it.
66
67	Label results when the distinction matters:
68
69	- Orchestrator-accepted: independently checked enough to drive decisions.
70	- Worker-reported: plausible but not independently checked.
71	- Unverified: requires another proof surface.
72
73	## Reporting
74
75	Use `/concise-report` to keep the human oriented to meaningful outcomes, evidence, project learning, decisions, blockers, next actions, and residual risk. Keep raw detail in worker threads, proof artifacts, PRs, or ledgers.
76
77	## Gotchas
78
79	- Do not stop after spawning or silently leave completed workers unreviewed.
80	- Do not over-steer active workers.
81	- Do not let worker confidence replace real-surface proof.
82	- Do not reuse unknown,

People who liked this also viewed

6 picks

Type

orchestrator

34stars4forks

View on GitHub

How to install orchestrator?

minghinmatthewlam/agent-guards/orchestrator

$npx -y skills add minghinmatthewlam/agent-guards --skill orchestrator

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Orchestrator
2
3	Read `~/dev/agent-guards/AGENTS.md`.
4
5	The main session owns product context, task decomposition, supervision, integration, verification, and final reporting. Workers own bounded research, implementation, cleanup, or review. Do not turn the orchestrator into another implementation worker.
6
7	## Select The Host Path
8
9	Keep host mechanisms separate:
10
11	- Codex App: use native Codex App worker threads. Read [references/codex-app.md](references/codex-app.md) before spawning.
12	- Claude Code: use headless Pi workers. Read [references/claude-pi.md](references/claude-pi.md) before spawning.
13	- Cursor: use Cursor's native worker/subagent capabilities from the IDE or agent window, with Grok 4.5 High as the default worker model. Trust Cursor's built-in orchestration rather than adding CLI wrappers.
14
15	Do not mix host mechanisms unless the user explicitly wants cross-host work.
16
17	If edit isolation is needed, read [references/worktrees.md](references/worktrees.md) before creating or reusing a worktree.
18
19	## Shared Workflow
20
21	1. Define the goal and evidence required for acceptance.
22	2. Split separable outcomes into bounded worker tasks; keep dependent decisions in the main session.
23	3. Choose the host-native worker mechanism and the least-isolated safe checkout.
24	4. Give each worker the task contract below.
25	5. Arm supervision immediately after spawning.
26	6. Review the result and claimed evidence; follow up on the same worker when context should be preserved.
27	7. Independently verify in proportion to risk, integrate centrally, and report with `/concise-report`.
28
29	Continue until the requested outcome is accepted or a real blocker requires the user. Creating workers is not completion.
30
31	## Worker Task Contract
32
33	Tell the worker:
34
35	- the specific goal and why it matters;
36	- allowed edits and forbidden actions;
37	- success criteria and the highest-signal self-test surface;
38	- required proof artifacts and where they should live;
39	- the expected result: outcome, important evidence, changed files, blockers, decisions, and residual risk;
40	- to use `/use-loop` and wrap up before context exhaustion.
41
42	Trust workers to choose implementation details. Split work when outcomes can run independently or one worker would accumulate unrelated deliverables. Use one integrated `/explain-report` or `/explain-diff` owner only when its trigger policy applies; other workers return evidence.
43
44	## Supervision Contract
45
46	Every worker must have a supervision path established immediately after spawn:
47
48	- Codex App: heartbeat automation wakes the orchestrator and checks the worker with `read_thread`.
49	- Claude/Pi: `/loop` checks process state and `hb.json`, not the transcript.
50	- Cursor: use native agent-window status and completion signals. Add fallback monitoring only for detached shell work.
51
52	Keep checks cheap and adaptive. Report only meaningful changes, blockers, or final completion. Do not repeatedly ingest worker histories or streams. Stop and delete fallback supervision after every tracked result is accepted.
53
54	Treat a quiet active worker as working unless status, heartbeat age, process state, or a task-specific timeout shows otherwise. Steer only for new user context, an explicit blocker, incorrect scope, or concrete stall evidence.
55
56	## Acceptance
57
58	Worker output is evidence, not an automatic final answer.
59
60	- Check every success criterion and distinguish verified facts from inference.
61	- Inspect or rerun the highest-signal proof before using a result to drive consequential work.
62	- Require durable screenshots or recordings when visual state, focus, timing, or interaction matters.
63	- Re-derive methodology-critical claims from raw evidence with an independent probe; do not validate measurement, accounting, schema, comparability, or security claims only against worker-authored tests.
64	- Resolve overlap and conflicts centrally.
65	- Preserve contributor credit and verify no live process is using a checkout before merging into it.
66
67	Label results when the distinction matters:
68
69	- Orchestrator-accepted: independently checked enough to drive decisions.
70	- Worker-reported: plausible but not independently checked.
71	- Unverified: requires another proof surface.
72
73	## Reporting
74
75	Use `/concise-report` to keep the human oriented to meaningful outcomes, evidence, project learning, decisions, blockers, next actions, and residual risk. Keep raw detail in worker threads, proof artifacts, PRs, or ledgers.
76
77	## Gotchas
78
79	- Do not stop after spawning or silently leave completed workers unreviewed.
80	- Do not over-steer active workers.
81	- Do not let worker confidence replace real-surface proof.
82	- Do not reuse unknown,

People who liked this also viewed

6 picks

Type