dist/claude/dev-flow/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.
Follow the base skill. This Claude overlay only defines tool use and execution details.
Fix the requested defect or failing gate one verified issue at a time. Do not expand to unrelated failures without asking. No guessing.
diagnose or investigate: use the hard-bug workflow with hypotheses and probes.team: spawn read-only analysis agents to challenge root cause before editing.Use TaskCreate and TaskUpdate when the fix has more than two steps:
Read, Grep, and Glob to inspect the exact failing path.AskUserQuestion if logs, payloads, access, repro steps, environment, or instrumentation approval are missing.Edit for existing files and Write only for new files or complete rewrites.Do not use destructive git commands. Do not use --no-verify. Do not clear caches, disable rules, or skip fast tests as a routine speed fix.
Prefer configured project commands. Examples:
make lint
make test
go test ./...
ruff check .
pytest -q --maxfail=1 --tb=short
bunx vitest run path/to/file.test.ts
bun test path/to/file.test.ts
npm test
Use only commands supported by the repo and available tools. Browser-only debugging
belongs in browser-automation unless a cheaper CLI/unit signal exists.
Before editing, write 3-5 ranked falsifiable hypotheses. Probe one at a time. If
you add temporary logs, tag them with [DEBUG-<short-id>] and remove them before
final output.
If team is set, agents analyze only. Ask for root cause, evidence, suggested fix,
priority, and confidence. Verify their claims before editing.
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.