איך לכתוב סקיל משלכם ל-Claude Code

התקנתם כמה סקילים ל-Claude Code וראיתם איך הם משנים את זרימת העבודה. עכשיו אתם תוהים: אפשר לכתוב סקיל משלי? בהחלט — וזה פשוט יותר ממה שאתם חושבים.

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

מבנה קובץ הסקיל

סקיל הוא קובץ Markdown עם שני חלקים: מטא-דאטה בפרונטמאטר וגוף התוכן.

---
name: my-skill-name
description: Use when doing X with Y technology
triggers:
  - keywords: ["keyword1", "keyword2"]
  - fileTypes: [".ext"]
version: "1.0"
author: "Your Name"
---

## Rules

- חוק ראשון
- חוק שני

## Patterns

דוגמאות קוד או הנחיות מובנות כאן.

הפרונטמאטר הוא YAML בין סימני ---. הגוף הוא Markdown רגיל — כותרות, רשימות, בלוקי קוד — כל מה ש-Claude יכול לקרוא.

שדות הפרונטמאטר

| שדה | חובה | מטרה | |-----|------|-------| | name | כן | מזהה ייחודי לסקיל | | description | כן | אומר ל-Claude מתי להפעיל את הסקיל | | triggers | מומלץ | מילות מפתח וסוגי קבצים שמפעילים את הסקיל | | version | אופציונלי | מעקב אחר שינויים | | author | אופציונלי | ייחוס |

שדה ה-description חשוב יותר ממה שנראה. Claude משתמש בו כדי להחליט אם הסקיל רלוונטי למשימה. כתבו אותו כמשפט ברור בנוסח "Use when...".

היכן לשמור סקילים

כל הסקילים חיים ב-~/.claude/skills/. Claude Code סורק תיקייה זו בהפעלה וטוען את כל קבצי ה-.md שהוא מוצא.

~/.claude/skills/
├── react-expert.md
├── typescript-pro.md
├── devops-engineer.md
└── my-custom-skill.md   # הסקיל החדש שלכם

אפשר לארגן סקילים בתת-תיקיות — Claude Code מחפש רקורסיבית:

~/.claude/skills/
├── frontend/
│   ├── react-expert.md
│   └── vue-expert.md
└── backend/
    ├── fastapi-expert.md
    └── go-developer.md

לאחר הוספת סקיל, הפעילו מחדש את Claude Code וזהו. אין צורך בהגדרות.

מוסכמות שמות

שמות סקיל טובים עוקבים אחר תבנית פשוטה: domain-role.md או technology-specialty.md.

שמות טובים:

• react-expert.md
• sql-optimizer.md
• code-reviewer.md
• api-designer.md

הימנעו מ:

• my-stuff.md (לא ספציפי מספיק)
• reactNextjsTypescriptFrontendMaster.md (רחב מדי, שגיאות כתיב)
• skill1.md (חסר משמעות)

השם משמש גם כמזהה כשסקילים מוזכרים בשיחה, אז הפכו אותו לקריא ותיאורי.

כתיבת חוקים אפקטיביים

גוף הסקיל הוא המקום שבו הערך האמיתי חי. כך כותבים חוקים שמשנים את התנהגות Claude.

היו ספציפיים, לא כלליים

חוקים עמומים מייצרים תוצאות עמומות.

חלש: "כתוב קוד TypeScript טוב."

חזק:

## חוקים

- תמיד הפעילו strict mode (`"strict": true` ב-tsconfig)
- השתמשו ב-`unknown` במקום `any` — אל תשתמשו ב-`any` אלא אם כן ממשקים עם APIs חיצוניים ללא טיפוסים
- העדיפו `type` על פני `interface` לסוגי איחוד וסוגים ממופים
- השתמשו ב-branded types ל-IDs: `type UserId = string & { readonly __brand: 'UserId' }`
- החזירו `Result<T, E>` tuples לפעולות מועדות שגיאה במקום להשליך

תנו הקשר, לא רק פקודות

הסבירו את הלמה מאחורי החוקים. Claude מנמק טוב יותר עם הקשר.

## ניהול State

השתמשו ב-Zustand לstate גלובלי, React Query לstate שרת. שמרו אותם נפרדים.

