issue-creation

# Issue Creation ## Activation Contract Use this skill for drafting, creating, commenting on, triaging, or approving GitHub issues. Repository policy and selected YAML Issue Form are authoritative. ## Hard Rules - Reuse verified current-session facts; discover only missing or stale facts. - Before any needed target policy read or write, resolve the exact target as `[HOST/]OWNER/REPO`. Never assume the current repository. - YAML Issue Forms are the single format authority. Never use Markdown, a blank body, an alternate publisher, or a browser route as a fallback. - Complete one open-and-closed duplicate search before a write. Reuse that result while it remains current. - Never invent facts, selections, affirmations, labels, approval, or policy; ask for the smallest missing fact. - Create-time labels are limited to labels declared by the selected form, discovered to exist, and permitted for the actor. - Before ANY post-publication workflow mutation, read `references/delegated-workflow-actions.md` completely and follow it. It is normative, not optional background. - Require current direct human instruction: exact `HOST`, `REPO=OWNER/REPO`, issue/PR number/action. - Protected policy labels are `status:approved`, `size:exception`, and any repository-defined gate-override/authorization label. For `status:approved`, require target-host evidence binding the direct instructing principal to approval authority as a repository maintainer or repository-authorized approver. - Adding or...