| 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:
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:
- Read
registry/projects.md
- Identify the matching project from keywords in the request (match against alias / project name / description)
- If identified, use that path
- If not identifiable, present the list of registered project aliases and let the user choose
- 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.
- Enumerate all SKILL.md files under
.claude/skills/
- 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
- 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)
python tools/gen_delegate_payload.py preview \
--task-id <task-id> --project-slug <slug> \
--target <path>... --description "<desc>" \
--verification-depth full
python tools/gen_delegate_payload.py apply \
--task-id <task-id> --project-slug <slug> \
--target <path>... --description "<desc>" \
--verification-depth full
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:
- 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.
- Route Worker scope expansion proposals through escalation: the Lead does not pre-approve them and triggers
.claude/skills/org-escalation/SKILL.md (/org-escalation).
- 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).
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".