**הנמקה:** React Query מטפל ב-caching, refetching וסנכרון אוטומטית — אל
תשכפלו זאת עם Zustand. Zustand מיועד ל-UI state (מודאלים, סרגל צד, ערכת נושא)
שלא מגיע מהשרת.

**תבנית:**
- נתוני שרת → React Query (`useQuery`, `useMutation`)
- UI state → Zustand store
- State רכיב → `useState` (אל תעלו לדרגות גבוהות יותר אלא אם צריך)

כללו אנטי-תבניות

אמרו ל-Claude מה לא לעשות. זה לרוב שימושי יותר מחוקים על מה לעשות.

## אנטי-תבניות — לעולם אל תעשו אלה

- אל תשתמשו ב-`useEffect` לסנכרון state הנגזר מ-state אחר — השתמשו ב-`useMemo`
- אל תקראו ל-`setState` בלולאה — צרפו עדכונים או השתמשו ב-reducers
- אל תכניסו לוגיקה אסינכרונית ישירות ב-event handlers — חלצו ל-custom hooks
- אל תתעלמו מאזהרות ESLint — תקנו אותן או השביתו במפורש עם הערה שמסבירה מדוע

בדיקת הסקיל שלכם

לפני הסתמכות על סקיל לעבודה אמיתית, בדקו אותו:

1. התחילו session חדש של Claude Code לאחר שמירת קובץ הסקיל
2. בקשו משימה בתחום הסקיל — למשל, "בנה רכיב אימות משתמש"
3. בדקו אם Claude עוקב אחר חוקיכם — חפשו את התבניות שציינתם
4. חזרו על התהליך — אם Claude מחמיץ משהו, הפכו את החוק לספציפי יותר או הוסיפו דוגמה

מבחן שימושי: בקשו מ-Claude "תאר את החוקים שאתה עוקב אחריהם למשימה הזו" — הוא יסכם אילו סקילים נטענו ואילו הוראות הוא מיישם.

דוגמת סקיל מלאה 1: מעצב API

---
name: api-designer
description: Use when designing or reviewing REST APIs, defining endpoints, writing OpenAPI specs
triggers:
  - keywords: ["api", "endpoint", "rest", "openapi", "swagger"]
  - fileTypes: [".yaml", ".json"]
version: "1.0"
---

## חוקי עיצוב REST API

- השתמשו בשמות עצם למשאבים, לא בפעלים: `/users` לא `/getUsers`
- השתמשו בשמות משאב ברבים: `/orders` לא `/order`
- קננו משאבים עד 2 רמות עומק: `/users/{id}/orders` בסדר, עמוק יותר אינו
- השתמשו בשיטות HTTP כהלכה: GET (קריאה), POST (יצירה), PUT (החלפה), PATCH (עדכון), DELETE (מחיקה)
- החזירו קודי סטטוס מתאימים: 200, 201, 204, 400, 401, 403, 404, 422, 500

## פורמט תגובה

תמיד השתמשו במעטפת זו לתגובות רשימה:
```json
{
  "data": [...],
  "meta": {
    "total": 100,
    "page": 1,
    "perPage": 20
  }
}

למשאב יחיד: החזירו את האובייקט ישירות, ללא מעטפת. לשגיאות: { "error": { "code": "VALIDATION_ERROR", "message": "...", "fields": {...} } }

## דוגמת סקיל מלאה 2: בודק קוד

```markdown
---
name: code-reviewer
description: Use when reviewing code, providing feedback on pull requests, or auditing existing code
triggers:
  - keywords: ["review", "pr", "pull request", "audit", "feedback", "check this code"]
version: "1.0"
---

## רשימת בדיקה לסקירה

תמיד בדקו אלה לפי הסדר:

### 1. נכונות
- האם הקוד עושה מה שהוא טוען לעשות?
- האם מקרי קצה מטופלים (null, ריק, overflow, גישה מקבילה)?
- האם שגיאות נלכדות ומטופלות כראוי?

### 2. אבטחה
- האם קלט משתמש מאומת ומחוטא?
- האם יש סיכוני SQL injection, XSS או path traversal?
- האם סודות מקודדים בקשיחות בקוד?

### 3. ביצועים
- האם יש בעיות N+1 queries?
- האם פעולות כבדות מאוחסנות במטמון או מגובלות?
- האם מערכי נתונים גדולים מחולקים לדפים?

## טון משוב

