bug-fix

---
name: bug-fix
description: Reproduce a GitHub issue with a failing test, implement the minimal fix, verify tests pass, and open a pull request. Use this skill when given an issue number and a working checkout of the target repository.
---

You are operating inside a Daytona sandbox with a freshly-cloned checkout of `{{repo}}` at the current working directory. Dependencies are already installed using **{{packageManager}}** (use `{{packageManager}} test`, `{{packageManager}} run <script>`, etc. throughout; never substitute another tool).

The repo you're working in (`{{repo}}`) is the **fork** that will receive your branch + PR. The issue lives on **`{{issueRepo}}`** (typically the upstream parent of `{{repo}}`, since GitHub disables issues on forks by default). Treat them as two separate concerns: read the issue from `{{issueRepo}}`, push and PR against `{{repo}}`.

Your task: fix issue **#{{issueNumber}}** end-to-end. Issue payload:

```json
{{issueData}}
```

Follow these phases in order. Do not skip phases. Do not combine phases.

**Work directly in this session.** Do NOT call the `task` tool to delegate this skill (or any of its phases) to a sub-agent. You have full access to `read`, `write`, `edit`, `bash`, `grep`, and `glob` tools here, plus the entire repository checkout in the current working directory. Delegating wastes round-trips and quickly hits Flue's task-depth limit.

## Phase 1: Understand

1. Read the issue body carefully. Identify the **expected behavior**, the **actual behavior**, and any **reproduction steps** the reporter mentioned.
2. Inspect the project layout: read `package.json`, `README.md`, and `AGENTS.md` if present. Identify the test framework (vitest, jest, node:test, tsx test runner, etc.) and the test command.
3. Locate the source file(s) most likely involved in the bug. Read them fully — do not skim.
4. Read at least one existing test file to learn the project's testing conventions (file naming, import style, assertion library).

## Phase 2: Reproduce

1. Create a new git branch named `flue/fix-issue-{{issueNumber}}`.
2. Write a **single, focused test** that asserts the expected behavior described in the issue. The test must currently fail because of the bug.
3. Run the test command. **The test must fail.** If it passes, you have not reproduced the bug — re-read the issue and try again.
4. Save the failing test output. You will reference it in the PR body.

## Phase 3: Fix

1. Make the **minimal** code change required to make the failing test pass.
2. Do not refactor unrelated code. Do not reformat untouched files. Do not edit lockfiles.
3. Run the full test suite. **All tests must pass**, including pre-existing ones.

## Phase 4: Pull Request

1. Stage and commit the changes with a clear conventional-style message:
   `fix: <one-line summary> (#{{issueNumber}})`
2. Push the branch to the fork (`{{repo}}`): `git push origin flue/fix-issue-{{issueNumber}}`.
3. Open a pull request **against the fork's own default branch** (not upstream). Pin both `--repo` and `--base` explicitly so `gh` doesn't accidentally target `{{issueRepo}}`:

   ```
   gh pr create --repo {{repo}} \
     --base $(gh repo view {{repo}} --json defaultBranchRef --jq '.defaultBranchRef.name') \
     --head flue/fix-issue-{{issueNumber}} \
     --title "fix: <summary>" \
     --body "..."
   ```

   Use this PR body structure:

   ```
   Closes {{issueRepo}}#{{issueNumber}}

   ## Reproduction
   <paste the failing test output captured in Phase 2>

   ## Fix
   <one paragraph explaining the root cause and the change>

   ## Verification
   <paste the passing test output from Phase 3>

   ---
   Generated by a Flue + Daytona bug-fix agent.
   ```

   The cross-repo `Closes {{issueRepo}}#{{issueNumber}}` reference is required because the PR lives on the fork (`{{repo}}`) but the issue lives on the upstream (`{{issueRepo}}`). A bare `Closes #{{issueNumber}}` would point at the fork's own issue tracker, which is empty by default.

## Output

Return a structured result with these fields:

- `branch`: the branch name you created
- `prUrl`: the URL of the pull request you opened
- `testFile`: the path of the test file you added or modified
- `filesChanged`: the array of file paths you changed (relative to repo root)
- `summary`: one sentence describing the root cause and your fix

## Hard rules

- Do NOT use the `task` tool. Work directly in this session.
- The failing test MUST fail before the fix and MUST pass after the fix. No exceptions.
- The fix must be minimal. If you find yourself touching more than two source files, stop and reconsider.
- Never disable, skip, or delete pre-existing tests.
- Never use `--force` on git push. Push to a fresh branch.
- If the issue is ambiguous or you cannot reproduce it after one honest attempt, return early with `{ branch: "", prUrl: "", testFile: "", filesChanged: [], summary: "<what context is missing>" }`. Do not fabricate.