← ClaudeAtlas

session-delegationlisted

Dispatch named tasks of one work item to agents. Loads each task record through the runtime, resolves the permitted prerequisite closure, and records each result against its claimed identity. Use after /session-task-planning has written task records. Triggers on "/session-delegation" or when user says "execute the tasks", "run the plan", or "dispatch the agents".
matshoppenbrouwers/session-flow · ★ 3 · AI & Automation · score 76
Install: claude install-skill matshoppenbrouwers/session-flow
# Session Delegation Dispatch the named tasks of one work item, and nothing else. Open with one sentence saying what you are about to do and what it will produce. ## Non-Negotiables 1. **An invocation carries explicit task IDs.** Every dispatch names a SEQ identity and the task IDs it may run. A work item holds tasks belonging to different decisions; being able to read one grants no permission to run it. 2. **The task set never grows during a run.** The named IDs plus their permitted prerequisite closure are the whole set. A prerequisite already `done` contributes its result and its files as context, not as work to redo, and nothing else joins the run. 3. **Claim each task before dispatching it, and dispatch only within its `allowed_paths`.** The claim is the bounded assignment: identity, expected revision, allowed paths. It runs nothing by itself. 4. **Record each task's outcome through `record-result` against the claimed identity.** Progress never goes into the sequence view or a task index; both are generated, and the next `render` discards anything typed there. 5. **Parallel means one message with several Task tool calls.** Not several sequential messages. 6. **A task result is a task result.** Reaching `passed` on every named task does not complete the parent: that needs applicable evidence for the accepted outcome, which is `/session-verify`'s judgement. 7. **The acceptance tests are written before the implementers start, by a different agent, and implementers never