[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M77KBJ79WH7GRBEG0ATSRC5M":3,"skill-same:01M77KBJ79WH7GRBEG0ATSRC5M":75},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":19,"linkOnly":20,"markdownContent":21,"markdownBody":22,"frontMatter":23,"refName":29,"commitSha":30,"skillDirectory":31,"forksCount":32,"repositoryHtmlUrl":33,"repositoryHomepageUrl":6,"ownerHtmlUrl":34,"ownerBlogUrl":35,"ownerDescription":36,"updatedAt":37,"install":38,"resources":50},"01M77KBJ79WH7GRBEG0ATSRC5M","debug",null,"Debug and diagnose broken behavior via a disciplined six-phase loop: build feedback loop → reproduce → hypothesize → instrument → fix + regression test → cleanup. Use when: the user reports an OBSERVED FAILURE with no pre-existing reproduction, in any of three shapes: wrong or broken behavior ('diagnose this', 'debug this', 'why is X broken', 'X is throwing'), a performance regression ('this is slow'), or an intermittent or flaky failure, whether seen in the UI, logs, production, or a screenshot. Phase 1 builds the loop; no phase proceeds without a fast, deterministic signal. Skip when: the symptom is already a failing test with no reproduction gap. Cycle it directly. Skip when a captured profile, trace or heap snapshot is in hand and the failure does not reproduce (`\u002Fdebugging:analyze-profile`). Outputs: reproduction loop, root-cause hypothesis, regression test or documented seam gap, cleaned fix, post-mortem finding.","melodic-software\u002Fclaude-code-plugins","melodic-software","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F58273638?v=4","01M77JVQTXNGKCE4MDFY2BC936","Melodic Software","01M77JVQVN9QDWKAH6W03ANP76",30,"MIT","https:\u002F\u002Fgithub.com\u002Fmelodic-software\u002Fclaude-code-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fdebugging\u002Fskills\u002Fdebug\u002FSKILL.md",[],[],"2026-11-15 14:19:17",false,"---\ndescription: \"Debug and diagnose broken behavior via a disciplined six-phase loop: build feedback loop → reproduce → hypothesize → instrument → fix + regression test → cleanup. Use when: the user reports an OBSERVED FAILURE with no pre-existing reproduction, in any of three shapes: wrong or broken behavior ('diagnose this', 'debug this', 'why is X broken', 'X is throwing'), a performance regression ('this is slow'), or an intermittent or flaky failure, whether seen in the UI, logs, production, or a screenshot. Phase 1 builds the loop; no phase proceeds without a fast, deterministic signal. Skip when: the symptom is already a failing test with no reproduction gap. Cycle it directly. Skip when a captured profile, trace or heap snapshot is in hand and the failure does not reproduce (`\u002Fdebugging:analyze-profile`). Outputs: reproduction loop, root-cause hypothesis, regression test or documented seam gap, cleaned fix, post-mortem finding.\"\nargument-hint: \"[--unattended] [bug description or observation]\"\nuser-invocable: true\ndisable-model-invocation: false\nmetadata:\n  workflow-stage: implement\n  summary: Diagnose broken behavior. Reproduce, hypothesize, instrument, fix with regression test\n---\n\n**Arguments.** `[--unattended] [bug description or observation]`. e.g., \u002Fdebugging:debug photo uploads over 20 MB fail with a 502\n\n## Repository context. Gather first\n\nCollect these with **individual** Bash calls, one command per call, never combined into a single\ninvocation:\n\n- Current branch, `git branch --show-current`\n- Recent commits, `git log --oneline -10`\n- Working tree status (empty = clean), `git status --porcelain | head -10`\n\nThe pipe is the bound and belongs in the command. A read-time cap (\"read only the first 10 entries\")\ncomes too late for whatever the command has already returned inline. What a result returns inline,\nand when it arrives as a saved file instead, is [Tools reference § Output\nlimits](https:\u002F\u002Fcode.claude.com\u002Fdocs\u002Fen\u002Ftools-reference#output-limits).\n\nTreat a failure (not a repository, git unavailable) as an unknown value and carry on. Keep these as\nseparate body Bash calls rather than pre-compute lines ([gather-block convention](https:\u002F\u002Fgithub.com\u002Fmelodic-software\u002Fclaude-code-plugins\u002Fblob\u002Fmain\u002Fdocs\u002Fconventions\u002Fgather-block\u002FREADME.md#the-pre-compute-block-runs-as-one-shell-invocation),\n\"The pre-compute block runs as one shell invocation\").\n\n## Variables\n\nArguments: `$ARGUMENTS`\n\n`--unattended`, anywhere in the arguments, is not part of the observation: it is the caller declaring that nobody is\npresent, which governs the `\u002Fdebug` offer under \"Routing\". Take it out before reading the rest.\n\n## Purpose\n\nThis skill turns a reported failure into a command that answers one question, \"is the bug still\nhere?\", and then uses that command as the judge for every later step. The six phases below each end\nin a gate. How well Phase 1 goes decides most of the outcome: with a quick, repeatable check that an\nagent can run unattended, Phases 3 to 5 become routine work; without one, every hypothesis is a\nguess. The usual way a debugging session goes wrong is starting on causes before any such check\nexists. Phase 1 and Phase 6 (the check, and the cleanup that removes what the run added) carry the\nweight; the three phases between them follow from the check.\n\nScope boundary: this skill starts from an **observed failure**: UI behaving wrong, a log line that should not appear, a performance regression, a screenshot of a bug, a production symptom. Its first job is to **construct** a reproduction loop. If the symptom is already a failing test with no reproduction gap, you do not need this skill. Cycle that test directly (reproduce → fix → retest → regression). What `\u002Fdebugging:debug` adds over a bare fix loop is a critical edge case: **if no correct test seam exists, that absence IS the finding**, filed as an architectural recommendation, not a forced test in the wrong place.\n\nRunning example. The phases below follow one case: a photo larger than 20 MB uploaded through the\nmobile API gets a 502 from the media service, while smaller photos upload normally.\n\n## Adapting to your environment (graceful degrade)\n\nThis skill is self-contained. Where a phase below names an adjacent capability, such as a test-investigation routine, a TDD helper, a headless-browser driver, an architecture-audit agent, an issue tracker, or an outcome-verifier, treat it as **optional**: *if your environment provides that capability (a skill, plugin, agent, or tool), invoke it; otherwise proceed with the inline guidance given here, which stands on its own.* Never block a phase because an adjacent tool is absent. Consumer-specific conventions (naming, module layout, banned APIs, work-notes location) come from your own project's `CLAUDE.md` and tool config. Read them; this skill does not assume them.\n\n## Secrets stay out of what you show\n\nAnything this skill puts in a reply, a work note or a commit is a place a secret can leak. The rule\nfor each kind of text:\n\n| Text | Rule |\n|---|---|\n| A loop script or harness you commit | It reads tokens and passwords from environment variables, so the file names the variable and never holds the value. |\n| A command line you show | Same: the variable name appears, the value does not. |\n| A capture (HAR file, log dump, replayed trace) | Assume it holds auth headers and session tokens. Show an excerpt of the lines where the failure appears, never the whole file. |\n| Any secret still left in what you show | Replace it with `\u003CREDACTED>` before the text leaves your hands. |\n\nIf the redacted excerpt is too thin to diagnose from, ask the user how to proceed; do not widen the\nexcerpt on your own.\n\n## Emit checklist\n\nFor any diagnostic run (Phases 1-6), track phase completion. A ready-to-fill checklist is bundled at `${CLAUDE_PLUGIN_ROOT}\u002Fskills\u002Fdebug\u002Ftemplates\u002Fchecklist.md`. If your project has a working-notes or scratch location, copy it there; otherwise track the six phases inline. Phase 4 is SKIPPED when Phase 2 repro conclusively verifies the Phase 3 hypothesis without instrumentation.\n\n## Phase 1: Build the reproduction loop\n\nWrite down what you are assuming about the failure first (for the running example: the 502 comes\nfrom our media service, not the CDN in front of it; staging fails the same way production does). Phase 3 ranks\nhypotheses against that list.\n\nMost of this skill's effort belongs here. The loop is done when one command returns pass or fail\nfor this bug, quickly, the same way each time, with no person needed to run it.\n\n### Picking a loop\n\nTry the rows roughly in table order. A lower row usually costs more to build or tells you less, so\nprefer the first row that can reach the failing code.\n\n| Rank | Loop | Choose it when | In the running example |\n|---|---|---|---|\n| 1 | A failing test (unit, integration or end-to-end) | some test seam already reaches the failing code | an integration test that posts a 25 MB JPEG and asserts a 201 |\n| 2 | A scripted HTTP call (curl or similar) | the failure shows at an endpoint of a dev server you can start | `curl` the upload endpoint with a 25 MB file and print the status code |\n| 3 | A CLI run on a fixture file | the code has a command-line entry point | run the thumbnailer CLI on `large.jpg` and diff its output against a known-good copy |\n| 4 | Browser automation run headless, through a Playwright-style driver if one is available | only the UI shows the failure | drive the web uploader and assert on the DOM, console and network panel |\n| 5 | A recorded input played back | a real request body or event stream can be saved | save one failing multipart request to disk and send it to the upload handler alone |\n| 6 | A disposable harness | starting the full stack takes minutes, but the failing module can be imported on its own | a scratch script imports the thumbnail module, swaps S3 for an in-memory store, and passes it `large.jpg` |\n| 7 | A randomized-input loop (property or fuzz) | the output is wrong only for some inputs | generate a thousand images of random size and format and keep the ones that fail |\n| 8 | An automated bisect | the bug has a history: an older release, data snapshot or dependency version where the upload still works | `check.sh` builds the checkout and exits 0 on a 201 for the 25 MB upload, 1 otherwise; `git bisect run .\u002Fcheck.sh` walks v3.2 to v3.4 with it |\n| 9 | A side-by-side run | two builds or two configurations should agree | send the same file through last week's build and this week's, then diff the results |\n| 10 | A human-driven script | a person has to click | see below |\n\nA human-driven loop is the fallback when nothing above works. Copy the bundled template at\n`${CLAUDE_PLUGIN_ROOT}\u002Fskills\u002Fdebug\u002Fscripts\u002Fhitl-loop.template.sh`, replace its example prompts with\nthe steps for this bug, and ask the **user** to run it in their own terminal: its interactive `read`\nprompts need a TTY that the Bash tool does not have. The script ends by printing a `=== results ===`\nblock of `NAME=value` lines; ask the user to paste that block back so each run reaches you in the\nsame shape.\n\nEvery answer the script collects with `ask` is printed in that results block and pasted into the\nsession, so ask only for what the user observes: yes or no, a number, copied error text. Never ask\nfor a password, token or other secret (see \"Secrets stay out of what you show\" above). Signing in\nstays an `instruct` step the user does on their own.\n\n### Loop-recursion hazard\n\nWhen the loop IS a test the suite\u002Frunner discovers and runs, watch for self-invocation: a test file that invokes the very runner (or pre-push lane) which re-discovers and re-runs it recurses until the box saturates. Each nested run re-triggers the test. The symptom reads as a *hang*, but it is fork-bombing, not a slow test. Guard with a re-entrancy sentinel: set an env marker before the inner run; a nested invocation that sees the marker exits early. Same pattern for any loop that shells out to a command which re-enters the loop.\n\n### Phase 1 exit check\n\nA loop that merely runs is not finished. Before leaving Phase 1, hold it to all three requirements\nbelow; each failing one has its own remedies.\n\n| Requirement | Met when | If not met |\n|---|---|---|\n| Speed | one run finishes in about 2 seconds; a 30-second loop is not acceptable | run only the one test, keep the server or fixtures alive between runs, skip start-up work the failing path does not touch |\n| One verdict | the same code gives the same verdict on every run; a loop that flips between runs tells you almost nothing | stub the network, give each run a fresh directory, seed the random generator, freeze the clock |\n| Precision | it goes red on the reported symptom and on nothing else | assert on the 502 from the upload call itself, not on \"the script exited non-zero\" |\n\nPer-ecosystem timing-injection patterns (and other I\u002FO-seam abstractions) live in the bundled reference at `${CLAUDE_PLUGIN_ROOT}\u002Fskills\u002Fdebug\u002Freference\u002Fecosystem-debugging.md`. See the `timing-injection` row for your stack. The universal principle: wrap I\u002FO and time sources at the seam where they enter the code so the loop can swap a deterministic stand-in.\n\n### Intermittent failures\n\nHere the goal is a failure rate you can measure, not a failure on every run. Track the rate as a\nnumber (failed runs out of total) and raise it until roughly every other run fails; at a rate near\none run in a hundred, the difference between two changes disappears into chance. Three levers raise\nit, used in any combination:\n\n| Lever | What to change |\n|---|---|\n| Timing | insert sleeps between the steps you suspect of racing, or shrink the gap between them |\n| Pressure | load the machine (CPU, disk, network) while the loop runs |\n| Volume | fire the trigger 100 times or more per loop run, and run several copies in parallel |\n\n### When no loop can be built\n\nThis is a full stop: no Phase 2 and no guessing at causes. Report instead, in three parts:\n\n1. **Tried.** Each loop kind from the table you attempted, and what blocked it.\n2. **Blocker.** What is missing: the environment, the data, or a way to observe the failure.\n3. **Request.** Ask the user for whichever of these would remove the blocker: permission to add\n   short-lived production instrumentation, a redacted capture (a screen recording with timestamps,\n   a core dump, a log dump, a HAR file), or access to an environment where the failure occurs.\n\nWhen the artifact in hand is a CPU profile, heap snapshot or performance trace and nothing reproduces, hand it to `\u002Fdebugging:analyze-profile`. It reads the recording down to a file:line cause without a loop; bring that cause back here for the fix and its regression test.\n\n**Gate: Phase 2 starts only once you trust the loop.**\n\n## Phase 2: Reproduce\n\nRun the loop and see it fail. Then check three things before going on:\n\n1. **It repeats.** The loop fails on every run, or, for an intermittent bug, at a rate high enough\n   to compare runs.\n2. **It is the reported failure.** The loop fails the way the **user** said it does. A nearby\n   failure (a 413 where the user saw a 502) sends the fix to the wrong place.\n3. **The symptom is on record.** Keep the exact error text, wrong value or timing, so Phase 5 can\n   show the fix changed that symptom and not some other one.\n\n### Minimize\n\nOnce the loop is red, shrink the reproduction to the smallest case that still fails. Cut inputs,\ncallers, config, data and steps one at a time, and re-run the loop after each cut. Keep a cut only\nwhen the loop stays red. Stop when every remaining element is needed: removing any one of them\nturns the loop green. Fewer parts means fewer suspects in Phase 3, and the minimized case becomes\nthe Phase 5 test. For an intermittent bug, an element counts as needed when removing it drops the\nmeasured failure rate, not when one run happens to pass.\n\n**Gate: Phase 3 starts only once the loop has reproduced the bug and the reproduction is minimized.**\n\n## Phase 3: Hypothesize\n\nThe output of this phase is a table, written down before any test runs. It holds **3 to 5 rows,\nranked**: a list of one invites every later test to be read as support for it.\n\n| Rank | Cause | Refuted if | Supported if |\n|---|---|---|---|\n| 1 | the reverse proxy caps request bodies at 20 MB and drops the connection | raising the proxy cap to 50 MB leaves 25 MB uploads failing | the same upload sent past the proxy, straight to the service, succeeds |\n| 2 | the resize step runs out of memory on large images | a 25 MB file in a format the resizer skips still fails | lowering the worker's memory limit makes 15 MB uploads fail too |\n\nA row is ready only when its \"refuted if\" cell names a result you could observe. If you cannot fill\nthat cell, the cause is too vague to test: narrow it until you can, or delete the row.\n\nGround the ranking in real repo state before you rank: recent commits in the affected area, open issues, architecture decision records, banned-symbol entries, known-issue or quirks notes, and the project instruction files and ADRs nearest the affected file. A hypothesis that contradicts a documented constraint ranks low; one that matches a recent change ranks high.\n\nTwo symptom shapes come with a known first suspect:\n\n| Symptom shape | Goes at the top of the table | Cheapest test |\n|---|---|---|\n| Started after a restart, with no code change | Whatever the old process left on disk for the new one, in this order: data it saved for the next run (a session or queue snapshot), then caches, then the config read at startup, and last any `.lock` or pid file | One file per loop run: rename it, relaunch, run the loop |\n| One worker, host, shard or tenant carries far more of it than the rest | The scheduling, routing or hashing code that keeps picking that actor, once the same actor leads on every pass | A small script that counts the symptom per actor, rerun on each loop pass |\n\nMake that count a script rather than a dashboard reading: a figure read once leaves the next pass\nnothing to compare against. A leader that changes from pass to pass is noise.\n\n**Break a cost tie by rows removed.** Two tests that cost about the same are not equal if one of them, whichever way it comes out, deletes more rows from the table; run that one first.\n\n**Post the table, then start row 1 without waiting for an answer.** The user may know what the\nrepo cannot show: that staging runs the same proxy cap and accepts the file, that every failing\nupload comes from the Android app, or that row 2 matches a ticket closed last month. One such reply\ncan drop a row, add one or change the order. In an unattended run nobody answers, and your ranking\nstands.\n\n## Phase 4: Instrument\n\nA probe exists to fill one cell of the Phase 3 table: before adding it, name the row and the\n\"refuted if\" or \"supported if\" result it will show. Between two loop runs, **change exactly one\nthing**, so any change in the verdict has one explanation.\n\n| Probe | Reach for it when | Note |\n|---|---|---|\n| Breakpoint in a debugger or REPL | the runtime supports one | first choice: one stop at the suspect line shows every local value at once |\n| Log line | no debugger fits, or the evidence spans processes | place it at the boundary where two rows predict different values, such as the body size the media service receives; write it with the session marker Phase 6 searches for |\n| Timer, benchmark, profiler or query plan | the report is \"thumbnails got slow\", not a wrong result | the first number is the baseline; bisect commits, inputs or code paths against it, and edit code only once the slow one is found |\n| Log everything, then search the output | never | the volume hides the line you need |\n\nPer-ecosystem logging API (idiomatic structured-logger choice for ad-hoc debug instrumentation), banned debug-output APIs, and the required tag-prefix convention live in the bundled reference at `${CLAUDE_PLUGIN_ROOT}\u002Fskills\u002Fdebug\u002Freference\u002Fecosystem-debugging.md`. See the `logging` + `banned-output` rows for your stack.\n\nTiming tools per stack (micro-bench libraries, query-plan inspection, profile primitives) live in the same reference; see its `perf-tooling` row.\n\n**A probe that writes a profile.** When an instrument step produces a CPU profile, heap snapshot or trace, read it with `\u002Fdebugging:analyze-profile` and test its file:line finding against the Phase 3 prediction it was meant to check.\n\n**Cold-vs-warm + contention.** A single timing datapoint taken right after filesystem churn (freshly-created fixtures, a just-cloned repo) or while the box is under load (leaked process trees, a parallel build, antivirus scanning) is cold-cache- and contention-inflated, often by multiples. Before calling a perf number reproducible: re-measure warm, on a quiet box, best-of-N (or worst-of-N for a regression ceiling). A number that drops several-fold on the second clean run was measuring contention, not the code path. Never trust one datapoint after churn.\n\n## Phase 5: Fix + regression test\n\n### Is there a correct seam?\n\nDecide this before writing the test. A seam is correct when a test placed there runs the bug the\nway production reaches it at the call site (for example, through the same callers). Which seam that\nis depends on the confirmed row. If row 1 holds (the proxy cap), a unit test that hands the resize\nfunction a 25 MB buffer never passes through the proxy: it passes before the fix and after, and\nproves nothing about the bug. If row 2 holds (resize runs out of memory), that same unit test\nreaches the cause and is a correct seam.\n\n| Seam | What to do |\n|---|---|\n| A correct seam exists | Write the regression test there, **before** the fix, using the steps below. |\n| No correct seam: no test can reach the bug, or every seam that can is too shallow to rebuild it (the bug needs several components or callers acting together and the seam isolates one) | Write no regression test; one at a shallow seam would pass for the wrong reason and make the bug look covered. Record the gap as **the finding**: the design keeps this bug from being pinned by a test. It goes into the Phase 6 architecture recommendation. |\n\n### With a correct seam\n\n1. At that seam, write a test that fails on the minimized repro, following your project's test naming\n   and layout. Take the expected value from the bug report (the behavior the reporter expected, or\n   the documented correct output), never from what the fixed code returns.\n2. Run it and see it fail (Red), and check that it fails **for the intended reason**. A typo, a bad\n   import or an unrelated defect also turns a test red, and a fix that clears *that* red has not\n   touched the bug. Compare the failure message with the root cause you are after; if they differ,\n   repair the test or the reproduction before you edit any implementation code. When the red came\n   from editing code or a fixture on purpose, diff the edited file against a pristine copy (the\n   committed version, or a copy saved before the edit) and confirm the edit is present before\n   trusting the red.\n3. Make the smallest change that removes the **root cause** rather than the symptom (Green).\n4. Run the test and see it pass.\n5. Run the **Phase 1 loop** again on the original, full-size scenario. A passing test is required\n   but does not prove the reported failure is gone.\n\nKeep the fix diff focused on the root cause. Leave surrounding cleanup out of this change, even in files you touched. If the fix reveals a design problem, note it for a separate refactor commit or the Phase 6 architectural recommendation.\n\nDiff the tree against the session's starting point before committing: any guard, retry, raised limit or other edit added for a hypothesis now marked refuted comes out, so the fix commit carries only the confirmed cause's fix, the Phase 6 sibling fixes of that same cause, and their regression tests.\n\n**Worked example: a load imbalance.** In every pass of the Phase 3 tally, export workers 2 and 5 hold most of the large jobs. Giving those two more memory, or adding workers, is a symptom fix: the code that picks a worker stays as it was. That picking code holds the defect, so the fix belongs there, for example hashing on a key with more spread, capping how many large jobs one worker may hold, or claiming by least current work.\n\n## Phase 6: Cleanup + post-mortem\n\nThe run is not done until every line below holds. They fall into three groups.\n\n**Remove what the run added.**\n\n- No temporary log line is left. Cleanup finds only what it can search for, so Phase 4 writes each\n  one with a marker chosen for this session, such as `[DEBUG-a4f2]`, and `grep -r \"\\[DEBUG-\"` over\n  the source now returns nothing. A line written without the marker can be found only by memory.\n- Disposable harnesses and prototypes are deleted, or kept only in a directory clearly named as scratch.\n\n**Prove the fix.**\n\n- Search the codebase for the same defect shape once the cause is fixed: the call, pattern or\n  wrong assumption the fix removed. One cause usually has more than one instance, so a fix to the\n  copy the loop found leaves the others to fail later. A match is a sibling when an input that\n  code path should accept fails there for the same reason. Fix each sibling in this change, with\n  a regression test where a correct seam exists, before the proof steps below, so they cover it.\n  File it with your issue tracker instead when fixing it needs a module, owner or seam this change\n  does not touch, since that fix needs its own review. Name the search and each sibling in the\n  record, so a reader can tell \"searched, none found\" from \"never searched\".\n- The Phase 1 loop, run again, no longer reproduces the failure.\n- The regression test passes, or the missing correct seam is written up as an architecture finding.\n- The user report and the PR description each carry two redacted runs of the Phase 1 loop: the red one from before the fix and the green one from after it. When no red run exists (say the loop was built only after a hotfix), the report records that gap and the evidence used in its place\n- Confirm the fix outcome: run the mechanical build\u002Ftest\u002Flint, then check the original symptom is resolved with no regression, and record the evidence. The context that produced the fix converges on approval rather than detection, so beyond those objective checks the outcome verdict should be rendered by an agent that did NOT produce the fix. If your environment has an outcome-verification capability, use it; otherwise dispatch a fresh-context verifier with the symptom, the fix diff, and pass\u002Ffail criteria. Boundary: `\u002Fdebugging:debug` DOES the fix + regression test; a verifier VERIFIES the outcome. Before that dispatch, run `bash \"${CLAUDE_PLUGIN_ROOT}\u002Flib\u002Fread-verification.sh\" --plugin debugging --skill debug` and copy its line into the record ([levels](https:\u002F\u002Fgithub.com\u002Fmelodic-software\u002Fclaude-code-plugins\u002Fblob\u002Fmain\u002Fdocs\u002Fcontracts\u002Fverification-level\u002FREADME.md)); it governs only this skill's own dispatch, since an outcome-verification capability applies its own level. Under `light`, and `off`, which acts as `light` here, dispatch no verifier and never render the outcome verdict yourself in its place: the record writes `verification: skipped (\u003Clevel>)` and the outcome stays unverified. The mechanical checks and the Phase 1 loop rerun still run at every level\n\n**Leave a record.**\n\n- The commit message or PR description names the hypothesis that proved right, so whoever debugs\n  this area next starts from it.\n- If the loop revealed a recurring class of bug, record it in your project's known-issues \u002F quirks notes\n- Propose one cheap, always-on signal (a log line, a metric or an assertion) that would have shown\n  the deciding fact (the value or state that settled the Phase 3 table) at first look. A deep dig\n  means the failure did not show that fact, and a signal left on shows it the next time without\n  another session. A proposal fits when it is cheap enough to leave on in production and, had it\n  existed, the first failing run would have shown the fact. Propose it in the record and leave it\n  out of the fix commit, because a signal left on in production needs its own review for cost and\n  noise; a Phase 4 probe kept as that signal loses its tag and goes through the same review.\n  Whether to propose is the `always_on_signal` key of `\u003Chome>\u002Fdebugging.yaml` under the git toplevel. Run\n  `bash \"${CLAUDE_PLUGIN_ROOT}\u002Flib\u002Fresolve-convention-home.sh\"` and follow its exit code; never\n  parse the instruction file yourself. Exit 0 prints `\u003Chome>`; exit 1 (no pointer) means\n  `docs\u002Fconventions`; exit 4 (the repository declined a home) and exit 5 (outside a git work tree,\n  or the root at or above your home directory) skip the file; exit 2 or 3 is reported in the reply\n  with the resolver's message and skips the file. `when-instrumented` (the default, used when the file or the key\n  is absent) proposes one when Phase 4 instrumentation ran, since needing a probe is what shows\n  the fact was hidden; `always` proposes one on every run; `never` skips it. A file that does not\n  parse, or any other value, is reported in the reply as invalid with the file, key and value, and\n  the default applies. Report the value in use in one line, such as\n  `always_on_signal: when-instrumented (default)`.\n\n### Prevention\n\nThis step runs only after the fix has landed, never before it: by then the loop and the fix have\nshown how the code really behaves, which the first guess at a cause did not know. Ask what would\nhave stopped this bug from being written. If the answer lies in the design (a missing abstraction,\ntwo modules coupled in a way neither shows, callers tangled together, or no seam where a test could\nreach the bug), write a recommendation:\n\n- State its `Basis:`, `verified` with the `file:line` or loop output it rests on, or `judgment` (only when it is not consequential: cross-repo, shared infrastructure, irreversible, or security). A consequential one is grounded in its consumers first; one that cannot be settled is withheld and filed as an open question naming the evidence that would settle it. Contract: [`${CLAUDE_PLUGIN_ROOT}\u002Fcontext\u002Frecommendation-basis.md`](..\u002F..\u002Fcontext\u002Frecommendation-basis.md); full convention: [recommendation-basis](https:\u002F\u002Fgithub.com\u002Fmelodic-software\u002Fclaude-code-plugins\u002Fblob\u002Fmain\u002Fdocs\u002Fcontracts\u002Frecommendation-basis\u002FREADME.md#grounding-bar)\n- File it with your issue tracker as an architectural finding\n- If your environment has an architecture-audit agent or a module-deepening review, suggest a focused audit of the affected module\n\nIf the answer is a check (a lint or analyzer rule, a test, a hook) that would have caught the mistake deterministically, name its owner instead of leaving it as a note. A repo or policy mistake (a banned API, a wrong file location, a review-standard violation) goes to `\u002Fcorrections:codify \"\u003Cthe mistake>\"` when the `corrections` plugin is installed, which counts the mistake and proposes a check proven against the old code. A mistake in how the agent worked during the session goes to `\u002Fsession-flow:retro` when the `session-flow` plugin is installed, which decides when a check is worth proposing. Otherwise, file it with your issue tracker as its own prevention finding. Propose the check; do not build it here.\n\n**Optional view.** After the post-mortem is written, offer an interactive view of it (the hypotheses with their verdicts and evidence, a tick for each the reader would re-open, a copy-out of the challenge). The page is never written beside the post-mortem, which stays the record. Build it only with `${CLAUDE_PLUGIN_ROOT}\u002Fscripts\u002Fbuild-view.mjs`, never hand-written; the medium resolver decides the destination, with this plugin's `medium` option `${user_config.medium}` as its `--option`, or `\"\"` when that reads empty or as an unsubstituted placeholder (read the value from this text; never put a `${user_config.*}` string in a shell command), and its report and notice lines are printed as they stand. Procedure and data shape: [`${CLAUDE_PLUGIN_ROOT}\u002Freference\u002Frendered-view.md`](${CLAUDE_PLUGIN_ROOT}\u002Freference\u002Frendered-view.md).\n\n## Boundary, the bundled `debug` skill\n\nThe names collide outright, so \"debug this\" can land on either, but the two debug different things.\n\n- **`debug` (bundled skill)**: troubleshoots Claude Code itself (what it enables and when: the\n  `\u002Fdebug` row of [Commands, \"All commands\"](https:\u002F\u002Fcode.claude.com\u002Fdocs\u002Fen\u002Fcommands#all-commands)). It is reserved\n  for the person to run; the model does not invoke it.\n- **This skill (marketplace plugin).** Debugs the user's application: build a reproduction loop,\n  confirm it fails, rank causes, probe them, fix with a regression test, remove what the run added.\n\n**Routing.** When the broken thing is Claude Code itself (a hook, a tool call, a permission, a\nsession misbehaving) rather than the user's code, offer it to the person:\nIf \u002Fdebug is available in your session (gate basis: `disableBundledSkills` or a `skillOverrides`\nentry can hide it; records in [reference\u002Fnative-debug.md](reference\u002Fnative-debug.md)), you can run\nit instead of or alongside this skill. Make the offer at Phase 1, before building a loop against the\napplication. When the caller passes `--unattended`, the run records the offer\nin its output instead of asking; without that flag it asks.\n\n**Mutation gate.** `debug` changes the session's logging (row above). This skill never runs it\non the person's behalf.\n\n**Availability is never assumed.** Bundled skills are gated on settings, environment, plan, and\nhost; this section states what to do when the person can run it, never that it is present. The\nfour-part records live in [reference\u002Fnative-debug.md](reference\u002Fnative-debug.md).\n\n## What this skill does NOT do\n\n- **Does not ship without a feedback loop**. Phase 1 is a hard gate. If a loop cannot be built, that is the report you deliver\n- **Does not retry blindly**. \"tried it again and it worked\" is not a fix. Intermittent passes mean the root cause is still present\n- **Does not fix the symptom**. A null check at the call site is fixing the symptom when the value should never be null: the guard hides the bug, and finding why the value is null is fixing the cause. Handling a state is the fix when the system can legitimately be in it (an optional field left blank, a lookup with no match), so the test is whether that state is legitimate, not whether the change adds a guard\n- **Does not refactor mid-fix**. Keep the diff focused. Architectural findings go to Phase 6\n- **Does not re-derive a known classification**. When the symptom matches a shape your environment already classifies (a known-error taxonomy, a test-investigation routine), lean on that instead of re-deriving it\n- **Does not ship a workaround in place of the cause**. A workaround that ships carries a tracking link or a removal condition in its comment, and the code-tidying comment-residue audit flags one with neither as `unjustified-workaround`. Before shipping one, go back to Phase 3 if the diff's odd behavior cannot be followed without that explanatory comment: the cause is still unfound\n- **Does not fix when the user asked only for a diagnosis**. Stop once a hypothesis is confirmed: report the cause at file:line with the loop output that confirms it, remove the Phase 4 instrumentation, and change no other code. Without that request, fixing is the default\n\n## Next\n\n- The fix landed with its regression test, or a documented seam gap: `\u002Fverification:confirm fix`, then `\u002Freview:quality-gate`.\n- Stopped at a diagnosis on request: `\u002Fimplementation:implement fix`.\n- An artifact with no reproduction: `\u002Fdebugging:analyze-profile`.\n- The root cause is a design flaw that a focused patch cannot fix: `\u002Fplanning:interview`.\n- No feedback loop could be built and the failure needs recording for later: `\u002Fbugs:write --file`.\n- Unsure where this leaves the work, or arrived mid-flow: `\u002Fsession-flow:workflow`.\n\n## When to escalate\n\n**Second failed fix.** Take a raised database write timeout and an added insert retry that both still fail the Phase 1 loop. Both rest on the claim that the database is timing out, so the loop's next job is to check that claim (does any write actually time out?) instead of trying a third fix. Whenever a second fix fails, reduce what the fixes share to one checkable claim like that one and test it the same way; when the symptom is uneven across actors, run the Phase 3 tally before that test. This check is advisory; Phase 1 stays the only hard gate.\n\nIf after 3 hypothesis-test cycles no candidate is panning out:\n\n- The hypothesis ranking was probably wrong. Go back to Phase 3, re-survey the repo, look for what was missed\n- The loop may not be tight enough. Go back to Phase 1 and hold the loop to the exit check again\n- The bug may need redesign rather than a patch. Re-scope it with `\u002Fplanning:interview` when the `planning` plugin is installed (it hands off to `\u002Fplanning:plan`), or your environment's own planning capability otherwise\n- Do not push through a fifth or sixth attempt. That is how technical debt compounds and \"fixes\" break unrelated code\n","**Arguments.** `[--unattended] [bug description or observation]`. e.g., \u002Fdebugging:debug photo uploads over 20 MB fail with a 502\n\n## Repository context. Gather first\n\nCollect these with **individual** Bash calls, one command per call, never combined into a single\ninvocation:\n\n- Current branch, `git branch --show-current`\n- Recent commits, `git log --oneline -10`\n- Working tree status (empty = clean), `git status --porcelain | head -10`\n\nThe pipe is the bound and belongs in the command. A read-time cap (\"read only the first 10 entries\")\ncomes too late for whatever the command has already returned inline. What a result returns inline,\nand when it arrives as a saved file instead, is [Tools reference § Output\nlimits](https:\u002F\u002Fcode.claude.com\u002Fdocs\u002Fen\u002Ftools-reference#output-limits).\n\nTreat a failure (not a repository, git unavailable) as an unknown value and carry on. Keep these as\nseparate body Bash calls rather than pre-compute lines ([gather-block convention](https:\u002F\u002Fgithub.com\u002Fmelodic-software\u002Fclaude-code-plugins\u002Fblob\u002Fmain\u002Fdocs\u002Fconventions\u002Fgather-block\u002FREADME.md#the-pre-compute-block-runs-as-one-shell-invocation),\n\"The pre-compute block runs as one shell invocation\").\n\n## Variables\n\nArguments: `$ARGUMENTS`\n\n`--unattended`, anywhere in the arguments, is not part of the observation: it is the caller declaring that nobody is\npresent, which governs the `\u002Fdebug` offer under \"Routing\". Take it out before reading the rest.\n\n## Purpose\n\nThis skill turns a reported failure into a command that answers one question, \"is the bug still\nhere?\", and then uses that command as the judge for every later step. The six phases below each end\nin a gate. How well Phase 1 goes decides most of the outcome: with a quick, repeatable check that an\nagent can run unattended, Phases 3 to 5 become routine work; without one, every hypothesis is a\nguess. The usual way a debugging session goes wrong is starting on causes before any such check\nexists. Phase 1 and Phase 6 (the check, and the cleanup that removes what the run added) carry the\nweight; the three phases between them follow from the check.\n\nScope boundary: this skill starts from an **observed failure**: UI behaving wrong, a log line that should not appear, a performance regression, a screenshot of a bug, a production symptom. Its first job is to **construct** a reproduction loop. If the symptom is already a failing test with no reproduction gap, you do not need this skill. Cycle that test directly (reproduce → fix → retest → regression). What `\u002Fdebugging:debug` adds over a bare fix loop is a critical edge case: **if no correct test seam exists, that absence IS the finding**, filed as an architectural recommendation, not a forced test in the wrong place.\n\nRunning example. The phases below follow one case: a photo larger than 20 MB uploaded through the\nmobile API gets a 502 from the media service, while smaller photos upload normally.\n\n## Adapting to your environment (graceful degrade)\n\nThis skill is self-contained. Where a phase below names an adjacent capability, such as a test-investigation routine, a TDD helper, a headless-browser driver, an architecture-audit agent, an issue tracker, or an outcome-verifier, treat it as **optional**: *if your environment provides that capability (a skill, plugin, agent, or tool), invoke it; otherwise proceed with the inline guidance given here, which stands on its own.* Never block a phase because an adjacent tool is absent. Consumer-specific conventions (naming, module layout, banned APIs, work-notes location) come from your own project's `CLAUDE.md` and tool config. Read them; this skill does not assume them.\n\n## Secrets stay out of what you show\n\nAnything this skill puts in a reply, a work note or a commit is a place a secret can leak. The rule\nfor each kind of text:\n\n| Text | Rule |\n|---|---|\n| A loop script or harness you commit | It reads tokens and passwords from environment variables, so the file names the variable and never holds the value. |\n| A command line you show | Same: the variable name appears, the value does not. |\n| A capture (HAR file, log dump, replayed trace) | Assume it holds auth headers and session tokens. Show an excerpt of the lines where the failure appears, never the whole file. |\n| Any secret still left in what you show | Replace it with `\u003CREDACTED>` before the text leaves your hands. |\n\nIf the redacted excerpt is too thin to diagnose from, ask the user how to proceed; do not widen the\nexcerpt on your own.\n\n## Emit checklist\n\nFor any diagnostic run (Phases 1-6), track phase completion. A ready-to-fill checklist is bundled at `${CLAUDE_PLUGIN_ROOT}\u002Fskills\u002Fdebug\u002Ftemplates\u002Fchecklist.md`. If your project has a working-notes or scratch location, copy it there; otherwise track the six phases inline. Phase 4 is SKIPPED when Phase 2 repro conclusively verifies the Phase 3 hypothesis without instrumentation.\n\n## Phase 1: Build the reproduction loop\n\nWrite down what you are assuming about the failure first (for the running example: the 502 comes\nfrom our media service, not the CDN in front of it; staging fails the same way production does). Phase 3 ranks\nhypotheses against that list.\n\nMost of this skill's effort belongs here. The loop is done when one command returns pass or fail\nfor this bug, quickly, the same way each time, with no person needed to run it.\n\n### Picking a loop\n\nTry the rows roughly in table order. A lower row usually costs more to build or tells you less, so\nprefer the first row that can reach the failing code.\n\n| Rank | Loop | Choose it when | In the running example |\n|---|---|---|---|\n| 1 | A failing test (unit, integration or end-to-end) | some test seam already reaches the failing code | an integration test that posts a 25 MB JPEG and asserts a 201 |\n| 2 | A scripted HTTP call (curl or similar) | the failure shows at an endpoint of a dev server you can start | `curl` the upload endpoint with a 25 MB file and print the status code |\n| 3 | A CLI run on a fixture file | the code has a command-line entry point | run the thumbnailer CLI on `large.jpg` and diff its output against a known-good copy |\n| 4 | Browser automation run headless, through a Playwright-style driver if one is available | only the UI shows the failure | drive the web uploader and assert on the DOM, console and network panel |\n| 5 | A recorded input played back | a real request body or event stream can be saved | save one failing multipart request to disk and send it to the upload handler alone |\n| 6 | A disposable harness | starting the full stack takes minutes, but the failing module can be imported on its own | a scratch script imports the thumbnail module, swaps S3 for an in-memory store, and passes it `large.jpg` |\n| 7 | A randomized-input loop (property or fuzz) | the output is wrong only for some inputs | generate a thousand images of random size and format and keep the ones that fail |\n| 8 | An automated bisect | the bug has a history: an older release, data snapshot or dependency version where the upload still works | `check.sh` builds the checkout and exits 0 on a 201 for the 25 MB upload, 1 otherwise; `git bisect run .\u002Fcheck.sh` walks v3.2 to v3.4 with it |\n| 9 | A side-by-side run | two builds or two configurations should agree | send the same file through last week's build and this week's, then diff the results |\n| 10 | A human-driven script | a person has to click | see below |\n\nA human-driven loop is the fallback when nothing above works. Copy the bundled template at\n`${CLAUDE_PLUGIN_ROOT}\u002Fskills\u002Fdebug\u002Fscripts\u002Fhitl-loop.template.sh`, replace its example prompts with\nthe steps for this bug, and ask the **user** to run it in their own terminal: its interactive `read`\nprompts need a TTY that the Bash tool does not have. The script ends by printing a `=== results ===`\nblock of `NAME=value` lines; ask the user to paste that block back so each run reaches you in the\nsame shape.\n\nEvery answer the script collects with `ask` is printed in that results block and pasted into the\nsession, so ask only for what the user observes: yes or no, a number, copied error text. Never ask\nfor a password, token or other secret (see \"Secrets stay out of what you show\" above). Signing in\nstays an `instruct` step the user does on their own.\n\n### Loop-recursion hazard\n\nWhen the loop IS a test the suite\u002Frunner discovers and runs, watch for self-invocation: a test file that invokes the very runner (or pre-push lane) which re-discovers and re-runs it recurses until the box saturates. Each nested run re-triggers the test. The symptom reads as a *hang*, but it is fork-bombing, not a slow test. Guard with a re-entrancy sentinel: set an env marker before the inner run; a nested invocation that sees the marker exits early. Same pattern for any loop that shells out to a command which re-enters the loop.\n\n### Phase 1 exit check\n\nA loop that merely runs is not finished. Before leaving Phase 1, hold it to all three requirements\nbelow; each failing one has its own remedies.\n\n| Requirement | Met when | If not met |\n|---|---|---|\n| Speed | one run finishes in about 2 seconds; a 30-second loop is not acceptable | run only the one test, keep the server or fixtures alive between runs, skip start-up work the failing path does not touch |\n| One verdict | the same code gives the same verdict on every run; a loop that flips between runs tells you almost nothing | stub the network, give each run a fresh directory, seed the random generator, freeze the clock |\n| Precision | it goes red on the reported symptom and on nothing else | assert on the 502 from the upload call itself, not on \"the script exited non-zero\" |\n\nPer-ecosystem timing-injection patterns (and other I\u002FO-seam abstractions) live in the bundled reference at `${CLAUDE_PLUGIN_ROOT}\u002Fskills\u002Fdebug\u002Freference\u002Fecosystem-debugging.md`. See the `timing-injection` row for your stack. The universal principle: wrap I\u002FO and time sources at the seam where they enter the code so the loop can swap a deterministic stand-in.\n\n### Intermittent failures\n\nHere the goal is a failure rate you can measure, not a failure on every run. Track the rate as a\nnumber (failed runs out of total) and raise it until roughly every other run fails; at a rate near\none run in a hundred, the difference between two changes disappears into chance. Three levers raise\nit, used in any combination:\n\n| Lever | What to change |\n|---|---|\n| Timing | insert sleeps between the steps you suspect of racing, or shrink the gap between them |\n| Pressure | load the machine (CPU, disk, network) while the loop runs |\n| Volume | fire the trigger 100 times or more per loop run, and run several copies in parallel |\n\n### When no loop can be built\n\nThis is a full stop: no Phase 2 and no guessing at causes. Report instead, in three parts:\n\n1. **Tried.** Each loop kind from the table you attempted, and what blocked it.\n2. **Blocker.** What is missing: the environment, the data, or a way to observe the failure.\n3. **Request.** Ask the user for whichever of these would remove the blocker: permission to add\n   short-lived production instrumentation, a redacted capture (a screen recording with timestamps,\n   a core dump, a log dump, a HAR file), or access to an environment where the failure occurs.\n\nWhen the artifact in hand is a CPU profile, heap snapshot or performance trace and nothing reproduces, hand it to `\u002Fdebugging:analyze-profile`. It reads the recording down to a file:line cause without a loop; bring that cause back here for the fix and its regression test.\n\n**Gate: Phase 2 starts only once you trust the loop.**\n\n## Phase 2: Reproduce\n\nRun the loop and see it fail. Then check three things before going on:\n\n1. **It repeats.** The loop fails on every run, or, for an intermittent bug, at a rate high enough\n   to compare runs.\n2. **It is the reported failure.** The loop fails the way the **user** said it does. A nearby\n   failure (a 413 where the user saw a 502) sends the fix to the wrong place.\n3. **The symptom is on record.** Keep the exact error text, wrong value or timing, so Phase 5 can\n   show the fix changed that symptom and not some other one.\n\n### Minimize\n\nOnce the loop is red, shrink the reproduction to the smallest case that still fails. Cut inputs,\ncallers, config, data and steps one at a time, and re-run the loop after each cut. Keep a cut only\nwhen the loop stays red. Stop when every remaining element is needed: removing any one of them\nturns the loop green. Fewer parts means fewer suspects in Phase 3, and the minimized case becomes\nthe Phase 5 test. For an intermittent bug, an element counts as needed when removing it drops the\nmeasured failure rate, not when one run happens to pass.\n\n**Gate: Phase 3 starts only once the loop has reproduced the bug and the reproduction is minimized.**\n\n## Phase 3: Hypothesize\n\nThe output of this phase is a table, written down before any test runs. It holds **3 to 5 rows,\nranked**: a list of one invites every later test to be read as support for it.\n\n| Rank | Cause | Refuted if | Supported if |\n|---|---|---|---|\n| 1 | the reverse proxy caps request bodies at 20 MB and drops the connection | raising the proxy cap to 50 MB leaves 25 MB uploads failing | the same upload sent past the proxy, straight to the service, succeeds |\n| 2 | the resize step runs out of memory on large images | a 25 MB file in a format the resizer skips still fails | lowering the worker's memory limit makes 15 MB uploads fail too |\n\nA row is ready only when its \"refuted if\" cell names a result you could observe. If you cannot fill\nthat cell, the cause is too vague to test: narrow it until you can, or delete the row.\n\nGround the ranking in real repo state before you rank: recent commits in the affected area, open issues, architecture decision records, banned-symbol entries, known-issue or quirks notes, and the project instruction files and ADRs nearest the affected file. A hypothesis that contradicts a documented constraint ranks low; one that matches a recent change ranks high.\n\nTwo symptom shapes come with a known first suspect:\n\n| Symptom shape | Goes at the top of the table | Cheapest test |\n|---|---|---|\n| Started after a restart, with no code change | Whatever the old process left on disk for the new one, in this order: data it saved for the next run (a session or queue snapshot), then caches, then the config read at startup, and last any `.lock` or pid file | One file per loop run: rename it, relaunch, run the loop |\n| One worker, host, shard or tenant carries far more of it than the rest | The scheduling, routing or hashing code that keeps picking that actor, once the same actor leads on every pass | A small script that counts the symptom per actor, rerun on each loop pass |\n\nMake that count a script rather than a dashboard reading: a figure read once leaves the next pass\nnothing to compare against. A leader that changes from pass to pass is noise.\n\n**Break a cost tie by rows removed.** Two tests that cost about the same are not equal if one of them, whichever way it comes out, deletes more rows from the table; run that one first.\n\n**Post the table, then start row 1 without waiting for an answer.** The user may know what the\nrepo cannot show: that staging runs the same proxy cap and accepts the file, that every failing\nupload comes from the Android app, or that row 2 matches a ticket closed last month. One such reply\ncan drop a row, add one or change the order. In an unattended run nobody answers, and your ranking\nstands.\n\n## Phase 4: Instrument\n\nA probe exists to fill one cell of the Phase 3 table: before adding it, name the row and the\n\"refuted if\" or \"supported if\" result it will show. Between two loop runs, **change exactly one\nthing**, so any change in the verdict has one explanation.\n\n| Probe | Reach for it when | Note |\n|---|---|---|\n| Breakpoint in a debugger or REPL | the runtime supports one | first choice: one stop at the suspect line shows every local value at once |\n| Log line | no debugger fits, or the evidence spans processes | place it at the boundary where two rows predict different values, such as the body size the media service receives; write it with the session marker Phase 6 searches for |\n| Timer, benchmark, profiler or query plan | the report is \"thumbnails got slow\", not a wrong result | the first number is the baseline; bisect commits, inputs or code paths against it, and edit code only once the slow one is found |\n| Log everything, then search the output | never | the volume hides the line you need |\n\nPer-ecosystem logging API (idiomatic structured-logger choice for ad-hoc debug instrumentation), banned debug-output APIs, and the required tag-prefix convention live in the bundled reference at `${CLAUDE_PLUGIN_ROOT}\u002Fskills\u002Fdebug\u002Freference\u002Fecosystem-debugging.md`. See the `logging` + `banned-output` rows for your stack.\n\nTiming tools per stack (micro-bench libraries, query-plan inspection, profile primitives) live in the same reference; see its `perf-tooling` row.\n\n**A probe that writes a profile.** When an instrument step produces a CPU profile, heap snapshot or trace, read it with `\u002Fdebugging:analyze-profile` and test its file:line finding against the Phase 3 prediction it was meant to check.\n\n**Cold-vs-warm + contention.** A single timing datapoint taken right after filesystem churn (freshly-created fixtures, a just-cloned repo) or while the box is under load (leaked process trees, a parallel build, antivirus scanning) is cold-cache- and contention-inflated, often by multiples. Before calling a perf number reproducible: re-measure warm, on a quiet box, best-of-N (or worst-of-N for a regression ceiling). A number that drops several-fold on the second clean run was measuring contention, not the code path. Never trust one datapoint after churn.\n\n## Phase 5: Fix + regression test\n\n### Is there a correct seam?\n\nDecide this before writing the test. A seam is correct when a test placed there runs the bug the\nway production reaches it at the call site (for example, through the same callers). Which seam that\nis depends on the confirmed row. If row 1 holds (the proxy cap), a unit test that hands the resize\nfunction a 25 MB buffer never passes through the proxy: it passes before the fix and after, and\nproves nothing about the bug. If row 2 holds (resize runs out of memory), that same unit test\nreaches the cause and is a correct seam.\n\n| Seam | What to do |\n|---|---|\n| A correct seam exists | Write the regression test there, **before** the fix, using the steps below. |\n| No correct seam: no test can reach the bug, or every seam that can is too shallow to rebuild it (the bug needs several components or callers acting together and the seam isolates one) | Write no regression test; one at a shallow seam would pass for the wrong reason and make the bug look covered. Record the gap as **the finding**: the design keeps this bug from being pinned by a test. It goes into the Phase 6 architecture recommendation. |\n\n### With a correct seam\n\n1. At that seam, write a test that fails on the minimized repro, following your project's test naming\n   and layout. Take the expected value from the bug report (the behavior the reporter expected, or\n   the documented correct output), never from what the fixed code returns.\n2. Run it and see it fail (Red), and check that it fails **for the intended reason**. A typo, a bad\n   import or an unrelated defect also turns a test red, and a fix that clears *that* red has not\n   touched the bug. Compare the failure message with the root cause you are after; if they differ,\n   repair the test or the reproduction before you edit any implementation code. When the red came\n   from editing code or a fixture on purpose, diff the edited file against a pristine copy (the\n   committed version, or a copy saved before the edit) and confirm the edit is present before\n   trusting the red.\n3. Make the smallest change that removes the **root cause** rather than the symptom (Green).\n4. Run the test and see it pass.\n5. Run the **Phase 1 loop** again on the original, full-size scenario. A passing test is required\n   but does not prove the reported failure is gone.\n\nKeep the fix diff focused on the root cause. Leave surrounding cleanup out of this change, even in files you touched. If the fix reveals a design problem, note it for a separate refactor commit or the Phase 6 architectural recommendation.\n\nDiff the tree against the session's starting point before committing: any guard, retry, raised limit or other edit added for a hypothesis now marked refuted comes out, so the fix commit carries only the confirmed cause's fix, the Phase 6 sibling fixes of that same cause, and their regression tests.\n\n**Worked example: a load imbalance.** In every pass of the Phase 3 tally, export workers 2 and 5 hold most of the large jobs. Giving those two more memory, or adding workers, is a symptom fix: the code that picks a worker stays as it was. That picking code holds the defect, so the fix belongs there, for example hashing on a key with more spread, capping how many large jobs one worker may hold, or claiming by least current work.\n\n## Phase 6: Cleanup + post-mortem\n\nThe run is not done until every line below holds. They fall into three groups.\n\n**Remove what the run added.**\n\n- No temporary log line is left. Cleanup finds only what it can search for, so Phase 4 writes each\n  one with a marker chosen for this session, such as `[DEBUG-a4f2]`, and `grep -r \"\\[DEBUG-\"` over\n  the source now returns nothing. A line written without the marker can be found only by memory.\n- Disposable harnesses and prototypes are deleted, or kept only in a directory clearly named as scratch.\n\n**Prove the fix.**\n\n- Search the codebase for the same defect shape once the cause is fixed: the call, pattern or\n  wrong assumption the fix removed. One cause usually has more than one instance, so a fix to the\n  copy the loop found leaves the others to fail later. A match is a sibling when an input that\n  code path should accept fails there for the same reason. Fix each sibling in this change, with\n  a regression test where a correct seam exists, before the proof steps below, so they cover it.\n  File it with your issue tracker instead when fixing it needs a module, owner or seam this change\n  does not touch, since that fix needs its own review. Name the search and each sibling in the\n  record, so a reader can tell \"searched, none found\" from \"never searched\".\n- The Phase 1 loop, run again, no longer reproduces the failure.\n- The regression test passes, or the missing correct seam is written up as an architecture finding.\n- The user report and the PR description each carry two redacted runs of the Phase 1 loop: the red one from before the fix and the green one from after it. When no red run exists (say the loop was built only after a hotfix), the report records that gap and the evidence used in its place\n- Confirm the fix outcome: run the mechanical build\u002Ftest\u002Flint, then check the original symptom is resolved with no regression, and record the evidence. The context that produced the fix converges on approval rather than detection, so beyond those objective checks the outcome verdict should be rendered by an agent that did NOT produce the fix. If your environment has an outcome-verification capability, use it; otherwise dispatch a fresh-context verifier with the symptom, the fix diff, and pass\u002Ffail criteria. Boundary: `\u002Fdebugging:debug` DOES the fix + regression test; a verifier VERIFIES the outcome. Before that dispatch, run `bash \"${CLAUDE_PLUGIN_ROOT}\u002Flib\u002Fread-verification.sh\" --plugin debugging --skill debug` and copy its line into the record ([levels](https:\u002F\u002Fgithub.com\u002Fmelodic-software\u002Fclaude-code-plugins\u002Fblob\u002Fmain\u002Fdocs\u002Fcontracts\u002Fverification-level\u002FREADME.md)); it governs only this skill's own dispatch, since an outcome-verification capability applies its own level. Under `light`, and `off`, which acts as `light` here, dispatch no verifier and never render the outcome verdict yourself in its place: the record writes `verification: skipped (\u003Clevel>)` and the outcome stays unverified. The mechanical checks and the Phase 1 loop rerun still run at every level\n\n**Leave a record.**\n\n- The commit message or PR description names the hypothesis that proved right, so whoever debugs\n  this area next starts from it.\n- If the loop revealed a recurring class of bug, record it in your project's known-issues \u002F quirks notes\n- Propose one cheap, always-on signal (a log line, a metric or an assertion) that would have shown\n  the deciding fact (the value or state that settled the Phase 3 table) at first look. A deep dig\n  means the failure did not show that fact, and a signal left on shows it the next time without\n  another session. A proposal fits when it is cheap enough to leave on in production and, had it\n  existed, the first failing run would have shown the fact. Propose it in the record and leave it\n  out of the fix commit, because a signal left on in production needs its own review for cost and\n  noise; a Phase 4 probe kept as that signal loses its tag and goes through the same review.\n  Whether to propose is the `always_on_signal` key of `\u003Chome>\u002Fdebugging.yaml` under the git toplevel. Run\n  `bash \"${CLAUDE_PLUGIN_ROOT}\u002Flib\u002Fresolve-convention-home.sh\"` and follow its exit code; never\n  parse the instruction file yourself. Exit 0 prints `\u003Chome>`; exit 1 (no pointer) means\n  `docs\u002Fconventions`; exit 4 (the repository declined a home) and exit 5 (outside a git work tree,\n  or the root at or above your home directory) skip the file; exit 2 or 3 is reported in the reply\n  with the resolver's message and skips the file. `when-instrumented` (the default, used when the file or the key\n  is absent) proposes one when Phase 4 instrumentation ran, since needing a probe is what shows\n  the fact was hidden; `always` proposes one on every run; `never` skips it. A file that does not\n  parse, or any other value, is reported in the reply as invalid with the file, key and value, and\n  the default applies. Report the value in use in one line, such as\n  `always_on_signal: when-instrumented (default)`.\n\n### Prevention\n\nThis step runs only after the fix has landed, never before it: by then the loop and the fix have\nshown how the code really behaves, which the first guess at a cause did not know. Ask what would\nhave stopped this bug from being written. If the answer lies in the design (a missing abstraction,\ntwo modules coupled in a way neither shows, callers tangled together, or no seam where a test could\nreach the bug), write a recommendation:\n\n- State its `Basis:`, `verified` with the `file:line` or loop output it rests on, or `judgment` (only when it is not consequential: cross-repo, shared infrastructure, irreversible, or security). A consequential one is grounded in its consumers first; one that cannot be settled is withheld and filed as an open question naming the evidence that would settle it. Contract: [`${CLAUDE_PLUGIN_ROOT}\u002Fcontext\u002Frecommendation-basis.md`](..\u002F..\u002Fcontext\u002Frecommendation-basis.md); full convention: [recommendation-basis](https:\u002F\u002Fgithub.com\u002Fmelodic-software\u002Fclaude-code-plugins\u002Fblob\u002Fmain\u002Fdocs\u002Fcontracts\u002Frecommendation-basis\u002FREADME.md#grounding-bar)\n- File it with your issue tracker as an architectural finding\n- If your environment has an architecture-audit agent or a module-deepening review, suggest a focused audit of the affected module\n\nIf the answer is a check (a lint or analyzer rule, a test, a hook) that would have caught the mistake deterministically, name its owner instead of leaving it as a note. A repo or policy mistake (a banned API, a wrong file location, a review-standard violation) goes to `\u002Fcorrections:codify \"\u003Cthe mistake>\"` when the `corrections` plugin is installed, which counts the mistake and proposes a check proven against the old code. A mistake in how the agent worked during the session goes to `\u002Fsession-flow:retro` when the `session-flow` plugin is installed, which decides when a check is worth proposing. Otherwise, file it with your issue tracker as its own prevention finding. Propose the check; do not build it here.\n\n**Optional view.** After the post-mortem is written, offer an interactive view of it (the hypotheses with their verdicts and evidence, a tick for each the reader would re-open, a copy-out of the challenge). The page is never written beside the post-mortem, which stays the record. Build it only with `${CLAUDE_PLUGIN_ROOT}\u002Fscripts\u002Fbuild-view.mjs`, never hand-written; the medium resolver decides the destination, with this plugin's `medium` option `${user_config.medium}` as its `--option`, or `\"\"` when that reads empty or as an unsubstituted placeholder (read the value from this text; never put a `${user_config.*}` string in a shell command), and its report and notice lines are printed as they stand. Procedure and data shape: [`${CLAUDE_PLUGIN_ROOT}\u002Freference\u002Frendered-view.md`](${CLAUDE_PLUGIN_ROOT}\u002Freference\u002Frendered-view.md).\n\n## Boundary, the bundled `debug` skill\n\nThe names collide outright, so \"debug this\" can land on either, but the two debug different things.\n\n- **`debug` (bundled skill)**: troubleshoots Claude Code itself (what it enables and when: the\n  `\u002Fdebug` row of [Commands, \"All commands\"](https:\u002F\u002Fcode.claude.com\u002Fdocs\u002Fen\u002Fcommands#all-commands)). It is reserved\n  for the person to run; the model does not invoke it.\n- **This skill (marketplace plugin).** Debugs the user's application: build a reproduction loop,\n  confirm it fails, rank causes, probe them, fix with a regression test, remove what the run added.\n\n**Routing.** When the broken thing is Claude Code itself (a hook, a tool call, a permission, a\nsession misbehaving) rather than the user's code, offer it to the person:\nIf \u002Fdebug is available in your session (gate basis: `disableBundledSkills` or a `skillOverrides`\nentry can hide it; records in [reference\u002Fnative-debug.md](reference\u002Fnative-debug.md)), you can run\nit instead of or alongside this skill. Make the offer at Phase 1, before building a loop against the\napplication. When the caller passes `--unattended`, the run records the offer\nin its output instead of asking; without that flag it asks.\n\n**Mutation gate.** `debug` changes the session's logging (row above). This skill never runs it\non the person's behalf.\n\n**Availability is never assumed.** Bundled skills are gated on settings, environment, plan, and\nhost; this section states what to do when the person can run it, never that it is present. The\nfour-part records live in [reference\u002Fnative-debug.md](reference\u002Fnative-debug.md).\n\n## What this skill does NOT do\n\n- **Does not ship without a feedback loop**. Phase 1 is a hard gate. If a loop cannot be built, that is the report you deliver\n- **Does not retry blindly**. \"tried it again and it worked\" is not a fix. Intermittent passes mean the root cause is still present\n- **Does not fix the symptom**. A null check at the call site is fixing the symptom when the value should never be null: the guard hides the bug, and finding why the value is null is fixing the cause. Handling a state is the fix when the system can legitimately be in it (an optional field left blank, a lookup with no match), so the test is whether that state is legitimate, not whether the change adds a guard\n- **Does not refactor mid-fix**. Keep the diff focused. Architectural findings go to Phase 6\n- **Does not re-derive a known classification**. When the symptom matches a shape your environment already classifies (a known-error taxonomy, a test-investigation routine), lean on that instead of re-deriving it\n- **Does not ship a workaround in place of the cause**. A workaround that ships carries a tracking link or a removal condition in its comment, and the code-tidying comment-residue audit flags one with neither as `unjustified-workaround`. Before shipping one, go back to Phase 3 if the diff's odd behavior cannot be followed without that explanatory comment: the cause is still unfound\n- **Does not fix when the user asked only for a diagnosis**. Stop once a hypothesis is confirmed: report the cause at file:line with the loop output that confirms it, remove the Phase 4 instrumentation, and change no other code. Without that request, fixing is the default\n\n## Next\n\n- The fix landed with its regression test, or a documented seam gap: `\u002Fverification:confirm fix`, then `\u002Freview:quality-gate`.\n- Stopped at a diagnosis on request: `\u002Fimplementation:implement fix`.\n- An artifact with no reproduction: `\u002Fdebugging:analyze-profile`.\n- The root cause is a design flaw that a focused patch cannot fix: `\u002Fplanning:interview`.\n- No feedback loop could be built and the failure needs recording for later: `\u002Fbugs:write --file`.\n- Unsure where this leaves the work, or arrived mid-flow: `\u002Fsession-flow:workflow`.\n\n## When to escalate\n\n**Second failed fix.** Take a raised database write timeout and an added insert retry that both still fail the Phase 1 loop. Both rest on the claim that the database is timing out, so the loop's next job is to check that claim (does any write actually time out?) instead of trying a third fix. Whenever a second fix fails, reduce what the fixes share to one checkable claim like that one and test it the same way; when the symptom is uneven across actors, run the Phase 3 tally before that test. This check is advisory; Phase 1 stays the only hard gate.\n\nIf after 3 hypothesis-test cycles no candidate is panning out:\n\n- The hypothesis ranking was probably wrong. Go back to Phase 3, re-survey the repo, look for what was missed\n- The loop may not be tight enough. Go back to Phase 1 and hold the loop to the exit check again\n- The bug may need redesign rather than a patch. Re-scope it with `\u002Fplanning:interview` when the `planning` plugin is installed (it hands off to `\u002Fplanning:plan`), or your environment's own planning capability otherwise\n- Do not push through a fifth or sixth attempt. That is how technical debt compounds and \"fixes\" break unrelated code\n",{"metadata":24,"description":7,"argument-hint":27,"user-invocable":28,"disable-model-invocation":20},{"summary":25,"workflow-stage":26},"Diagnose broken behavior. Reproduce, hypothesize, instrument, fix with regression test","implement","[--unattended] [bug description or observation]",true,"main","d0e68c3f36b92a1d6381f0ba0060d7a0b8b886c5","plugins\u002Fdebugging\u002Fskills\u002Fdebug",7,"https:\u002F\u002Fgithub.com\u002Fmelodic-software\u002Fclaude-code-plugins","https:\u002F\u002Fgithub.com\u002Fmelodic-software","https:\u002F\u002Fmelodicsoftware.com","Independent software studio building developer tools, automation, and application services, with roots in music.","2026-11-15 05:15:06",{"source":8,"skillName":5,"commands":39,"prompt":49,"zipAvailable":28},[40,43,46],{"tool":41,"command":42},"npx","npx skills add melodic-software\u002Fclaude-code-plugins --skill debug",{"tool":44,"command":45},"bunx","bunx skills add melodic-software\u002Fclaude-code-plugins --skill debug",{"tool":47,"command":48},"pnpm","pnpm dlx skills add melodic-software\u002Fclaude-code-plugins --skill debug","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmelodic-software\u002Fclaude-code-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fdebugging\u002Fskills\u002Fdebug\u002FSKILL.md",[51,57,61,67,71],{"path":52,"resourceType":53,"resourceTypeDesc":54,"sizeBytes":55,"sourceHtmlUrl":56},"reference\u002Fecosystem-debugging.md","REFERENCE","参考文档",3692,"https:\u002F\u002Fgithub.com\u002Fmelodic-software\u002Fclaude-code-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fdebugging\u002Fskills\u002Fdebug\u002Freference\u002Fecosystem-debugging.md",{"path":58,"resourceType":53,"resourceTypeDesc":54,"sizeBytes":59,"sourceHtmlUrl":60},"reference\u002Fnative-debug.md",2054,"https:\u002F\u002Fgithub.com\u002Fmelodic-software\u002Fclaude-code-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fdebugging\u002Fskills\u002Fdebug\u002Freference\u002Fnative-debug.md",{"path":62,"resourceType":63,"resourceTypeDesc":64,"sizeBytes":65,"sourceHtmlUrl":66},"scripts\u002Fhitl-loop.template.sh","SCRIPT","脚本",2033,"https:\u002F\u002Fgithub.com\u002Fmelodic-software\u002Fclaude-code-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fdebugging\u002Fskills\u002Fdebug\u002Fscripts\u002Fhitl-loop.template.sh",{"path":68,"resourceType":53,"resourceTypeDesc":54,"sizeBytes":69,"sourceHtmlUrl":70},"templates\u002Fchecklist.md",1174,"https:\u002F\u002Fgithub.com\u002Fmelodic-software\u002Fclaude-code-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fdebugging\u002Fskills\u002Fdebug\u002Ftemplates\u002Fchecklist.md",{"path":72,"resourceType":53,"resourceTypeDesc":54,"sizeBytes":73,"sourceHtmlUrl":74},"templates\u002Fpost-mortem-view.html",6074,"https:\u002F\u002Fgithub.com\u002Fmelodic-software\u002Fclaude-code-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fdebugging\u002Fskills\u002Fdebug\u002Ftemplates\u002Fpost-mortem-view.html",[76,83,90,97,102,109],{"skillNo":77,"name":78,"nameZh":6,"description":79,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":80,"categories":81,"keywords":82,"publishedAt":19},"01M7DYYDG31B9YX7N9MB9QW2GW","track","Backlog reads through the bound tracker: search open and closed items, view one item with its comments and state history. Use when another skill searches or reads tracker items.","https:\u002F\u002Fgithub.com\u002Fmelodic-software\u002Fclaude-code-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fsession-flow\u002Fevals\u002Frecall-still-reports-reopened-bug\u002Fwork-items-stub\u002Fskills\u002Ftrack\u002FSKILL.md",[],[],{"skillNo":84,"name":85,"nameZh":6,"description":86,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":87,"categories":88,"keywords":89,"publishedAt":19},"01M7DYXVBAVG3NV30PA7GKW9Q6","reviewer-media","Reviewer media for one pull request: decides whether it needs a narrated walkthrough, builds the storyboard from \u002Freview:explain-change's digest, has \u002Fexplainer-video:produce render it and hands the manifest to \u002Fsource-control:pull-request media. Use when asked for 'reviewer media', 'a walkthrough video for this PR', 'a produced video of this change', or when pull-request ready or monitor hands a PR over.","https:\u002F\u002Fgithub.com\u002Fmelodic-software\u002Fclaude-code-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Freview\u002Fskills\u002Freviewer-media\u002FSKILL.md",[],[],{"skillNo":91,"name":92,"nameZh":6,"description":93,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":94,"categories":95,"keywords":96,"publishedAt":19},"01M7DYRZ5YD44AMYH26YR25GZ8","route","Model and effort per agent role (orchestrator, worker, verifier, retrieval) for a multi-agent run, resolved through the bundled defaults and the user, team and personal override config layers into fenced JSON with single-agent and fan-out variants and the layer behind each value. Use when asked 'which model for the subagents', 'route the roles' or 'model routing', or before a skill passes a role's model on a spawn.","https:\u002F\u002Fgithub.com\u002Fmelodic-software\u002Fclaude-code-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fdiscovery\u002Fevals\u002Fex-model-pin-without-override\u002Fmulti-agent-stub\u002Fskills\u002Froute\u002FSKILL.md",[],[],{"skillNo":98,"name":92,"nameZh":6,"description":93,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":99,"categories":100,"keywords":101,"publishedAt":19},"01M7DYRTVT4FWTGDJY0HCCFJMZ","https:\u002F\u002Fgithub.com\u002Fmelodic-software\u002Fclaude-code-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fdiscovery\u002Fevals\u002Fex-model-override-from-route\u002Fmulti-agent-stub\u002Fskills\u002Froute\u002FSKILL.md",[],[],{"skillNo":103,"name":104,"nameZh":6,"description":105,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":106,"categories":107,"keywords":108,"publishedAt":19},"01M7DYNZC8PNW3T27V2ADKECKJ","principles","Module-design vocabulary for architecture findings, and the checks built on it. Use when: 'what is a deep module', 'what is a seam', 'deep vs shallow module', 'what is the deletion test', 'leverage and locality', 'module design vocabulary', 'which word do we use for X in architecture findings'. Scanning a codebase for friction is \u002Farchitecture:improve.","https:\u002F\u002Fgithub.com\u002Fmelodic-software\u002Fclaude-code-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Farchitecture\u002Fskills\u002Fprinciples\u002FSKILL.md",[],[],{"skillNo":110,"name":111,"nameZh":6,"description":112,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":113,"categories":114,"keywords":115,"publishedAt":19},"01M7DYNMCZNEWBFHV9KTSS6H60","write","Structured five-field bug report (title, steps to reproduce, expected vs actual, justified severity, suggested fix location) from an informal description, read-only. Use when the user names a defect they observed, or asks for one written up ('report a bug', 'file a bug', 'write this up as a bug').","https:\u002F\u002Fgithub.com\u002Fmelodic-software\u002Fclaude-code-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Farchitecture\u002Fevals\u002Fdeepening-defect-goes-to-bugs-write\u002Fbugs-stub\u002Fskills\u002Fwrite\u002FSKILL.md",[],[]]