איך להגדיר את Spec Kit ב-Claude Code ב-2026: מפרטים במקום הנחיות

מה קרה לקידוד הווייבים במאי 2026?#

בפברואר 2025 כתב קרפת'י פוסט ב-X שהפך את “vibe coding” למונח תרבותי: סוג של קידוד שבו “נכנעים לווייבים, מאמצים את האקספוננציאליות ושוכחים שהקוד בכלל קיים, כי מודלי LLM נעשים טובים מדי.” במהלך השנה שלאחר מכן הוא נעשה שם נרדף לכל עבודה לא מובנית עם סוכן AI.

שנה לאחר מכן, ב-4 בפברואר 2026, הוא פרסם שרשור רטרוספקטיבי:

בהרצאתו ב-Sequoia Ascent 2026 הוא ניסח זאת אפילו ביתר דיוק: “קידוד וייבים מעלה את הרצפה—את מה שכל אחד יכול לעשות בתוכנה. הנדסה סוכנית משמרת את התקרה—את רף האיכות של פיתוח מקצועי.” באותו במה הוא אמר משפט שנכנס ללקסיקון התעשייה: “אי אפשר להכניס חולשות אבטחה בגלל קידוד וייבים. אתם עדיין אחראים לתוכנה שלכם, כמו קודם.”

שני דברים התרחשו במקביל. בספטמבר 2025 פרסמה GitHub את כלי Spec Kit—הוא צבר 107,000 כוכבים ב-8 חודשים. בפברואר 2026 פרסמה AWS מקרה בוחן מפורט בנושא גילוי תרופות שדיווח על “95% מהלוגיקה העסקית שנוצרה מהמפרט, וחיסכון של 80+ שעות.”

עד סוף מאי 2026 התגבש קונצנזוס במרחב המידע דובר האנגלית: קידוד וייבים כשיטת עבודה הוא רמת מתחילים. השלב הבא הוא פיתוח מונחה מפרטים. המדריך הזה מסביר כיצד להתקין את הגישה וליישם אותה.

מה הם Spec Kit ופיתוח מונחה מפרטים?#

רעיון הליבה של המתודולוגיה מתמצה בשורה אחת מהתיעוד הרשמי של GitHub:

בפועל, התהליך מתפרש על פני 4 שלבים (Spec Kit מוסיף שלב אחד נוסף, שלב אפס—חוקה, שמתואר בהמשך):

1. Specify - כותבים בשפה טבעית מפרט של מה שרוצים. מה לעשות ולמה. לא איך.
2. Plan - הסוכן מקבל את המפרט ומרכיב תוכנית טכנית: באילו טכנולוגיות להשתמש, מהי הארכיטקטורה ואילו רכיבים נדרשים.
3. Tasks - הסוכן מפרק את התוכנית למשימות ספציפיות שאפשר לאמת, עם תלויות ביניהן.
4. Implement - הסוכן (או סוכני המשנה שלו) מתקדם במשימות וכותב את הקוד.

אחרי Implement, בגרסה הנוכחית של Spec Kit יש שלב אימות בשם Converge: הסוכן בודק את הקוד שהושלם מול המפרט, התוכנית והמשימות, ואז מוסיף ל-tasks.md כל דבר שנשכח. מריצים את Implement ואת Converge בלולאה עד ש-Converge משיב “Converged”.

כל שלב הוא קובץ Markdown נפרד במאגר. כל שלב הוא פקודת לוכסן נפרדת ב-Claude Code: /speckit-specify, /speckit-plan, /speckit-tasks, /speckit-implement, ואילו הבדיקה היא /speckit-converge. בתיעוד Spec Kit אותן פקודות נכתבות עם נקודה (/speckit.specify), אבל ב-Claude Code Spec Kit מתקין אותן כ-skills והן מופעלות עם מקף. אם משהו משתבש בשלב כלשהו, עורכים את קובץ ה-Markdown ומריצים מחדש את השלב הבא.

