# Bug Report En

> Interactively gather bug details, investigate code, and create a structured GitHub Issue.

- Skill: `ousiass/bug-report-en` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add ousiass/bug-report-en`
- Raw SKILL.md: https://api.skillmd.com/api/skills/ousiass/bug-report-en/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Docs & Writing
- Author: ousiass (https://skillmd.com/u/ousiass)
- Updated: 2026-09-10
- Page: https://skillmd.com/skills/ousiass/bug-report-en

---


**Language: Always interact with the user in 日本語.**

# bug-report-en

Usable by non-engineers. Just answer questions to create a proper bug report.

## Prerequisites

- Claude Code environment
- `gh` CLI (for GitHub Issue output)

## Arguments

- **Text** (e.g., `/bug-report-en Can't log in`): Use as initial info, interview for missing details
- **No arguments**: Start interviewing from scratch

## Phase 1: Interview

**Ask in plain language without technical jargon.**

#### 1-1: Basic Information

Use `AskUserQuestion` to gather (skip what's already known from arguments):
1. **What happened**: What problem occurred
2. **Where it happened**: Which screen, feature, or page
3. **Error messages**: Displayed on screen or console (request screenshots)

#### 1-2: Follow-up Questions

Ask **only what's needed** based on responses (max 3, don't ask what can be inferred):

| Situation | What to ask |
|-----------|-------------|
| Error message exists | Error details, screenshots |
| Reproduction unclear | Every time or specific conditions |
| Screen/UI issue | Browser, device, screen size |
| Data issue | Specific data/account only |
| Timing issue | Since when, recent changes |
| Steps unclear | Specific operation steps |

## Phase 2: Codebase Investigation

1. **Identify related code** — Search by screen/feature name/error message with `Grep`/`Glob`. Use `Explore` agent for broader investigation if needed
2. **Estimate cause** — Trace from error messages/stack traces. State confidence level (certain / likely / needs investigation)
3. **Check impact scope** — Check other features using same code, related tests
4. **Attempt reproduction** — Only if reproducible via tests or commands. Do not create tests

## Phase 3: Duplicate Check

1. Search existing Issues with `gh issue list --state open --search "<bug-summary>"`
2. If similar Issue found -> report to user, confirm whether to comment on existing or create new

## Phase 4: Preview and Output Destination

1. Create draft from gathered info and investigation results
2. Show preview to user (technical content + plain explanation)
3. Apply revisions if any
4. Confirm output destination with `AskUserQuestion`:
   - **GitHub Issue** (recommended)
   - **Local MD file**

## Phase 5: Output

#### GitHub Issue
- Create with `gh issue create`, title `bug: <summary>`, label `bug`
- Use template from `templates/issue.md`
- Report URL to user

#### Local MD
- Generate `bug-report-<summary-kebab-case>.md`
- Report path to user

## Severity Criteria

| Severity | Criteria | Example |
|----------|----------|---------|
| Critical | Service down, data loss, security risk | Can't log in, data deleted |
| High | Major feature unusable, no workaround | Search broken, can't save |
| Medium | Feature works but inconvenient, workaround exists | Display broken, slow |
| Low | Minor, no usage impact | Typo, color mismatch |

## Rules

- **No technical jargon** in interviews. Mirror user's own terms only
- **Minimal questions**. Don't ask what can be inferred
- Code investigation must **verify against actual code**, not guess
- State confidence level honestly for cause estimates
- **Always preview and get user approval** before creating Issue
- Do not modify code. Output is Issue only
- If fix is needed, suggest `/bug-fix #<issue-number>`