domains / families / software-engineering / debugging-toolkit-smart-debug

debugging-toolkit-smart-debug

combined

Diagnose software failures using observability data, ranked hypotheses, and targeted instrumentation. Use when the cause is unclear or an issue requires systematic investigation. Diagnose failures from reproduction steps, traces, logs and code; test hypotheses and verify a scoped fix without inventing production evidence.

When to use

• Working on debugging toolkit smart debug tasks or workflows
• Needing guidance, best practices, or checklists for debugging toolkit smart debug
• A reproducible failure or intermittent incident needs evidence-driven debugging.
• Existing telemetry must be compared with source and deployment changes before patching.

When not to use

• The task is unrelated to debugging toolkit smart debug
• You need a different domain or tool outside this scope
• No supporting scripts or references are bundled in this entrypoint. Tool availability and real trace results must be checked in the current environment.
• Use this skill only when the task clearly matches the scope described above.
• Do not treat the output as a substitute for environment-specific validation, testing, or expert review.
• Stop and ask for clarification if required inputs, permissions, safety boundaries, or success criteria are missing.

Skill page

Conflict

The two copies share the same 10-step debugging workflow, but they disagree on how to execute it. The rmyndharis copy mandates a specific subagent call and uses calibrated probability scores, while the sickn33 copy explicitly forbids inventing calibrated probabilities and requires authorization before using subagents or production techniques. The sickn33 copy also adds safety constraints (data redaction, rollback, and authorization checks) that the rmyndharis copy lacks. Because the sickn33 copy is a safety-hardened variant of the rmyndharis procedure, crowning one would hide the other's specific constraints or its more direct execution model.