كيفية إعداد Spec Kit في Claude Code عام 2026: المواصفات بدلاً من الطلبات

ماذا حدث للبرمجة بأسلوب vibe coding في مايو 2026؟#

وبعد عام، في 4 فبراير 2026، نشر سلسلة منشورات استرجاعية:

وفي حديثه في Sequoia Ascent 2026، صاغ الفكرة بدقة أكبر: «ترفع vibe coding الحد الأدنى—أي مقدار ما يستطيع الجميع إنجازه في البرمجيات. أما الهندسة الوكيلة فتحافظ على السقف—مستوى الجودة في التطوير الاحترافي». وعلى المنصة نفسها، قال عبارة دخلت معجم المجال: «لا يحق لك إدخال ثغرات بسبب vibe coding. ما زلت مسؤولاً عن برمجياتك كما كنت من قبل».

حدث أمران بالتوازي. في سبتمبر 2025، نشرت GitHub أداة Spec Kit—وحصدت 107,000 نجمة في 8 أشهر. وفي فبراير 2026، نشرت AWS دراسة حالة مفصلة عن اكتشاف الأدوية أفادت بأن «95% من منطق الأعمال وُلّد من المواصفات، ما وفر أكثر من 80 ساعة».

بحلول نهاية مايو 2026، تبلور إجماع في فضاء المعلومات الناطق بالإنجليزية: البرمجة بأسلوب vibe coding، بوصفها طريقة عمل، هي مستوى المبتدئين. ويأتي بعدها التطوير المدفوع بالمواصفات. يشرح هذا الدليل كيفية تثبيت هذا النهج وتطبيقه.

ما Spec Kit وما التطوير المدفوع بالمواصفات؟#

يمكن تلخيص الفكرة الأساسية للمنهجية في سطر واحد من الوثائق الرسمية لـ GitHub:

عملياً، يتوزع ذلك على 4 مراحل (تضيف Spec Kit مرحلة أخرى تسبقها، وهي المرحلة صفر—الدستور، وسنشرحها أدناه):

1. Specify - اكتب مواصفات ما تريده بلغة طبيعية. ماذا يجب فعله ولماذا. لا كيف.
2. Plan - يأخذ الوكيل المواصفات ويعد خطة تقنية: ما التقنيات، وما البنية، وما المكونات.
3. Tasks - يقسم الوكيل الخطة إلى مهام محددة قابلة للتحقق، مع بيان التبعيات.
4. Implement - ينفذ الوكيل (أو وكلاؤه الفرعيون) المهام ويكتب الكود.

بعد Implement، يتضمن الإصدار الحالي من Spec Kit خطوة تحقق اسمها Converge: يفحص الوكيل الكود المكتمل بمقارنته بالمواصفات والخطة والمهام، ثم يضيف إلى tasks.md ما فات. كرر Implement وConverge حتى تكون الإجابة «Converged».

تُحفظ كل مرحلة في ملف Markdown مستقل داخل المستودع. ولكل مرحلة أمر slash منفصل في Claude Code: /speckit-specify و/speckit-plan و/speckit-tasks و/speckit-implement، أما الفحص فهو /speckit-converge. تكتب وثائق Spec Kit الأوامر نفسها بنقطة (/speckit.specify)، لكن Spec Kit يثبتها في Claude Code كمهارات، وتُستدعى بشرطة. إذا حدث خطأ في أي خطوة، عدّل ملف Markdown وأعد تشغيل المرحلة التالية.

Spec Kit تطبيق محدد لـ SDD. وفي مايو 2026، كان لديه بالفعل أكثر من 30 تكاملاً مع وكلاء ذكاء اصطناعي مختلفين. يعمل Spec Kit بالطريقة نفسها داخل المستودع الواحد مع Claude Code وCursor وGitHub Copilot وCodex CLI وWindsurf وQwen وTabnine وAmazon Q وGemini وGoose وعشرات غيرها.

