技能 Workflow Patterns
📦

Workflow Patterns

安全

إتقان سير عمل TDD باستخدام Conductor

هل تعاني من فوضى في سير عمل التطوير وضعف في تغطية الاختبارات؟ توفر هذه المهارة إطار عمل TDD منظم مع نقاط فحص للمراحل وإدارة commits لـ git وبروتوكولات تحقق لضمان جودة الكود طوال التنفيذ.

支持: Claude Codex Code(CC)
📊 69 充足
1

下载技能 ZIP

2

在 Claude 中上传

前往 设置 → 功能 → 技能 → 上传技能

3

开启并开始使用

测试它

正在使用“Workflow Patterns”。 ساعدني في إنشاء commit نقطة فحص بعد إكمال المرحلة 1

预期结果:

  • تشغيل التحقق الآلي...
  • مجموعة الاختبارات: نجح 47 اختباراً
  • التغطية: 87% (الهدف: 80%)
  • التنقيح: لا توجد أخطاء
  • تم إنشاء commit نقطة الفحص: def5678
  • تم تحديث الخطة مع checkpoint SHA
  • في انتظار موافقة التحقق اليدوي

正在使用“Workflow Patterns”。 وجهني خلال سير عمل TDD للمهمة 2.1

预期结果:

  • الخطوة 1: تحديد المهمة التالية - تم تحديد المهمة 2.1
  • الخطوة 2: وضع علامة قيد التنفيذ [~] في plan.md
  • الخطوة 3: RED - كتابة اختبارات فاشلة (test_validate_user_email)
  • الخطوة 4: GREEN - تنفيذ الحد الأدنى من الكود (validate_email method)
  • الخطوة 5: REFACTOR - استخراج الأنماط، تحسين التسمية
  • الخطوة 6: التحقق من أن التغطية >= 80%
  • الخطوة 7: توثيق أي انحرافات
  • الخطوة 8: إنشاء commit منظم
  • الخطوة 9: إرفاق ملاحظات git مع ملخص
  • الخطوة 10: تحديث plan.md مع commit SHA
  • الخطوة 11: commit تحديث الخطة

安全审计

安全
v1 • 2/25/2026

Static analysis detected 80 potential security issues in resources/implementation-playbook.md, all of which are false positives. The file contains Markdown documentation with bash code examples for educational purposes. The external_commands patterns are git command examples in code blocks (lines 25-571), not executable code. The weak_crypto findings are documentation text, not cryptographic implementations. This skill contains only documentation and no executable code, posing no security risk.

1
已扫描文件
622
分析行数
1
发现项
1
审计总数
中风险问题 (1)
External Command Patterns in Documentation
Static scanner detected Ruby/shell backtick execution patterns at 65 locations in resources/implementation-playbook.md. These are all bash code examples within Markdown code blocks demonstrating git commands (git commit, git notes, git diff, pytest, etc.) for educational purposes. No executable code exists.
审计者: claude

质量评分

38
架构
100
可维护性
87
内容
21
社区
100
安全
83
规范符合性

你能构建什么

تنفيذ ميزة جديدة باستخدام TDD

ينفذ المطور ميزة مصادقة مستخدم جديدة باتباع دورة red-green-refactor، مع تغطية اختبار مناسبة و git commits في كل خطوة.

إنشاء نقاط فحص للمراحل

ينشئ القائد التقني نقاط تحقق في نهاية كل مرحلة تطوير لضمان استيفاء بوابات الجودة قبل المتابعة.

تتبع تقدم التنفيذ

يتتبع المطور اكتمال المهمة عن طريق تحديث plan.md مع commit SHAs والحفاظ على إمكانية التتبع من التخطيط إلى الكود.

试试这些提示

