plugins/dev-workflow/skills-codex/fixing-code/SKILL.md
Fix code problems with disciplined diagnosis — run checks, build a repro for bugs, rank falsifiable hypotheses, fix one issue at a time, and verify until clean. Use when fixing, debugging, diagnosing, or resolving lint/test/build failures.
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 until clean. For hard bugs, diagnose before editing. No guessing. Confirm before any destructive command; never use git reset --hard, git clean, or force push as a fix.
For lint/build/test failures, run validation first:
make lint 2>&1 | head -150
make test 2>&1 | head -150
No Makefile? Detect language:
# Go
golangci-lint run ./... 2>&1 | head -150
go test -race ./... 2>&1 | head -150
# Python
ruff check . 2>&1 | head -150
pytest --tb=short 2>&1 | head -150
# TypeScript
bun lint 2>&1 | head -150
bun test 2>&1 | head -150
If all checks pass, report All checks pass and stop.
For reported bugs, first build a fast pass/fail signal that reproduces the user's symptom:
git bisect run harness for regressions.Do not proceed to fixes until the loop reproduces the symptom. If no loop is possible, stop and ask for access, logs, captured payloads, or permission to add temporary instrumentation.
Catalog every distinct issue:
For hard bugs, write 3–5 ranked falsifiable hypotheses before testing one:
If <cause> is true, then <probe/change> will make <specific symptom> disappear or change.
Read files and tool output. Do not guess at code content.
Probe one hypothesis at a time.
[DEBUG-a4f2].For each issue, in priority order:
If the only available test seam is too shallow, report that. Do not write fake-confidence tests against helpers while the real bug path stays uncovered.
If a fix causes new failures, revert or adjust it before touching the next issue.
Required before done:
[DEBUG-...] probes are removed.Run:
make lint && make test
Or language equivalents. Loop back to root-cause analysis if anything still fails.
FIX COMPLETE
============
Mode: standard | diagnose
Issues found: X
Fixed: Y
Remaining: Z
Status: CLEAN | NEEDS ATTENTION
Root cause:
- <short verified cause>
Changes:
- file:line — fix
Verification:
- <command> — pass/fail
If unresolved, state the blocker and exact artifact/access needed. Do not pretend clean.
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.