وهكذا، بعد تشغيلها، لا يحتوي مستودعك على الكود فحسب، بل على مواصفاته وخطته ومهامه أيضاً. بعد شهر، يمكنك العودة إلى المشروع وقراءة spec.md لفهم ما أُنجز ولماذا. لم يعد الأمر «vibe coding تنسى وجود الكود»—بل أصبحت هذه الملفات ذاكرة العمل للمشروع.

لماذا يحتاج هذا مطور vibe coding الذي لا يكتب الكود؟#

يفصل Spec Kit بين التخطيط والتنفيذ عبر خطوات مستقلة، باستخدام 4 أوامر slash. المنطق: افصل «التفكير في الأمر» عن «تنفيذه» كي يحدثا في نافذتي سياق مختلفتين. تحصل كل مرحلة على سياق نظيف لم تشوشه المرحلة السابقة.

ثلاث فوائد ملموسة لمطور vibe coding:

• القدرة على التنبؤ. عندما تقول للوكيل «أنشئ نموذج تسجيل مع تأكيد البريد الإلكتروني»، فإنه يخمن 10 تفاصيل من تلقاء نفسه—ويخطئ في ثلاث منها مقارنة بما قصدته. أما مع spec.md الذي يتضمن User Stories وAcceptance Scenarios وعلامات [NEEDS CLARIFICATION] عند كل نقطة غير مؤكدة، فلا شيء يحتاج إلى تخمين.
• ذاكرة المشروع. بعد شهر، لن تتذكر ما ناقشته مع الوكيل في المحادثة. لكن spec.md وplan.md وtasks.md موجودة في المستودع، في المجلد specs/###-feature/ بجوار الكود. وهي توضح لك ليس ما أُنجز فحسب، بل السبب أيضاً.
• التوسع. إذا شملت الميزة ملفاً أو ملفين، يكاد الفرق ألا يُلاحظ. أما إذا شملت 20 ملفاً و5 كيانات بيانات، فالفرق هو بين «إعادة كتابة كل شيء بعد 4 ساعات» و«وصول كل شيء إلى الفرع الرئيسي بعد 4 ساعات». أثبت AWS Kiro أتمتة 95% من منطق الأعمال انطلاقاً من مواصفات في مشروع TargetID.

أكبر خدعة في vibe coding أنها تبدو أسرع في البداية. نصف ساعة، ولديك نموذج أولي. لكن بحلول نهاية الأسبوع الأول، يتعطل النموذج ويصبح التخلص منه أسهل. يستغرق التطوير المدفوع بالمواصفات وقتاً أطول قليلاً في البداية (ساعة بدلاً من نصف ساعة)، لكنك بعد أسبوع ما زلت تعمل في المستودع نفسه.

كيفية تثبيت Spec Kit في Claude Code (4 خطوات)#

الخطوة 1. تثبيت uv. عليك فعل ذلك مرة واحدة فقط؛ وسيبقى على نظامك.

# macOS / Linux
curl -LsSf https://astral.sh/uv/install.sh | sh

# Windows
powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex"

تحقق من تثبيت uv:

uv --version

الخطوة 2. تثبيت Spec Kit. أمر واحد:

uv tool install specify-cli --from git+https://github.com/github/spec-kit.git

تحقق:

specify --version

الخطوة 3. تهيئة المستودع. انتقل إلى مجلد مشروعك (أو أنشئ مجلداً جديداً) وشغّل:

specify init --here --integration claude

يختار الخيار --integration claude Claude Code مباشرة. وبدونه، يطلب منك Spec Kit اختيار وكيل من قائمة تفاعلية، وقد يسألك أيضاً عن نوع السكربت (على macOS وLinux، اتركه sh). إذا لم يكن المجلد فارغاً، فسيحذرك Spec Kit من أنه سيدمج ملفاته مع ملفاتك: احفظ عملك في commit أولاً، ثم أعد تشغيل الأمر مع الخيار --force.

بعد ذلك، ستظهر العناصر التالية في المستودع:

