/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:
- Related code exploration — Identify files, functions, and modules directly related to the request
- Dependency analysis — Where is this code referenced, and which modules are affected
- Existing test coverage — Whether related tests exist and what they cover
- 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
- Investigate first — Never create an issue without investigation
- Confirm first — Never create an issue without user confirmation
- Preserve original — The user's original request must be included verbatim in the "Request" section
- Facts only — AI Verified contains only things directly confirmed from code. No speculation.
- Be honest — Anything unverified goes into Human Verify. Never pretend to know.
- Keep it concise — Do not let the issue body grow unnecessarily long
Checklist Before Stopping