Claude-Skills focused-fix

install
source · Clone the upstream repo
git clone https://github.com/borghei/Claude-Skills
Claude Code · Install into ~/.claude/skills/
T=$(mktemp -d) && git clone --depth=1 https://github.com/borghei/Claude-Skills "$T" && mkdir -p ~/.claude/skills && cp -r "$T/engineering/focused-fix" ~/.claude/skills/borghei-claude-skills-focused-fix && rm -rf "$T"
manifest: engineering/focused-fix/SKILL.md
source content

Focused Fix

Category: Engineering Domain: Debugging & Maintenance

Overview

The Focused Fix skill enforces a disciplined minimal-change approach to bug fixing. Instead of refactoring or improving code during a bugfix, it identifies the smallest possible change set that resolves the issue. This reduces risk, simplifies code review, and prevents scope creep.

Quick Start

# Analyze a bug description to identify minimal change scope
python scripts/change_scope_analyzer.py --bug "Login fails when email has + character" --path ./src

# Analyze with JSON output
python scripts/change_scope_analyzer.py --bug "API returns 500 on empty array input" --path ./src --format json

# Analyze with specific file extensions
python scripts/change_scope_analyzer.py --bug "CSS overflow on mobile" --path ./src --extensions .css .scss .html

Tools Overview

ToolPurposeKey Flags
change_scope_analyzer.py
Identify minimal files to change for a bugfix
--bug
,
--path
,
--extensions
,
--format

change_scope_analyzer.py

Analyzes a bug description against a codebase to identify:

  • Files most likely related to the bug (keyword matching, import tracing)
  • Estimated change scope (number of files, lines)
  • Risk assessment for the change
  • Recommended fix approach (minimal vs. structural)

Workflows

Focused Bugfix Workflow

  1. Write a clear bug description
  2. Run
    change_scope_analyzer.py
    to identify scope
  3. Review the recommended files and approach
  4. Make ONLY the changes needed to fix the bug
  5. Verify no unrelated changes leaked in
  6. Submit PR with focused change set

Scope Validation

  1. After making changes, re-run analyzer
  2. Compare actual changes against recommended scope
  3. Flag any out-of-scope modifications for separate PRs

Reference Documentation

Common Patterns

Do

  • Fix the exact bug reported
  • Add a regression test for the fix
  • Document why the fix works in the commit message
  • Keep the diff as small as possible

Don't

  • Refactor surrounding code during a bugfix
  • Fix "nearby" issues in the same PR
  • Change formatting or style in touched files
  • Add features disguised as bugfixes