.specify/
  memory/
    constitution.md        # project rules, filled in by /speckit-constitution
  scripts/
  templates/
    spec-template.md
    plan-template.md
    tasks-template.md
.claude/
  skills/
    speckit-constitution/SKILL.md
    speckit-specify/SKILL.md
    speckit-clarify/SKILL.md
    speckit-plan/SKILL.md
    speckit-checklist/SKILL.md
    speckit-tasks/SKILL.md
    speckit-analyze/SKILL.md
    speckit-implement/SKILL.md
    speckit-converge/SKILL.md
    speckit-taskstoissues/SKILL.md

الخطوة 4. افتح Claude Code وتحقق من أوامر slash. نفّذ هذا في المجلد نفسه:

claude

في الجلسة، اكتب /speckit—ينبغي أن تظهر أوامر speckit-* ضمن الاقتراحات. إذا لم تظهر، فأعد تشغيل Claude Code كي يعيد قراءة .claude/skills/. وإذا كان لديك بالفعل CLAUDE.md في جذر المشروع، فسيتركه Spec Kit كما هو—إذ يعمل إلى جانبه، داخل .specify/memory/constitution.md.

يعمل Spec Kit أيضاً من دون Claude Code (إذ يدعم أكثر من 30 وكيلاً)، لكن هذا الدليل يشرح الإعداد باستخدام Claude تحديداً. وإذا أردت تثبيت أداتين فوراً، فاطّلع على الدليلين المنفصلين حول إعداد CLAUDE.md وPlan Mode في Claude Code.

Spec Kit هو أول مكوّن في «عقد عمل الوكيل». يتضمن الإعداد الكامل العناصر الثلاثة: نسخة ذكاء اصطناعي (منهجيتك بصيغة Skills ووكلاء فرعيين)، وSecond Brain (بنية business/ التي يعود إليها الوكيل في كل مرة)، وهندسة السياق (Spec Kit وPlan Mode و/compact). هذه هي الركائز الثلاث التي لا يستغني عنها الذكاء الاصطناعي من دون أن يهذي.

كيفية كتابة مواصفاتك الأولى (Specify)#

في Claude Code، اكتب:

/speckit-specify

ثم سيطلب منك الوكيل وصف الميزة. في هذه الخطوة، استخدم لغة بسيطة من دون مصطلحات تقنية:

I want a registration form in my app. The user enters an email
and password, receives a confirmation email, and after confirming
lands on the dashboard. Confirmation expires after 48 hours. If the
email is still unconfirmed, delete the account within 5 minutes after
that deadline; never delete a confirmed account.

في هذا المثال التوضيحي، وُضّح أن تأخر الحذف المسموح خمس دقائق بعد مهلة 48 ساعة. أكد هذا الهامش لمنتج حقيقي قبل Plan؛ فموعد 48 ساعة الدقيق يتطلب تصميمًا واختبارات تفرض المطلب الأقوى. سيعد الوكيل الملف specs/001-registration/spec.md. افتحه، وسترى بنية شبيهة بما يلي:

# Feature Specification: User Registration

**Feature Branch**: `001-registration`
**Created**: 2026-05-31
**Status**: Draft
**Input**: User Description: "I want a registration form..."

## User Scenarios & Testing *(mandatory)*

### Primary User Story
As a new user, I want to register an account with email confirmation,
so that I can access the dashboard with a verified identity.

### Acceptance Scenarios
1. **Given** I am on the registration page,
   **When** I submit valid email and password,
   **Then** I receive a confirmation email within 1 minute.
2. **Given** I clicked the confirmation link within 48 hours,
   **When** I land on the dashboard,
   **Then** I see my email confirmed in profile.
3. **Given** I have not confirmed at the 48-hour deadline,
   **When** cleanup runs within the next 5 minutes,
   **Then** my account is deleted and email is freed for re-registration.
4. **Given** my account is just under 48 hours old or already confirmed,
   **When** cleanup runs,
   **Then** the account is not deleted.