بدء تنفيذ مهمة TDD
أبدأ المهمة 2.1: تنفيذ التحقق من صحة المستخدم. ساعدني في اتباع سير عمل TDD لكتابة اختبارات فاشلة أولاً، ثم تنفيذ الحد الأدنى من الكود للنجاح، وإعادة الهيكلة للوضوح.
إنشاء نقطة فحص للمرحلة
أكملت جميع المهام في المرحلة 1. ساعدني في إنشاء commit نقطة فحص مع التحقق: تشغيل مجموعة الاختبارات الكاملة، والتحقق من أن التغطية فوق 80%، وإنشاء قائمة تحقق للتحقق اليدوي.
تنسيق Git Commit منظم
ساعدني في إنشاء رسالة commit منظمة لإكمال المهمة 2.1 باتباع التنسيق: type(scope): subject، body مع نقاط تعداد، و footer مع مراجع المهمة/المسار.
معالجة انحراف التنفيذ
أثناء التنفيذ اكتشفت أننا بحاجة إلى نهج مختلف عن المخطط. ساعدني في توثيق هذا الانحراف بشكل صحيح في plan.md و tech-stack.md.

最佳实践

  • اكتب دائماً اختبارات فاشلة أولاً (RED) قبل التنفيذ (GREEN) - لا تتخطى مرحلة RED أبداً
  • أنشئ commits ذرية - تغيير منطقي واحد لكل commit مع نجاح الاختبارات بعد كل commit
  • انتظر موافقة المستخدم الصريحة قبل تجاوز نقاط فحص المرحلة - لا تتخطى بوابات التحقق
  • حدّث plan.md فوراً بعد إكمال كل مهمة مع commit SHA لإمكانية التتبع

避免

  • كتابة كود التنفيذ قبل الاختبارات - هذا ينتهك مبادئ TDD ويقلل من فعالية الاختبار
  • دمج مهام متعددة في commit واحد - هذا يكسر إمكانية التتبع ويجعل التراجع الدلالي صعباً
  • المضي في المرحلة التالية دون موافقة نقطة الفحص - هذا يتجاوز بوابات الجودة ويخاطر بتراكم الديون التقنية
  • تحديث plan.md فقط بعد مهام متعددة - هذا يفقد إمكانية التتبع ويجعل تدقيق التقدم صعباً

常见问题

ما هي دورة RED-GREEN-REFACTOR؟
RED تعني كتابة اختبارات فاشلة أولاً. GREEN تعني كتابة الحد الأدنى من الكود لاجتياز الاختبارات. REFACTOR تعني تحسين بنية الكود مع الحفاظ على نجاح الاختبارات. تضمن هذه الدورة أن الاختبارات تقود التطوير ويبقى الكود نظيفاً.
لماذا أحتاج إلى تسجيل commit SHAs في plan.md؟
تسجيل commit SHAs ينشئ إمكانية تتبع من الخطة إلى الكود. يمكّن من عمليات التراجع الدلالية، وتدقيق التقدم، ويساعدك على فهم أي كود ينفذ أي مهمة محددة.
هل يمكنني الانتقال إلى المرحلة التالية دون موافقة نقطة الفحص؟
لا. موافقة نقطة الفحص هي بوابة جودة حاسمة. المتابعة دون موافقة تخاطر بتراكم مشاكل غير مكتشفة. انتظر دائماً موافقة صريحة قبل الانتقال إلى المرحلة التالية.
ماذا يجب أن أفعل إذا انحرف التنفيذ عن الخطة؟
وثّق الانحراف في plan.md مع السبب والتأثير. حدّث tech-stack.md إذا تغيرت التبعيات. حدّث spec.md إذا تغيرت المتطلبات. هذا يحافظ على إمكانية تتبع القرارات.
لماذا أستخدم ملاحظات git بدلاً من وضع كل شيء في رسالة commit؟
ملاحظات git تحفظ سياقاً غنياً دون إرباك رسائل commit. تتيح استعلامات دلالية عبر commits وتدعم عمليات قائمة على المسارات مع الحفاظ على commits موجزة وسهلة المسح.
ما هو هدف التغطية 80% ولماذا هو مهم؟
هدف التغطية 80% يضمن اختباراً شاملاً للكود الجديد. يوازن بين الشمولية والواقعية - 100% غالباً غير فعّال من حيث التكلفة، لكن أقل من 80% يخاطر بفقدان المسارات الحرجة.