Gh Create Issue

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

Display the complete proposed issue (title + body) and ask the user to confirm or request changes. End your response and wait for explicit confirmation before filing.

Step 8 — Create the issue

After the user confirms, create the issue:

ISSUE_BODY=$(cat <<'EOF'
<formatted body here>
EOF
)
gh issue create --repo elastic/kibana --title "<TITLE>" --body "$ISSUE_BODY" --label "<bug|enhancement>"

Use label bug for bug reports and enhancement for feature requests.

Report the new issue URL to the user when done.