• Screenshots / images: Read the image file to extract text, error messages, UI state, stack traces, and any visible context. Pay attention to browser URLs, error codes, timestamps, and user-visible symptoms.
• Pasted text: Bug report emails, Slack messages, support tickets, error logs, user complaints.
• Verbal descriptions: The user describing a bug or feature request conversationally.
• Multiple sources: The user may provide several screenshots plus some context text. Combine all of them.

• Title: A clear, concise summary (imperative or descriptive — e.g., "Login button unresponsive on mobile Safari")
• Description: What's happening, including any error messages, stack traces, or reproduction context from the source material
• Steps to reproduce: If inferable from the input
• Expected vs actual behavior: If inferable
• Environment details: OS, browser, app version — anything visible in the input
• Severity/priority signal: If the source indicates urgency ("critical", "blocking", "P0", etc.)
• Labels: Suggest appropriate labels based on content (e.g.,

  bug

  ,

  enhancement

  ,

  critical

  ,

  ui

  ,

  backend

  )

• Names of end users or reporters — replace with generic references like "a user", "the reporter". Keep names only if the person is a team member the user explicitly wants tagged.
• Email addresses — redact entirely (e.g.,

  j***@example.com

  or just remove)
• Phone numbers — remove
• Physical addresses — remove
• User IDs / account names of end users — replace with

  [user_id]

  or

  [redacted]

• API keys, tokens, passwords — if visible in screenshots or logs, replace with

  [REDACTED_API_KEY]

  ,

  [REDACTED_TOKEN]

  , etc. Flag these to the user as a heads-up ("I noticed an API key in the screenshot — I've removed it from the issue.")
• Session IDs, cookies, auth headers — redact
• Database connection strings — redact

• Internal IP addresses — replace with

  [internal_ip]

• Internal hostnames / URLs that expose infrastructure — replace with

  [internal_host]

• Database names, table names — keep only if directly relevant to the bug

• Customer data visible in screenshots (financial info, health info, private messages) — describe the data type without reproducing the actual values (e.g., "the user's transaction history was visible" instead of listing actual transactions)
• Proprietary business logic visible in error details — summarize rather than quote verbatim if it reveals trade secrets

• After extracting information in Phase 1, do a sweep for all of the above before composing the issue body.
• When you redact something, note it briefly in the proposal so the user can see what was removed and override if needed (e.g., "Note: removed reporter's email address and an exposed API key from the issue body").
• If the input is heavily loaded with sensitive data and redacting it would make the bug report meaningless, flag this to the user: "This report contains a lot of sensitive details. Want me to create a more generic description, or would you prefer a private/internal issue?"
• When in doubt, redact. It's easy for the user to add information back; it's hard to un-leak something posted publicly.

1. [Step 1]
2. [Step 2]
3. [Step 3]

• OS: [if known]
• Browser/Version: [if known]
• App Version: [if known]

bug

ui

[Show the full issue body as it will appear on GitHub]

If proposing updates to existing issues, show what will be added (as a comment or body edit) and link to the existing issue.

End with a clear prompt:

> **Does this look right?** You can:
> - Say **"go"** or **"approve"** to create/update all issues as shown
> - Say **"skip 2"** to exclude a specific issue
> - Ask me to modify any issue before creating it
> - Say **"cancel"** to abort

**Do not proceed until the user explicitly approves.** This is critical — creating issues is a visible action that others will see.

gh

gh issue create --title "TITLE" --body "$(cat <<'ISSUE_BODY'
... issue body ...
ISSUE_BODY
)" --label "bug,ui"

gh issue comment ISSUE_NUMBER --body "$(cat <<'COMMENT_BODY'
... update content ...
COMMENT_BODY
)"

gh issue edit ISSUE_NUMBER --add-label "label1,label2"

Done! Created/updated the following issues:

• #42: Login button unresponsive on mobile Safari
• #38: (updated) Add dark mode support — added reproduction details

1. Open https://app.example.com on iPhone with Safari (iOS 17)
2. Enter valid credentials
3. Tap the "Log In" button

• OS: iOS 17.4
• Browser: Safari (mobile)
• App Version: 2.3.1

• No repo access / gh not authenticated: Run

  gh auth status

  at the start; stop and tell the user what's missing before extracting any data.
• Duplicate issue: Search open issues for keyword matches before proposing creation; if a near-duplicate is found, offer to update it with a comment instead.
• Missing required fields: If the input lacks enough detail to write a meaningful description or steps to reproduce, ask clarifying questions rather than filing a skeletal issue.
• PII-heavy input: If redacting sensitive data would make the report meaningless, flag this to the user and offer to create a private/internal issue or use generic descriptions.
• Multiple issues in one input: Extract each distinct problem as a separate numbered proposal; let the user approve, skip, or modify each independently.
• YAML issue templates: Parse

  .yml

  templates with structured fields and map extracted data to the template's field IDs and types; respect required fields.
• User drops image without context: Read the image to extract all visible text, UI state, error codes, and URLs; infer the issue from the visual context before asking for clarification.

• gh auth status

  and

  gh repo view

  succeed before any extraction begins
• Each issue identified in the input is proposed individually with title, labels, template, and full body preview
• PII (names, emails, API keys, internal IPs) is redacted before issue body is shown to the user
• Existing open issues are searched for potential duplicates; matches are flagged
• No issue is created or updated without explicit user approval ("go" / "approve")
• Each created issue returns a URL confirming the issue number
• Labels used exist in the repo (

  gh label list

  ) or are clearly flagged as new
• Sensitive data removal is disclosed in the proposal (e.g., "Note: removed API key")

• Never create issues without approval. The proposal step is not optional.
• Preserve original context. When the input is a screenshot or email, mention the source in the issue body (e.g., "Reported via email on 2026-03-17" or "From screenshot of error dialog"). Don't attach the screenshot itself to the issue unless the user asks — just describe what's visible.
• One input can yield multiple issues. A single screenshot might show several problems. A forwarded email might contain a list of bugs. Extract them all as separate issues.
• Be conservative with labels. Only suggest labels that clearly apply. If the repo has existing labels, prefer those over inventing new ones. Check with:

  gh label list --limit 50

• Handle ambiguity by asking. If you're not sure whether something is a bug or a feature request, or whether two things should be one issue or two, ask the user.
• YAML template parsing. Some repos use

  .yml

  templates with structured fields (type: input, type: textarea, etc.). When you encounter these, map your extracted data to the template's field IDs and format the issue body accordingly, respecting required fields and field types.