subagent-contract

Load dh:dh-cli-usage before using <sam_cli/> or <dh_scripts/>.

Subagent Contract

When your dispatch names a ledger address and attempt, use this DH contract even if its prompt opens with Your ROLE_TYPE is sub-agent. Without that ledger identity, follow the response contract named by your dispatch; if it names none, use the contract selected by your caller. The rules below apply when dh:subagent-contract is selected; a no-ledger handoff naming the separate agent-orchestration delegate contract follows that contract instead.

Begin your response with STATUS: DONE or STATUS: BLOCKED as its own first line. Consumers branch on that line in that position.

When your dispatch names a ledger address and attempt, send DONE once finish was recorded, whatever its durable result. This reports successful recording of the attempt's end, including failed, blocked or needs-input; it does not assert task success. Send BLOCKED when closure could not be recorded, naming the refusal or missing input and what would unblock it. Follow the runner contract's refusal handling when the attempt is stale or already closed.

For no-ledger work governed by this contract, send DONE once the acceptance criteria are met as written and every stated constraint is respected. Send BLOCKED when the required scope cannot be completed, including unmet criteria, failed verification or a missing required input. Carry the completed work, the unmet scope, the observed evidence and the input or action needed to proceed; do not infer a missing input.

DONE carries what was accomplished, the deliverables in the form your dispatch named, and any observed risk.

This line reaches your immediate caller only, in the response it reads the moment your launch returns. It is not a record: a reader arriving later, in another session, sees nothing of it unless someone wrote it down. When your dispatch names a ledger address and attempt, <work_ledger/> below says what to write down and how.

There is no third token here. With a ledger, a mixed outcome is recorded one row per task; finish --result has no partial value. Send DONE once all the attempts you were responsible for closing were recorded; send BLOCKED if any could not be closed, and identify them. The agent-orchestration plugin's similarly named delegate/references/sub-agent-contract.md does pin a third token, PARTIAL, for dispatches invoking that separate delegate contract. Absence of a ledger alone does not select either contract; use the applicability rule above.

<dispatch_input>

If your dispatch concerns a specific backlog item and your tools: list carries mcp__plugin_dh_backlog, fetch that item yourself — backlog_view(selector=<item_ref>, ...) — instead of expecting its title, description, or any other section pasted into your dispatch prompt. Content addressable by an item reference and a section name is never re-typed into a prompt; a dispatch naming only item_ref (or selector) already gives you everything the item itself carries. A dispatch with no backlog item in scope at all (verifying a standalone claim, analyzing a plugin path) has nothing here to fetch — this rule does not require calling backlog_view when no item reference was ever part of the task.

This does not cover content that exists only because the current run produced it — a claim string to verify, a finding a peer teammate computed this run — since no item_ref lookup retrieves something not yet written anywhere. A dispatch carrying that kind of content is not a violation of this rule.

</dispatch_input>

<result_destination>

Put your result where your own agent file says. A dispatch naming a different form overrides that — it is how you are put to work beyond your one task — including a body it asks you to return for it to store.

Where neither names one: deliverables the repository keeps — source, tests, documentation — go in repository files; every other document is an artifact, registered with artifact_register carrying its content, since an id registered without content persists nothing.