$npx -y skills add alexei-led/cc-thingz --skill fixing-codeFollow the base skill. This Claude overlay only defines tool use and execution details.
| 1 | # Fix and Diagnose Code |
| 2 | |
| 3 | Follow the base skill. This Claude overlay only defines tool use and execution details. |
| 4 | |
| 5 | Fix the requested defect or failing gate one verified issue at a time. Do not expand |
| 6 | to unrelated failures without asking. No guessing. |
| 7 | |
| 8 | ## Arguments |
| 9 | |
| 10 | - `diagnose` or `investigate`: use the hard-bug workflow with hypotheses and probes. |
| 11 | - `team`: spawn read-only analysis agents to challenge root cause before editing. |
| 12 | |
| 13 | Use `TaskCreate` and `TaskUpdate` when the fix has more than two steps: |
| 14 | |
| 15 | 1. Reproduce or run the failing gate. |
| 16 | 2. Read the failing path. |
| 17 | 3. Diagnose root cause. |
| 18 | 4. Patch one issue. |
| 19 | 5. Verify narrow and broad checks. |
| 20 | 6. Clean up probes. |
| 21 | |
| 22 | ## Tool order |
| 23 | |
| 24 | 1. Run the smallest known failing command or project gate. Prefer focused tests, lint, or typecheck while editing and the broader project gate before final output. |
| 25 | 2. Use `Read`, `Grep`, and `Glob` to inspect the exact failing path. |
| 26 | 3. Use `AskUserQuestion` if logs, payloads, access, repro steps, environment, or instrumentation approval are missing. |
| 27 | 4. Use `Edit` for existing files and `Write` only for new files or complete rewrites. |
| 28 | 5. Run the narrow repro after each patch. |
| 29 | 6. Run the relevant broader check before final output. |
| 30 | |
| 31 | 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. |
| 32 | |
| 33 | ## Repro commands |
| 34 | |
| 35 | Prefer configured project commands. Examples: |
| 36 | |
| 37 | ```bash |
| 38 | make lint |
| 39 | make test |
| 40 | go test ./... |
| 41 | ruff check . |
| 42 | pytest -q --maxfail=1 --tb=short |
| 43 | bunx vitest run path/to/file.test.ts |
| 44 | bun test path/to/file.test.ts |
| 45 | npm test |
| 46 | ``` |
| 47 | |
| 48 | Use only commands supported by the repo and available tools. Browser-only debugging |
| 49 | belongs in `browser-automation` unless a cheaper CLI/unit signal exists. |
| 50 | |
| 51 | ## Hard-bug mode |
| 52 | |
| 53 | Before editing, write 3-5 ranked falsifiable hypotheses. Probe one at a time. If |
| 54 | you add temporary logs, tag them with `[DEBUG-<short-id>]` and remove them before |
| 55 | final output. |
| 56 | |
| 57 | If `team` is set, agents analyze only. Ask for root cause, evidence, suggested fix, |
| 58 | priority, and confidence. Verify their claims before editing. |
| 59 | |
| 60 | ## Scope control |
| 61 | |
| 62 | - If all checks pass and no bug is reproduced, report that and ask for a repro artifact. |
| 63 | - If the failing gate contains unrelated failures, fix the requested issue first and ask before expanding. |
| 64 | - If the only test seam is too shallow, say so; do not create fake-confidence tests. |
| 65 | - If a patch causes new failures, diagnose that failure before continuing. |