- התחילו עם מה שטוב לפני רשימת הבעיות
- היו ספציפיים: "הלולאה הזו רצה O(n²) כי..." לא "זה איטי"
- ספקו את התיקון, לא רק הבעיה
- סווגו משוב: [BLOCKER], [SUGGESTION], [NITPICK]

דוגמת סקיל מלאה 3: מייטב מסד נתונים

---
name: sql-optimizer
description: Use when writing SQL queries, designing schemas, or optimizing database performance
triggers:
  - keywords: ["sql", "query", "database", "postgres", "mysql", "index", "schema"]
  - fileTypes: [".sql"]
version: "1.0"
---

## חוקי שאילתות

- תמיד השתמשו בשמות עמודות מפורשים ב-SELECT — לעולם לא `SELECT *` בקוד ייצור
- השתמשו בשאילתות פרמטריות — אף פעם לא שרשור מחרוזות עבור קלט משתמש
- הוסיפו EXPLAIN ANALYZE לפני הצעת כל שאילתה כאופטימלית
- השתמשו ב-CTEs (סעיפי WITH) לשאילתות מורכבות — קריא יותר משאילתות משנה מקוננות

## אסטרטגיית אינדקסים

צרו אינדקסים עבור:
- כל מפתחות זרים
- עמודות המשמשות בסעיפי WHERE המסננות טבלאות גדולות
- עמודות המשמשות ב-ORDER BY על תוצאות גדולות
- אינדקסים מורכבים כשמספר עמודות תמיד נשאלות יחד

תבניות מתקדמות

סעיפים תנאיים

אפשר לבנות את הסקיל עם הנחיות מותנות באמצעות כותרות ברורות:

## בעבודה עם Next.js App Router

- השתמשו ב-Server Components כברירת מחדל
- הוסיפו `"use client"` רק כשצריך אינטראקטיביות או APIs של הדפדפן
- שמרו רכיבים ספציפיים לדף בתיקיית הנתיב

## בעבודה עם Next.js Pages Router

- השתמשו ב-`getServerSideProps` רק כשצריך נתונים בזמן בקשה
- העדיפו `getStaticProps` עם `revalidate` לרוב הדפים
- השתמשו ב-API routes ללוגיקת backend

Claude יישם את הסעיף שמתאים להקשר האמיתי של המשימה שלכם.

כולל תבניות קוד

הכניסו boilerplate ישירות לסקיל כך ש-Claude ישתמש בו כנקודת התחלה:

## תבנית רכיב

תמיד התחילו רכיבי React חדשים מהתבנית הזו:

```tsx
import type { FC } from 'react'

interface Props {
  // הגדירו props כאן
}

const ComponentName: FC<Props> = ({ }) => {
  return (
    <div>
      {/* תוכן */}
    </div>
  )
}

export default ComponentName

## טעויות נפוצות להימנע מהן

**רחב מדי:** סקיל המכסה 10 תחומים שונים ידלל את יעילותו. שמרו כל סקיל ממוקד.

**ללא דוגמאות:** חוקים ללא דוגמאות קוד משאירים מקום לעמימות. הראו בדיוק מה אתם מתכוונים.

**תבניות מיושנות:** אם הסקיל שלכם מפנה ל-API שהשתנה, Claude עדיין עלול לעקוב אחר הסקיל. בדקו ועדכנו סקילים מעת לעת.

**חוקים סותרים:** אם שני סקילים טעונים נותנים עצות סותרות, Claude ינסה ליישב — לעיתים קרובות בצורה בלתי צפויה. תכננו סקילים להיות ניתנים להרכבה.

## הסקיל הראשון שלכם ב-10 דקות

1. פתחו `~/.claude/skills/my-first-skill.md`
2. הוסיפו פרונטמאטר עם שם ותיאור ברורים
3. כתבו 5-10 חוקים ספציפיים שחשובים לכם
4. הוסיפו דוגמת קוד מלאה אחת
5. שמרו, הפעילו מחדש את Claude Code
6. בדקו עם משימה אמיתית

התחילו קטן. סקיל ממוקד בן 20 שורות עדיף על אחד משתרע בן 200 שורות. ברגע שהוא עובד טוב, הרחיבו אותו.

---

*רוצים 139 סקילים מוכחים במקום לכתוב אותם מאפס? [קבלו SuperSkills ב-$50](/pricing) — כל סקיל מעוצב באופן מקצועי ומוכן לשימוש.*