Spec Kit הוא מימוש מסוים של SDD. במאי 2026 כבר היו לו יותר מ-30 אינטגרציות עם סוכני AI שונים. בתוך אותו מאגר, Spec Kit עובד באותה צורה עם Claude Code, Cursor, GitHub Copilot, Codex CLI, Windsurf, Qwen, Tabnine, Amazon Q, Gemini, Goose ועוד תריסר כלים.

לכן, אחרי ריצה, המאגר שלכם מכיל לא רק קוד אלא גם את המפרט, התוכנית והמשימות שלו. כעבור חודש תוכלו לחזור לפרויקט, לקרוא את spec.md ולהבין מה נעשה ולמה. זה כבר לא “קידוד וייבים שבו שוכחים שהקוד קיים”—זו סביבת הזיכרון של הפרויקט.

למה שמי שמקודד בווייבים ולא כותב קוד יצטרך את זה?#

המתודולוגיה של ארטמי מילר מאפריל 2026 דומה ל-SDD. במפגש החי של המחזור השלישי הוא ניסח זאת כך:

את מה שארטמי עשה ידנית (4 צ'אטים במקום אחד), Spec Kit מסדיר באמצעות 4 פקודות לוכסן. ההיגיון זהה: להפריד בין “חשיבה על הדברים” לבין “מימושם”, כך שכל אחד מהם יתרחש בחלון הקשר אחר. כל שלב מקבל הקשר נקי שלא התבלגן בגלל השלב הקודם.

שלושה יתרונות מוחשיים למי שמקודד בווייבים:

• צפיות. כשאומרים לסוכן “בנה טופס הרשמה עם אישור בדוא״ל”, הוא מנחש בעצמו 10 פרטים—ובשלושה מהם טועה ביחס למה שהתכוונתם. כשיש לכם spec.md עם User Stories, תרחישי קבלה וסמנים של [NEEDS CLARIFICATION] בכל נקודה לא ודאית, אין מה לנחש.
• זיכרון הפרויקט. כעבור חודש לא תזכרו מה דנתם עם הסוכן בצ'אט. אבל spec.md, plan.md ו-tasks.md נמצאים במאגר, בתיקיית specs/###-feature/ לצד הקוד. הם מראים לא רק מה נעשה, אלא גם למה.
• התרחבות. בתכונה הכוללת 1-2 קבצים, כמעט שלא מבחינים בהבדל. בתכונה הכוללת 20 קבצים ו-5 ישויות נתונים, ההבדל הוא בין “לשכתב הכול אחרי 4 שעות” לבין “הכול כבר הגיע לענף הראשי אחרי 4 שעות.” AWS Kiro הדגימה אוטומציה של 95% מהלוגיקה העסקית על בסיס מפרט בפרויקט TargetID.

האשליה המרכזית של קידוד וייבים היא שהוא נראה מהיר בהתחלה. חצי שעה, וכבר יש אבטיפוס. אבל כעבור שבוע האבטיפוס נשבר, וקל יותר לזרוק אותו. פיתוח מונחה מפרטים לוקח קצת יותר זמן בהתחלה (שעה במקום חצי שעה), אבל כעבור שבוע אתם עדיין עובדים באותו מאגר.

איך להתקין את 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        # כללי הפרויקט, ממולאים באמצעות /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 ובודקים את פקודות הלוכסן. מריצים זאת באותה תיקייה:

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 הוא אבן הבניין הראשונה ב“חוזה העסקה של סוכן”. ההגדרה השלמה כוללת את שלושתם: שיבוט AI (המתודולוגיה שלכם בצורת Skills וסוכני משנה), מוח שני (מבנה business/ שאליו הסוכן חוזר בכל פעם), והנדסת הקשר (Spec Kit, Plan Mode, ‎/compact). אלה שלושת העמודים שבלעדיהם ה-AI הוזה.

איך לכתוב את המפרט הראשון שלכם (Specify)#

ב-Claude Code, הקלידו:

/speckit-specify

לאחר מכן הסוכן יבקש תיאור של התכונה. בשלב הזה, השתמשו בשפה פשוטה וללא ז'רגון טכני:

אני רוצה טופס הרשמה באפליקציה שלי. המשתמש מזין כתובת דוא״ל
וסיסמה, מקבל הודעת אישור בדוא״ל, ואחרי האישור מגיע ללוח הבקרה.
אפשרות האישור פגה אחרי 48 שעות. אם כתובת הדוא״ל עדיין לא אושרה,
מחקו את החשבון בתוך 5 דקות אחרי המועד הזה; לעולם אל תמחקו חשבון שאושר.

בדוגמה להמחשה הזאת הובהר שעיכוב המחיקה המותר הוא 5 דקות לאחר מועד 48 השעות. במוצר אמיתי אשרו את הסבילות הזאת לפני Plan; דרישה למועד מדויק של 48 שעות מחייבת תכנון ובדיקות שאוכפים את הדרישה המחמירה יותר. הסוכן ירכיב את specs/001-registration/spec.md. פתחו אותו ותראו מבנה דומה לזה:

# מפרט תכונה: הרשמת משתמש

**Feature Branch**: `001-registration`
**Created**: 2026-05-31
**Status**: Draft
**Input**: User Description: "אני רוצה טופס הרשמה..."

## תרחישי משתמש ובדיקות *(חובה)*

### סיפור משתמש ראשי
כמשתמש חדש, אני רוצה לרשום חשבון עם אישור בדוא״ל,
כדי שאוכל לגשת ללוח הבקרה עם זהות מאומתת.

### תרחישי קבלה
1. **Given** אני נמצא בדף ההרשמה,
   **When** אני שולח כתובת דוא״ל וסיסמה תקינות,
   **Then** אני מקבל הודעת אישור בדוא״ל בתוך 1 דקה.
2. **Given** לחצתי על קישור האישור בתוך 48 שעות,
   **When** אני מגיע ללוח הבקרה,
   **Then** אני רואה שהדוא״ל שלי אושר בפרופיל.
3. **Given** לא אישרתי במועד של 48 שעות,
   **When** הניקוי מופעל בתוך 5 הדקות הבאות,
   **Then** החשבון שלי נמחק וניתן להשתמש שוב בכתובת הדוא״ל להרשמה.
4. **Given** החשבון שלי צעיר במעט מ-48 שעות או כבר אושר,
   **When** הניקוי מופעל,
   **Then** החשבון אינו נמחק.

## דרישות *(חובה)*

### דרישות פונקציונליות
- **FR-001**: המערכת MUST לאפשר הרשמה באמצעות [NEEDS CLARIFICATION:
  דוא״ל/סיסמה בלבד, או גם SSO/OAuth?]
- **FR-002**: המערכת MUST לשלוח הודעת אישור בדוא״ל בתוך 60 שניות
- **FR-003**: אפשרות האישור MUST לפוג אחרי 48 שעות; המערכת MUST
  למחוק חשבונות שעדיין לא אושרו לא יאוחר מ-5 דקות לאחר המועד הזה
  ו-MUST NOT למחוק חשבונות שאושרו
- **FR-004**: המערכת MUST לתעד את כל ניסיונות ההרשמה למשך [NEEDS
  CLARIFICATION: לכמה זמן נשמור את היומנים - 30 ימים, 90 ימים, לנצח?]

### ישויות מפתח
- User: email, password_hash, email_verified_at, created_at, deleted_at
- ConfirmationToken: token, user_id, expires_at, used_at

## קריטריוני הצלחה *(חובה)*
- **SC-001**: 95% מהודעות האישור נמסרות בתוך 60 שניות (p95)
- **SC-002**: 0 מחיקות בשוגג של חשבונות שאושרו
- **SC-004**: אין מחיקה לפני 48 שעות; כל חשבון לא מאושר הזכאי למחיקה
  נמחק עד גיל 48 שעות ו-5 דקות בעומס העבודה שנבדק
- **SC-003**: שיעור השלמת ההרשמה > 60% (מפתיחת הטופס ועד ללוח הבקרה)

שימו לב לסמנים [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 במבנה דומה לזה:

# תוכנית מימוש: הרשמת משתמש

## הקשר טכני
- 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

## החלטות ארכיטקטורה

### 1. אחסון אסימונים
האסימונים מאוחסנים ב-DB (טבלת ConfirmationToken), ולא ב-JWT.
סיבה: נדרשת אפשרות לביטול בצד השרת במקרה של הרשמה חוזרת בדוא״ל.

### 2. שליחת דוא״ל
באופן אסינכרוני דרך cron `/api/cron/send-confirmation` שמופעל מיד
לאחר ההרשמה. Resend מטפל בניסיונות חוזרים.

### 3. משימת cron למחיקה אוטומטית
הריצו את `/api/cron/cleanup-unconfirmed` בכל דקה. מחקו שורות רק כאשר
created_at <= NOW() - INTERVAL '48 hours' AND email_verified_at IS NULL.
הדוגמה שהובהרה מאפשרת עיכוב מחיקה של 5 דקות לכל היותר.
בדקו את השהיית המתזמן ואת זמן ההשלמה מול הגבול הזה; דווחו על
חריגה מהגבול ככישלון, ולא כניקוי יומי מוצלח.

## מודל נתונים
ראו data-model.md

## חוזי API
ראו contracts/
- POST /api/auth/register
- POST /api/auth/confirm
- GET /api/auth/resend-confirmation

## שלבי מימוש
1. מיגרציית מסד נתונים (סכמת Prisma + קובץ מיגרציה)
2. נתיבי API (3 נקודות קצה)
3. ממשק משתמש: טופס הרשמה + דף אישור מוצלח
4. משימות cron (שליחה + ניקוי)
5. תבנית דוא״ל
6. בדיקות אינטגרציה

data-model.md יתאר את הישויות ואת הקשרים ביניהן. contracts/ יכיל שלדי חוזי API (ב-YAML של OpenAPI או בסוגי בקשה/תגובה של TypeScript). זה אינו קוד—זו כוונה ש-Claude יהפוך בהמשך לנתיבים בפועל.

היתרון המרכזי של שלב Plan הוא הקשר נקי. Claude לא מנסה להחזיק בראש בו-זמנית גם את המפרט וגם את המימוש. הוא חושב על הדברים תחילה, מתעד את ההחלטה בקובץ, ואז ממשיך.

לאחר מכן יש את הפקודה האופציונלית /speckit-analyze. מריצים אותה אחרי שלב Tasks ולפני Implement: היא בוחנת את קבוצת spec.md + plan.md + tasks.md כדי למצוא סתירות ובודקת אם כל דרישות המפרט מכוסות בתוכנית ובמשימות. היא אינה עורכת קבצים, אלא מפיקה דוח בלבד. למעשה, זו בדיקת היגיון פורמלית לפני המימוש.

איך לפרק את העבודה למשימות (Tasks)#

אחרי שיש לכם spec.md ו-plan.md, הריצו:

/speckit-tasks

Claude מרחיב את התוכנית ל-tasks.md:

# משימות: הרשמת משתמש

## שלב 1: מסד נתונים (ללא תלויות)
- [ ] T-001: הוסיפו מודל User ל-prisma/schema.prisma (בטוח לביצוע במקביל)
- [ ] T-002: הוסיפו מודל ConfirmationToken ל-prisma/schema.prisma (אחרי T-001)
- [ ] T-003: צרו מיגרציה `add-user-registration` (אחרי T-002)

## שלב 2: חוזי API (ללא תלויות)
- [ ] T-004: צרו סכמות Zod ב-shared/validation/auth.ts
- [ ] T-005: הגדירו סוגי TypeScript ב-shared/types/auth.ts (אחרי T-004)

## שלב 3: נתיבים (תלוי בשלבים 1+2)
- [ ] T-006: מימוש POST /api/auth/register
- [ ] T-007: מימוש POST /api/auth/confirm
- [ ] T-008: מימוש GET /api/auth/resend-confirmation

## שלב 4: ממשק משתמש (במקביל לשלב 3)
- [ ] T-009: בנו את דף /register עם טופס
- [ ] T-010: בנו את דף /register/confirm/[token]
- [ ] T-011: בנו את דף /register/success

## שלב 5: cron ואינטגרציה (תלוי בשלבים 3+4)
- [ ] T-012: cron /api/cron/send-confirmation
- [ ] T-013: cron /api/cron/cleanup-unconfirmed
- [ ] T-014: תבנית דוא״ל registration-confirmation.tsx
- [ ] T-015: בדיקות אינטגרציה (Playwright), כולל ניקוי רגע לפני 48h,
  בדיוק ב-48h, מחיקה עד 48h 5m, כישלון משימה שהתעכבה
  והגנה על חשבונות שאושרו

## הערות
- T-001, T-004, T-009-T-011 בטוחות לביצוע במקביל (קבצים שונים)
- T-002 מתנגשת עם T-001 (אותו קובץ: schema.prisma) - יש לבצע ברצף
- T-006 דורשת את T-003 (המיגרציה הוחלה) ואת T-005 (הסוגים)

שימו לב לסמנים parallel-safe ול-after T-NNN. זהו גרף התלויות שמאפשר בהמשך להריץ כמה שלבים במקביל. כל גישת ההאצה של Spec Kit נשענת על המנגנון הזה: חלק מהמשימות אפשר להעביר לחמישה מפגשים שונים של Claude בבת אחת, ואחרות חייבות להתבצע ברצף.

ארטמי מילר מתאר את אותה גישה במפגש חי מהמחזור הראשון:

Spec Kit עושה זאת אוטומטית בפקודה אחת, מיד עם ההתקנה.

הפקודה האופציונלית /speckit-taskstoissues מקבלת את tasks.md ויוצרת GitHub Issues מתוך הרשימה, עם קישור אל spec.md בכל issue. הדבר מועיל אם אתם עובדים בצוות או רוצים לעקוב אחר ההתקדמות באמצעות GitHub Projects.

איך לממש בעזרת סוכני משנה (Implement)#

/speckit-implement

Claude מתחיל במשימה הראשונה ב-tasks.md. כל משימה עוברת מחזור קצר: קוראים את הקבצים הרלוונטיים, כותבים diff, מריצים בדיקות ומסמנים [x]. סוכני משנה נקראים אוטומטית לפי הצורך: אחד נפרד לסקירת קוד, אחד להרצת linter ואחד לבדיקת רגרסיות.

בוריס צ'רני, יוצר Claude Code ב-Anthropic, מתאר גישה דומה בקצרה:

ועל הכללים הוא אומר בנפרד:

ב-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”, סוקרים את ה-PR (או סדרת PRs אם יש משימות רבות) וממזגים אותו. התוצרים—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 מאפיינים:

ארטמי מתאר את התפקיד של CLAUDE.md כ“חוזה העסקה”:

במונחים של 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% ביעילות.” זה כבר לא תכונה קטנה—זה פרויקט Enterprise מלא.
• הצמיחה של GitHub Spec Kit. נכון ל-7 במאי 2026, היו למאגר 93,000 כוכבים; עד 31 במאי היו לו 107,000. זו תוספת של +14,000 כוכבים בשלושה שבועות. קצב הצמיחה הזה הוא סימן ברור לכך שהגישה צוברת נתח שוק.
• בוריס צ'רני (Claude Code). יוצר Claude Code משתמש בגישה דומה בת 3 שלבים: מחקר → תכנון (כתיבת spec.md,‏ design.md,‏ tasks.md) → מימוש בחלון חדש עם הקשר נקי. הוא מספר שהוא משאיר 5 מופעים של Claude Code בטרמינל פתוחים בו-זמנית, ועוד 5-10 הפעלות אינטרנט ב-claude.ai/code.

לקוראים פירוש הדבר שהגישה אינה תאורטית: צוותים רציניים כבר משתמשים בה בייצור.

מתי Spec Kit אינו מתאים?#

לא מתאים #1 - עריכות קטנות. אם המשימה היא “לשנות שם של משתנה”, “לתקן טעות הקלדה בטקסט” או “להוסיף יומן”, מעבר דרך Specify → Plan → Tasks יארך יותר מהעריכה עצמה. בריגיטה בקלר מ-Thoughtworks כותבת על כך ישירות: “אני מעדיפה לקרוא את הקוד מאשר את כל קובצי ה-Markdown האלה.” לעריכות קטנות, Plan Mode או פשוט הנחיה ישירה ב-Claude Code מהירים יותר.

לא מתאים #2 - ניסויים בזמן אמת. כשעדיין לא יודעים מה רוצים וצריך “לשחק” עם הממשק או להרכיב במהירות אבטיפוס כדי לראות “אם זה עובד”, אין טעם במפרט. הערך נמצא בעצם האלתור. באותו ציטוט רטרוספקטיבי, קרפת'י אומר: “קידוד וייבים מעלה את הרצפה—את מה שכל אחד יכול לעשות בתוכנה.” ברמה של “לשחק עם רעיון”, הווייב הוא בדיוק מה שעובד, לא מפרט.

לא מתאים #3 - קוד מורשת עם מצב מורכב. טיעון נגדי חזק: המציאות משתנה מהר יותר ממפרטים. קחו לדוגמה חיוב מנויים: הצוות תיאר מחזורי חיוב וכללי מס, ואז שבוע לאחר מכן מחלקת הכספים ביקשה מע״מ אירופי—המפרט התיישן לפני ההשקה. כשהלוגיקה העסקית משתנה במהירות, תחזוקת מפרטים נעשית למעמסה.

סיכון נוסף הוא תחושת שליטה כוזבת. המאמר של מרטין פאולר בוחן זאת: המבנים אלגנטיים, אבל סוכנים מתעלמים לעיתים קרובות מהוראות או, להפך, מצייתים לתבניות באופן מילולי מדי. התוצאה היא קוד שנכון מבחינה מבנית אבל אינו מתאים למאגר המסוים שלכם—המפרט אינו מבטיח שהסוכן הבין אותו כפי שהתכוונתם.

אנליסטים בתעשייה הזהירו מפני מפל מים: כתיבת מפרט גדול לפני כתיבת הקוד היא דרך שכבר הטביעה את התעשייה פעם אחת, בימי הדרישות בנות 200 העמודים. מאז מהנדסים מתייחסים לגישה הזו בזהירות, והזהירות מוצדקת.

מה לעשות בנידון. אני מציע כלל פשוט: גודל התכונה לעומת הזמן הדרוש לכתיבת מפרט. אם מימוש תכונה ייקח פחות מ-2 שעות, אל תכתבו מפרט—Plan Mode מהיר יותר. אם התכונה תימשך שבוע, השתמשו בהחלט ב-Spec Kit; החיסכון בזמן יחזיר את ההשקעה במפרט בן שעה פי חמישה. בין 2 שעות לשבוע, הפעילו שיקול דעת, אם כי אני אישית כותב מפרט גם לתכונות של חצי יום, כי התוצר במאגר שווה יותר מ-30 הדקות שנחסכו.

מה הלאה: איך לשלב את Spec Kit בפרויקט שלכם?#

תוכנית מעשית ל-7 הימים הבאים:

• יום 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. סקרו את ה-PR (או את סדרת ה-PRs). מזגו אותו. קראו את 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.

זרימת העבודה המלאה עם הקשר: שיבוט AI + מוח שני + הנדסת הקשר.

חומרים נוספים זמינים ב-Ailoot.