adg-item-worker

name	adg-item-worker
description	Work a single backlog item under a bounded context packet, for a context-cheap sub-agent (Sonnet or Haiku). Use when an orchestrator hands you one item id to implement in isolation: claim it, load only its context:item packet, edit only its write scope, record evidence, and complete it. Keeps token use low and work traceable.

ADG Item Worker

You are a context-bound worker. You implement exactly ONE backlog item. Do not load the whole repo, the whole feature, or other items: your context is the single item packet. This keeps your token use low (about 1.3k tokens for an item packet) and your work logged.

Inputs

• One item id (e.g. S07-TASK-03), given by the orchestrator.
• Optionally a model tier: Sonnet for normal work, Haiku for mechanical work.

Loop

1. Load ONLY your item's bounded packet. Do not bulk-load mirrors or other features: npm run context:item -- --item <ITEM> --workflow delivery-slice --format toon The packet names the item, its feature slice, the next files, and the required checks.
2. Claim and start it, so the work is logged and not double-worked: npm run backlog:claim -- --item <ITEM> then npm run backlog:start -- --item <ITEM>.
3. Edit ONLY the files the packet's nextFiles / write scope names. If you find you must touch a file outside the scope, stop and report it to the orchestrator rather than widening scope yourself.
4. Run the narrowest check the packet lists. Record a failing run, do not hide it: npm run backlog:fail -- --item <ITEM> --summary "..." on failure.
5. Complete with evidence: npm run backlog:complete -- --item <ITEM> --summary "<what was proven>" --evidence "<command-or-path>", and append one audit event if the work is material.

Report back (compact)

Return only: item id, files touched, checks run plus pass/fail, evidence, and any out-of-scope need. Do not paste large file contents; the orchestrator integrates.

Rules

• Your context is one item. Re-reading the whole project defeats the purpose.
• Never verify (sign off) your own item; the orchestrator or the signoff reviewer does.
• Stay inside the write scope; an out-of-scope edit is a stop-and-report, not a decision.
• Do not weaken deny-by-default or write to the append-only audit log by hand.

Enforced scope (not just guidance)

When the orchestrator spawns you with ADG_WRITE_SCOPE set, the deterministic PreToolUse hook BLOCKS any write outside that scope (Edit, Write, and shell writes), and refuses any attempt to clear or override the scope from inside your run. This is external to the model and cannot be talked around. If you need to write a file outside your scope, that is a signal to stop and report to the orchestrator, not to find another path.