## Requirements *(mandatory)*

### Functional Requirements
- **FR-001**: System MUST accept registration via [NEEDS CLARIFICATION:
  email/password only, or also SSO/OAuth?]
- **FR-002**: System MUST send confirmation email within 60 seconds
- **FR-003**: Confirmation MUST expire at 48 hours; the system MUST
  delete still-unconfirmed accounts no later than 5 minutes after that
  deadline and MUST NOT delete confirmed accounts
- **FR-004**: System MUST log all registration attempts for [NEEDS
  CLARIFICATION: how long do we retain logs - 30 days, 90 days, forever?]

### Key Entities
- User: email, password_hash, email_verified_at, created_at, deleted_at
- ConfirmationToken: token, user_id, expires_at, used_at

## Success Criteria *(mandatory)*
- **SC-001**: 95% of confirmation emails delivered within 60 seconds (p95)
- **SC-002**: 0 accidental deletions of confirmed accounts
- **SC-004**: No deletion before 48 hours; every eligible unconfirmed
  account is deleted by age 48 hours 5 minutes under the tested workload
- **SC-003**: Registration completion rate > 60% (from form open to dashboard)

انتبه إلى علامات [NEEDS CLARIFICATION: ...]. يضيفها Spec Kit عمداً في كل موضع لم يحصل فيه الوكيل على جواب لا لبس فيه من نصك. قبل الانتقال إلى مرحلة Plan، يجب أن تجيب عنها يدوياً في spec.md أو تشغّل /speckit-clarify، وسيتناول الوكيل النقاط غير الواضحة ويسألك عنها في الحوار.

في Spec Kit، يحل الأمر المدمج /speckit-clarify محل عبارة «اطرح عليّ أسئلة» المنطوقة. والنتيجة واحدة: لا تنتقل إلى Plan قبل إزالة جميع علامات [NEEDS CLARIFICATION] من spec.md.

يجب ألا يتضمن spec.md أي تقنيات. لا تذكر React أو Postgres أو Prisma أو Redis. تصف المواصفات ما يفعله النظام من منظور المستخدم والأعمال. ويأتي اختيار حزمة التقنيات في المرحلة التالية.

ماذا يفعل Claude في مرحلة Plan؟#

عندما يصبح spec.md جاهزاً، شغّل:

/speckit-plan

ويمكنك اختيارياً تمرير تلميحات تقنية مباشرة في الأمر:

/speckit-plan Next.js App Router, Prisma, PostgreSQL, Resend for email

يقرأ Claude ثلاثة مصادر: ملف spec.md وملف CLAUDE.md (أو memory/constitution.md) والكود الموجود في المستودع. ويكون الناتج plan.md ببنية تقريبية كهذه:

# Implementation Plan: User Registration

## Technical Context
- Framework: Next.js 14 App Router
- Database: PostgreSQL via Prisma
- Email: Resend (single transport)
- Validation: Zod schema in shared lib
- Auth: NextAuth.js with credentials provider

## Architecture Decisions

### 1. Token storage
Tokens stored in DB (table ConfirmationToken), not in JWT.
Reason: need server-side revoke on email re-register.

### 2. Email delivery
Async via cron `/api/cron/send-confirmation` triggered immediately
after registration. Retries handled by Resend.

### 3. Auto-delete cron
Run `/api/cron/cleanup-unconfirmed` every minute. Delete rows only where
created_at <= NOW() - INTERVAL '48 hours' AND email_verified_at IS NULL.
The clarified example allows at most 5 minutes of deletion delay.
Verify scheduler lag and completion time against that bound; report
a missed bound as a failure, not a successful daily cleanup.

## Data Model
See data-model.md

## API Contracts
See contracts/
- POST /api/auth/register
- POST /api/auth/confirm
- GET /api/auth/resend-confirmation

