orchestrate-task-interactive
Skill1 starsChanged 7 days agoMITView on GitHub
Drive one task through the engine on the interactive×claude lane. Thin supervisor — all deterministic logic lives in the `orchestrator` CLI; this skill only sequences calls.
In this repository17 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- batch-planSkill
- brainstormSkill
- new-projectSkill
- orchestrate-batch-headlessSkill
- orchestrate-batch-interactiveSkill
- orchestrate-task-interactiveSkill
- spec-intakeSkill
- triage-followupsSkill
- batch-planSkill
- brainstormSkill
- new-projectSkill
- orchestrate-batch-headlessSkill
- orchestrate-batch-interactiveSkill
- spec-intakeSkill
- triage-followupsSkill
The file
We split this skill into the rules it gives an agent
5 rules. About 0 are common, 1 is distinctive, and 4 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈1
Distinctive · estimate
This author's own choices. Worth a look.
4
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 30
Before every model dispatch, require the Claude Code status-line sensor.
- Very specific: line 38
If WORK is null, the task is done — stop.
- Very specific: line 71
persist + record: write each returned StageResult to a temp file and run … record --result <file>.
- Distinctive: line 89
When the task completes, the engine publishes the run's evidence through the project adapter — no supervisor action needed:
- Very specific: line 115
Run … status and check lane_audit.clean == true: every recorded model call must be interactive:claude with zero unattributed/off_lane.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Supervisor — interactive×claude lane
You are the supervisor. The deterministic logic (stage order, retry, cost,
status, capacity) lives in the orchestrator engine CLI. Your only job is the loop:
ask what's ready → dispatch via the Workflow shim → record the result → repeat.
You never call a model directly and you never run claude -p.
Constants
RUN= the run id.TASK= the task id (a GitHub issue, e.g.#505).PROJECT=<your-project-adapter>(e.g.adapters.project.selfhost, the reference; or your own).- Engine call shape:
uv run orchestrator --run "$RUN" --project "$PROJECT" <cmd> ... - No
ROOTis needed (#523): the run's logs live at~/Development/runs/<project name>/<YYYY-MM-DD>/<run>/(ORCHESTRATOR_RUNS_ROOTmoves the top level), the project name is the adapter'sname, and every command finds the run by--runalone. Each engine command printsnote: … run store at <dir>on stderr — that is the run dir (RUN_DIR/<run dir>) the paths below refer to.--root <dir>(with--shared-rootfor a fresh legacyruns/) is only for pre-#523 runs or scripts that pin a location.
One-time setup
… init-run --lane full(orlite/micro).… add-task --task "$TASK"(resolves the issue via the GitHub task source).
The loop (repeat until the task is terminal)
Before every model dispatch, require the Claude Code status-line sensor. Configure
orchestrator statusline as this session's statusLine command; it retains the existing
5h/7d display and caches Claude Code's context_window payload for the guard. Confirm it
with orchestrator supervisor-context (unavailable/stale fails closed).
- next:
WORK=$(… next --task "$TASK" --util auto --guard-supervisor-context --supervisor-resume-command "start a fresh Claude Code session and invoke /orchestrate-task-interactive for $RUN $TASK").- If
WORKisnull, the task is done — stop. - First check
… status: ifrun_stateisparked, reportsupervisor_parked.reasonand itsresume_command, then stop. The engine evaluated the exact rendered prompt before emitting it or taking a lease, so there is nothing to replay. A fresh session runs… resume-supervisoronce, then restarts this loop. - Deterministic stages are already done for you.
nextruns any leading deterministic stage (e.g.intake— worktree/branch/baseline) in-process on theengine:nonelane and returns the first model WorkItem. You never create a worktree by hand or dispatch intake to a model. --util autoprobes the account's REAL 5h utilization (seeorchestrator util; a probe miss falls back to 0.0 and says so) and the engine turns it into the binding dispatch limit. Do not exceed the engine's limit even though the Workflow cap could allow more — the engine's number is the policy, the Workflow cap is a ceiling.
- If
- dispatch: invoke the Workflow shim (
run_targets/workflow_shim.js) with{ workItems: [WORK], dispatchLimit: <engine limit>, now: <ISO timestamp>, schemas: {...} }. The shim CANNOT enforcetimeout_s(no clock in the Workflow sandbox) — YOU own it: if a dispatch visibly exceeds the WorkItem'stimeout_s, stop waiting, hand-craft that item'sStageResultwithstatus: "timeout"and a one-lineerror, and record it — the engine classifies TIMEOUT and retries from the checkpoint. Never leave a hung dispatch un-recorded. The shim callsagent()in-session and returns an array ofStageResultobjects (it cannot write to disk). It does the actual work in the task's worktree.- Pass the WorkItem through VERBATIM (#311): copy the whole JSON object
nextprinted — never retype or abbreviate a field.content_hashis a 64-char digest whose only job is tying the returned result back to this dispatch, so a truncated log preview (the livebatch-next5bfailure) or a hash copied from another in-flight item breaks that tie.recordrefuses such a result and the shim aborts the batch before spending anything when the shape is wrong. - Honor the WorkItem's
effort(#96/#140): each WorkItem carries a per-stage reasoningeffort(low/medium/high, or absent). The shim forwards it asagent({ effort: wi.effort })so the dispatched sub-agent runs at that reasoning level — pass the WorkItem through unmodified and never strip or overrideeffort(an absenteffortis itself valid — it means "use the provider default," which the shim expresses aswi.effort || undefined; do not substitute a value of your own). It rides back on theStageResult(echoed for the ledger/audit row), so dropping it both mis-sets the sub-agent's effort and corrupts the cost attribution.
- Pass the WorkItem through VERBATIM (#311): copy the whole JSON object
persist + record: write each returned
StageResultto a temp file and run… record --result <file>. Read the JSON outcome:task_completed→ the PR is open; stop (success).task_failed_*→ stop (failure); surface the reason.stage_completed/stage_failed_will_retry→ loop again (the engine re-emits the same stage with appended learnings on a retry).- non-zero exit with
{"ok": false, "recorded": false, …}→ the result did not answer the outstanding dispatch (garbled/cross-pastedcontent_hash, wrong work item, or a replay); the engine logged aresult_rejectedevent and stored nothing. Do NOT edit the result'scontent_hashto make it pass — that defeats the check. Re-dispatch the stage with… next --resumeand record what actually comes back.
Preserve the agent's narrative: pass its full prose back as the
StageResult'sraw_output(the shim does this fromagentResult.raw), not just the structured fields — the per-stage log keeps it as the durable "why", and the review stage's narrative is the human-readable audit of the approve/deny decision.
Evidence-out (automatic at task_completed)
When the task completes, the engine publishes the run's evidence through the project adapter — no supervisor action needed:
- files each non-blocking review finding (
review.non_blocking[*]) as a follow-up issue, unlabeled for triage (a reviewer's nits are never dropped); - self-improvement loop: files the review's
improvementidea as anenhancementissue and renders both it and theretrospective(process lesson) into the note — so a completed run also grows the roadmap, not just ships a fix; - posts a completion note (stage table + PR + verdict + follow-ups + self-improvement) to the PR/issue.
These run through optional file_followup / publish_note task-source hooks; an adapter
that omits them is a silent no-op — satisfying the "nothing silently dropped" norm.
Resumability
Because the shim only returns results on Workflow completion, a session death
mid-dispatch loses only the in-flight batch. The crash leaves the dispatch lease
held, so a plain … next refuses (it guards the in-flight result) — recover with
… next --resume, which re-emits the un-recorded stage at the same attempt. Keep
batches small. Use --resume ONLY to recover a genuine crash, never as a routine
re-preview — always capture next into WORK in the single call above so you never
call next then next --resume for the same live stage. A resume that supersedes a
still-outstanding lease is self-describing in the timeline (#142): the re-dispatch's
stage_dispatched carries resume: true / supersedes: <old work_item_id> and the
retired lease gets its own lease_superseded event, so no orphan dispatch is left.
Audit (every gate)
Run … status and check lane_audit.clean == true: every recorded model call must
be interactive:claude with zero unattributed/off_lane. A hidden claude -p
would show up here — there should be none.
Post-run follow-up triage (opt-in: --triage-followups)
A completed task's evidence-out seam files its review's non_blocking findings and
improvement idea as GitHub issues automatically, with no human gate. If the invocation
args include --triage-followups (or the human asks to triage), then after the task
is terminal and the audit is clean, invoke the triage-followups skill on this RUN:
it walks the issues this run filed one at a time — explaining each from its source review
finding and the code it points at — and takes the human's keep / close / promote / edit
call. Read-only on the run, re-runnable, so triage can also be done later instead of
inline. Without the flag, the run finalizes and its auto-filed issues stay untriaged.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

