onejaejae/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.

When to Use /issue vs Other Skills

| Skill | Purpose | Output | When to use | |-------|---------|--------|-------------| | /issue | Create a structured GitHub issue | GitHub issue with confidence-classified findings | When you need a tracked, shareable issue from investigation | | /bugfix | Diagnose and fix a bug | spec.json + executed code fix | When you want to fix the bug now, not just document it | | /scope | Quick blast-radius analysis | Markdown report (Change Map + Risk) | When you need scope understanding without creating an issue | | /gh-pr-create | Create a pull request | GitHub draft PR | When code is already written and needs a PR, not an issue |

Error Handling

• gh CLI not authenticated: If gh issue create fails with auth error, show the error and instruct the user to run gh auth login. Do not retry.
• No matching labels: If --label fails because the label does not exist in the repo, retry without labels and note which labels were unavailable.
• Empty investigation: If all parallel agents return no relevant findings, inform the user that investigation found no related code and ask whether to proceed with a minimal issue or cancel.
• User cancels: Print "Issue creation cancelled." and stop cleanly. Do not leave partial state.

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)