Gh Enhance Issue

1. Check the labels array first. If any label contains bug (case-insensitive), treat it as a bug. If any label contains enhancement or feature (case-insensitive), treat it as a feature request.
2. If labels are ambiguous or absent, infer from the title and body:
   • Language like "broken", "crash", "error", "fails", "not working", "regression", "unexpected behavior" → bug.
   • Language like "add support for", "allow", "should be able to", "would be nice", "request", "proposal", "improve" → feature request.
3. If classification is still uncertain, ask the user before proceeding.

Step 3 — Extract what you can from the existing body

Using the original title and body as source material, map existing content to the appropriate template fields. For feature requests, look for scope boundaries, current workarounds, target user, and any mentioned blockers or dependencies. Leave fields blank where no information is available in the original issue.

*** Bug report *** Read .github/ISSUE_TEMPLATE/Bug_report.md to get the required fields.

*** Feature request *** Read .github/ISSUE_TEMPLATE/Feature_request.yml to get the required fields.

Step 4 — Interview the user for empty fields

After extracting what you can, identify which fields are still empty. Ask the first empty field's question, then end your response and wait for the user to reply. Do not ask the next question or proceed to Step 5 until the user has answered.

Guidelines:

• For required fields (e.g. "Describe the bug", "Steps to reproduce", "What feature do you want added?", "Why?"): always ask.
• For optional fields (e.g. screenshots, browser console errors, logs, additional context): ask once and accept "N/A" or "none" as a valid answer; do not press further.
• If the user's answer is vague, ask one targeted follow-up question to clarify, then end your response and wait before moving on.
• Once all empty fields have been addressed, proceed to Step 5.

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 5 — Show the diff and confirm

Display the proposed new body to the user and ask for confirmation before making any changes. End your response and wait for the user to explicitly confirm before proceeding to Step 6.

Step 6 — Update the issue

After the user confirms, update the issue body:

gh issue edit <NUMBER> --repo elastic/kibana --body "<NEW_BODY>"

Pass the body via a shell variable or heredoc to avoid quoting issues:

NEW_BODY=$(cat <<'EOF'
<reformatted body here>
EOF
)
gh issue edit <NUMBER> --repo elastic/kibana --body "$NEW_BODY"

Confirm success by reporting the issue URL.