creating-block-issueslisted

## When this skill applies The target repo is a Spec Kit project: `.specify/` exists at repo root, and at least one `specs/<NNN>-<feature>/tasks.md` is present with `#### Block <X> — <name>` PR-stack headings (the structure produced by `/coding-skills:speckit-tasks` and aligned with [`implementing-blocks`](../implementing-blocks/SKILL.md)). The repo has a GitHub `origin` remote. This skill creates **one tracking issue per Block**, not per task. No epic, no per-task issues. Whoever picks up the issue (a human assignee or an automation pipeline that polls GitHub) runs the block-implement loop. The issue body is intentionally minimal (4 short bullets: pointer, heading, a 1-2 sentence summary, task IDs) and points at `tasks.md` as the source of truth; constitution, scars, conventions, and per-task acceptance criteria are NOT duplicated per issue (the assignee reads them from the file at implementation time). If the repo is not a Spec Kit project, or `tasks.md` does not use the `#### Block <X>` structure, fall back to manual `gh issue create` per the project's own issue conventions. ## Issue template (load-bearing) Every block-issue body MUST match this exact shape — keeping the body minimal is the contract. Drift between issue and `tasks.md` is what we are explicitly avoiding: ```markdown - **Spec:** `specs/<NNN>-<feature>/tasks.md` - **Block:** Block <X> — <name> (verbatim from the `####` heading in tasks.md) - **What:** <1-2 sentences: what the block builds and why it exi