fix-issue

Fix Issue

Implements a fix following how a senior engineer actually thinks: understand first, code second, verify the problem is gone — not just the tests pass.

Input

• Analysis from analyze-issue, or the issue itself
• A feature branch (not main/master/develop/staging)

Branch check

Before touching any code, check the current branch:

git branch --show-current

If it's a protected branch (main, master, develop, staging), create a new one off it, named <type>/<issue-number>-<func-name> — <type> matches the commit convention below (feat, fix, refactor, test, chore, docs).

# Preferred — creates the branch and records the current branch as its base,
# so create-mr can later target the MR back to the right branch
RESOLVE="$HOME/.claude/skills/gitlab-config/scripts/auto_resolve_issue.py"
python $RESOLVE create-branch <issue_iid> "<func name>" <type>
# e.g. python $RESOLVE create-branch 123 "add login" feat  ->  feat/123-add-login

# Fallback (manual)
BASE=$(git branch --show-current)
git checkout -b <type>/<issue-number>-<func-name>
git config --local branch.<type>/<issue-number>-<func-name>.base "$BASE"

Already on a non-protected feature branch? Keep working on it — don't create a nested branch.

The loop

Phase 1: Understand before touching anything

Read the relevant code before writing a single line. You cannot fix what you don't understand.

• Find the code involved: grep, file search, follow the call chain
• Understand why the current behavior happens — confirm the root cause from the analysis
• If the root cause turns out to be different from the analysis, stop and update the analysis

Phase 2: Plan the minimal change

Write a short plan (bullet points) before coding:

• What exactly will you change and why
• What you will NOT touch (scope boundary)
• What could go wrong with your approach

The plan should describe the fix to the root cause — not a workaround or a patch over the symptom. If you're writing a workaround, say so explicitly and explain why.