buildable-issuelisted

# Skill: buildable-issue ## Activation Contract Use this skill when the user needs a GitHub issue that another agent or human can implement without guessing. This is the renamed public capability for the older `sdd-issue` wording. Treat legacy phrases like “SDD-ready issue” as compatible triggers, but prefer `buildable-issue` in new documentation. ## Responsibility Create or enrich GitHub issues with enough structure for implementation: intent, type, scope, acceptance scenarios, technical context, constraints, and priority. Do not run the implementation, orchestrate SDD phases, or invent missing product decisions. Interview the user when critical fields are missing. ## Required Context - Repository or project where the issue belongs. - Intended change, bug, refactor, or chore. - Known constraints, affected files/modules, and acceptance expectations. - Existing issue number when enriching rather than creating. ## Hard Rules - Search existing issues for likely duplicates before creating a new issue. - Fill all issue sections; do not leave placeholder text behind. - Every in-scope item needs observable acceptance scenarios. - Acceptance scenarios use Given/When/Then language. - Scope must include both in-scope and out-of-scope boundaries. - Apply the `sdd-ready` label when the issue is structured for automated SDD consumption. - Return the issue URL or updated issue reference when done. ## Issue Template ````markdown ## Intent <Why this change is needed. Explain the