## Implementation Phases
1. Database migration (Prisma schema + migration file)
2. API routes (3 endpoints)
3. UI: registration form + confirmation success page
4. Cron jobs (send + cleanup)
5. Email template
6. Integration tests

يصف data-model.md الكيانات وعلاقاتها. ويتضمن contracts/ مسودات عقود API (إما بصيغة OpenAPI YAML أو أنواع طلب واستجابة TypeScript). هذه ليست شيفرة، بل وصف لما سيحوله Claude لاحقاً إلى مسارات فعلية.

الميزة الرئيسية لمرحلة Plan هي السياق النظيف. فلا يحاول Claude إبقاء المواصفات والتنفيذ حاضرين في ذهنه في الوقت نفسه. بل يفكر أولاً في الأمر، ويسجل القرار في ملف، ثم ينتقل إلى التنفيذ.

بعد ذلك يأتي الأمر الاختياري /speckit-analyze. يُشغّل بعد مرحلة Tasks وقبل Implement: يراجع مجموعة spec.md + plan.md + tasks.md بحثاً عن التناقضات، ويتحقق من تغطية الخطة والمهام لجميع متطلبات المواصفات. ولا يحرر الملفات؛ بل ينتج تقريراً فقط. إنه فحص رسمي لسلامة العمل قبل التنفيذ.

كيفية تقسيم العمل إلى مهام (Tasks)#

بعد أن يصبح لديك spec.md وplan.md، شغّل:

/speckit-tasks

يوسع Claude الخطة إلى tasks.md:

# Tasks: User Registration

## Phase 1: Database (no dependencies)
- [ ] T-001: Add User model to prisma/schema.prisma (parallel-safe)
- [ ] T-002: Add ConfirmationToken model to prisma/schema.prisma (after T-001)
- [ ] T-003: Generate migration `add-user-registration` (after T-002)

## Phase 2: API contracts (no dependencies)
- [ ] T-004: Create Zod schemas in shared/validation/auth.ts
- [ ] T-005: Define TypeScript types in shared/types/auth.ts (after T-004)

## Phase 3: Routes (depends on Phase 1+2)
- [ ] T-006: Implement POST /api/auth/register
- [ ] T-007: Implement POST /api/auth/confirm
- [ ] T-008: Implement GET /api/auth/resend-confirmation

## Phase 4: UI (parallel with Phase 3)
- [ ] T-009: Build /register page with form
- [ ] T-010: Build /register/confirm/[token] page
- [ ] T-011: Build /register/success page

## Phase 5: Cron + integration (depends on Phase 3+4)
- [ ] T-012: Cron /api/cron/send-confirmation
- [ ] T-013: Cron /api/cron/cleanup-unconfirmed
- [ ] T-014: Email template registration-confirmation.tsx
- [ ] T-015: Integration tests (Playwright), including cleanup just
  before 48h, exactly at 48h, deletion by 48h 5m, delayed-job failure,
  and protection of confirmed accounts

## Notes
- T-001, T-004, T-009-T-011 are parallel-safe (different files)
- T-002 conflicts with T-001 (same file: schema.prisma) - run sequentially
- T-006 needs T-003 (migration applied) and T-005 (types)

لاحظ علامات parallel-safe وafter T-NNN. هذه هي تبعيات المهام التي تتيح لك لاحقاً تشغيل عدة مراحل بالتوازي. ويعتمد نهج تسريع Spec Kit كله على هذه الآلية: يمكن إسناد بعض المهام إلى خمسة من Claude Code في الوقت نفسه، بينما يجب تنفيذ مهام أخرى بالتتابع حصراً.

ينفذ Spec Kit ذلك تلقائياً بأمر واحد، مباشرةً ومن دون إعداد إضافي.

يأخذ الأمر الاختياري /speckit-taskstoissues ملف tasks.md وينشئ GitHub Issues من قائمته، مع رابط يعود إلى spec.md في كل منها. وهذا مفيد إن كنت تعمل ضمن فريق أو تريد تتبع التقدم عبر GitHub Projects.

