菜单
Dispatch a Worker Claude to delegate work. The Lead is the command tower; hands-on execution is, in principle, left to Workers. Fires when a user request involves actual hands-on work such as file edits, implementation, or investigation.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Triage open Issues and have the Lead present "next-work candidates (N items + 1 recommendation)" to the human. Run the deterministic tool tools/work_discovery_scan.py once and stop after rendering the candidate JSON in the human-readable format defined by design doc §5.2 (propose-only). The trigger is restricted to the Lead. Manual / event-driven only (no resident /loop). Fires when the Lead manually invokes for "show next-work candidates", "triage", "what's next?", or for proactive next-dispatch after a PR merge.
Start up the org. Load the previous state and brief, then launch the dispatcher pane. Run this once right after starting Claude Code. Also triggered by "start", "boot", "begin", etc. The curator is not launched (it has moved to on-demand launch by the dispatcher when the threshold check at worker close fires).
Suspend the org and fully stop it, down to and including the broker daemon. Use when told "stop it completely", "bring it down including the daemon", "org down it", "shut everything down". An integrated shutdown that runs suspend (state save + stopping ja-managed processes / panes) to completion and then calls `claude-org-runtime org down`. For a plain "suspend" / "done for today", use /org-suspend, which leaves the daemon running.
After the user approves a worker's completion report, the Lead handles push / PR creation / CI monitoring / review-feedback loop / final close after PR merge. Triggers: (1) immediately after a worker submits a completion report and the user gives explicit approval such as "OK" or "go ahead", (2) when review feedback / CI failure arrives on the GitHub PR and you need to send fix instructions back to the worker, (3) when the PR is merged and the final close conditions are met. The initial "delegate work to a worker" step is handled by org-delegate, not by this skill.
Suspend the org and persist all state to disk. Use when the user says "suspend", "save and exit", "I want to close", "let's stop for now", "done for today".
Run PR CI / merge monitoring (tools/pr-watch.sh) in a dedicated pane pr-watch-<PR> inside the broker tmux session. When the Lead starts it with `/pr-watch-pane <PR>` right after creating a PR, the monitoring runs in ja-root cwd, outside the sandbox, and continues independently of /clear or the Lead session's lifetime. Idempotent start via the pane name (no double monitoring), identity registration with role=watcher, and the pane auto-closes when monitoring ends (CI green / PR merged / timeout). The Bash tool's background mode is session-lifetime-bound and unsuitable for a long-running watcher, so this skill is the recommended path. Triggered by "watch CI in a pane", "run pr-watch in a pane", "watch PR <N>'s CI", etc.
| name | org-delegate |
| description | Dispatch a Worker Claude to delegate work. The Lead is the command tower; hands-on execution is, in principle, left to Workers. Fires when a user request involves actual hands-on work such as file edits, implementation, or investigation. |
| effort | medium |
| allowed-tools | ["Read","Edit","Write","Bash(python tools/gen_delegate_payload.py:*)","Bash(py -3 tools/gen_delegate_payload.py:*)","Bash(bash tools/journal_append.sh:*)","Bash(py -3 tools/journal_append.py:*)","Bash(python -m tools.state_db.importer:*)","Bash(git fetch:*)","Bash(git log:*)","Bash(gh issue create:*)","mcp__renga-peers__send_message","mcp__renga-peers__inspect_pane","mcp__renga-peers__list_peers","mcp__renga-peers__list_panes"] |
Delegate work to a Worker Claude. The Lead performs only task decomposition and dispatch-payload generation; pane spawning and instruction delivery are delegated to the Dispatcher. This minimizes the time the Lead is locked.
Scope of this SKILL: Only the "initial leg" of dispatch (task identification → dispatch-payload generation → handoff of DELEGATE to the Dispatcher → greeting after the Worker is started → ack and REVIEW transition when progress / completion reports come in). The following are separated into other skills / references:
- Worker spawning, instruction sending, and state recording procedures →
.dispatcher/references/spawn-flow.md(Dispatcher-exclusive)- Post-user-approval push / PR / CI watch / review-comment loop / post-merge close →
.claude/skills/org-pull-request/SKILL.md- Escalation of judgment requests / scope expansion / blockers from Workers →
.claude/skills/org-escalation/SKILL.md- Minimum 3 elements of an ack message and per-kind example texts →
.claude/skills/org-delegate/references/ack-template.md(single SoT)
state-db cutover (M4, Issue #267 / #284): All writes to structured sections must go through
StateWriter.transaction(). A post-commit hook auto-regenerates.state/org-state.md/.state/org-state.jsonfrom the DB, and callingupdate_run_status('<task_id>', 'completed')automatically moves.state/workers/worker-<task_id>.mdto.state/workers/archive/. Direct markdown edits are detected by drift_check. The SoT for events is the DBeventstable (tools/journal_append.sh/.pyalready route to the DB). When the DB is missing, build it withpython -m tools.state_db.importer --db .state/state.db --rebuild --no-strict.
Transport layer (transport) both systems — default
renga/ opt-inbroker: this skill'smcp__renga-peers__*calls are written for defaultrenga(ORG_TRANSPORTunset) and can be followed as-is (default behavior unchanged). UnderORG_TRANSPORT=broker(opt-in, revertible) the MCP server name becomesorg-broker, and tools' fully qualified names get machine-substituted frommcp__renga-peers__*→mcp__org-broker__*(argument shape and semantics are identical, so the procedure logic is unchanged). Only the transport-dependent points are noted in broker form:
- Receive model (push-primary =
claude/channel/ pull fallback): under renga, progress / completion / judgment requests from workers are pushed in-band as<channel source="renga-peers" …>. Broker has been redesigned to push-primary (runtime push-first 0.1.24+, transport-labdocs/design/broker-native-roles.md§9): the per-pane channel sidecar (server:org-broker-channel) claim→pushes the broker queue at ~1 s intervals and injects the body into the idle session vianotifications/claude/channel(giving the same "received → respond immediately" trigger as renga's in-band push). Pull is the fallback layer: when the sidecar is absent / unhealthy (delivery_mode=PULLon heartbeat timeout) / channel-incapable pane / claude.ai login is absent, each role activelycheck_messages(broker:mcp__org-broker__check_messages) at its own cadence (the per-role cadence in the §9.6 reading-substitution table. A nudge can be a trigger, but it does not wake an idle session, so an active poll is the canonical reception path. The existing "see the nudge →check_messages" prose is not retracted and is read as this fallback cadence). Step 5's "when a message arrives from the worker" happens via channel injection under push-primary, and on fallback it is received by the Lead's activecheck_messagesat the start of each turn (the acksend_messageetc. keeps the same shape). Contract: Surface 8 has push-primary ratified (2026-06-15, S3; supersedes the broker pull-only and pull is retained as fallback; existing ratified text unchanged; renga unchanged).- Spawn rite (folder-trust approval + dev-channel sidecar approval re-introduced): worker spawn is dispatcher-exclusive (
.dispatcher/references/spawn-flow.md), but under broker the--mcp-config <broker>injection (daemon, all tools + agent token) and Claude Code's folder-trust prompt machine-approval (send_keys(enter=true)) also include loading the channel sidecar with--dangerously-load-development-channels server:org-broker-channelfor push-primary, and the dev-channel approval prompt (spawn-flow 3-3b) is re-introduced and machine-approved withsend_keys(enter=true)(broker-native-roles.md §9.5). This is an addition, not a replacement, of the ratified §5/§8.5 folder-trust flow (* the "dev-channel prompt does not exist" wording indocs/design/renga-decoupling.md§4.6 / the dev-channel→--mcp-configsubstitution in contract §5.1 / §8.5 is, with push-primary adoption, additively reinstated for the channel sidecar's dev-channel load = ratified 2026-06-15 as S3 and amended into the contract). Thesend_keyspre-approval for root.claude/**self-edits (Step 5 below) also usesmcp__org-broker__send_keysunder broker in the same procedure.- Error branching (broker additional codes): on top of the renga codes, broker may return
[token_invalid]/[session_invalid]/[tool_not_authorized]/[no_backend](= adapter_unavailable) /[nudge_failed]/[peer_not_found]/[name_taken](unknown codes hit the default branch to escalate). See the broker section in.claude/skills/org-delegate/references/renga-error-codes.md.
new_tab/focus_paneare absent from the broker surface (intentional exclusion; this flow does not use them anyway). The canonical contract isdocs/contracts/backend-interface-contract.mdSurface 8 (broker auth & delivery, ratified 2026-06-14; the push-primary additive amendment S3 is ratified 2026-06-15, "Ratified amendment" section; existing ratified text unchanged); the design SoT is transport-labdocs/design/broker-native-roles.md§9 (push-primary redesign) /docs/design/ja-migration-plan.md§5.2(ii) / §8. Broker real-run (dogfood) is scoped to Epic #6 Issue G and is not this skill's default path.
| Step | Owner |
|---|---|
| Project name resolution | Lead |
| work-skill search | Lead |
| Task decomposition / dispatch-payload generation | Lead (gen_delegate_payload.py) |
| DELEGATE send | Lead (the Lead is released at this point) |
| Pane spawn / peer wait / instruction send / state recording | Dispatcher (.dispatcher/references/spawn-flow.md) |
| Dispatch-complete report back to the Lead | Dispatcher |
| Receiving progress / completion / escalation reports from Workers | Lead |
| Pane close on Worker completion | Dispatcher (on CLOSE_PANE request from the Lead) |
Before entering task decomposition, check the request from the following angles. If any apply, ask the user back.
| Check item | Situations to confirm | Example |
|---|---|---|
| Ambiguous terms / abbreviations | When a tool name, service name, or abbreviation could mean multiple things | "gog" → Google OAuth? gog CLI? |
| OS-specific preconditions | When producing OS-specific deliverables, default settings must be made explicit | Mac=zsh, Windows=py -3, path separator |
claude-org-runtime, etc.): confirm that the day's /org-start Block C2 runtime drift check was clean (exit 0). If it detected drift (exit 1) or was "PyPI unconfirmed" (exit 2 = could not reach PyPI, e.g. run inside the sandbox), the old venv may be hitting a bug already fixed upstream, so first upgrade the venv + bump the pin window to bring it up to date, and confirm the issue still reproduces before delegating (prevents a phantom dispatch against an already-fixed bug). The pin lag is a session constant, so one check at org-start suffices; a per-delegation re-check is not needed (background: 2026-07-08 #119).For incorporation / sync tasks that bring a source (review results / another branch / state of another repository) into a destination, when the source commit is more than N commits ahead of the destination's current state, consider selective merge (cherry-pick / apply only the necessary hunks) as the initial move. A byte-identical cp risks mechanically overwriting Codex iterative review fixes.
| Angle | Check | Action |
|---|---|---|
| Divergence between source and destination | Verify both directions with git log <source>..<destination> / git log <destination>..<source> | If both directions have diverged, prohibit cp and adopt selective merge |
| Additional fixes on the destination side | Whether Codex review fixes / Blocker fixes are stacked on the destination branch | If they are, do not mechanically overwrite with cp (cherry-pick or hunk-level apply) |
Background: There have been past incidents where cp mechanically reverted destination-side fixes (a destination-side credential-exposure Blocker fix nearly got reverted). Require the Worker brief to specify "no cp as the initial step / state the incorporation strategy explicitly".
Identify the project from the user's request:
registry/projects.mdregistry/projects.mdBefore task decomposition, search for any related existing work-skills. Matched work-skills are included as reference information in the Worker instructions.
.claude/skills/type / description / triggers) against the task content. The org- prefix denotes org-operation skills and is excluded from the searchWhen matches are found:
{skill-name} — including as reference information"gen_delegate_payload.py via the --knowledge flag. The Stage 2 brief renderer embeds that path into CLAUDE.md / CLAUDE.local.md as [references].knowledge. For multiple matches, repeat: --knowledge <path1> --knowledge <path2>Do not copy the work-skill's procedure verbatim. Present it as reference information and let the Worker decide.
Before gen_delegate_payload.py apply, update the target project's local main with git fetch origin + git pull --ff-only origin main only when one of the following 4 conditions applies:
release, release/, vX.Y.ZCHANGELOG.md promotion / __about__.__version__ / pyproject.toml version bumps, etc.release (e.g., runtime-0-1-10-release)For detailed conditions, the execution command, and the rationale behind the worker permissions deny (fetch miss → worker BLOCKER within 5 minutes → 10-minute-plus loss background), refer to references/release-pre-fetch.md as the primary source. The 4 conditions retained in this body must not be omitted, because missing the trigger leads directly to a worker BLOCKER.
Distinction from Pattern B (Issue #480): For Pattern B, apply itself runs
git fetch originand branches offorigin/HEADwhen creating the worktree, so the freshness of the worktree's starting point does not depend on this Step 0.6. What Step 0.6 guarantees is the freshness of local main for Pattern A (where the worker cutsrelease/*from local main); the two address different targets. For details, see the "Relation to Issue #480" section of.claude/skills/org-delegate/references/release-pre-fetch.md.
Step 0.7 (gitignore pre-check) / Step 1 (Pattern determination) / Step 1.5 (Worker directory preparation + role decision + settings generation) / Step 2 (DELEGATE body assembly) are all handled by tools/gen_delegate_payload.py. The Lead's responsibility is only task identification (Step 0), work-skill search (Step 0.5), target-file extraction, and depth judgment.
# 1. preview: completely non-destructive. Only confirms the DELEGATE body and the list of files to be created
python tools/gen_delegate_payload.py preview \
--task-id <task-id> --project-slug <slug> \
--target <path>... --description "<desc>" \
--verification-depth full
# 1.5. Step 1.7 gate: evaluate the Codex design review trigger conditions on the preview output
# Only when applicable, run a design review with codex exec and pass the summary
# to apply via --impl-guidance or --knowledge (see Step 1.7 below)
# 2. apply: reserve in state.db with runs.status='queued' + place CLAUDE.md/CLAUDE.local.md
# + run claude-org-runtime settings generate + emit send_plan.json
python tools/gen_delegate_payload.py apply \
--task-id <task-id> --project-slug <slug> \
--target <path>... --description "<desc>" \
--verification-depth full
# 3. Copy-paste the send_plan.json from the apply output into the MCP call
# cat <worker_dir>/send_plan.json
# → mcp__renga-peers__send_message(to_id="dispatcher", message=<message>)
apply performs only T1 reservation (runs.status='queued'). Activation into Active Work Items is the Dispatcher's T2 (docs/contracts/delegation-lifecycle-contract.md), so this skill does not touch it. On failure, leave the queue as is and escalate to the Secretary for judgment.
--mode edit|audit (default edit): For read-only audit tasks on claude-org, explicitly specify --mode audit--branch <name>: Override planned_branch. Default is feat/<task-id> (becomes fix/<task-id> if the description contains "fix" / "bug" / "修正")--commit-prefix "<prefix>": When omitted, inferred from the head of project_slug (e.g., claude-org-ja → feat(claude):)--closes-issue N / --refs-issues N1 N2: Embeds "Closes #N" / "Refs #N1 #N2" into the brief--impl-target <path> / --impl-guidance "<text>" / --knowledge <path>: optional [implementation] / [references] sections--skip-settings: Skip claude-org-runtime settings generate (for environments without the CLI)--from-toml <path>: Take an existing worker_brief.toml as input. CLI flags override the TOMLFor the determination logic (Pattern A vs B vs C / gitignored sub-mode / role table / planned_branch / required lines in the DELEGATE body), see .claude/skills/org-delegate/references/delegate-flow-details.md. For the special case of self-edit tasks (Issue #289, pattern_variant='live_repo_worktree'), see .claude/skills/org-delegate/references/claude-org-self-edit.md §3.
"Target files" are extracted by the Lead from the task description (paths explicitly stated in the request text, Issue body, or user utterances; no mechanical determination). For tasks whose target files cannot be identified (pure investigation, new-creation tasks with no fixed target path, etc.), --target need not be passed.
When the standard route (gen_delegate_payload.py apply) returns unexpected output (Pattern misjudgment / resolver error / brief inconsistency, etc.), the Secretary must not manually reproduce the same work. File an Issue as a resolver bug, and pause delegation of that task until the resolver is fixed. Manual fallback is out of scope for this skill. In environments without the CLI, limit yourself to the --skip-settings flag. A museum copy of the historic hand-typed route exists at docs/legacy/hand-typed-delegate-path.md, but it is prohibited from reference in standard operations.
For heavy-lane tasks at M-class or above / involving design judgment / spanning multiple files, you may permit the Worker to use ultracode (multi-agent workflow) (recommended). The Lead states the permission in the brief via gen_delegate_payload.py's --impl-guidance "<text>" (example: --impl-guidance "This task involves multiple files and design judgment, so ultracode use is permitted. Use ultracode for implementation and pre-Codex self-review convergence; the final Codex gate is maintained as before"). This text is rendered into the "Implementation guidance" section of the worker brief (default CLAUDE.md; for claude-org self-edit tasks, CLAUDE.local.md), and the Dispatcher reads it there to decide whether arming is needed (.dispatcher/references/spawn-flow.md 3-5a).
Do not let strong-permission pre-authorization wording be written into the workflow's agent prompts (important): even when ultracode is permitted, do not let wording that pre-authorizes strong permissions — dangerouslyDisableSandbox / --dangerously-skip-permissions and the like — be written into the body of the workflow's agent() prompts (nor put such pre-authorization wording into the Lead's --impl-guidance). The safety classifier will silently block the corresponding agent call, causing the accident where the workflow stalls with no discernible cause. If a stage truly requires strong permissions, the brief should prompt the worker to build into the workflow an explicit success/failure check for that agent (detecting the block via the return value / failure detection) and a recovery path for the blocked case (re-run that stage with normal permissions / run it manually in the worker session itself, etc.). The same constraint is placed with the same meaning in .dispatcher/references/spawn-flow.md 3-5a (with only one of the two, the dangerous pattern recurs from the kickoff path).
However, the brief text is a "permission declaration", not an "opt-in arming" (Issue #554). ultracode is armed only when an ultracode token appears in a user turn input of the worker session. Live runs have confirmed that even if the keyword appears in the brief file (the worker behavioral rules file — default CLAUDE.md, CLAUDE.local.md for self-edit tasks — loaded as context), in send_message bodies, or in the body delivered via check_messages, no arming occurs. The arming trigger is for the Dispatcher to issue the kickoff as a user turn via send_keys on the in-use transport, with a standalone ultracode token in that body (SoT: .dispatcher/references/spawn-flow.md 3-5a). In other words, the Lead's brief permission is a necessary condition; the Dispatcher's send_keys kickoff is the arming condition.
Adding a dedicated flag to gen_delegate_payload.py is out of scope (the division of labor — permission via the --impl-guidance brief text, arming via the Dispatcher's send_keys — is sufficient). Positioning: ultracode is the front stage used for implementation and pre-Codex self-review convergence, not a replacement for the final Codex gate (independent review by a separate model, Blocker / Major zero). Do not permit ultracode for light-lane tasks or small single-file tasks.
Per-stage model selection (recommended): for tasks where ultracode workflow is permitted, the brief may encourage using different models per workflow stage. Route mechanical fan-out stages (boilerplate replacement, identical transforms across many files, simple collection — parallel work with no judgment) to Sonnet 5 via agent(..., {model: 'sonnet'}) to optimize cost and speed, while judgment/verification/synthesis stages (review, design judgment, adversarial verify, synthesis) inherit the session model (default opus) to secure quality. Granularity is controlled via the Workflow tool's agent() opts.model (keep the per-stage note consistent with .dispatcher/references/spawn-flow.md 3-5a).
Decide whether to perform a Codex design review before apply. Run it only when one of the following applies:
docs/contracts/For the detailed trigger-determination table, the codex exec command, and the procedure for incorporating the review summary via --impl-guidance / --knowledge, refer to references/codex-design-review.md as the primary source.
A task that introduces a new CLI tool / new runtime / new workflow / new protocol, or that redesigns an existing tool with a breaking change, is a dogfood target. Paired with the implementation delegation, create a follow-up issue and earmark the subsequent real-use delegation as a dogfood pass.
For the dogfood-target determination, the Lead's responsibilities — (A) appending to registry/dogfood_pending.md at implementation filing and (B) the dogfood pass earmark procedure — the org-pull-request coordination, the register format, and the hygiene check (consumed → closed), refer to references/dogfood-protocol.md as the primary source.
State transitions: pending → open → consumed → closed.
For the detailed procedure (3-1 balanced split / 3-1c SPLIT_CAPACITY_EXCEEDED escalate / 3-2 spawn / 3-3 pane_started / 3-3b channel approve / 3-4 list_peers / 3-5 instruction send / 3-6 sequential spawn / Step 4 state recording / Worker Directory Registry), reference .dispatcher/references/spawn-flow.md as the primary source. The Lead does not touch it.
The Dispatcher returns DELEGATE_COMPLETE to the Lead upon dispatch completion.
tools/journal_append.sh / tools/journal_append.py / tools/set_run_pr_open.py / python -c "... StateWriter ..." and the like — any tool that opens state.db via a relative path — assume ja-root-relative. If you launch them from a worker / worktree cwd, they will fail silently or crash with no such table: runs / no such table: events, and the downstream post-commit hook and snapshot regeneration will not run either. Always cd <ja-root> before executing. Issue #398 is tracking a root fix.
Every message the Lead sends to an existing Worker follows the "1 worker = 1 task = 1 scope" principle. For the canonical 3 rules, refer to CLAUDE.md "Role Boundaries > Boundary for follow-up requests to a Worker" as the SoT:
.claude/skills/org-escalation/SKILL.md (/org-escalation).Violation case: 2026-05-21, mixing a separate concern into the voice-v2-independent pane (an out-of-scope task was sent on to the same Worker, collapsing into one Worker a separate concern that should have had its own Worker). The guard / CI implementation for this section is a separate Issue.
When you receive a dispatch-complete report from the Dispatcher, send a greeting message to each Worker:
mcp__renga-peers__send_message(
to_id="worker-{task_id}",
message="This is the Lead. You are assigned to {task_id}. Send all reports — completion, progress, and blockers — to `to_id=\"secretary\"` over renga-peers."
)
Canonical event flow (intermediate steps must not be skipped):
worker → Secretary peer message
1. ack to worker (required for all messages; deadlock prevention)
2. update Progress Log + DB (run.status / events / pending-decisions register)
3. report to user (only for completion / escalation / blocker; progress reports not needed)
4. wait for user approval before push/PR
5. CI watch / next instruction → [`.claude/skills/org-pull-request/SKILL.md`](../org-pull-request/SKILL.md)
.claude/skills/org-delegate/references/ack-template.md. ack ≠ user approval: git push / gh pr create / /pr-watch-pane are issued only after the user's explicit OK→ Trigger .claude/skills/org-escalation/SKILL.md. The Secretary does not pre-approve.
This subsection applies not only to the literal word "progress" but to all kinds of worker→secretary peer messages other than completion reports (2a) / judgment-escalation・blockers (0) / plan・prep handoff (intermediate handoff reports such as progress sharing, rebase-completion reports, confirmation requests). plan / prep handoff stays on the existing flow of being journaled under their dedicated kinds (plan_delivered / prep_delivered, docs/journal-events.md) and is not switched to worker_reported (the design-flow consumer side references the dedicated kinds).
.claude/skills/org-delegate/references/ack-template.md; before the Progress Log append). Do not escalate progress reports to the user or wait for approval.state/workers/worker-{task_id}.mdworker_reported to the DB events table (non-omittable, Issue #699):
bash tools/journal_append.sh worker_reported worker=worker-{task_id} task={task_id} summary="<summary>"
worker_reported row in docs/journal-events.md: worker, task, summary). Keep the kind unified as worker_reported (do not use aliases such as worker_progress). The dispatcher's PANE_OUTPUT_WITHOUT_PEER_MSG judgment (.dispatcher/references/worker-monitoring.md Step 5.2) references the worker_reported trace in the events table via SQL, so a missing journal entry for an intermediate handoff report creates a state of "the peer message arrived but there is no trace in events," which is a direct cause of a false positive that misdetects a healthy, running worker as a silent dead-lock (real example on 2026-07-08 kura conveyor)..claude/skills/org-delegate/references/ack-template.md)python -c "
from pathlib import Path
from tools.state_db import connect
from tools.state_db.writer import StateWriter
conn = connect('.state/state.db')
with StateWriter(conn, claude_org_root=Path('.')).transaction() as w:
w.update_run_status('<task_id>', 'review')
"
bash tools/journal_append.sh ...)WORKER_COMPLETION_NOTED to the dispatcher best-effort and non-blocking (非 blocking). The dispatcher picks it up on its normal /loop 3m check_messages, reflects it into completion_reported_at in worker-idle-state.json, and suppresses the PANE_OUTPUT_WITHOUT_PEER_MSG detector (the false positive that misjudges a completed worker's normal review-wait idle as a silent dead-lock, .dispatcher/references/worker-monitoring.md Step 5.2 — maintained in the upstream ja repository, not mirrored here; see CONTRIBUTING "Mirror scope"). This is a monitoring-suppression receipt notice, not a "completion determination" (the T4 completion transition is the secretary's responsibility; the dispatcher does not decide completion itself). Do not wait (待たない) for a dispatcher reply (a blocking wait is prohibited because it would create a new stop point in the T4 hand-off to human review). Include task_id and received_at (ISO-8601 UTC) in the body:
mcp__renga-peers__send_message(to_id="dispatcher", message="WORKER_COMPLETION_NOTED: worker-<task_id> (task_id=<task_id>, received_at=<ISO-8601 UTC>)")
WORKER_REOPENED on T6 re-instruction (.claude/skills/org-pull-request/SKILL.md 2c). Send it for both minimal and full completion reports (silent-dead-lock suppression does not depend on verification depth).dogfood_run_task_id column of registry/dogfood_pending.md, transition that row's status from open → consumed. Defects are assumed to already be aggregated in the paired follow-up issue (the dogfood_issue column) — the format is specified in the dogfood pass worker's brief. The full protocol's SoT is Step 1.8 of this SKILLbash tools/journal_append.sh notify_sent kind=awaiting_user task_id=<task_id> gate=worker_completed note="<short context such as PR/Issue>"
secretary_awaiting_user (default severity urgent) and beeps even when the user is not in front of the screen. See the CLAUDE.md section "Notify when the secretary is waiting for the user's judgment"→ Trigger .claude/skills/org-pull-request/SKILL.md.
After dispatch, periodically check that the Worker has not entered a deep-dive or excessive-verification loop. Intervention triggers (if any one or more applies, check the situation with mcp__renga-peers__inspect_pane):
Intervention procedure: Check the screen with inspect_pane → if judged to be deep-diving, interrupt with send_keys(target="worker-{task_id}", keys=["Escape"]) → send a tight correction instruction via send_message (e.g., "Switch verification depth to minimal. Codex review and additional tests prohibited. Return only the single line done: {commit SHA} {filename}").
The Lead substituting in a commit on its own at the Worker's worktree is blocked by the auto-mode classifier (scope deviation). Intervention should be done strictly by "re-sending instructions".