with one click
orchestrator-control
// Control-plane workflow for resolving targets, provisioning repos, and launching focused workers with the right role, mode, and model.
// Control-plane workflow for resolving targets, provisioning repos, and launching focused workers with the right role, mode, and model.
[HINT] Download the complete skill directory including SKILL.md and all related files
| name | orchestrator-control |
| description | Control-plane workflow for resolving targets, provisioning repos, and launching focused workers with the right role, mode, and model. |
Use this skill when acting as the orchestrator agent.
The orchestrator is the primary operator-facing control plane.
It should:
Hard rule:
Operator requests may identify the target as:
nostr://<owner-npub>/<repo-d-tag>30617:<owner-pubkey>:<repo-d-tag> repo keynpub/<repo-d-tag> shorthandResolve the target to a kind 30617 Nostr repository announcement before choosing a worker.
Local paths, URLs, aliases, and folder names are only hints.
For nostr:// targets, resolve by checking URI relay hints, the owner's kind 10002 outbox relays, then configured fallback announcement relays; clone from the ordered clone URLs in the announcement.
Hard rule:
orchestrator-01, create or reuse the orchestrator-owned fork before worker handoffUse:
researcher for read-only investigation, planning briefs, upstream/reference research, architecture comparison, and unclear fix directionbuilder for implementation and bug fixingtriager for issue intake, reproduction, and classificationqa for browser-first validation and real-flow testingPrefer one-off workers by default.
Researcher includes planning. Do not create a separate planner role; use researcher tasks for both investigation and planning.
Use long-running workers only when continuous watch/monitor behavior is actually needed.
The orchestrator should prefer the local CLI control surface rather than inventing ad hoc worker management.
Useful commands:
openteam launch builder --target 30617:<owner-pubkey>:<repo-d-tag> --mode web --task "..." --detach
openteam launch builder --target 30617:<owner-pubkey>:<repo-d-tag> --mode web --parallel --task "..." --detach
openteam launch researcher --target 30617:<owner-pubkey>:<repo-d-tag> --mode code --task "Research the safest implementation plan for ..." --detach
openteam enqueue builder --target <repo-hint-or-alias> --mode code --task "..."
openteam worker start triager --target <repo-hint-or-alias> --mode code --name triager-repo-a
openteam worker stop triager-repo-a
openteam worker list
openteam runs list --limit 10
openteam runs show <run-id>
openteam runs diagnose <run-id>
openteam runs evidence <run-id>
openteam runs repair-evidence <run-id>
openteam runs continue <run-id> --task "finish the remaining work and verify it"
openteam runs cleanup-stale --dry-run
openteam runs stop <run-id>
openteam browser attach <agent-or-role>
Preferred operator-facing request verbs:
statusstop <worker-name>start <role> on <target>watch <target> as <role>research <target> and <question>plan <target> and <goal>work on <target> [as <role>] [in <mode> mode] [with model <model>] [in parallel] and do <task>Prefer these verbs over vague control-plane phrasing when possible.
Guidance:
launch for one-off focused worklaunch defaults to detached execution; from OpenCode or other managed/non-interactive sessions, use --detach and never --attach because the caller's tool timeout can kill the runworker start only when a long-running watcher or pinned repo worker is actually neededworker list before starting another persistent worker for the same role/targetin parallel only when the operator intentionally wants a separate context for concurrent work on the same Nostr reporuns list / runs show for completed task metrics, phase timings, log paths, and live-signal effective stateverificationPlan and verificationRunners as local verification capability metadata; use verification.results and logs as runner execution evidenceevidenceType, flow, url, screenshots, consoleSummary, networkSummary, and eventIds when browser/Nostr/GUI verification was performedruns evidence <run-id> to classify completion as evidence-backed, weak-evidence, blocked, failed, or needing human reviewruns repair-evidence <run-id> when the worker likely completed the edit but evidence is missing, weak, or blockedruns continue <run-id> --task "..." for broader follow-up on the same idle repo contextopencode --dir ... command from OpenCode, an openteam worker, or automationruns observe <run-id> for a single-run live snapshot and runs watch --active for transition pollingruntime/orchestrator/observations.json as the persisted last-seen observation state for run transitionsneeds-review as completed worker execution with insufficient evidence, not as a normal successworkerState from verificationState; a worker can finish successfully while final web-runtime verification failsopenteam runs list, openteam runs show <run-id>, or openteam status before telling the operator they are running or completestate: "stale" as authoritative even when storedState: "running" appears; storedState is only the raw run-file flagstate: "failed" with storedState: "succeeded" as authoritative when diagnosis reports an OpenCode hard failureverificationState: "failed" and failureCategory: "dev-server-unhealthy" as a runtime verification failure, even if workerState is succeededfailureCategory: "verification-failed" or "verification-blocked" as failed worker-produced verification evidence, not as worker implementation successPR eligible: yes from runs evidence; draft/WIP publication must be explicitverify-dev-server phase is followed by a succeeded restart-dev-server and verify-dev-server-after-restart, report it as recovered rather than silently ignoring the transient failureruns diagnose for detailed evidence when a run is stale, logs are idle, process evidence is missing, or the dev URL is unreachableruns cleanup-stale --dry-run to confirm stale records before cleanup; cleanup marks stale records terminal and releases repo leases without deleting checkoutsbrowser attach for live web-task observation details instead of guessing profile or artifact pathsbrowser attach, browser status, or runs diagnose reports the dev URL reachable.envrc use flake, flake.nix, shell.nix, or default.nix, openteam should run provisioning and worker processes through that declared environmentProvisioning sessions must prepare the managed repo context and then stop.
Hard rules:
openteam launch, openteam enqueue, openteam serve, or openteam worker ... from a provisioning sessionEvery worker launch should decide:
web or codeGuidance:
web when browser/dev-server verification is genuinely neededcode for repository tasks that do not need a browserThe orchestrator runs as a normal user.
It may:
Do not assume unrestricted root access.
When system-level packages are missing, explain the requirement clearly and prefer explicit install commands over hidden mutation.
dmRelays are orchestrator control-plane relays, not worker instruction relays.openteam/repo-context.jsonopenteam repo publish ... for repo-side writes instead of raw relay selectiongh auth for Nostr-git PR publication; the default path is git push origin <branch> plus openteam repo publish pr ...