كيفية التنفيذ باستخدام الوكلاء الفرعيين (Implement)#

/speckit-implement

يبدأ Claude بأول مهمة في tasks.md. تمر كل مهمة بدورة قصيرة: قراءة الملفات ذات الصلة، وكتابة diff، وتشغيل الاختبارات، ووضع علامة [x]. وتُستدعى الوكلاء الفرعيون تلقائياً عند الحاجة: واحد لمراجعة الكود، وآخر لتشغيل أداة الفحص، وثالث للتحقق من عدم ظهور تراجعات.

وقال أيضاً عن القواعد:

في Spec Kit، أصبحت هذه الدورة رسمية. لديك spec.md بوصفه مصدر الحقيقة، وplan.md للقرارات التقنية، وtasks.md كقائمة تحقق. إذا انحرف Claude عن المسار في أي خطوة، عد إلى المواصفات وقل: «هذا لا يطابق FR-003؛ أعده». لا حاجة إلى طلبات طويلة تقول «تذكر ما ناقشناه...»—فالتاريخ كله موجود في الملفات.

إذا كنت قد ربطت Dynamic Workflows في Opus 4.8، يمكنك وضع Spec Kit في وضع الأتمتة الكاملة: أمر /speckit-implement واحد، ويقسم Claude العمل بالتوازي، ويدمج النتائج، ويفحصها. الحد هو 1000 وكيل فرعي دفعة واحدة. وتكفي 10-30 لمعظم الميزات.

عندما تُعلّم كل المربعات [x] ويُظهر الفحص في القسم التالي «Converged»، راجع طلب السحب (أو سلسلة من طلبات السحب إن كان هناك كثير من المهام) وادمجه. وتبقى الآثار—spec.md وplan.md وtasks.md—في المستودع لتوثيق الميزة. وبعد عام، لن تحتاج إلى استنباط المنطق عكسياً من الكود.

كيفية التحقق من أن الوكيل لم يفوّت شيئاً (Converge)#

/speckit-converge

يقدم الوكيل أولاً ملخصاً لما وجده، مع مستويات الخطورة، ثم تكون النتيجة واحدة من اثنتين. تعني «Converged» عدم وجود نواقص، وبقاء tasks.md دون أي تغيير على مستوى البايت، وإمكانية الانتقال إلى المراجعة. أما «Tasks appended» فتعني العثور على نواقص، وإضافتها إلى قسم Convergence في tasks.md، وإخبارك بعددها.

لا يعدل Converge الكود أو يحذفه؛ والشيء الوحيد الذي يكتبه هو المهام الجديدة في tasks.md. لذا يمكنك تشغيله من دون قلق، ولكن فقط بعد أن يكون /speckit-implement قد نفذ المهام الموجودة حالياً في tasks.md. وتكشف كل جولة لاحقة نواقص أقل.

ما الفرق بين Spec Kit وCLAUDE.md وPlan Mode؟#

قارن بينها وفق 5 خصائص:

في مصطلحات Spec Kit، هذا هو .specify/memory/constitution.md. عند التهيئة، يمكن لـ Spec Kit إما استخدام CLAUDE.md الموجود أساساً منطلقاً للدستور، أو إنشاء ملف مستقل بجواره. عادةً ما أحتفظ بـ CLAUDE.md بوصفه «العقد» العام (حزمة التقنيات والمعجم وبروتوكول النشر)، وأستخدم دستور Spec Kit للقواعد الخاصة بالميزة—مثلاً، «تُتحقق صحة جميع النماذج عبر Zod، ومن دون فحوص يدوية».

والصلة بـ Plan Mode أبسط. Plan Mode هو وضع سريع لـ«التخطيط قبل كتابة الكود» ضمن جلسة واحدة. وهو مناسب للتغييرات الصغيرة (إصلاح خطأ برمجي، أو إعادة هيكلة دالة). أما مع ميزة كبيرة، فلا يصمد Plan Mode لأن نافذة سياق جلسة واحدة أصغر من أن تستوعب خطة من 3000 سطر—كما أوضح مباشرة في الجلسة المباشرة:

