safe-debug
PopularRigor Debug / Rigor Audit skill for deep learning research work. Use when the user pastes a traceback, terminal error, CUDA OOM, checkpoint load failure, shape mismatch, NaN loss symptom, or training failure and wants conservative diagnosis before any patching, with debug fixes clearly separated from research contributions. Do not use for broad refactoring, speculative adaptation, automatic exploratory patching, or general repository familiarization.
Rigor Debug / Rigor Audit skill for deep learning research work. Use when the user pastes a traceback, terminal error, CUDA OOM, checkpoint load failure, shape mismatch, NaN loss symptom, or training failure and wants conservative diagnosis before any patching, with debug fixes clearly separated from research contributions. Do not use for broad refactoring, speculative adaptation, automatic exploratory patching, or general repository familiarization.
safe-debug
Use this as the Rigor Debug / Rigor Audit skill. The installed slug remains
safe-debug for compatibility.
Use the shared operating principles in
../../references/agent-operating-principles.md; this skill should guide
conservative diagnosis without blocking the model from finding the local root
cause.
When to apply
- The user provides a traceback, terminal error, or concrete training or inference failure symptom.
- The user wants diagnosis, root-cause narrowing, and minimal patch suggestions before code is changed.
- The user wants a safe debug flow with explicit human approval before mutation.
When not to apply
- When the user wants a broad repository walkthrough without an active failure.
- When the task is speculative experimentation or code adaptation.
- When the user is asking for a large refactor or readability rewrite.
Clear boundaries
- Diagnose first.
- Do not modify repository code by default.
- If a patch is needed, propose the smallest fix and require explicit approval first.
- Escalate savepoint or branch creation before medium-risk or high-risk changes.
- A debug fix is not automatically a research contribution; if it changes
experiment meaning or comparability, say so explicitly.
Output expectations
debug_outputs/DIAGNOSIS.mddebug_outputs/PATCH_PLAN.mddebug_outputs/status.json
Notes
Use references/debug-policy.md, ../../references/research-rigor-principles.md, and the shared references/research-pitfall-checklist.md.
You Might Also Like
Related Skills
receiving-code-review
Use when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performative agreement or blind implementation
obrarequesting-code-review
Use when completing tasks, implementing major features, or before merging to verify work meets requirements
obra
hyperframes-animation
All animation knowledge for HyperFrames — atomic motion rules, multi-phase scene blueprints, scene transitions, broader motion-design techniques, AND the seven runtime adapters (GSAP default, plus Lottie, Three.js, Anime.js, CSS keyframes, Web Animations API, TypeGPU). Use for any motion or animation task: pick 2-4 rules and compose, or load a blueprint, or look up runtime-specific API (e.g. GSAP eases / Lottie player / Three.js mixer). HyperFrames-native: single paused timeline, seek-safe, deterministic.
heygen-compr-to-video
turn a GitHub pull request (a PR URL like github.com/<owner>/<repo>/pull/<N>, an <owner>/<repo>#<N> ref, or 'this PR' in a checked-out repo) into a code-change explainer video, up to ~3 min (sweet spot 30-90s) — changelog, feature reveal, fix, or refactor walkthrough, rendered from the diff / commits / files. The input is a CODE CHANGE read via the gh CLI; there is no website capture. Use this skill for a GitHub PR. Do not use it for a product launch/promo (use /product-launch-video), a tour of a real website (use /website-to-video), a topic explainer with no PR (use /faceless-explainer), captions on existing footage (use /embedded-captions), or a short unnarrated motion graphic (use /motion-graphics). If the intent is unclear, route through /hyperframes first.
heygen-com
golang-dependency-injection
Comprehensive guide for dependency injection (DI) in Golang. Covers why DI matters (testability, loose coupling, separation of concerns, lifecycle management), manual constructor injection, and DI library comparison (google/wire, uber-go/dig, uber-go/fx, samber/do). Use this skill when designing service architecture, setting up dependency injection, refactoring tightly coupled code, managing singletons or service factories, or when the user asks about inversion of control, service containers, or wiring dependencies in Go. For a specific DI library, → See `samber/cc-skills-golang@golang-google-wire`, `samber/cc-skills-golang@golang-uber-dig`, `samber/cc-skills-golang@golang-uber-fx`, or `samber/cc-skills-golang@golang-samber-do` skills.
sambergolang-samber-mo
Monadic types for Golang using samber/mo — Option, Result, Either, Future, IO, Task, and State types for type-safe nullable values, error handling, and functional composition with pipeline sub-packages. Apply when using or adopting samber/mo, when the codebase imports `github.com/samber/mo`, or when considering functional programming patterns as a safety design for Golang.
samber