# Bug Fix Wt En

> Bug investigation, fix, regression test, and PR creation in an isolated git worktree.

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

---


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

# bug-fix-wt-en

Worktree-isolated version of `bug-fix`. Fixes bugs without affecting the main working tree.

## Prerequisites

- Claude Code environment
- `git`, `gh` CLI

## Arguments

- **Issue number** (e.g., `/bug-fix-wt-en #42`): Fetch bug report from GitHub Issue
- **Issue URL** (e.g., `/bug-fix-wt-en https://github.com/owner/repo/issues/42`): Same as above
- **Text** (e.g., `/bug-fix-wt-en 500 error on login`): Use text as bug report
- **No arguments**: Interview the user about symptoms

## Phase 1: Bug Report Organization and Worktree Creation

1. Retrieve bug report from arguments
   - Issue: Read body, comments, and labels via `gh issue view`
   - Text: Use as bug report
   - No arguments: Interview the user
2. Organize the following (confirm missing info with user):
   - **Symptoms**: What is happening
   - **Expected behavior**: What should happen
   - **Reproduction steps**: How to reproduce
   - **Environment**: Browser, OS, environment (production/staging/local)
   - **Frequency**: Always / sometimes / under specific conditions
3. Record the current branch as the base branch (PR merge target)
   - Run `git branch --show-current` and display to user: "Base branch: <branch-name>"
   - Retain this name until PR creation in Phase 4
4. Determine the working branch name
   - Issue: `fix/#<issue-number>` (e.g., `fix/#42`)
   - Text / no arguments: `fix/<bug-summary>` (e.g., `fix/login-500-error`)
5. **Create git worktree** (see `references/worktree-setup.md`)
6. Create tasks with TaskCreate

## Phase 2: Root Cause Investigation

**IMPORTANT: All operations from Phase 2 onward must be inside the worktree directory.**

1. **Reproduce** — Follow reproduction steps. If not reproducible, ask user for more info
2. **Identify impact scope** — Search related code with `Explore` agent or `Grep`/`Glob`. Check related tests
3. **Identify root cause** — Pinpoint the root cause with code flow evidence. Report cause and fix plan to user for agreement

## Phase 3: Fix Cycle

#### 3-1: Create Regression Test
- **Before fixing**, create a test that reproduces the bug and confirm it fails

#### 3-2: Fix
- Fix the bug with minimal changes

#### 3-3: Verify
- Confirm regression test + all existing tests pass

#### 3-4: Review
- Review the fix with the `review` agent
- Include worktree path in prompt

#### 3-5: Improvement Cycle
- If review issues found -> fix -> re-review -> repeat until no issues

#### 3-6: Format & Lint
- **Run format/lint inside the worktree directory.** Skip if no settings found

#### 3-7: Commit
- **Run `git add` / `git commit` inside the worktree directory**
- Follow commit message conventions in CLAUDE.md

## Phase 4: Pull Request

1. **Run `git push -u origin <working-branch>` inside the worktree directory**
2. Create PR with `gh pr create --base <base-branch>`
   - **Use the base branch recorded in Phase 1. Never fall back to `main` or `master`.**
   - If unclear, check fork point with `git log --oneline --graph HEAD...main`
   - With Issue: Include Issue number in title, then link via `gh pr edit <PR#> --add-issue <Issue URL>` after creation (do not use Closes keyword)
   - PR body: Bug symptoms, cause, fix summary + manual checklist (see `templates/pr-checklist.md`)
3. Report fix summary and **worktree path** to user

Report example:
```
## Done
- PR: <URL>
- Worktree: <path> (run `git worktree remove <path>` after verification)
```

## Rules

- Never fix by guessing. Identify the root cause before fixing
- Always write a regression test before fixing (test fails -> fix -> test passes)
- Keep fixes minimal. Never mix unrelated refactoring
- Always report cause and fix plan to user for agreement
- Always fix review issues at severity levels. For lower severity, fix only if clear benefit
- Track progress with TaskCreate/TaskUpdate
- **All git/file operations must be inside the worktree directory. Never modify the main working tree.**