Loading blog posts...
Loading blog posts...
جاري التحميل...

نصف مكاسب "إنتاجية الذكاء الاصطناعي" هذه تختفي بعد حوالي 6 أسابيع، لأن الفرق تعود تدريجياً إلى Prompts لمرة واحدة وعادات مراجعة غير ثابتة. رأيت هذا يحدث أكثر من مرة. Claude Code Skills يقلب هذا السيناريو: يحوّل أفضل Prompts لديك إلى كتيبات عمل (Playbooks) مُرقّمة بالإصدارات وقابلة للاختبار، وتبقى صالحة حتى مع تغيّر الفريق في 2026.
إليك القالب العملي وقائمة التحقق التي تستخدمها الفرق للحصول على نتائج قابلة للقياس. نتحدث عن 80% أقل من Prompts لمرة واحدة، وحوالي 50% أسرع للوصول إلى أول مسودة، و30-40% أقل من دورات المراجعة عندما تطبق هذا بأسلوب تكراري ومع قياس فعلي (وليس "إحساساً عاماً").
bash# Minimal Claude Code Skill layout (portable across projects) skills/ api-contract-review/ SKILL.md templates/ contract-review.md references/ api-guidelines.md scripts/ lint_openapi.sh
هذا الهيكل هو الجزء "الممل" الذي يجعل Skills تعمل على نطاق واسع - وبصراحة، الملل هنا شيء جيد. ملف SKILL.md هو نقطة البداية. مجلد templates/ يحافظ على اتساق المخرجات. مجلد references/ يثبت المعايير. ومجلد scripts/ يجعل النتائج أكثر حتمية من الاعتماد على الـ prompting وحده (مثلاً: التحقق من OpenAPI قبل أن يعلّق Claude).
text# Skill: [SKILL_NAME] Version: [SEMVER] Owner: [TEAM_OR_PERSON] Scope: [ONE_SENTENCE_SCOPE] Non-goals: [WHAT_THIS_SKILL_WILL_NOT_DO] ## When to use - [TRIGGER_1] - [TRIGGER_2] ## Inputs (required) - [INPUT_1]: [FORMAT] (example: [EXAMPLE_VALUE]) - [INPUT_2]: [FORMAT] (example: [EXAMPLE_VALUE]) ## Outputs (exact) - Output A: [FILE_PATH_OR_FORMAT] - Output B: [FILE_PATH_OR_FORMAT] ## Acceptance criteria (must pass) - [CRITERION_1: measurable] - [CRITERION_2: measurable] - [CRITERION_3: measurable] ## Safety and compliance - Never request or output secrets like `API_KEY`, `JWT`, `PRIVATE_KEY`. - Redact PII (emails, phone numbers, addresses) unless explicitly provided and required. - Allowed sources: repo files + [APPROVED_INTERNAL_DOCS]. No browsing. ## Procedure (step-by-step) 1) Validate inputs. If missing, ask only for required fields. 2) Load repo context from `CLAUDE.md` and relevant files. 3) Execute deterministic checks (scripts/tools) if available. 4) Produce outputs using templates. Keep formatting stable. 5) Run self-check against acceptance criteria. Fix failures. 6) Provide a short "diff summary" and "next actions". ## Few-shot examples ### Example 1: Happy path Input: - [INPUT_1]=.. - [INPUT_2]=.. Expected output: -.. ### Example 2: Edge case Input: -.. Expected behavior: -.. ## Failure modes and recovery - If [COMMON_FAILURE]: do [RECOVERY_ACTION]. - If tool/script fails: report error + fallback approach. ## Changelog - [DATE] [VERSION]: [CHANGE_SUMMARY]
هذا القالب يفرض شيئين تغفل عنهما معظم Skills: معايير القبول والتعامل مع حالات الفشل. ومن تجربتي، هذان القسمان هما ما يقلل فعلاً دورات المراجعة، لأن Claude يستطيع أن يراجع نفسه ويصحح قبل أن يعيد العمل للبشر.
Important
[!IMPORTANT]
اجعل Scope ضيقاً. Skills التي تحاول "فعل كل شيء" تصبح غير متوقعة، وفي النهاية يتم التخلي عنها.
text# CLAUDE.md (repo root) Product: [PRODUCT_NAME] Architecture: [ONE_PARAGRAPH_SYSTEM_OVERVIEW] ## Conventions - Language/runtime: [NODE_20 | PYTHON_3_12 |..] - Formatting: [PRETTIER | BLACK | GOLANGCI-LINT] - Testing: [JEST | PYTEST |..] - Branching: [TRUNK | GITFLOW] ## Code review standards - Security: validate authz (authorization) paths and input validation. - Reliability: timeouts, retries, idempotency for external calls. - Observability: structured logs, metrics, tracing where relevant. ## Guardrails - Do not output secrets or internal tokens. - Do not invent endpoints, tables, or config keys not present in repo. - If uncertain: ask for the missing file or point to the exact assumption. ## Approved sources - Repo files - `docs/` and `adr/` - Internal spec: [SPEC_PATH_OR_NAME] ## Skill registry (optional) - skills/api-contract-review - skills/pr-risk-triage - skills/migration-plan-writer
أحب أن أتعامل مع CLAUDE.md كأنه "الدستور"، وكل Skill كأنها "قانون". إذا تخطيت CLAUDE.md، تبدأ Skills بالانحراف ببطء بين المستخدمين والواجهات (Claude.ai مقابل Claude Code)، وتتوقف الجودة عن كونها قابلة للتكرار. هذا الانحراف خادع - غالباً لا تلاحظه إلا بعد بضعة أسابيع.
Tip
[!TIP]
ضع قواعد "لا تختلق" في CLAUDE.md، وليس داخل كل Skill. هذا يقلل التكرار ويحافظ على ثبات الضوابط.
textClaude Code Skill Checklist (ship-ready) [ ] Scope هو مهمة واحدة مع Trigger واضح (وليس دوراً مثل "Senior Engineer") [ ] Inputs واضحة ويتم التحقق منها (الصيغ + أمثلة) [ ] Outputs مسماة وثابتة (ملفات، أقسام، schemas) [ ] Acceptance criteria قابلة للقياس (lint ينجح، اختبارات تُضاف، الصيغ تطابق) [ ] Procedure خطوة بخطوة مع فحوصات حتمية حيثما أمكن [ ] Few-shot examples تتضمن على الأقل 1 edge case و1 failure recovery [ ] قسم السلامة يغطي الأسرار + PII + المصادر المسموحة [ ] تم اختبارها على الواجهات المستهدفة (Claude Code وأي عميل آخر مستخدم) [ ] مُرقّمة بالإصدارات مع changelog ومالك [ ] Metrics محددة (time-to-first-draft, review cycles, defect rate)
استخدم هذه القائمة أثناء مراجعة PR الخاصة بالـ Skill نفسها. الفكرة بسيطة: إذا تعاملت مع Skills كأنها كود إنتاجي (مراجعة، إصدار، قياس)، ستتصرف ككود إنتاجي.
textAnti-pattern test If SKILL.md exceeds ~200-300 lines, split it into: - one Skill that produces a structured artifact - one Skill that reviews that artifact - one Skill that applies changes
Skills الطويلة تميل إلى إخفاء متطلبات متعارضة. التقسيم حسب حدود الـ artifact يجعل المخرجات قابلة للاختبار. بالإضافة إلى ذلك، يجهزك لفكرة "فرق الوكلاء" حيث تولّد Skill شيئاً وتتحقق Skill أخرى منه.
text# Skill: pr-risk-triage Version: 1.0.0 Scope: Classify PR risk and produce a review checklist tailored to the diff. Inputs: - PR_DIFF: unified diff text or list of changed files - CONTEXT: optional notes (deployment, incident, deadline) Outputs: - Risk report: Markdown with risk score 1-5 and rationale - Review checklist: bullet list mapped to changed areas Acceptance criteria: - Mentions authn/authz impacts if any security-sensitive files changed - Flags data migrations and backward compatibility risks - Includes at least 5 checklist items for risk >= 3 Procedure: 1) Identify touched components and runtime boundaries. 2) Map changes to risk dimensions: security, data, availability, cost. 3) Produce a risk score 1-5 with 3 supporting reasons. 4) Generate a targeted checklist with file-level pointers. 5) Self-check: ensure checklist covers the top 3 risks.
هذه Skill تنجح لأنها تنتج مخرجين يمكن للمراجعين استخدامهما فوراً. كما أنها تمنح الفريق لغة موحدة للمخاطر (قد يبدو هذا تفصيلاً صغيراً، لكنه يساعد كثيراً).
text# Skill: api-contract-review Scope: Review an OpenAPI spec for correctness, consistency, and backward compatibility. Inputs: - OPENAPI_PATH: path like `openapi.yaml` - CHANGE_INTENT: one sentence describing what changed Outputs: - Review notes: Markdown grouped by severity (blocker, major, minor) - Patch suggestions: exact YAML snippets for fixes Acceptance criteria: - Validates required fields, response codes, and schema references - Flags breaking changes (removed fields, changed types, removed endpoints) - Provides at least 1 concrete patch snippet for each blocker
اربطها مع script مثل scripts/lint_openapi.sh لتحويل المراجعة من شيء "ذوقي" إلى بوابة قابلة للتكرار.
text# Skill: migration-plan-writer Scope: Produce a step-by-step migration plan with rollback and verification. Inputs: - CHANGE_DESCRIPTION: what is changing - SYSTEMS: services, DBs, queues involved - CONSTRAINTS: downtime allowed, rollout window Outputs: - Migration plan: phases with commands, checks, owners - Rollback plan: explicit revert steps - Verification plan: metrics and log queries to confirm success Acceptance criteria: - Includes pre-flight checks and post-deploy validation - Includes rollback steps that can be executed in under [X] minutes - Calls out irreversible steps explicitly
هنا تتفوق Skills على الـ prompting العشوائي: وجود صيغة ثابتة للخطة يجعل الموافقات أسرع وأكثر أماناً.
python# scripts/run_tests.py - deterministic harness a Skill can call conceptually import subprocess import sys def run: p = subprocess.run(["pytest", "-q"], capture_output=True, text=True) print(p.stdout) print(p.stderr, file=sys.stderr) return p.returncode if __name__ == "__main__": raise SystemExit(run)
text# Skill: fix-failing-tests Scope: Fix failing unit tests with minimal changes and clear rationale. Inputs: - FAIL_OUTPUT: raw test output - TARGET: optional path like `tests/` Outputs: - Patch: code changes only - Explanation: 5-10 lines mapping failures to fixes Acceptance criteria: - Does not weaken assertions unless justified - Adds/updates tests when behavior changed - Mentions root cause category: logic bug, race, mock drift, fixture mismatch
وجود harness حتمي مع معايير قبول واضحة يمنع الفشل الكلاسيكي: "نجعل الاختبارات خضراء بحذف assertions". (كلنا رأينا هذا الـ PR.)
text# Skill: authz-regression-scan Scope: Identify authorization regressions and missing checks in a diff. Inputs: - PR_DIFF - AUTH_MODEL: file paths to policy docs or middleware Outputs: - Findings: Markdown with severity and exploit scenario - Fix suggestions: code-level recommendations referencing exact files Acceptance criteria: - Flags new endpoints missing auth middleware - Flags direct object reference risks (IDOR) when resource IDs are used - Mentions logging/alerting gaps for sensitive actions
هذه Skill مفيدة لأنها تُشفّر نموذج auth الخاص بالفريق مرة واحدة، ثم تطبقه باستمرار.
text# Skill: a11y-review Scope: Review UI changes for accessibility issues and provide fixes. Inputs: - DIFF - COMPONENT_LIBRARY: name + link/path in repo Outputs: - Issues list: WCAG-aligned categories (labels, focus, contrast, semantics) - Fix snippets: JSX/TSX examples Acceptance criteria: - Mentions keyboard navigation and focus management for interactive components - Flags missing labels/aria attributes for inputs and buttons - Provides at least 3 concrete code snippets when issues exist
هذه Skill تأثيرها كبير لأنها تلتقط المشاكل قبل QA، عندما تكون الإصلاحات أرخص.
text# Skill: release-notes-from-diff Scope: Generate customer-facing and internal release notes from a diff or changelog. Inputs: - CHANGESET: diff, PR list, or changelog entries - AUDIENCE: `external` or `internal` Outputs: - Release notes: Markdown sections (Added, Changed, Fixed, Deprecated) Acceptance criteria: - Avoids internal jargon for external notes - Includes at least 1 "Impact" line for breaking changes - Lists known limitations explicitly if present in changeset
هذه Skill تقلل فوضى اللحظات الأخيرة وتجعل الإصدارات أكثر اتساقاً.
text# Skill: doc-code-alignment Scope: Detect mismatches between docs and implementation and propose updates. Inputs: - DOC_PATHS: list like `docs/api.md` - CODE_PATHS: list like `src/api/` Outputs: - Mismatch report: table of doc claim vs code reality - Patch suggestions: doc edits with exact replacements Acceptance criteria: - Includes at least 5 doc claims checked against code - Marks each mismatch as: outdated, ambiguous, incorrect, missing - Proposes patches that preserve doc tone and structure
طريقة عملية لإبقاء الوثائق دقيقة دون الحاجة إلى sprint مخصص للوثائق.
text# Skill: skill-generator Scope: Generate a new Skill folder from a short spec and 2 examples. Inputs: - SKILL_NAME - TASK_SCOPE - INPUTS - OUTPUTS - 2_EXAMPLES: happy path + edge case Outputs: - `skills/[SKILL_NAME]/SKILL.md` - Optional `templates/` skeleton Acceptance criteria: - Includes acceptance criteria and failure recovery - Includes at least 2 few-shot examples - Includes safety and allowed sources section
Meta Skills هي مضاعف 2026 - توحّد طريقة توحيد الفرق لمعاييرها (فكرة "ميتا" قليلاً، لكنها تعمل).
text# Skill: incident-summary Scope: Turn logs, timeline notes, and metrics into a structured incident summary. Inputs: - TIMELINE: bullet notes with timestamps - IMPACT: users affected, duration, financial impact if known - ROOT_CAUSE: known or suspected - ACTION_ITEMS: raw list Outputs: - Summary: 5 sections (Impact, Timeline, Detection, Root cause, Actions) - Action items: rewritten as SMART tasks with owners and due dates Acceptance criteria: - Timeline includes detection time and mitigation time - Action items each include an owner role and measurable completion criteria - Separates contributing factors from root cause
هذه Skill تجعل تقارير الحوادث متسقة، وهذا يجعل عمل الوقاية أسهل في المتابعة.
| Mechanism | Strength | Weakness | Best for |
|---|---|---|---|
| Skills | Playbooks قابلة للتكرار ومُرقّمة بالإصدارات مع أمثلة وضوابط | تحتاج صيانة واختبار | المراجعات، توليد الملفات، SOPs، سير عمل حتمي |
| Slash commands | اختصارات سريعة وارتجالية | صعبة التوحيد والترقيم بالإصدارات | إجراءات سريعة وإنتاجية شخصية |
| Subagents | تنفيذ متوازٍ وتخصص | عبء تنسيق | مسارات فرز (Triage) متعددة، تحليل متعدد الخطوات، سير عمل متعدد الأدوار |
| Plugins/integrations | وصول فعلي للأنظمة | تعقيد أمني وحوكمة | التذاكر، إشارات CI، بيانات repo، External APIs |
الخطأ الذي تكرره الفرق في 2026 هو استخدام subagents لسير عمل كان يجب أن يكون مجرد Skill. قاعدتي: إذا كان يتكرر أسبوعياً، فهو ينتمي إلى Skill. وإذا كان يحتاج وصولاً فعلياً للأنظمة، فغالباً يحتاج integration.
textSkill test harness concept (copyable checklist) - Given: fixed input fixture (diff, spec, logs) - When: run Skill vX.Y.Z - Then: output matches template + passes acceptance criteria - And: no policy violations (secrets, PII, invented facts)
الجدول الزمني للتبني: المتبنون الأوائل يقومون بالفعل بـ fixtures يدوية. وبحلول أواخر 2026، ستخزن الفرق fixtures داخل repo وتراجع تغييرات Skills كما تراجع الكود.
ماذا يعني هذا: تعامل مع تحديثات Skill كأنها تغييرات كاسرة أو غير كاسرة. رقّمها بالإصدارات. وتتبع ثبات المخرجات.
زاوية مخالفة: الاختبارات الصارمة قد تؤدي إلى overfitting وتقلل الإبداع. الحل (أو بالأدق التوازن) هو اختبار البنية والقيود، لا الكلمات حرفياً.
textPrompt-wiki migration plan 1) Identify top 20 copied prompts from wiki/chat exports 2) Convert each into a Skill with acceptance criteria 3) Add 2 examples and 1 edge case 4) Put owners on each Skill 5) Deprecate wiki pages with a pointer to Skill path
ماذا يعني هذا: مكتبات الـ prompts الداخلية ستنتقل من صفحات ثابتة إلى playbooks قابلة للتنفيذ. القيمة الحقيقية هي الحوكمة وقابلية التكرار، وليس مجرد الراحة.
حجم النظام البيئي المعلن يدعم ذلك بالفعل: أكثر من 50 Skill رسمية و350+ قالباً مجتمعياً. هذا الحجم يدفع المؤسسات إلى تنظيم الكتالوجات بموافقات ومالكين وإعدادات افتراضية آمنة.
ماذا يعني هذا: توقع قوائم "Skills معتمدة" لكل مجال: الأمن، البيانات، المنصة، الواجهة الأمامية. ستظل Skills غير المعتمدة موجودة، لكنها لن تُستخدم في سير عمل منظم أو خاضع للامتثال.
زاوية مخالفة: الكتالوجات المركزية قد تبطئ الفرق. النموذج المتوازن هو "sandbox Skills" مع "approved Skills" ومعايير ترقية واضحة.
textHigh-ROI Skill backlog (ranked) 1) PR risk triage 2) Security/authz regression scan 3) Migration plan writer 4) API contract review 5) Incident summary
ماذا يعني هذا: توليد الكود هو الجزء اللامع، لكن المراجعة والتخطيط يقللان العيوب وإعادة العمل. من هنا تأتي عادة نسبة 30-40% أقل من دورات المراجعة في التجارب.
textAgent team handoff contract Agent A output: `templates/spec.md` Agent B input: that file + acceptance criteria Agent C output: patch + tests Final gate: review Skill validates criteria and formats
ماذا يعني هذا: تنسيق الوكلاء دون artifacts ثابتة يتحول إلى فوضى. Skills تمنحك نقاط تسليم ثابتة وتبقي الـ pipeline قابلاً للتشخيص.
text2-week pilot scorecard - Baseline: - one-off prompts per engineer per week - time-to-first-draft for PR description / migration plan / review notes - review cycles per PR (number of "changes requested" rounds) - After 2 weeks: - same metrics + qualitative notes on failure modes - Target outcomes: - 30% reduction in review cycles on pilot repos - 25-50% faster time-to-first-draft for selected artifacts
هذا يتجنب مقاييس "الزينة" مثل "عدد tokens المستخدمة". بدلاً من ذلك، تتبع زمن الدورة وتذبذب المراجعات.
حققت Netflix تحسناً بمقدار 2x في أزمنة البناء عبر توحيد CI وسير عمل المطورين، وهذا يذكّرنا بأن playbooks القابلة للتكرار تتفوق على الإصلاحات الارتجالية. تشتهر Stripe باتساق قوي في API عبر عمليات مراجعة منضبطة، وهو تشابه قريب لما تفرضه Skills لمراجعة عقد API. كما أكدت Shopify علناً على إنتاجية المطورين عبر أدوات ومعايير موحدة، وهو ما يتماشى مع نموذج "CLAUDE.md + Skills" لتقنين المعايير.
استخدم هذه الأمثلة للمعايرة: المكسب هو التوحيد وقابلية التكرار، وليس "Prompts أذكى".
Warning
[!WARNING] لا تنشر Skills على مستوى المؤسسة دون مالكين. Skills بلا مالك تتدهور بسرعة، ويتوقف الناس عن الثقة بالنظام كله.
textStability fix - Add templates for outputs - Add acceptance criteria that can be checked by reading the output - Add a self-check step that explicitly verifies each criterion
إذا كانت المخرجات تتغير كثيراً، سيتوقف المراجعون عن الثقة بها. القوالب مع self-check تعيد قابلية التوقع.
textCompliance fix snippet Safety and compliance - Never output secrets: `API_KEY`, `JWT`, `PRIVATE_KEY`, `.env` contents - Redact PII unless required and provided - Allowed sources: repo files only - If missing context: ask for file paths, not "best guesses"
ضع هذا في كل Skill إلى أن يصبح CLAUDE.md ناضجاً ومطبقاً باستمرار. (نعم، هو متكرر. وهذا جزء من الفكرة في البداية.)
textCross-surface test protocol 1) Run the Skill in Claude Code on a real repo task 2) Run it in the other surface your team uses 3) Compare: output structure, missing context, tool assumptions 4) Patch SKILL.md to remove surface-specific dependencies
اختلاف السلوك طبيعي. الاختبار عبر الواجهات هو ما يجعل Skill قابلة للنقل.
ابدأ من هنا (خطوتك الأولى)
أنشئ CLAUDE.md في repo واحد وأضف 10 نقاط conventions plus 5 guardrails.
مكاسب سريعة (تأثير فوري)
SKILL.md template، مع مثالين و3 معايير قبول لكل واحدة.pr-risk-triage) واجعلها مطلوبة على 10 PRs، ثم قِس دورات المراجعة قبل وبعد.تعمق أكثر (لمن يريد المزيد)
skill-generator واستخدمها لإنشاء 10 Skills جديدة خلال أسبوع، ثم أوقف صفحات الويكي المكافئة مع الإشارة إلى مسار Skill.SEMVER.في 2026، الميزة التنافسية لن تكون "من لديه أفضل نموذج". ستكون لمن تستطيع فرقه تحويل العمل الجيد إلى Skills قابلة لإعادة الاستخدام، مُرقّمة بالإصدارات، وبمعايير قبول قابلة للقياس.
أسرع طريق بسيط: ابدأ بـ CLAUDE.md، أطلق 3 Skills ضيقة النطاق، قِس دورات المراجعة، ثم كرر التحسين كما تفعل مع أي نظام إنتاجي.
للمزيد حول تحويل الـ prompts إلى نتائج قابلة للتكرار، راجع Best AI Tools for Productivity in 2025: Transform Your Workflow وAI Revolution 2025: The Breakthrough Models That Are Changing Everything.