Spec Kit أداة ملموسة لهندسة السياق. فهو ينقل «البساط المعماري» من المحادثة إلى الملفات. يبقى Spec.md في المستودع، وتعيد كل جلسة Claude جديدة قراءته—فلا تضطر إلى تكرار كلامك.

إعداد مشروع كبير:

1. CLAUDE.md - حزمة التقنيات والمعجم وما يجب عدم فعله. يوجد في الجذر.
2. .specify/memory/constitution.md لـ Spec Kit—قواعد خاصة بسير العمل هذا.
3. specs/001-feature-A/spec.md, plan.md, tasks.md - الميزة الأولى.
4. specs/002-feature-B/spec.md, plan.md, tasks.md - الميزة الثانية.
5. للعمل اليومي، استخدم إما /speckit-implement (للمهام الجاهزة) أو /plan (لمراجعة سريعة قبل التغيير).

ما الحالات الناجحة في الواقع؟#

حالات محددة:

• AWS Kiro - وكيل اكتشاف الأدوية. في منشور مدونة AWS Industries المؤرخ 18 فبراير 2026، يصف الفريق مشروع TargetID. ثلاثة مطورين، وثلاثة أسابيع، ووكيل لاكتشاف الأدوية. الأرقام الواردة في المقال: ولّد Kiro أكثر من 95% من شيفرة منطق الأعمال، موفراً أكثر من 80 ساعة تطوير. وجاء فيه أيضاً: «وفّر توثيق README الذي كتبه Kiro نحو 8 ساعات بحسب تقديرنا» و«40% دورات أقل لتكرار الطلبات وإصلاح الأخطاء».
• Rackspace Technology. في مدونة AWS نفسها، أفادت Rackspace بأنها «أنجزت عملاً مقدراً بـ52 أسبوعاً خلال 3 أسابيع فقط» مع «زيادة في الكفاءة بنسبة 90%». لم تعد هذه ميزة صغيرة، بل مشروعاً مؤسسياً كاملاً.
• نمو GitHub Spec Kit. بحلول 31 مايو، بلغ عدد نجوم المستودع 107,000. ويشير هذا المعدل بوضوح إلى أن النهج يكتسب حصة سوقية.

بالنسبة للقارئ، فهذا يعني أن النهج ليس نظرياً: فالفرق الجادة تستخدمه بالفعل في بيئة الإنتاج.

متى لا يكون Spec Kit مناسباً؟#

غير مناسب #1 - التعديلات الصغيرة. إذا كانت المهمة «إعادة تسمية متغير» أو «إصلاح خطأ مطبعي في النص» أو «إضافة سجل»، فسيستغرق تنفيذ Specify ← Plan ← Tasks وقتاً أطول من التعديل نفسه. التعديلات الصغيرة أسرع باستخدام Plan Mode أو بطلب مباشر بسيط في Claude Code.

غير مناسب #2 - التجارب المباشرة. عندما لا تعرف بعد ما تريده وتحتاج إلى «استكشاف» الواجهة أو تجميع نموذج أولي سريع لترى «إن كان سيعجبك»، تصبح المواصفات بلا جدوى. فقيمة الأمر تكمن تحديداً في الارتجال. وعلى مستوى «العبث بفكرة»، فإن vibe هو ما ينجح بالضبط، لا المواصفات.

غير مناسب #3 - الكود القديم ذو الحالة المعقدة. حجة مضادة قوية: «يتغير الواقع أسرع من المواصفات». مثال ذلك فوترة الاشتراكات: وصف الفريق دورات الفوترة وقواعد الضرائب، ثم طلب قسم المالية بعد أسبوع إضافة ضريبة القيمة المضافة الأوروبية—فأصبحت المواصفات قديمة قبل الإصدار. وعندما يتطور منطق الأعمال بسرعة، يغدو الحفاظ على المواصفات عبئاً.

