Agent-Harness-Kit: Skill for Claude Code

Parallel dispatch

Also participate before graph creation when writing-plans identifies independent candidate workstreams. Assess contracts, exclusive ownership, and actual host capacity before collapsing a block into one node; execute only after graph readiness and leases are established. A preflight default does not establish host capacity. Keep atomic fast-route work solo.

Follow ../../../harness/playbooks/parallel-execution.md. Activate automatically after graph reconciliation whenever at least two nodes are ready; the user does not need to name this skill.

1. Read the host-evidenced numeric implementation capacity and the current graph revision. If parallel contexts are unavailable, record sequential-fallback; do not claim parallel execution.
2. Run agent-harness schedule harness-state/TASK-GRAPH.md --capacity <host-capacity> (or the equivalent packaged CLI) and use only its selected IDs. The scheduler rechecks completed dependencies, accepted assurance, active capacity, and normalized write collisions.
3. For the whole selected batch, pin task specs, reserve distinct leases/isolations/model-dispatch routes under the expected graph revision, and create harness.parallel-dispatch/v1 as reserving. Never dispatch from conversational memory.
4. Invoke the actual Codex subagent/task operation once for every selected node without waiting for earlier children to complete. Use separate calls/references, explicit model/reasoning overrides, and the smallest declared context packet. Calls may return sequentially; the children must remain running concurrently.
5. Persist each returned agent/task reference and adapter evidence, transition only confirmed children to active, and report the active worker count.
6. Wait for the first child completion or attention event and refill free capacity. At 60–90 seconds without observable progress, warn/request a checkpoint; on the second consecutive occurrence, interrupt, preserve state, and reassign or serialize within budget.
7. Dependents become ready only after all declared dependencies and assurance gates pass. Cross-area results meet in an explicit integration node; never let parallel children edit shared integration/generated outputs concurrently.

Automatic fan-out, refill, and fan-in are normal execution and require no repeated human approval. Human input is requested only for a genuine authority/product/risk decision.