dist/gemini/skills/fixing-code/SKILL.md
Fix code defects with a reproducible feedback loop, root-cause diagnosis, minimal patch, regression test, and clean verification. Use when debugging, diagnosing, or resolving lint/test/build failures. NOT for behavior-preserving refactors (use refactoring-code), test-suite cleanup without a production bug (use improving-tests), or code review findings without fixes (use reviewing-code).
npx skillsauth add alexei-led/claude-code-config fixing-codeInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Fix the requested defect or failing gate one verified issue at a time. Do not patch from guesses. Do not expand to unrelated failures without asking.
Never use destructive git commands such as hard reset, clean, force push, or checkout-overwrites as a fix.
Detect capability from tools:
Use an interactive question tool when available for missing logs, payloads, repro steps, environment details, access, or permission for temporary instrumentation.
Do not use this for:
refactoring-codeimproving-testsreviewing-codebrowser-automationLoad the matching reference for the language under repair:
references/csharp.mdreferences/go.mdreferences/java-kotlin.mdreferences/python.mdreferences/rust.mdreferences/typescript.mdUnsupported language: use the general workflow in this file only.
For lint/build/test failures, run the fastest reliable failing signal first.
Prefer a focused test, package, or file command while editing; use make lint,
make test, or the broader project gate before final output. Use configured
language tools from the nearest project root.
For reported bugs, build the fastest reliable pass/fail signal:
If no repro is possible, stop and ask for the missing artifact. Do not proceed to a speculative fix.
Tests, lint, typecheck, format, vet, and build commands are feedback loops. Every second is paid on each agent iteration.
Record each issue as file:line, exact symptom, reporting tool, and priority.
Trace from the failing boundary toward the first bad state, contract mismatch, or
missing side effect.
For hard bugs, write 3-5 ranked falsifiable hypotheses:
If <cause> is true, then <probe/change> will make <specific symptom> change in <specific way>.
Use graph tools only when available and when they reduce search space:
For each issue:
For test or lint fixes, prefer targeted fast commands in the edit loop. Keep expensive reporting commands for coverage-specific work or final gate parity, not every patch attempt.
Do not write helper-level tests that miss the user-visible bug path. If the only available seam is too shallow, report the risk.
If a fix causes new failures, diagnose that failure before touching the next issue.
Before done:
Engineer:
FIX COMPLETE
============
Mode: standard | diagnose | team | diagnose+team
Issues found: X
Fixed: Y
Remaining: Z
Status: CLEAN | NEEDS ATTENTION
Root cause:
- <verified cause and evidence>
Changes:
- path:line — fix
Verification:
- <command> — pass/fail/skipped with reason
Reviewer or blocked:
## Proposed Changes | BLOCKED
Root cause:
- <verified cause and evidence, or unknown because blocked>
Blocker:
- <missing artifact, access, tool, or permission>
### Change 1: <brief description>
File: `path/to/file`
Action: CREATE | MODIFY | DELETE
Code: <complete code block or changed region with enough context>
Rationale: <why this fixes the root cause>
Do not claim clean without a clean check or an explicit skipped-check reason.
tools
Use when planning, executing, checkpointing, finishing, or inspecting lightweight spec-driven work. Runs one task at a time using `.spec/` markdown files and the bundled `specctl` helper. NOT for broad product discovery beyond a short requirement interview. NOT for generic implementation planning that does not read or write `.spec/` files.
development
Simple web development with HTML, CSS, JS, and HTMX. Use when working with .html, .css, or .htmx files, web templates, stylesheets, or vanilla JS scripts. NOT for React/Vue/Angular (use writing-typescript) or Node.js backends.
tools
Idiomatic TypeScript development. Use when writing TypeScript code, Node.js services, React apps, or TypeScript design advice. Emphasizes strict typing, boundary validation, composition, fast feedback, behavior tests, and project-configured tooling. NOT for Go, Python, Rust, plain HTML/CSS/JS, or server-rendered templates (use writing-web).
tools
Idiomatic shell development for POSIX sh, Bash, Zsh, Fish, hooks, CI shell steps, and scriptable CLI glue. Use when writing or changing `.sh`, `.bash`, `.zsh`, `.fish`, `.bats`, shell functions, shell pipelines, CI `run:` shell bodies, or command-runner recipes. Emphasizes portability, quoting, safe filesystem/process handling, non-TUI CLI tools, ShellCheck, shfmt, Bats, and ShellSpec. NOT for Python, Rust, TypeScript, Go, web code, or GitHub Actions workflow/job/permissions semantics; use operating-infra.