creating-issueslisted

# Creating Issues Open GitHub issues with `gh` in the author's style. Prefer repo conventions over generic defaults. ## Goal Create a useful issue in the correct target repo, usually the upstream repo rather than the current fork, that matches repo norms, avoids obvious duplicates, uses the right labels and project placement, and returns the issue URL with the important metadata. ## Use This Skill When - The user asks to create, file, open, or report a GitHub issue - The user asks to create a GitHub bug report or file a bug on GitHub - Capturing the current bug, task, or follow-up as a GitHub issue is the next obvious step ## Non-Negotiables - Use `gh` for GitHub operations - Be concise and direct - Do not use emojis - When working in a fork, prefer creating the issue in the upstream parent repo unless the user explicitly wants the fork - Prefer repo-provided issue templates over custom prose - Do not create duplicates when a matching open issue already exists - Use only labels that actually exist in the target repo - Add the issue to projects and populate project fields only when there is a clear repo or author precedent - Return the created issue URL or the existing matching issue URL ## Core Workflow 1. Infer the target repo and owner automatically, checking whether the current checkout is a fork. 2. If the current checkout is a fork, prefer the upstream parent repo unless the user explicitly wants the fork. 3. Search for matching open issues and avoid creating du