alexei-led/fixing-code
src/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).
$ install --global
skillsauthnpx skillsauth add alexei-led/claude-code-config fixing-codeInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
Security Scan Results
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
3
Scanners Passed
9
Scanners in report
Clean
TrivyContainer and dependency vulnerability scanner
95%
Clean
SemgrepStatic code analysis for vulnerabilities
95%
Clean
mcp-scan (Snyk)Model Context Protocol security validation
95%
Skipped
Snyk (dep)Open source security scanning
50%
Skipped
Socket.devSupply chain security analysis
50%
Skipped
VirusTotalMulti-engine malware detection
50%
Skipped
CrowdStrikeAdvanced threat intelligence
50%
Skipped
OSV-ScannerOpen Source Vulnerability database check
50%
Skipped
OWASP Dep-Check
50%
Last scanned: Jun 5, 2026, 3:40 AM9.3s3 files scanned
SKILL.md
- name:
- fixing-code
Fix and Diagnose Code
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.
Role-gated action
Detect capability from tools:
- Write-capable role: reproduce, diagnose, patch, test, and clean up.
- Read-only role: diagnose from files and supplied output, then emit the fix in the Proposed Changes contract. Apply nothing; run nothing.
- Missing key tool or permission: stop with Blocked and ask for the exact artifact, access, or approval needed.
Use an interactive question tool when available for missing logs, payloads, repro steps, environment details, access, or permission for temporary instrumentation.
Route elsewhere
Do not use this for:
- pure refactors with unchanged behavior →
refactoring-code - test-only improvement or coverage work →
improving-tests - review-only findings →
reviewing-code - broad architecture redesign → architecture skills
- browser-only UI investigation without a cheaper signal →
browser-automation
Reproduce first
For lint/build/test failures, run the relevant project gate first. Prefer make lint and make test when present; otherwise use configured language tools from
the nearest project root.
For reported bugs, build the fastest reliable pass/fail signal:
- Existing failing test or new regression test at the behavior seam.
- CLI, HTTP, or browser script with fixture input.
- Replay captured payload, log, trace, or production-like case.
- Small harness around the real code path.
- Property, fuzz, race, or bisect harness when supported and safe.
If no repro is possible, stop and ask for the missing artifact. Do not proceed to a speculative fix.
Diagnose with evidence
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:
- GitNexus: query the error text or symptom; use context for suspect symbols; use impact before changing widely called code; use detect-changes after a fix to see affected flows.
- codegraph: check freshness first; if fresh, inspect callers, callees, references, and blast radius.
- Stale graph indexes are not evidence. Refresh if allowed; otherwise report the gap and use search, source reads, LSP, and tests.
Patch narrowly
For each issue:
- Read the exact code path.
- Change the smallest root cause, not adjacent style or structure.
- Add or update a regression test when a real seam exists.
- Run the narrow repro.
- Run broader lint/test before moving to another issue.
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.
Cleanup and verify
Before done:
- Original repro no longer fails.
- Regression test passes, or the missing seam is reported.
- Full relevant validation passes, or skipped checks have exact reasons.
- Temporary logs, probes, harnesses, and debug flags are removed or promoted to real tests.
- New failures are diagnosed before any second patch.
Output
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.
Related Skills
alexei-led/writing-shell
tools
VerifiedTrustedCommunity
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, or command-runner recipes. Emphasizes portability, quoting, safe filesystem/process handling, non-TUI CLI tools, ShellCheck, shfmt, Bats, and ShellSpec. NOT for Python, TypeScript, Go, web code, or infrastructure operations.
33SKILL.mdUpdated Jun 5, 2026
alexei-led/spec-flow
tools
VerifiedTrustedCommunity
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.
33SKILL.mdUpdated Jun 5, 2026
alexei-led/operating-infra
testing
VerifiedTrustedCommunity
Author, inspect, troubleshoot, and review infrastructure across IaC, Kubernetes, cloud resources, containers, CI/CD, and Linux hosts. Use when changing Terraform/OpenTofu, Kubernetes, Helm, Kustomize, Dockerfiles, GitHub Actions, AWS, GCP, Cloud Run, BigQuery, IAM, logs, instances, or service health. NOT for deploy/apply/rollback workflows (see deploying-infra). NOT for shell scripts or generic command pipelines (see writing-shell).
33SKILL.mdUpdated Jun 5, 2026
alexei-led/configuring-git-hygiene
development
VerifiedTrustedCommunity
Configure safe git workflow hygiene: pre-commit/pre-push hooks, Gitleaks secret scanning, .gitignore rules, local git config, and guardrails. Use when setting up git hooks, gitleaks/git leaks, staged pre-commit checks, pre-push validation, core.hooksPath, .gitignore, or git config best practices. NOT for creating commits (use committing-code), cleaning branches/worktrees (use cleanup-git), or creating worktrees (use using-git-worktrees).
33SKILL.mdUpdated Jun 5, 2026