القائمة
When the user reports a bug, error, or something not working. When there is a failing test or CI/CD failure. When the user sees an exception in logs or unexpected behaviour.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
| name | systematic-debugging |
| description | When the user reports a bug, error, or something not working. When there is a failing test or CI/CD failure. When the user sees an exception in logs or unexpected behaviour. |
| tools | ["read","exec","search"] |
Without a structured process, developers often guess at root causes and fix symptoms instead of the underlying problem — wasting time and leaving the bug latent. This skill prevents that by enforcing a 5-phase reproduce-locate-analyze-fix-verify cycle.
Never diagnose a bug you cannot consistently reproduce — it leads to fixing the wrong thing.
# Run the failing test to get a stable reproduction
pytest tests/test_foo.py::test_failing -v
Find where it breaks before analyzing why; narrowing the search space saves time.
Understand why it breaks — check assumptions, data types, and recent changes.
Correct the logic, add input validation guards, and add logging if the failure mode was hard to detect.
Confirm the fix is complete before declaring done.
pytest # all tests must pass, not just the originally failing one
❌ Guessing without reproducing first ❌ Fixing symptoms without finding root cause ❌ Declaring "fixed" without running the full test suite ❌ Skipping the minimal reproduction step
When the user wants to add a new feature or capability. When the user says "I want to build" or "I'm thinking about". When requirements are unclear and need to be refined.
When the user says they are ready for review or wants to create a PR. When the user asks to check if code is ready for review. When the task or feature is complete and needs quality validation.
When the user approves a plan and wants to execute it. When the user says "execute the plan" or "let's go" or "start implementation". When a PLAN.md exists and is ready to be executed task-by-task.
When the user is implementing a new feature or fixing a bug. When the user wants to write tests first before writing code. When the user is refactoring and needs to verify behaviour is preserved.
When the user wants to create an implementation plan. When the user says "let's implement this" or "create a plan". When a design has been approved and is ready to be broken into tasks.
Systematic code review workflow — evaluate changes for correctness, style, security, and test coverage before merging. When the user asks to review code or a pull request. When the user says "check code quality" or "look over this diff". When the user requests feedback on changes before merging.