to-issueslisted

# To Issues Turn a feature's requirements into work items someone (human or agent) can grab and finish independently. Where the issues land depends on `issue_backend` (ADR_0003); the requirements they trace to are always sphinx-needs. ## Workflow ### 1. Resolve configuration and scope Read `[tool.patdhlk-skills]` from `ubproject.toml`: `issue_backend`, `spec_dir`, `builder`, `issue_doc`, role map. Missing config or unmapped `requirement` role (plus `issue` role on the sphinx-needs backend) → stop, point to `/setup-patdhlk-skills`. Identify the target feature from conversation (or ask). Build a fresh needs.json (ADR_0006) and collect its requirements: needs of the requirement type whose `satisfies` (or `links`) includes the feature ID. Skip reqs already covered — an existing issue `implements` them (local) or they carry a `:github:` reference (github backend). ### 2. Slice into vertical slices — not 1:1 req→issue Group requirements into issues that each deliver **observable behavior end to end** (a tracer bullet first: the thinnest path through the whole stack). Split a req that hides two work items; bundle reqs that only make sense shipped together. Every issue must state: - what to build (1–3 sentences, self-contained — readable without the PRD), - which requirement IDs it implements, - how to verify it (the demo/test that proves it done). Mark issues an agent can finish unattended `ready-for-agent`; ones needing human judgment, credentials, or design taste `ready-f