spawnlisted

# spawn — Decompose Current Task into Child Rows Use when an AFK worker hits a decision/blocker outside its CHOICES scope or that only a human can resolve. Per AGENTS.md §2 (Concern → HITL Decomposition), the worker MUST decompose rather than guess or stall. `spawn` is a **ledger-write** skill: it inserts N child rows, sets `parent.blocked_by=[childIds]`, flips `parent.state=blocked`. All writes route through bookie. Not to be confused with process spawning (factory does that). ## When to use - Decision outside this worker's scope (taste call, public-facing artifact, irreversible action). - Blocker only a human can resolve (credentials, external dependency, policy call). - Task body turns out to require >1 atomic unit of work. Do **not** spawn for in-scope, low-risk, reversible work — just do it. ## Inputs | Flag | Required | Notes | |---|---|---| | `--parent` | yes | parent issue id (the current task) | | `--children` | yes | JSON array of child specs (see schema) | Child spec schema: ```json { "kind": "task" | "encounter_reply", "type": "HITL" | "mvp" | "cron" | "security" | "quality" | "scale" | "efficiency" | "deferred", "title": "<short title>", "body": "<markdown, optional>", "acceptance": "<markdown, optional>", "hitl": 0 | 1 } ``` For HITL decomposition the typical child has `kind=task, type=HITL, hitl=1`. ## Constraints - **Fanout cap = 5.** If you need more than 5 children, the task isn't atomic — re-shape it (one umbrella child that itself de