# Delegate Work > Coordinate bounded delegation for non-trivial work when independent investigation, separated implementation and review, or separable workstreams materially improve latency, context, or confidence. Decline trivial, tightly coupled, or serial work. - Skill: `flurdy/delegate-work` (Agent Skill, multi-file: 5 files) - Install (CLI): `npx skillmds@latest add flurdy/delegate-work` - Raw SKILL.md: https://api.skillmd.com/api/skills/flurdy/delegate-work/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: flurdy (https://skillmd.com/u/flurdy) - Updated: 2026-09-10 - Page: https://skillmd.com/skills/flurdy/delegate-work --- # Delegate Work Coordinate bounded delegated work while keeping outcome, scope, judgment, integration, and final validation in the parent agent. Delegation is an execution mechanism, not a transfer of authority. This skill is a conservative delegation workflow, not a persistent or fully adaptive scheduler — by decision, not as an interim step. See [`README.md`](README.md) for current maturity and the scope decision behind it. ## Tier guard This skill is `model-tier: premium`. Before starting, check the current model. If it is below the runtime's premium tier, say so and use the runtime's native user-question mechanism (`AskUserQuestion` in Claude Code) to offer: - **Continue here** — accept reduced coordination depth for this run. - **Stop** — switch to a premium model and invoke the skill again. If the runtime cannot expose the effective model, say so and ask whether to continue with an unverified tier; never claim that the premium guard passed. Skip the prompt when the user explicitly selected the current model. On a verified premium model, stay silent. This guard checks capability; parent-route cost confirmation remains the runtime/router's responsibility. Use `high` for routine coordination and raise effort only when architecture, risk, or final judgment warrants it. ## 1. Decide whether delegation pays Select this skill dynamically when a non-trivial task has clear enough outcomes and acceptance evidence, and independent investigation, separated implementation and review, or genuinely separable workstreams could materially improve latency, context, or confidence. Explicit invocation remains supported. Selection authorizes the delegation return-on-investment assessment, not external side effects, tracker mutations, product decisions, broader work, or bypassing child-route consent. Decline delegation and continue directly when the task is trivial, tightly coupled, inherently serial, or cheaper to do than to brief and supervise. Delegation must save more context, latency, or cost than briefing, coordination, and review consume. The parent always owns: - Outcome, scope, acceptance, architecture, and high-impact decisions - Decomposition, child selection, route consent, and writer ownership - Integration, conflict resolution, review synthesis, and final response - Inspection of the actual diff and validation evidence Use `architect` when ambiguity or blast radius requires a plan. Do not send unresolved architecture to a worker. `verify-task` and `total-review` remain separate gates; invoke them rather than copying their workflows. ## 2. Establish outcome, context, and acceptance Before delegation, establish the user-visible outcome, explicit non-goals, and acceptance evidence. If those are disputed or consequential architecture remains unresolved, ask the user or invoke `architect` before assigning implementation. Preserve acceptance as explicit **outcome → evidence** pairs for every implementation slice or consequential work unit: ```text observable outcome: acceptance evidence: expected signal: ``` Use repository-supported commands when they exist. Use named CI checks/artifacts when the environment owns proof, and minimal manual UAT for inherently experiential or external behavior. Documentation-only work may use source/render/link evidence. Never manufacture a shell command to make acceptance look concrete; mark unavailable proof and its prerequisite explicitly. Continue directly when the work is one coherent unit with shared context, ownership, and validation. For work with material dependencies, uncertainties, or integration seams, read and follow [`references/work-graph.md`](references/work-graph.md). Its compact method separates: 1. Decisions retained by the parent, user, or `architect`. 2. Material uncertainties and the smallest evidence needed to resolve them. 3. Bounded work units with hard dependencies and ownership boundaries. 4. Integration points, ready work, and the critical dependency path or candidates. 5. Splits whose coordination value is too low and should be collapsed. A work-graph node is not automatically a child launch or tracker item. A valid graph may conclude that one writer should perform all work serially. The graph exposes topology and readiness; later execution-shape selection decides what, if anything, to delegate. This version still uses a shallow execution shape, not a persistent dependency scheduler. Use parallel children only for genuinely independent read-only questions or intentionally isolated worktrees. If decomposition exposes unresolved architecture, return to the parent or invoke `architect`, then rebuild affected graph edges before assigning implementation. Read repository rules, established patterns, and current status/diff. Use tracking only for durable context: - Use Beads only when `bd` is available, active Beads context exists, and a relevant bead or epic is present. Resolve that bead's owning store first with `~/.agents/skills/next/scripts/next-select resolve ` and read it with `bd -C show `; never infer the store from the ID or the cwd. On `ambiguous` or `unavailable`, report and treat the bead as unavailable context. - Otherwise use the established Jira, Trello, or other tracker. If none exists, report durable milestone suggestions generically. - Never create one item per child, recon pass, review, retry, or handoff. - Propose independently valuable tracker work only; mutate tracking after explicit approval. Invoke `triage` only in a Beads-enabled repository. - Consume a present `workspace.json` project-context index when useful, but do not require, create, or silently rewrite one. ## 3. Choose the execution shape Give the user a short execution shape before launching children. For a non-trivial work graph, include only the material fields: ```text retained decisions: material uncertainties: work graph: ready/critical: integration: declined fanout: writer: verification: escalate/stop: ``` For one coherent unit, keep this to outcome, writer ownership, verification, and stop conditions; do not manufacture registers or graph nodes for presentation. Default to: ```text scope and acceptance -> optional independent recon/advice -> one implementation writer -> integration inspection -> independent review/validation -> at most one focused fix pass -> parent final validation and response ``` This is a default, not a reason to manufacture children. Omit stages that provide no independent value. ## 4. Load launch policy and runtime mechanics Before any child launch: 1. Read and follow [`references/child-routing-policy.md`](references/child-routing-policy.md). 2. Detect the active runtime, then read and follow [`references/runtime-adapters.md`](references/runtime-adapters.md). The compact invariant is: launch without another cost prompt only when trusted evidence resolves the effective child identity before launch and classifies it as unmetered. Metered, inherited, or unknown routes require current-run consent. Parent route approval never authorizes child fanout; mismatches stop further launches; ad hoc consent is never persisted. Do not parse or merge model-tier-router configuration, change canonical agent settings, infer billing, or invent a mapping. The references own route policy and runtime mechanics; the remainder of this skill owns work coordination. ## 5. Give every child a judgment packet Match packet size to risk. A cheap read-only lookup needs an objective, bounded scope, expected evidence, and stop condition. A writer or consequential analyst needs: 1. Goal and user-visible outcome. 2. Owned files/modules or bounded read-only question. 3. Relevant rules, context pointers, and established patterns. 4. Non-goals and prohibited expansion. 5. The owned outcome → evidence pairs: observable result, evidence type, exact command/check/flow or source proof, and expected decisive signal. 6. Shared integration/CI gates that supplement rather than replace those pairs. 7. Risks, assumptions, dependencies, and unresolved questions. 8. Required result: status, files/evidence, each pair's observed outcome and proof, validation outcomes, discoveries, residual risks, and decisions needed from the parent. 9. Escalation and stop conditions. Require the child to return one of `complete`, `blocked`, or `needs-decision`. A blocked or decision result must include evidence and the smallest question needed to continue. Do not let children silently redefine scope, architecture, acceptance, or substitute an easier check that cannot prove the paired outcome. Give reviewers the same outcome → evidence pairs as writers. Reviewers assess both the implementation and whether the returned proof is capable of demonstrating each outcome. If a planned command becomes invalid or a manual flow cannot be witnessed, the child returns `blocked` or `needs-decision`; it does not invent replacement evidence. If the packet still asks the child to discover architecture or choose a high-impact alternative, retain that work in the parent or use a stronger advisory/planning pass. ## 6. Assign by work shape and risk Use semantic classes rather than exact shared model IDs or changed-line counts: | Work shape | Assignment | |---|---| | Focused lookup or repository/document research | Read-only context/research role; an `economy` route only when verified. | | Narrow mechanical implementation | One writer on `standard` with `high` effort only when the packet fixes scope, pattern, non-goals, acceptance, validation, and escalation. | | Bounded implementation or routine independent review | One `standard`/`high` writer or fresh reviewer on a verified route; otherwise inherit with disclosure and consent. | | Complex implementation with local design judgment | Verified `premium`/`high` child, inherited child with consent, or retain in the parent. | | Architecture, unclear ownership, public contracts, destructive or security-sensitive work | Retain the decision in the premium parent; use a strongest-route advisor only when justified. | | Final craft judgment | Fresh `premium`/`xhigh` reviewer or a named review skill; use extra effort only when risk warrants it. | All writes use the runtime's implementation role, named `worker` when available. Tune effort within a suitable class before moving to a stronger capability tier. ## 7. Execute, communicate, and integrate Only one writer may edit a shared worktree at a time. Parallelize research, recon, review, and validation—not ordinary writes. Parallel writers require intentional worktree isolation, a clean base, non-overlapping ownership, and an explicit integration order. Use native progress/intercom facilities when available for material discoveries, blockers, and decision requests. Do not require chatter for healthy bounded work; a one-shot result envelope is the portable fallback. The parent decides whether new evidence changes the packet, requires a focused follow-up, returns to architecture, or stops. After a writer returns, the parent must inspect the actual diff, reconcile it with other findings and repository state, and run or witness required validation. Reconcile each planned outcome → evidence pair against what was actually observed, then run shared integration gates. A child summary, command invocation without its expected signal, or unrelated green CI is not integration evidence. Use fresh/separate context for genuine independent review where supported. Cap routine fanout at two or three distinct angles. The implementer cannot be the sole authority that its work is complete when delegation exists. Use named review gates rather than building an unbounded generic review loop. If delegation is unavailable or declined, continue serially and label the result **self-validated**, not independently reviewed. If genuine independence is required, use `second-opinion` under its cost guardrails or stop and ask. ## 8. Verify, escalate, and finish A child must stop and return evidence when: - Work expands beyond owned files or acceptance criteria. - Repository behavior contradicts the packet or invalidates an assumption. - A public API, schema, migration, permission, compatibility, product, or architecture decision appears. - Auth, secrets, destructive operations, financial correctness, concurrency, deployment control, or irreversible data appears unexpectedly. - The same validation failure survives two evidence-based attempts. - It is guessing about hidden state or cannot explain the failure. - Integration reveals conflicting edits or architectural coupling. Use the smallest responsible response: revise the bounded packet, increase effort in the same class, use a stronger worker/advisor, return to architecture/user judgment, or stop. Do not automatically jump to a maximum-effort panel or silently widen scope. Finish when every required observable outcome has matching witnessed evidence, shared validation passes, and review finds no fixes worth doing now; remaining findings are optional/deferred; a decision needs the user; or the selected review gate reaches its cap. Routine delegated work normally uses one review and at most one focused follow-up. Report the execution shape, material child route evidence, each outcome and its acceptance evidence, shared validation, conflicts or decisions, residual risks, deferred work, and whether validation was independent or self-validated.