Debugging lab notebook
Skill alinafe82/cognitive-deadlift/skills/debugging-lab-notebook
AI coding skills, hooks, and plugins that keep developers thinking instead of autopiloting
npx -y skills add alinafe82/cognitive-deadlift --skill debugging-lab-notebookAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Debug hard failures with reproduction, hypotheses, instrumentation, experiments, and regression proof. Use when bugs are flaky, poorly understood, production-facing, performance-related, or AI starts guessing fixes. NOT for simple bugs that already have a deterministic failing test.
SKILL.md
3.1 KB, as published. Nobody here has run it
Debugging Lab Notebook
Purpose
Turn hard debugging into a recorded experiment loop instead of a sequence of guesses.
Preserves
Systematic debugging and error interpretation.
Required Evidence
- Symptom and reproduction attempt.
- Logs, traces, metrics, failing command, or user report if available.
- Code area or workflow likely involved.
Failure Signs
- A patch is proposed before a hypothesis.
- Only one favored hypothesis is kept.
- Negative findings are dropped.
When To Use
- A bug is hard, flaky, or poorly understood.
- The failure crosses services, time, state, or concurrency boundaries.
- AI starts proposing fixes without a hypothesis.
- Negative findings need to be preserved.
When Not To Use
- Simple bugs that already have a failing test.
- Purely visual defects with an obvious screenshot reproduction.
- Incidents where immediate mitigation must happen before root-cause analysis.
Inputs Expected
- Symptom and reproduction attempt.
- Logs, traces, metrics, failing command, or user report if available.
- Code area or workflow likely involved.
- Constraints on instrumentation or environment access.
Output Expected
Reproduction:
Hypotheses:
Experiment:
Result:
Next hypothesis:
Regression proof:
Process
- Build the smallest available reproduction or observation signal.
- Write competing hypotheses.
- Add instrumentation that distinguishes between hypotheses.
- Run one experiment at a time.
- Record negative findings.
- Add regression proof after the fix.
Quality Bar
A good notebook lets another engineer see what was tried, what was ruled out, and why the final fix is credible.
Examples
Simple case: a CLI sometimes exits zero after failure. The skill should reproduce the command, list hypotheses around exception handling, and add a regression check.
Complex case: a worker drops messages under load. The skill should separate queue delivery, concurrency, retry, timeout, and persistence hypotheses before changing code.
See examples/simple.md and examples/edge-case.md.
Failure Modes
- Reproduction unavailable: define the next best observation point and explain the uncertainty.
- Flaky signal: measure frequency before and after changes.
- Logs contain sensitive data: request redacted or synthetic traces.
- Permissions missing: ask for specific command output rather than broad access.
Safety And Privacy
Do not expose raw production logs, tokens, customer data, internal hostnames, or private incident details. Remove exploratory instrumentation unless it is intentionally kept.
Anti-Slop Rules
- Do not patch before naming a hypothesis.
- Do not keep only one favored hypothesis.
- Do not drop negative findings.
- Do not claim root cause until the experiment supports it.