gh-create-issue

name	gh-create-issue
description	Create a new GitHub issue (feature request or bug report) by gathering an unstructured description from the user, classifying it, filling out the appropriate Kibana template, interviewing the user to improve any weak sections, and filing the issue via the GitHub CLI.
disable-model-invocation	true

Create GitHub Issue

Guide the user through creating a well-structured GitHub issue from scratch.

Step 1 — Gather the unstructured description

Ask the user to describe their feature request or bug report in their own words — no structure required. Tell them to include as much or as little as they know. End your response and wait for the user to reply before proceeding.

Example prompt to the user:

Describe the feature you'd like or the bug you've found in your own words. Don't worry about structure — just tell me what you're thinking and I'll help shape it.

Step 2 — Classify the issue

Using the user's description, determine whether this is a bug report or a feature request:

• Language like "broken", "crash", "error", "fails", "not working", "regression", "unexpected behavior", "should have worked" → bug report.
• Language like "add support for", "allow", "should be able to", "would be nice", "request", "proposal", "improve", "I wish", "it would be helpful if" → feature request.

If classification is ambiguous, ask the user which type applies before continuing.

Step 3 — Read the appropriate template

Read the template to know which fields to populate:

• Bug report: read .github/ISSUE_TEMPLATE/Bug_report.md
• Feature request: read .github/ISSUE_TEMPLATE/Feature_request.yml

Step 4 — Draft the issue from the description

Using the user's description as source material, populate as many template fields as you can. Apply reasonable inference:

• For feature requests: synthesize a clear "What feature do you want added?" statement (noting what's explicitly out of scope if apparent), derive a "Why?" from the use-case (including how users work around the gap today and who the target user is), draft initial Acceptance Criteria (happy path + edge cases) from the described behavior, infer a priority if clues are present, and note any blocking issues for the "Blocked By" field.
• For bug reports: extract steps to reproduce, expected vs actual behavior, and any environment details mentioned.

Leave fields blank where the description provides no basis for inference. Do not ask questions yet — draft first.

Step 5 — Generate a title

Draft a concise, descriptive issue title (under 72 characters) that captures the core ask or bug. Prefix with the relevant area if apparent (e.g. [Discover], [Maps], [Alerting]).

Step 6 — Interview the user for weak or missing fields

Review your draft. Identify fields that are:

• Empty, or
• Vague / not independently verifiable (for Acceptance Criteria), or
• Missing required information

For each such field, ask one question at a time, then end your response and wait for the user to reply before moving to the next field.

Guidelines:

• For required fields (Describe the bug, Steps to reproduce, Expected behavior, What feature do you want added?, Why?): always ask if missing or weak.
• For Acceptance Criteria: if the drafted criteria are vague (e.g. "should work correctly"), ask the user to make them concrete and testable.
• For optional fields (screenshots, logs, browser console errors, additional context, Priority): ask once; accept "N/A" or "none" and move on.
• If an answer is still vague after one follow-up, ask one more targeted clarifying question, then move on.
• Once all fields are addressed, proceed to Step 7.

For feature requests, also probe for these common gaps (even if the field is not empty, ensure the draft addresses them):

• Scope boundaries: Is it clear what's not included? If the feature could be interpreted broadly, ask what's explicitly out of scope.
• Current workaround: How do users accomplish this today? If the "Why?" doesn't describe the workaround, ask.
• Target user: Who would use this — what role or persona? If not stated, ask.
• Dependencies: Are there issues, features, or infrastructure changes that must land first? If so, capture them in the "Blocked By" field.

Step 7 — Collect and validate labels

Ask the user for a team label (e.g. Team:Visualizations) and any additional labels (e.g. accessibility, performance). Accept "none" for either. The type label (bug or enhancement) is added automatically.

End your response and wait for the user to reply before proceeding.

Once the user provides labels, validate all of them in parallel against the repository:

gh label list --repo elastic/kibana --search "<label>" --limit 10 --json name,description --jq '.[] | "- `\(.name)` — \(.description // "no description")"'

For each label:

• Exact match → keep it.
• Close matches only → show them as `<name>` — <description> and ask the user to pick one or skip.
• No matches → inform the user and ask to skip or provide an alternative.

If any labels need user input, wait for the reply, then re-validate any new labels. Repeat until all labels are resolved.

Step 8 — Show the draft and confirm

Display the complete issue preview using this format:

Title: <title> Labels: <label1>, <label2>, ...

---

<issue body>

Ask the user to confirm or request changes.

End your response and wait for explicit confirmation before filing.

Step 9 — Create the issue

gh issue create --repo elastic/kibana \
  --title "<TITLE>" \
  --label "<label1>" --label "<label2>" --label "<labelN>" \
  --body "$(cat <<'EOF'
<formatted body here>
EOF
)"

Add one --label flag per label.

Always include the type label (bug or enhancement) plus all validated labels. Report the new issue URL to the user when done.