菜单
Use when the user reports a bug they can't reproduce, asks where to start debugging, or mentions a Heisenbug / production-only failure. Drives the observe→hypothesize→predict→test→iterate scientific method.
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/Tibsfox/gsd-skill-creator --skill debugging-testing命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
Use the moment a request is underspecified and you are about to act on an ASSUMED goal. Enumerate the candidate goals the request could mean, project the action or artifact each one implies, and check whether they diverge: if two or more plausible goals lead to materially different actions or artifacts, ask exactly ONE targeted clarifying question; otherwise proceed on the most-likely goal and state the assumption in one line. Clarification is an evidence-producing action, not a delay — but one question, never an interrogation. Distinct from gsd-spec-phase (GSD-phase-bound, emits a heavy SPEC.md) and intent-router (fetch strategy, not goal disambiguation). Backed by agent goal-state inference (arxiv 2606.16813v1). Triggers on acting under an assumed goal when the request admits more than one materially different reading.
Use at write time to vector/embedding memory — Grove content-addressed insertion, chroma/pgvector upserts, memory-consolidation promoting session traces to MEMORY.md, or embedding externally-ingested content. Scores each candidate record against a fixed panel of sentinel queries and quarantines any record that would become the nearest neighbor of too many unrelated queries — a hub — whether from adversarial poisoning or accidental over-generality. This is the memory-record-side sibling of skill-injection-guardian (file-side) and the write-side complement of memory-use-warrant (read-side). Quarantine, never silently drop; a human reviews. Backed by the admission-time hubness gate (arxiv 2606.19692v1). Triggers on inserting into vector memory, consolidating memory, and embedding stranger content.
Run this appropriateness check the moment you are about to integrate a retrieved long-term memory — a Grove content-addressed hit, a chroma/pgvector neighbour, a memory-consolidation digest, or a MEMORY.md line — into a response, especially anything touching private origins, Fox Companies IP, credentials, or Center Camp / consent-governed content. It answers a question intent-router never asks: not WHAT to fetch or HOW, but WHETHER a correctly-retrieved item should reach output. Relevance is not appropriateness — a perfect similarity match can still be a boundary violation. Default is FAIL-CLOSED: if in-context authorization is uncertain, the memory may inform behaviour but must not be surfaced. Backed by RBI-Eval (arxiv 2606.06055v1). Triggers on surfacing recalled sensitive memory into a response.
正在显示 SKILL.md
基于 SOC 职业分类
| name | debugging-testing |
| description | Use when the user reports a bug they can't reproduce, asks where to start debugging, or mentions a Heisenbug / production-only failure. Drives the observe→hypothesize→predict→test→iterate scientific method. |
| description-frequency | on-demand |
| type | skill |
| category | coding |
| status | stable |
| origin | tibsfox |
| modified | false |
| first_seen | "2026-04-12T00:00:00.000Z" |
| first_path | examples/skills/coding/debugging-testing/SKILL.md |
| superseded_by | null |
A program without tests is a hypothesis. A program with bugs and no debugging strategy is a mystery. This skill catalogs systematic approaches to both: finding defects (debugging) and preventing them (testing). The emphasis is on method over intuition -- debugging and testing are engineering disciplines with established techniques, not arts that depend on talent.
Agent affinity: hopper (coined "debugging" when she found a moth in the Mark II), dijkstra (program correctness as a mathematical property)
Concept IDs: code-debugging-strategies, code-iterative-development, code-peer-review
A bug is a hypothesis falsifier: your mental model of the program says X should happen, but Y happens instead. Debugging is the process of updating your mental model until it matches reality.
This is the scientific method applied to code. The most common debugging mistake is skipping step 2 -- changing things at random hoping the bug disappears. Random changes do not build understanding. They may mask the bug or introduce new ones.
In 1947, operators of the Harvard Mark II found a moth trapped in a relay, causing a malfunction. Grace Hopper taped the moth into the logbook with the note "First actual case of bug being found." The term "debugging" predates this incident, but Hopper's story crystallized the concept: finding and removing defects is a first-class engineering activity, not a sign of failure.
Hopper's broader contribution to debugging was the invention of the compiler. Before compilers, programs were written in machine code, and every error was a numerical one. Compilers introduced symbolic names, structured control flow, and -- critically -- error messages. The compiler was the first automated debugging tool.
Technique: Insert print statements or log calls at strategic points to observe the program's state as it executes.
When to use. First response for any bug. Fast to deploy, works in any language, requires no special tools. Especially valuable in environments where interactive debuggers are impractical (distributed systems, embedded systems, CI pipelines).
Best practices.
Limitation. Heisenbug risk: adding print statements can change timing, which may mask concurrency bugs.
Technique: Pause execution at breakpoints, inspect variables, step through code line by line.
Tools. GDB (C/C++), LLDB (C/C++/Rust), pdb (Python), Chrome DevTools (JavaScript), VS Code debugger (multi-language).
Key operations.
i == 999).When to use. Complex control flow where printf would require dozens of statements. Inspecting data structures that are hard to print (circular references, large trees). Understanding unfamiliar code.
Technique: Narrow the problem to the smallest possible scope by halving the search space at each step.
Application to time. If a bug appeared recently, use git bisect to binary-search through commits: mark a known-good commit and a known-bad commit, test the midpoint, repeat. In O(log n) steps, find the exact commit that introduced the bug.
Application to code. Comment out half the code. Does the bug persist? If yes, the bug is in the remaining half. If no, the bug is in the commented half. Repeat.
Application to data. If the bug occurs with a large input, halve the input. Does the bug persist? Binary search to find the minimal reproducing input.
Technique: Explain the code, line by line, to an inanimate object (traditionally a rubber duck). The act of articulating your assumptions often reveals the one that is wrong.
Why it works. Reading code silently allows your brain to skip over details. Speaking forces you to process each line consciously. The mismatch between what you say and what the code does surfaces the bug.
Formal variant. Code review. Explaining your code to a colleague achieves the same effect with the added benefit of a second perspective.
Technique: Record program execution and replay it, stepping backward and forward through time.
Tools. rr (Linux, C/C++/Rust), Replay.io (JavaScript), IntelliJ's step-back feature.
When to use. Concurrency bugs, non-deterministic failures, bugs that are hard to reproduce. Time-travel debugging eliminates the need to reproduce the bug -- you debug the exact execution that failed.
Technique: Automated binary search through git history to find the commit that introduced a bug.
Usage.
git bisect start
git bisect bad # Current commit has the bug
git bisect good abc1234 # This commit was known-good
# Git checks out the midpoint. Test it.
git bisect good # or: git bisect bad
# Repeat until the first bad commit is found.
git bisect reset # Return to original state
Automation. git bisect run ./test.sh -- provide a script that returns 0 for good and non-zero for bad. Git runs the binary search automatically.
Prerequisite. Each commit must be independently testable. This is one reason to keep commits small and atomic.
Scope: Test a single function, method, or class in isolation.
Characteristics. Fast (milliseconds per test), deterministic (no I/O, no network, no database), focused (one assertion per logical concept).
Isolation techniques. Mocks (simulate dependencies), stubs (provide canned answers), fakes (simplified implementations, e.g., in-memory database).
When to use. Every pure function. Every method with business logic. The foundation of the test pyramid.
Scope: Test the interaction between two or more components (e.g., service + database, API + authentication).
Characteristics. Slower than unit tests, may require real infrastructure (database, message queue), tests contracts between components.
When to use. Validating that the database layer correctly persists and retrieves data. Ensuring that API endpoints handle real HTTP requests. Testing message serialization/deserialization across service boundaries.
Scope: Test the entire system from the user's perspective. UI clicks through backend to database and back.
Characteristics. Slowest, most brittle (sensitive to UI changes, timing, environment), most realistic.
Tools. Playwright, Cypress, Selenium (web), Appium (mobile).
When to use. Sparingly. Cover the critical user journeys (signup, purchase, core workflow). Too many E2E tests create a slow, flaky test suite that developers learn to ignore.
Scope: Verify that the system meets the business requirements as specified by stakeholders.
Relationship to levels. Acceptance tests can run at any level (unit, integration, E2E) depending on what is being verified. They are defined by intent (does the system do what the business needs?) rather than technique.
/ E2E \ Few, slow, brittle
/----------\
/ Integration \ Some, medium speed
/----------------\
/ Unit Tests \ Many, fast, focused
Invert the pyramid (many E2E, few units) and you get a slow, fragile, expensive test suite. The pyramid structure maximizes confidence per test-dollar.
Repeat. Each cycle takes minutes, not hours. The test suite grows with the code, providing continuous regression protection.
Technique: Divide the input space into classes where the program should behave identically. Test one representative from each class.
Example. A function that grades scores 0-100: F (0-59), D (60-69), C (70-79), B (80-89), A (90-100). Test one value from each partition: 45, 65, 75, 85, 95.
Technique: Test at the edges of equivalence partitions, where off-by-one errors concentrate.
Example. For the grading function above: 0, 59, 60, 69, 70, 79, 80, 89, 90, 100. Also test just outside the valid range: -1, 101.
Technique: Instead of specifying individual test cases, specify properties that must hold for all inputs. The testing framework generates hundreds or thousands of random inputs and checks the property.
Tools. Hypothesis (Python), fast-check (JavaScript/TypeScript), QuickCheck (Haskell, original), proptest (Rust).
Example properties.
sort(list) has the same length as list.sort(list) contains the same elements as list.sort(list) is non-decreasing.reverse(reverse(list)) == list.parse(serialize(obj)) == obj (round-trip).Shrinking. When a failing input is found, the framework automatically simplifies it to the minimal reproducing case. This is enormously valuable for debugging.
Technique: Automatically introduce small changes (mutations) to the code -- change + to -, flip < to <=, delete a line. If the test suite still passes, it has a gap: the mutant "survived." Kill rate measures test suite thoroughness.
Tools. Stryker (JavaScript/TypeScript), mutmut (Python), pitest (Java).
Interpretation. A high kill rate (>80%) indicates thorough testing. Surviving mutants reveal specific untested behaviors.
Sampling profiler. Periodically records which function is executing. Low overhead, statistical accuracy. Identifies hot functions (where most time is spent).
Instrumentation profiler. Records entry and exit of every function. High overhead, exact counts. Identifies call frequency and per-call duration.
Tools. perf (Linux), Instruments (macOS), py-spy (Python), clinic.js (Node.js), cargo-flamegraph (Rust).
Heap profiling. Track allocations, find memory leaks (objects that grow without bound), identify excessive allocation churn.
Tools. Valgrind/Massif (C/C++), tracemalloc (Python), Chrome DevTools heap snapshot (JavaScript), DHAT (Rust via Valgrind).
Visualization. A flame graph shows the call stack with width proportional to time spent. Wide bars at the top are the hot functions. The shape reveals whether the time is spent in one deep call chain or spread across many.
Reading a flame graph. The x-axis is NOT time -- it is the alphabetical sort of stack frames at each depth. Width is the cumulative time. Look for wide plateaus (optimization targets) and unexpected width (functions that should be fast but are not).
| Symptom | First technique | Why |
|---|---|---|
| Wrong output, simple function | Printf + unit test | Fast feedback, isolate the logic |
| Wrong output, complex flow | Interactive debugger | Step through the decision path |
| Recent regression | Git bisect | Find the exact commit |
| Intermittent failure | Logging + time-travel debug | Capture the non-deterministic execution |
| Performance degradation | CPU profiler + flame graph | Identify the hot path |
| Memory growth | Heap profiler | Find the leak |
| Concurrency bug | Thread sanitizer + rr | Detect races, replay exact execution |
| "It works on my machine" | Environment diff + integration test | Isolate the environmental dependency |
| Mistake | Why it fails | Fix |
|---|---|---|
| Testing implementation, not behavior | Tests break on refactoring | Test the public interface, not internal details |
| 100% code coverage as a goal | Coverage measures lines executed, not correctness | Aim for meaningful coverage of behavior, not line count |
| Flaky tests left unfixed | Team learns to ignore test failures | Fix or delete flaky tests immediately |
| No test isolation | Tests depend on each other's state | Each test sets up and tears down its own state |
| Debugging by random changes | No understanding of the bug | Apply the scientific method: hypothesize, predict, test |
| Skipping the minimal reproduction | Debugging a complex system when the bug is in one function | Reduce to the smallest failing case before debugging |
| Over-mocking | Tests pass but code fails in production | Use integration tests for interaction boundaries |