issue

/issue — Structured GitHub Issue Creator

Investigate the codebase based on the user's request and create a GitHub issue with clearly defined confidence boundaries.

Input

The text the user typed after /issue is the original request. Preserve it verbatim.

Examples:

• /issue Duplicate Shorts URL fetches in YouTube subscription feed
• /issue Add notification settings tab to Settings page
• /issue Scheduler occasionally runs twice

If the input is too vague (e.g., "there's a bug"), ask ONE clarifying question. Otherwise, start investigating immediately.

Phase 1: Impact Analysis

Perform a full impact analysis based on the user's request. Use Agent to investigate in parallel.

What to Investigate

Launch agents in parallel where possible:

1. Related code exploration — Identify files, functions, and modules directly related to the request
2. Dependency analysis — Where is this code referenced, and which modules are affected
3. Existing test coverage — Whether related tests exist and what they cover
4. Related issues/history — Relevant change history from git log, known issues

Classifying Findings

Classify all findings into three confidence levels:

✅ AI Verified

Objective facts confirmed through code exploration. No need for human re-verification.

• Function/file locations, call relationships
• Whether tests exist
• Current behavior (as read directly from code)
• Relevant config values, environment variables

🤔 Decision Required

Decision points that AI cannot make on your behalf.

• Trade-off choices (performance vs. accuracy, UX vs. security, etc.)
• Business logic decisions
• Scope decisions (how much to fix)
• Priority judgment

⚠️ Human Verify

Risks and caveats AI may have missed.

• Potential side effects
• Risks from production environment differences
• External service dependencies
• Whether data migration is needed
• Areas AI could not verify (external systems, real user data, etc.)

Phase 2: Preview & Confirm

After investigation, show the user a preview of the issue body.

Issue Body Template

## Request

> {original text the user typed after /issue, verbatim}

## Impact Analysis

### Related Code
- `file:line` — description
- ...

### Scope of Impact
- List of affected modules/features

---

## ✅ AI Verified
> Facts confirmed through code exploration. No further verification needed.

- [ ] Confirmed fact 1
- [ ] Confirmed fact 2

## 🤔 Decision Required
> Decision points requiring human judgment.

- [ ] Decision point 1 — Option A vs B, considerations
- [ ] Decision point 2

## ⚠️ Human Verify
> Risks AI may have missed. Needs human review before and/or after implementation.

- [ ] Verification point 1 — why this needs checking
- [ ] Verification point 2

After showing the preview, confirm with AskUserQuestion:

AskUserQuestion(
  question: "Should I create a GitHub issue with this content?",
  header: "Issue Preview",
  options: [
    { label: "Create", description: "Create the issue as-is" },
    { label: "Edit then create", description: "I want to make changes first" },
    { label: "Cancel", description: "Do not create the issue" }
  ]
)

• Create → Proceed to Phase 3
• Edit then create → Incorporate user feedback, then show preview again
• Cancel → "Issue creation cancelled." → Stop

Phase 3: Create Issue

Create the issue with gh issue create.

gh issue create --title "Issue title" --body "$(cat <<'EOF'
Issue body
EOF
)"

Title Rules

• Under 70 characters
• Use a prefix: feat:, fix:, refactor:, chore:, etc. (based on content)
• English or Korean OK

Label Auto-mapping

Based on the issue content, add matching labels via the --label flag using the table below. Multiple labels allowed. If no match, create without labels.

Issue type	Label
Bug, error, broken behavior	bug
New feature, addition, improvement	enhancement
Documentation related	documentation
Question, investigation, needs clarification	question

After creation, return the issue URL to the user.

Hard Rules

1. Investigate first — Never create an issue without investigation
2. Confirm first — Never create an issue without user confirmation
3. Preserve original — The user's original request must be included verbatim in the "Request" section
4. Facts only — AI Verified contains only things directly confirmed from code. No speculation.
5. Be honest — Anything unverified goes into Human Verify. Never pretend to know.
6. Keep it concise — Do not let the issue body grow unnecessarily long

Checklist Before Stopping

• Codebase impact analysis completed
• Findings classified into three confidence levels
• User's original request included verbatim
• User reviewed the preview
• gh issue create executed and URL returned (or user cancelled)