org-delegate

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"]

org-delegate: Worker dispatch

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.json from the DB, and calling update_run_status('<task_id>', 'completed') automatically moves .state/workers/worker-<task_id>.md to .state/workers/archive/. Direct markdown edits are detected by drift_check. The SoT for events is the DB events table (tools/journal_append.sh / .py already route to the DB). When the DB is missing, build it with python -m tools.state_db.importer --db .state/state.db --rebuild --no-strict.

Transport layer (transport) both systems — default renga / opt-in broker: this skill's mcp__renga-peers__* calls are written for default renga (ORG_TRANSPORT unset) and can be followed as-is (default behavior unchanged). Under ORG_TRANSPORT=broker (opt-in, revertible) the MCP server name becomes org-broker, and tools' fully qualified names get machine-substituted from mcp__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-lab docs/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 via notifications/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=PULL on heartbeat timeout) / channel-incapable pane / claude.ai login is absent, each role actively check_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 active check_messages at the start of each turn (the ack send_message etc. 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-channel for push-primary, and the dev-channel approval prompt (spawn-flow 3-3b) is re-introduced and machine-approved with send_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 in docs/design/renga-decoupling.md §4.6 / the dev-channel→--mcp-config substitution 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). The send_keys pre-approval for root .claude/** self-edits (Step 5 below) also uses mcp__org-broker__send_keys under 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_pane are absent from the broker surface (intentional exclusion; this flow does not use them anyway). The canonical contract is docs/contracts/backend-interface-contract.md Surface 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-lab docs/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.

Lead / Dispatcher division of roles

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)

Pre-delegation checklist (executed by 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

• When there is an ambiguous term: ask the user "Do you mean XX by YY?" before proceeding
• For OS-specific tasks: include OS-specific preconditions in the Worker instructions when generating the payload
• Before delegating a suspected bug in a pin-managed internal package (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).

Initial-step checklist for incorporation / sync tasks

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".

Step 0: Project name resolution (executed by the Lead)

Identify the project from the user's request:

1. Read registry/projects.md
2. Identify the matching project from keywords in the request (match against alias / project name / description)
3. If identified, use that path
4. If not identifiable, present the list of registered project aliases and let the user choose
5. For a new project:
   • Confirm the path with the user
   • Estimate alias / description / typical work examples, confirm with the user, then append to registry/projects.md

Step 0.5: work-skill search (executed by the Lead)

Before task decomposition, search for any related existing work-skills. Matched work-skills are included as reference information in the Worker instructions.

1. Enumerate all SKILL.md files under .claude/skills/
2. Compare each SKILL.md's frontmatter (type / description / triggers) against the task content. The org- prefix denotes org-operation skills and is excluded from the search
3. Include any relevant candidates (exact match not required; for multiple matches, include all in relevance order)

When matches are found:

• Notify the human: "Found a related work-skill: {skill-name} — including as reference information"
• Pass the work-skill's SKILL.md path to 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>
• Also note the presence of the reference skill in the Worker instructions (instruction-template)

Do not copy the work-skill's procedure verbatim. Present it as reference information and let the Worker decide.

Step 0.6: Pre-fetch for release-class tasks (executed by the Lead)

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:

• The task description / commit-prefix / planned branch contains release-promotion words such as release, release/, vX.Y.Z
• The target files include CHANGELOG.md promotion / __about__.__version__ / pyproject.toml version bumps, etc.
• The task_id contains 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 origin and branches off origin/HEAD when 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 cuts release/* 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 / 1 / 1.5 / 2: Generate the dispatch payload in 1 command (Issue #283)

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.

Standard flow (recommended)

# 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.

Frequently used flags

• --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 TOML

Details on Pattern / role / branch determination

For 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-file extraction

"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 returns unexpected output

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.

Heavy-lane brief enhancement (ultracode)

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).

Step 1.7: Codex design review trigger (executed by the Lead, Issue #337)

Decide whether to perform a Codex design review before apply. Run it only when one of the following applies:

• Estimated effort ≥ 3h
• Introduction of a new module / new tool
• File changes ≥ 3
• Reference to contract documents under 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.

Step 1.8: dogfood follow-up issue protocol (Lead + org-pull-request coordination, Issue #338)

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.

Step 3 / 4: Worker spawn / instruction send / state recording (executed by the Dispatcher)

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.

Step 5: Progress management (executed by the Lead)

⚠️ cwd caution: state.db touching tools

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.

Lead → Worker messaging rules (Issue #475: 1 worker = 1 task = 1 scope)

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:

1. Keep follow-up requests within the original task's scope: only send on supplementary or corrective instructions within the range laid out in the brief. Do not feed an out-of-scope, separate concern into the same Worker; re-run this SKILL from Step 0 and dispatch a different Worker via the Dispatcher.
2. Route Worker scope expansion proposals through escalation: the Lead does not pre-approve them and triggers .claude/skills/org-escalation/SKILL.md (/org-escalation).
3. The Lead does not do the Worker's work: do not reach into a Lead-side worktree for file edits, commits, tests, etc.; return the work to the Worker as a follow-up request, or dispatch a different Worker.

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.

On DELEGATE_COMPLETE receipt

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."
)

On message receipt from a Worker

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)

• For the minimum ack contents and per-kind example texts, see .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
• The 2 → 3 ordering follows the principle "reconcile internal state first, then report to the user"

0. Judgment request / scope expansion / blocker (identify with top priority)

→ Trigger .claude/skills/org-escalation/SKILL.md. The Secretary does not pre-approve.

1. Progress report (all intermediate handoff reports other than completion — progress, rebase reports, requests, etc.)

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).

• Return ack to the worker (see the "progress report ack" section of .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
• Append to the Progress Log of .state/workers/worker-{task_id}.md
• Always append worker_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>"
  

  Match the payload keys to the event catalog (the 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).

2a. Completion report

• Return ack to the worker (see the "completion report ack" section of .claude/skills/org-delegate/references/ack-template.md)
• Transition the run to REVIEW via the DB (direct markdown edits prohibited):

  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')
  "
  

• Append an event to the DB events table (bash tools/journal_append.sh ...)
• Notify the dispatcher of the completion receipt (monitoring suppression, Issue #658): After finishing the worker ack and the state updates above (REVIEW transition, events append), send 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>)")
  

  The paired release is 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).
• Register update on dogfood pass completion (Issue #338): If the completed task was earmarked in the 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 SKILL
• Emit awaiting_user notification (Issue #28): Just before reporting to the human → entering an approval-wait stop, inform the attention watcher that "the Secretary is stopping while awaiting the user's judgment":

  bash tools/journal_append.sh notify_sent kind=awaiting_user task_id=<task_id> gate=worker_completed note="<short context such as PR/Issue>"
  

  The classifier of the parallel runtime PR picks this single line up as 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"
• Report the result to the human and stop awaiting approval without closing the pane. Issuing push/PR without approval is a protocol violation toward both the worker and the user

2b / 2c. After user approval / review comments / post-merge close

→ Trigger .claude/skills/org-pull-request/SKILL.md.

Worker monitoring and intervention judgment (executed by the Lead)

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):

• More than 30 minutes elapsed on the same task, and entering the same phase (implementation / review / verification) for the 3rd time or later
• Silent for more than 1 hour with no progress report (not waiting for input either, and no progress log being emitted)
• (When using codex) Codex self-review is on its 4th or later round

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".