القائمة
Use when you hit any bug, test failure, or unexpected behavior - find the root cause before proposing a fix.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Use to build an approved detailed spec task by task in the current session - tests required, single-agent by default, subagents only for large or parallel tasks.
You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores intent, requirements, and design before implementation.
Use when implementation is complete and verified, to integrate the work - merge, PR, or cleanup - after a final evidence check.
Use after a design is approved in brainstorming, to turn it into one layered detailed spec (acceptance criteria, tasks, and how to verify) before touching code.
Use when starting any conversation - establishes how to find and use decentpowers skills and the workflow they form.
Use before claiming work is complete, fixed, or passing - runs the deterministic gate (tests, build, lint, types, acceptance) and one light judgment review, with evidence before any claim.
| name | debugging |
| description | Use when you hit any bug, test failure, or unexpected behavior - find the root cause before proposing a fix. |
Guessing wastes time and adds bugs. Find the root cause first, then fix it once.
Core principle: No fix before you understand the cause. A symptom patch is a failure, even when it makes the red go away.
Any test failure, crash, wrong output, performance cliff, build break, or "that's weird" - especially under time pressure, when a quick fix looks obvious, or when a previous fix did not hold. Simple bugs have root causes too.
Investigate. Read the error and stack trace completely - they often name the cause. Reproduce it reliably; if you cannot, gather more data rather than guess. Check what changed recently (git diff, recent commits, new deps/config). In a multi-component path, add instrumentation at each boundary and run once to see where it breaks before deciding why.
Trace to the source. Follow the bad value backward - where did it originate, what passed it in - until you reach the origin. Fix at the source, not where the symptom surfaced. Compare against a working example in the same codebase and list every difference; do not assume "that cannot matter".
One hypothesis at a time. State it: "I think X is the cause because Y." Make the smallest change that tests it - one variable. Did it work? If not, form a new hypothesis; do not stack fixes. If you do not understand something, say so and dig, do not pretend.
Fix at the root, with a test. Write a failing test that reproduces the bug and watch it fail (the test-first discipline from implementing). Make one root-cause fix, then verify: the test passes, nothing else broke, the issue is actually gone.
After 3 failed fixes, stop fixing. The pattern - each fix uncovers new coupling elsewhere, or needs "massive refactoring" - means the architecture is wrong, not the hypothesis. Raise it with your human partner instead of attempting fix #4.
"Quick fix now, investigate later" · "just try changing X" · several changes at once · "skip the test, I'll check by hand" · "it's probably X" · listing fixes before tracing the data flow · "one more attempt" after two failures.
