fixing-code
Fix and Diagnose Code
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.
Parse $ARGUMENTS:
diagnoseorinvestigate→ hard-bug workflow: feedback loop, repro, hypotheses, probes, regression test.team→ parallel analysis agents challenge root causes before fixes.
Use TaskCreate / TaskUpdate to track:
- Run validation or build a repro
- Analyze root causes
- Fix one issue at a time
- Verify after each fix
- Final verification and cleanup
Phase 1: Feedback Loop First
For lint/build/test failures, run validation:
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 - Web:
bunx eslint "**/*.js" 2>&1 | head -100 && bunx stylelint "**/*.css" 2>&1 | head -100
If all checks pass: report All checks pass and stop.
For reported bugs or diagnose/investigate, build a fast, deterministic pass/fail signal before editing. Try, in order:
- Failing unit/integration/e2e test at the right seam.
- CLI or HTTP script with fixture input.
- Playwright/headless browser script for UI bugs.
- Replay captured payload/log/trace.
- Throwaway harness around the smallest real code path.
- Property/fuzz loop for intermittent wrong output.
git bisect runharness for regressions.- Human-in-the-loop script if manual steps are unavoidable.
Do not proceed to fixes until the loop reproduces the user's symptom. If no loop is possible, stop and ask for access, logs, HAR/core dump, screen recording with timestamps, or permission to add temporary instrumentation.
Phase 2: Analyze Root Causes
Read the failing output and relevant files. If claude-mem is available, search for prior gotchas on failing files.
For straightforward check failures, catalog every distinct issue:
- file:line
- exact error/test failure
- tool that reported it
- priority: critical / important / minor
For hard bugs, generate 3–5 ranked falsifiable hypotheses before testing any one of them:
If <cause> is true, then <probe/change> will make <specific symptom> disappear or change.
Avoid testing only the first plausible hypothesis; that anchors the fix on guesswork.
If team is set, spawn relevant language QA/test/implementation agents in parallel. Agents analyze only; they must not edit. Ask them for root cause, evidence, suggested fix, priority, and confidence.
Phase 3: Instrument Carefully
Probe one hypothesis at a time.
- Prefer debugger/REPL inspection when available.
- Otherwise add targeted logs at boundaries that distinguish hypotheses.
- Tag temporary logs with a unique prefix like
[DEBUG-a4f2]. - For performance regressions: measure baseline first, then bisect/profile. Do not fix from guesswork.
Phase 4: Fix One Issue at a Time
For each issue, in priority order:
- Read the exact code path.
- Apply the smallest root-cause fix.
- Add or update a regression test at the correct seam when possible.
- Run the narrow check.
- Run broader lint/test before moving on.
If the only available test seam is too shallow, say so. Do not write a fake-confidence test that only proves a helper works while the real bug path stays uncovered.
If a fix causes new failures, revert or adjust it before touching the next issue.
Phase 5: Final Verification and Cleanup
Required before done:
- Original repro no longer reproduces.
- Regression test passes, or missing test seam is explicitly reported.
- Full validation passes.
- All
[DEBUG-...]probes are removed. - Throwaway harnesses are deleted or clearly moved into test fixtures.
Run:
make lint && make test
Or language equivalents.
Loop back to Phase 2 if anything still fails.
Output
FIX COMPLETE
============
Mode: standard | diagnose | team | diagnose+team
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 the exact artifact/access needed. Do not pretend clean.
More from alexei-led/cc-thingz
improving-tests
Improve test design and coverage, including TDD/red-green-refactor guidance. Use when user says "improve tests", "refactor tests", "test coverage", "combine tests", "table-driven", "parametrize", "test.each", "test-first", "TDD", "red-green-refactor", or wants to remove test waste.
4debating-ideas
Dialectic thinking — spawn thesis and antithesis agents to stress-test ideas, then synthesize and verify against code. Use when user says "debate", "argue both sides", "devil's advocate", "stress test this idea", "pros and cons of approach", or wants rigorous evaluation of a design decision.
3learning-patterns
Extract learnings and generate project-specific customizations (CLAUDE.md, commands, skills, hooks). Use when user says "learn", "extract learnings", "what did we learn", "save learnings", "adapt config", or wants to improve Claude Code based on conversation patterns.
3documenting-code
Update project documentation based on recent changes. Use when user says "update docs", "document", "add documentation", "update readme", "write docs", or wants to improve documentation.
3committing-code
Smart git commits with logical grouping. Use when user says "commit", "commit changes", "save changes", "create commit", "bundle commits", "git commit", or wants to commit their work.
3testing-e2e
E2E testing with Playwright — the primary user-facing skill for writing, running, and generating browser tests. Use when user asks to "write e2e tests", "test this page", "run playwright tests", "generate browser tests", "check accessibility", or "visual regression". Supports TypeScript tests and Go/HTMX web applications.
3