وثمة خطر إضافي هو الإحساس الزائف بالتحكم: البنى أنيقة، لكن الوكلاء كثيراً ما يتجاهلون التعليمات أو، على العكس، يتبعون القوالب حرفياً أكثر من اللازم. والنتيجة كود صحيح من ناحية البنية لكنه لا يلائم مستودعك تحديداً—فالمواصفات لا تضمن فهم الوكيل لها كما قصدت.

حذّر محللون في المجال من النهج الشلالي: فكتابة مواصفات كبيرة قبل الكود طريق سبق أن أوقع المجال في مأزق، في أيام المتطلبات ذات الـ200 صفحة. ومنذ ذلك الحين، توخى المهندسون الحذر من هذا النهج، وله ما يبرره.

ماذا تفعل حيال ذلك؟ أقترح قاعدة بسيطة: وازن بين حجم الميزة والوقت اللازم لكتابة مواصفاتها. إن كانت الميزة ستستغرق أقل من ساعتين لتنفيذها، فلا تكتب مواصفات—فـPlan Mode أسرع. وإن كانت ستستغرق أسبوعاً، فاستخدم Spec Kit بالتأكيد؛ إذ سيعوض توفير الوقت الساعة التي قضيتها في المواصفات خمسة أضعاف. أما بين ساعتين وأسبوع، فالأمر متروك لتقديرك، مع أنني شخصياً أكتب مواصفات حتى للميزات التي تستغرق نصف يوم، لأن أثرها في المستودع أهم من توفير 30 دقيقة.

ماذا بعد: كيف تدمج Spec Kit في مشروعك؟#

خطة عملية للأيام السبعة القادمة:

• اليوم 1. ثبّت uv وSpec Kit (5-10 دقائق). تحقق من ظهور أوامر /speckit-* في Claude Code. لا تحاول تطبيقها على مشروع قائم—ابدأ بمشروع جديد.
• اليوم 2. اختر ميزة فعلية تخطط لبنائها. شغّل /speckit-specify مع وصف حر. افتح spec.md واقرأه وأجب عن كل علامات [NEEDS CLARIFICATION]. لا تتسرع في الانتقال إلى Plan.
• اليوم 3. شغّل /speckit-plan مع تلميحات عن حزمة تقنياتك. اقرأ plan.md، وخصوصاً قسم Architecture Decisions. إن لم يناسبك شيء، فعدّله يدوياً.
• اليومان 4-5. شغّل /speckit-tasks، ثم /speckit-analyze لمراجعة مجموعة المواصفات والخطة والمهام، ثم /speckit-implement. راقب كيف يضع Claude علامات [x] في tasks.md. قد يتعثر في موضع ما—وهذا طبيعي. عُد إلى spec.md ووضّح المتطلب، ثم أعد تشغيل /speckit-implement بمهمة محددة. وبعد إغلاق المهام، شغّل /speckit-converge وكرر تسلسل Implement وConverge حتى يجيب «Converged».
• اليومان 6-7. راجع طلب السحب (أو سلسلة طلبات السحب). ادمجه. اقرأ spec.md وplan.md—فهذه وثائق ميزتك للعام القادم.

ما أقترح قراءته بالتوازي:

• كيفية إعداد CLAUDE.md في 2026 - أساس دستور Spec Kit.
• Plan Mode في Claude Code - بديل سريع للمهام الصغيرة.
• هندسة السياق في 2026 - لماذا ينجح Spec Kit أصلاً.
• Skills أم Subagents أم MCP أم Plugins - ما الذي تضيفه إلى Spec Kit لسير عملك.
• Dynamic Workflows في Claude Code - كيفية إطلاق عدد كبير من الوكلاء الفرعيين دفعة واحدة لمرحلة Implement.

سير العمل السياقي الكامل: نسخة الذكاء الاصطناعي + Second Brain + هندسة السياق.

تتوفر مواد إضافية على Ailoot.