flow-debugging
تصحيح الأخطاء بالطريقة المنهجية
يخمن المطورون غالباً حلولاً للأخطاء، مما يؤدي إلى انتكاسات وإهدار للوقت. تفرض هذه المهارة عملية تصحيح صارمة في 4 مراحل تتطلب التحقيق في السبب الجذري قبل أي تغييرات في الكود.
スキルZIPをダウンロード
Claudeでアップロード
設定 → 機能 → スキル → スキルをアップロードへ移動
オンにして利用開始
テストする
「flow-debugging」を使用しています。 Help me debug: My API returns 500 errors intermittently for user login requests.
期待される結果:
Let's start Phase 1: Root Cause Investigation.
## Step 1: Record Error Details
- Error type: HTTP 500 Internal Server Error
- Frequency: Intermittent (not every request)
- Impact: Users cannot log in during failures
## Step 2: Stable Reproduction
What conditions precede this error?
- Time of day? Load level? Specific user types?
## Step 3: Check Recent Changes
Run: git log --oneline -20
Run: git diff HEAD~5
What changed around when this started?
## Step 4: Trace Data Flow
Where does the login request flow break?
- Check logs for stack traces
- Identify the exact line throwing 500
STOP. Do NOT implement fixes yet. First, confirm root cause.
「flow-debugging」を使用しています。 I'm stuck. I've tried 3 fixes but the bug keeps coming back.
期待される結果:
Three failed fix attempts detected. This is a red flag. STOP and apply the methodology.
## Go Back to Phase 1
You likely fixed symptoms, not root cause.
## Questions to Answer
1. Did you reproduce before each fix?
2. Did you write failing tests first?
3. Did you verify root cause with evidence?
## Recommendation
- Roll back all recent changes
- Re-run Phase 1 systematically
- Only then proceed to Phase 2-4
The Iron Law applies: NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST.
セキュリティ監査
安全Documentation-only skill describing a 4-phase debugging methodology. All static findings are false positives: markdown code blocks flagged as shell execution, SHA256 hash strings flagged as crypto vulnerabilities, and relative documentation paths flagged as path traversal. No executable code exists.
品質スコア
作れるもの
إصلاح الأخطاء المعقدة بشكل منهجي
عند مواجهة أخطاء صعبة قاومت محاولات إصلاح متعددة، استخدم هذه المهارة للتراجع وتطبيق تحليل السبب الجذري الصارم قبل إجراء المزيد من التغييرات.
تعلم التصحيح المنهجي
يمكن للمطورين المبتدئين استخدام هذه المهارة لتعلم تقنيات التصحيح الاحترافية التي تؤكد على التحقيق القائم على الأدلة بدلاً من التخمين.
منع أنماط التصحيح المضادة
عندما تكتشف نفسك تقول 'دعني أجرب هذا'، استخدم هذه المهارة لإعادة التهيأة وتطبيق منهجية التصحيح المنظمة بدلاً من المحاولات العشوائية.
これらのプロンプトを試す
أواجه خطأ: [describe the error]. ساعدني في تصحيح هذا بشكل منهجي باستخدام عملية الـ 4 مراحل. ابدأ بالمرحلة 1: التحقيق في السبب الجذري. ماذا يجب أن أبحث عنه وأسجله؟
أعتقد أنني فهمت الخطأ. قبل تنفيذ الإصلاح، أرشدني خلال إنشاء حالة إعادة إنتاج مستقرة والتحقق من التغييرات الأخيرة باستخدام أوامر git.
لقد أعدت إنتاج الخطأ. الآن ساعدني في المرحلة 2: تحليل الأنماط. كيف أجد أمثلة مماثلة تعمل وأقارنها مع الكود المكسور؟
فرضيتي هي: [state hypothesis]. أرشدني خلال المرحلة 3: اختبار الفرضيات والمرحلة 4: تطبيق تطوير الاختبارات. ساعدني في كتابة اختبار فاشل أولاً.
ベストプラクティス
- أكمل دائماً المرحلة 1 (التحقيق في السبب الجذري) قبل كتابة أي كود إصلاح. المقاومة لهذه الخطوة علامة تحذيرية.
- اكتب اختباراً فاشلاً يُعيد إنتاج الخطأ قبل تنفيذ أي إصلاح. هذه 'الضوء الأحمر' في المرحلة 4.
- عندما تفشل 3+ محاولات إصلاح، توقف فوراً وابدأ من المرحلة 1. المشكلة أعمق مما تعتقد.
- وثق تحقيقك باستخدام القالب المنظم. التوثيق الواضح يمنع إعادة زيارة المشاكل التي تم حلها.
回避
- تصحيح القصف: تجربة تغييرات عشوائية حتى يعمل شيء ما. هذا ليس تصحيحاً، إنه تخمين.
- منهجية الإصلاح أولاً: تنفيذ الإصلاحات قبل فهم السبب الجذري. هذا يؤدي إلى الانتكاسات.
- تجاوز إعادة الإنتاج: محاولة الإصلاحات دون إنشاء خطوات إعادة إنتاج موثوقة أولاً.
- تجاوز التوثيق: قول 'أعرف ما الخطأ' بدون تحقيق قائم على الأدلة.