delegate-verbose-work

Imported from arinyaho/concord (plugins/concord/skills/delegate-verbose-work/SKILL.md). Install upstream with npx skills add arinyaho/concord --skill delegate-verbose-work. Copyright stays with the author.

Delegate verbose work

A broad search sweep or a repeated file re-read belongs on a subagent's thread, not the main one. The main thread keeps orchestration, decisions, and concise summaries; a subagent absorbs the many tool calls and reports back only the conclusion.

When to delegate

• A question needs many grep/search calls to answer (roughly 10 or more) — "every caller of X", "where is Y configured across the repo", broad terminology or convention sweeps.
• A file has already been Read this session — check what you already have before issuing another Read; if the prior content is stale or incomplete, delegate the re-check rather than re-Reading from the main thread.

When not to

• One or two targeted greps to confirm a specific claim.
• A file being read for the first time this session.
• The result must inform the very next tool call you make (delegating adds a round trip you can't afford there).

How

Give the subagent the exact question and enough context to answer it standalone, and ask for a conclusion, not a transcript — "report file paths and line numbers, not the full grep output." Discard the sweep once you have the conclusion; do not pull it back into the main thread's context.

If this trigger fires while running under a more specific skill that sets its own delegation default (for example ticket-to-pr's "keep implementation and review with the active agent; do not hand either stage to another AI"), that skill's contract wins.

Resuming after worktree loss

A worktree-isolated investigative subagent (an Agent tool call with isolation: "worktree") loses its worktree whenever the harness cleans it up between dispatch and resumption — this is guaranteed, not occasional, for a read-only investigative subagent: it makes no changes by construction, and the harness cleans up an unchanged worktree by default. A relaunch or resume that follows a long idle period carries the same risk. Do not let the resumed subagent start blind and redo the sweep from scratch:

• If an earlier notification from that subagent already reported a conclusion, pass that conclusion forward in the resume prompt instead of a bare re-dispatch, and instruct the subagent to use it unless it finds the conclusion stale or contradicted.
• If no conclusion was received yet, ask the resumed subagent to report what it already found — including any note it can recover from its own prior output — before it redoes the sweep, and have it redo only the portion that report cannot answer.

Losing worktree state is the harness's; redoing the investigation without checking for what survived is the orchestrator's. The orchestrator, not the resumed subagent, is the one holding the last notification, so the orchestrator is the one obligated to hand it forward.