debug
Systematic Debugging
Overview
Random fixes waste time and create new bugs. Quick patches mask underlying issues.
Core principle: ALWAYS find root cause before attempting fixes. Symptom fixes are failure.
Violating the letter of this process is violating the spirit of debugging.
The Iron Law
NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST
If you haven't completed Phase 1, you cannot propose fixes.
When to Use
More from udecode/dotai
tdd
Test-driven development with red-green-refactor loop. Use when user wants to build features or fix bugs using TDD, mentions "red-green-refactor", wants integration tests, or asks for test-first development.
88changelog
Use when updating CHANGELOG.md. Enforces consistent formatting with bolded item names, dash separators, and specific section ordering.
19dig
Look up documentation and source code for libraries and packages. Use when the user asks a question about a library, needs to understand a library's API, or when you need information about a library that you don't know about. Triggers on questions like "How do I use X library?", "What's the API for Y?", "Show me how Z library handles this", or when encountering unfamiliar library usage.
18pr
Comprehensive GitHub pull request management - create regular/draft PRs with descriptions and commits, review PRs with severity ratings. Triggers on "create a PR", "make a draft PR", "review PR", or any PR workflow task.
11trace
Use when errors occur deep in execution and you need to trace back to find the original trigger - systematically traces bugs backward through call stack, adding instrumentation when needed, to identify source of invalid data or incorrect behavior
11learn
|
10