Work on spec

Invocation and shared ownership

Start only when the user requests overall specification delivery, including an authorized continuation of that delivery. Merely reading a spec, decomposing it, or investigating a bug grants no execution authority. The calling agent is the one overall technical lead; ticket agents use work-on for bounded changes. Cross-ticket decisions, shared interfaces, scheduling, integration and whole-agreement accountability stay here. Loading a skill launches nothing and grants no installation, spending, disclosure, tracker mutation, destructive operation, merge, deployment or release permission.

Before coordinating, discover work-on through the runtime/project catalog or an explicit approved source, read its complete entry and references/contracts.md, and record the resolved source/revision or digest. Confirm those required reads are complete before coordinating; use the contract's “Complete reads and reference resolution” procedure for incomplete output and companion/library paths, including tracker discovery. Consume that contract as a read-only library without invoking its single-change entry. It solely owns handoff/evidence fields, shared worker/repair/model limits and delivery gates. Require compatible bounded assignments, inline method/specialist use, root-owned launches, retained history and distinct local/integrated evidence. Ambiguous or missing companions block dependent routes, never trigger automatic installation or legacy fallback. Recheck compatibility on changed sources, authority or resume.

Multi-ticket execution requires an authorized runtime capable of bounded writable work-on ticket assignments, exclusive isolation, lifecycle inspection and separately inspectable results. An inspect-only delegate cannot implement tickets. Without that capability/permission, inspect the graph and return a plan or preserved blocker; do not silently substitute an overall direct build or create another orchestration service. With fewer available slots, serialize eligible ticket assignments and independent review axes under the discovered shared ceiling. Ticket leads request additional workers/review/model allocations from this root rather than launching recursively.

For package changes or validation, read validation.

1. Inspect the agreement, context and actual progress

Read target instructions and their project/workflow/authority, documentation, relevant domain/ADR and tracker/label pointers. Pin the approved spec and acceptance IDs, exclusions, intended tickets and exact permitted effects. Inspect actual branches/worktrees, dirty artifacts, protected work, existing PR/acceptance/merge evidence and retained root ledger. Missing consequential intent goes to its owner; routine engineering choices stay with the lead.

Reuse current ticket investigation/analysis and local decisions after inspecting cited sources/raw evidence and comparing deciding content, callers, configuration and environment. A new ticket/phase or elapsed time alone warrants no fresh investigation, analysis or optional model call. Refresh only dependent missing/stale claims; preserve unaffected decisions. Shared trade-offs return to this lead; product changes require agreement-owner approval. Discover analyze, shape-work, write-spec, write-tickets or the domain owner only for their actual gaps, through Work On's capability contract.

If owners, operations, graph, evidence or budget history are uncertain, read recovery before writes or launches. Multi-session work uses an approved durable evidence pointer, not a new committed state service.