一键导入
orchestrate-work
Delegate one scoped implementation to an isolated executor while the parent retains authority and review control.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Delegate one scoped implementation to an isolated executor while the parent retains authority and review control.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Repo-grounded ideation, research, and technical solution design before planning or implementation.
Research and define codebase issues before implementation planning. Use when the human explicitly invokes `$diagnose-issue`, or when an active documented workflow such as `planning-workflow`, `shape-requirements`, or `architect` routes a current-code question here. Do not select it directly from a generic bug, ticket, symptom, or design concern; enter through `planning-workflow` instead. Do not use when the user asks for a step-by-step implementation plan, direct implementation, or code review of an existing diff.
Coordinate planning from intent to implementation. Route through shape-requirements, diagnose-issue, review-spec, create-plan, plan-review, and handoff-work. Use when starting feature work, fixing a non-trivial issue, or running the full plan-build cycle.
Shape requirements before planning or implementing. Gate underspecified build, fix, or plan tasks. Interview when the user says "interview me about", "ask me questions about", "help me think through", "I need to spec out", "let's flesh out", or has a vague idea to turn into a brief.
Operate one manually stepped Harness Factory work item from intake through triage, planning, implementation, continuation, publication, and merge acknowledgement. Use when asked to run, resume, inspect, or recover Factory; interpret its next reaction or durable evidence; or apply guarded Linear projections.
Brief a code change, diff, branch, commit range, or pull request so the user can decide whether to approve, merge, revise, or build on it. Use when the user asks for a walkthrough of what changed or how it works, wants behavior or day-to-day impact, asks about API, contract, or boundary changes, questions diff size or complexity, or wants accepted tradeoffs.
| name | orchestrate-work |
| description | Delegate one scoped implementation to an isolated executor while the parent retains authority and review control. |
| disable-model-invocation | true |
Delegate one bounded implementation to one isolated Codex executor. The executor is the single writer. This parent stays read-only and owns authority, decision steering, review dispositions, and acceptance.
Success means the executor starts from the verified repository and exact baseline, both callback directions work before mutation, decision-changing work reaches the parent before action, and the user receives either an accepted result or an exact recoverable state.
model and thinking. Omit both by default; apply
only explicit, schema-valid overrides to the named destination. Never copy
settings from the sender.none; never
infer package-manager setup.Fill the executor contract below. Use handoff-work for concise context and
point to durable sources instead of copying them.
Use codex_app__list_projects; select the project matching the repository.
Stop when project identity is missing or ambiguous.
Inspect the live codex_app__create_thread schema, then create one isolated
worktree with the minimal project target:
{
prompt: "[completed delegation and handoff]",
target: {
type: "project",
projectId: "[discovered project ID]",
environment: { type: "worktree" }
}
}
Add only explicit, schema-valid destination overrides. Use a starting state only when the accepted task selects one.
Create once. A validation rejection created no task: correct the request from
the live schema and resubmit it. After an ambiguous result, use
codex_app__list_threads and codex_app__read_thread to match the project,
prompt, and creation window; retry only when discovery proves none exists.
Record the executor task ID. Resolve a queued clientThreadId through list or
read before steering. Set a useful title with codex_app__set_thread_title,
then verify the intended project and fresh worktree.
Require a before-edit checkpoint with actual worktree, branch or detached-HEAD
state, exact git rev-parse HEAD, cleanliness, the exact readiness command,
intended file surface, existing seams, and material conflicts. Pause on
baseline mismatch.
Verify both callback directions before mutation:
<source_thread_id>;{ threadId, hostId } route returned by
codex_app__list_threads or codex_app__read_thread.A callback's source identifies the executor, not the parent. Omit hostId for
a verified local task when the live schema permits it; otherwise use the
discovered routing hostId. source_host_id and title-update output are not
steering routes.
Require the executor to inspect codex_app__send_message_to_thread before its
first checkpoint; do the same before the first parent reply. Prove delivery
with a successful send plus read-back or acknowledgement.
Parent acknowledgement authorizes the reported readiness command as bounded setup. The executor runs it before source edits or provider work. Failure pauses with exact evidence; success needs no second approval.
Bootstrap is complete only when repository identity, exact baseline, isolation,
both callback directions, and readiness are verified. Otherwise report
blocked.
The executor reports before edits, at coherent implementation, at requested
review, and at final handoff. It may consult the parent whenever a decision or
blocker appears. Each checkpoint includes evidence, boundary impact, one
recommendation, and proceeding or paused.
Pause for scope or authority changes, product or architecture choices, destructive or unauthorized external actions, review dispositions, unsafe overlap, unexpected routing, or operational blockers. Only decisions requiring new authority return to the user.
At each checkpoint, independently inspect material claims and send one bounded direction: proceed, correct, pause, or stop, plus the proof expected next. Keep routine in-scope implementation with the executor. Update at decisions, exceptions, and milestones; do not poll unchanged state.
When review is requested, the executor follows change-review-workflow, reports
every role and underlying issue, proposes issue-local dispositions, and pauses
before fixes. The parent approves or adjusts dispositions. Record current-head
review as approved, unresolved, or not requested.
A checkpoint is complete when material evidence is verified, one direction is delivered and acknowledged, and the next proof is explicit.
At normal completion, require a handoff-work handoff with exact branch and tip,
cleanliness, diff, verification, current-head review, publication, caveats, and
open decisions. Verify the evidence and current accepted publication authority,
then ensure the executor stops.
For cancellation or supersession, interrupt when supported. Otherwise direct the executor to finish its current safe atomic operation, stop mutation and publication, and report exact recoverable Git/worktree state. Verify it stopped before replacement work.
Return status, branch/tip or pull request, verification, review result, caveats, and open decisions. Completion requires an accepted result or exact unresolved state reported to the user, with the executor stopped.
Implement [bounded goal] in this isolated worktree.
Authority: [request/plan/spec]
Repository: [repository and isolated-worktree requirement]
Baseline: [verified exact commit; branch only when selected]
Readiness: [target-repo command or none]
Settings: preserve destination settings; use only explicit schema-valid
overrides for the named destination.
Single writer: own changes only in this worktree; treat other worktrees as
read-only.
Boundaries: [material constraints and non-goals]
Verification: [exact commands/gates and evidence required]
Done: [checkable behavior, clean state, and current-head review requirement]
Publication: [none, commit, push, pull request, or merge authority]
Callback: read the parent ID from the outer
<codex_delegation>/<source_thread_id>. Inspect the live
codex_app__send_message_to_thread schema, preserve the parent's settings unless
an explicit override names it, and prove the first delivery. Stop if the parent
ID is absent.
Checkpoints:
- Before edits: prove worktree, Git state, exact HEAD, cleanliness, readiness,
scope, seams, and conflicts.
- Coherent implementation: report diff, behavior, verification, adaptations,
risks, and remaining gates.
- Review when requested: follow change-review-workflow, propose dispositions,
and pause before fixes.
- Final: send a handoff-work handoff with exact recoverable state, then stop.
Consult the parent on demand for decisions or blockers. Pause for new authority.