יכולות מותאמות אישית (Skills) ואוטומציה

בפרק 10 נגענו בקצרה ב-Skills. בפרק הזה ניכנס לעומק: איך בונים "מתכוני עבודה" ש-Claude יודע להפעיל לבד, מעבירים להם פרמטרים, מזינים אותם במידע עדכני מהפרויקט, ומגבילים מה מותר להם לעשות.

Skill (מיומנות) הוא בעצם מתכון עבודה כתוב. במקום להסביר ל-Claude בכל פעם מחדש "ככה אנחנו סוקרים קוד אצלנו", כותבים את זה פעם אחת בקובץ. מאותו רגע, Claude יודע לשלוף את המתכון כשהוא רלוונטי, ואתם יכולים להפעיל אותו בפקודה קצרה כמו /review-pr.

Skill מול כל השאר

איפה Skills גרים

כל Skill הוא תיקייה. שם התיקייה הוא שם הפקודה. ככה נראה פרויקט עם שלושה Skills:

my-project/
└── .claude/
    └── skills/
        ├── review-pr/
        │   ├── SKILL.md          ← חובה: ההוראות
        │   └── checklist.md      ← נטען רק כשצריך
        ├── generate-tests/
        │   ├── SKILL.md
        │   └── examples/
        │       └── sample.test.ts
        └── deploy/
            ├── SKILL.md
            └── scripts/
                └── smoke-test.sh ← סקריפט שרץ, ולא נקרא

האנטומיה של SKILL.md

קובץ SKILL.md בנוי משני חלקים: כותרת עליונה (Frontmatter) בין שני קווים ---, עם הגדרות, וגוף עם ההוראות עצמן.

---
name: summarize-changes
description: Summarizes uncommitted changes and flags anything risky. Use when the user asks what changed, wants a commit message, or asks to review their diff.
---
 
## Current changes
 
!`git diff HEAD`
 
## Instructions
 
Summarize the changes above in two or three bullet points, then list any
risks you notice such as missing error handling, hardcoded values, or tests
that need updating. If the diff is empty, say there are no uncommitted changes.

(זו דוגמה מהתיעוד הרשמי. השורה !`git diff HEAD` מיוחדת, ונסביר אותה בהמשך.)

השדות החשובים בכותרת

כל השדות אופציונליים, אבל description חשוב מאוד: לפיו Claude מחליט מתי להשתמש ב-Skill.

מתי Claude מפעיל, ומתי אתם

יש שתי דרכים להפעיל Skill:

• אוטומטית: Claude קורא את התיאורים, ואם הבקשה שלכם מתאימה, הוא טוען את ה-Skill לבד.
• ידנית: מקלידים / ואת שם ה-Skill, בתחילת ההודעה, אפשר גם עם פרמטרים. שם שמופיע באמצע משפט לא מפעיל את ה-Skill, אלא רק נותן ל-Claude רשות להשתמש בו.

פרמטרים: להעביר מידע ל-Skill

כשמפעילים Skill ידנית, כל מה שכותבים אחרי השם עובר אליו כפרמטרים:

כמה הערות:

• פרמטר עם רווחים? עוטפים אותו במירכאות: /generate-tests "lib/my file.ts".
• אם ה-Skill לא משתמש באף משתנה, Claude Code מוסיף את הפרמטרים בסוף ההוראות לבד.
• כדי לכתוב סימן דולר אמיתי, מוסיפים לפניו לוכסן הפוך: \$1.00.

הזרקת מידע חי: !`פקודה`

זו אחת היכולות החזקות ביותר. שורה בצורה !`git status` בתוך SKILL.md רצה לפני ש-Claude רואה את ה-Skill, והפלט שלה מחליף אותה. כך ה-Skill מגיע ל-Claude כבר עם המידע העדכני, בלי שיצטרך לחפש.

## הענף הנוכחי
!`git branch --show-current`
 
## השינויים לעומת main
!`git diff main...HEAD --stat`

בונים שלוש מיומנויות

1. /review-pr: סקירת קוד לפי הסטנדרט שלכם

ל-Claude Code יש כבר /code-review מובנה. אז למה לבנות משלכם? כי לכל פרויקט יש דברים שחשובים לו: באתר המתכונים, למשל, נגישות למבוגרים ותמיכה בעברית.

---
name: review-pr
description: Review the current branch against main using this project's checklist (RTL, accessibility for older users, Hebrew copy). Use when the user asks for a review, before opening a PR, or before merging.
allowed-tools: Bash(git diff *) Bash(git log *) Bash(npm run build)
disallowed-tools: Edit Write
---
 
## Branch
!`git branch --show-current`
 
## Commits on this branch
!`git log main..HEAD --oneline`
 
## Changed files
!`git diff main...HEAD --stat`
 
## Instructions
 
1. Read the full diff with `git diff main...HEAD`.
2. Run `npm run build` and report whether it passes.
3. Review against [checklist.md](checklist.md).
4. Report findings in Hebrew, grouped by severity (גבוהה / בינונית / נמוכה),
   each with file and line.
5. Do NOT fix anything. End with a one-line verdict: ready to merge or not.

# Project review checklist
- All user-facing text is in Hebrew and renders correctly RTL.
- Text is at least 18px; buttons have text, not only icons.
- Works on a 375px-wide phone screen.
- No secrets, API keys, or personal data in the diff.
- No new dependencies unless they were discussed.
- No ts-ignore, eslint-disable, or swallowed errors.

שימו לב לשלוש החלטות בקובץ:

• allowed-tools מאשר מראש רק פקודות קריאה ובנייה, כך שהסקירה רצה בלי שאלות.
• disallowed-tools: Edit Write מבטיח שהסוקר לא יתקן כלום בזמן הסקירה. מסקירה מצפים לממצאים, לא לשינויים.
• רשימת הבדיקה בקובץ נפרד נטענת רק כשהסקירה רצה. ככה ה-SKILL.md נשאר קצר וממוקד.

הפעלה:

/review-pr

2. /generate-tests: בדיקות לקובץ, עם פרמטר

---
name: generate-tests
description: Generate unit tests for a given file, following the project's existing test style. Use when the user asks to add or write tests for a file or function.
argument-hint: [file-path]
---
 
Write tests for: $0
 
1. Read $0 and list every exported function and its edge cases
   (empty input, zero, very large numbers, missing fields, Hebrew text).
2. Look at examples/sample.test.ts and match its style exactly.
3. Write the tests next to the file, as <name>.test.ts.
4. Run only the new test file. If a test fails, decide whether the test
   or the code is wrong. Never weaken a test just to make it pass.
5. Summarize in Hebrew: how many tests, what they cover, what failed and why.

הפעלה:

/generate-tests lib/servings.ts

3. /deploy: העלאה לאוויר, רק בהפעלה ידנית

---
name: deploy
description: Ship the current main branch to production through Vercel
disable-model-invocation: true
allowed-tools: Bash(npm run build) Bash(git status *) Bash(git log *)
---
 
Deploy checklist:
 
1. Confirm we are on main and the working tree is clean (`git status`).
   If not, STOP and tell me what is uncommitted.
2. Run `npm run build`. If it fails, STOP and show the errors.
3. Show me the commits that will go live (`git log origin/main..HEAD --oneline`)
   and WAIT for my explicit approval.
4. Only after I approve: `git push origin main`. Vercel deploys automatically.
5. Tell me where to watch the deployment, and remind me to run the
   live-site checklist from chapter 9.

שימו לב:

• disable-model-invocation: true: רק אתם מפעילים. Claude לעולם לא יחליט לבד להעלות לאוויר.
• git push לא נמצא ב-allowed-tools: כך הדחיפה עדיין תבקש אישור, גם בתוך ה-Skill. ואם הגדרתם חוק ask ל-git push בפרק 8, הוא ממשיך לעבוד.
• נקודות עצירה מפורשות ("STOP", "WAIT"): Skills טובים לפעולות רגישות כוללים מקומות שבהם עוצרים ושואלים.

הרשאות ובקרה

חוקי הרשאות ל-Skills נכתבים כמו כל חוקי ההרשאות מפרק 8:

{
  "permissions": {
    "ask": ["Skill(deploy *)"],
    "deny": ["Skill(dangerous-cleanup)"]
  }
}

עכשיו, בכל הפעלה של /deploy, Claude Code יבקש אישור, וה-Skill dangerous-cleanup חסום לגמרי.

לתת ל-Claude לכתוב את ה-Skill

לא חייבים לכתוב Skills ביד. Claude מכיר את הפורמט היטב:

לכתוב Skills טובים: חמישה עקרונות

1. Skill אחד, משימה אחת. "סקירת PR" ו"כתיבת בדיקות" הם שני Skills, לא אחד.
2. רק צעדים ב-SKILL.md. רקע, דוגמאות ורשימות ארוכות הולכים לקבצים נלווים. ההמלצה: פחות מ-500 שורות ב-SKILL.md, והחשוב ביותר בהתחלה.
3. פורמט פלט מוגדר. "דווח בעברית, לפי חומרה, עם קובץ ושורה" עדיף על "תדווח מה מצאת".
4. נקודות עצירה בפעולות רגישות. "STOP" ו-"WAIT for approval" לפני כל דבר שקשה לבטל.
5. ללמוד מטעויות. הוסיפו לתיקיית ה-Skill קובץ learnings.md, ובקשו מ-Claude לעדכן אותו כשמשהו לא עבד. בפעם הבאה ה-Skill יהיה טוב יותר.

Skills מהקהילה

לא צריך להמציא הכול לבד. יש מאגרים גדולים של Skills מוכנים:

alirezarezvani/claude-skills

מאגר ב-GitHub, ברישיון MIT, עם כ-390 Skills ב-20 תחומים: הנדסה, שיווק, ניהול מוצר, פיננסים ועוד. דוגמאות למה שתמצאו שם:

אפשר להתקין דרך מערכת התוספים של Claude Code, או פשוט להעתיק תיקייה של Skill אחד ל-~/.claude/skills/:

/plugin marketplace add alirezarezvani/claude-skills
/plugin install engineering-skills@claude-code-skills

aitmpl.com (Claude Code Templates)

aitmpl.com הוא קטלוג אינטראקטיבי של Skills, סוכנים, פקודות, הגדרות ושרתי MCP, שמבוסס על הפרויקט הפתוח claude-code-templates (רישיון MIT). אפשר לדפדף באתר, או להריץ את מתקין שורת הפקודה:

npx claude-code-templates@latest

תרגיל: ערכת ה-Skills של הפרויקט

באתר המתכונים (או בכל פרויקט עם Git):

1. צרו את שלושת ה-Skills מהפרק: review-pr, generate-tests ו-deploy.
2. הקלידו / ובדקו ששלושתם מופיעים בתפריט.
3. הפעילו את /review-pr על ענף עם שינוי קטן. הסוקר נמנע מלתקן?
4. כתבו "תוסיף בדיקות לקובץ של מחשבון המנות" בלי לכתוב /. Claude הפעיל את generate-tests לבד?
5. כתבו "נראה שהכול מוכן, אולי כדאי להעלות לאוויר?". Claude לא אמור להפעיל את deploy לבד.
6. בקשו מ-Claude לבנות Skill רביעי משלכם, למשל new-recipe.
7. הוסיפו חוק ask ל-Skill(deploy *) ב-.claude/settings.json.

סיכום

• Skill = מתכון עבודה כתוב: תיקייה עם SKILL.md, ב-.claude/skills/ (פרויקט) או ב-~/.claude/skills/ (אישי).
• טעינה הדרגתית: רק השם והתיאור נטענים מראש. התוכן והקבצים הנלווים נטענים רק כשצריך.
• התיאור קובע מתי Claude יפעיל לבד. disable-model-invocation: true לכל מה שיש לו השלכות.
• פרמטרים עם $ARGUMENTS ו-$0, ומידע חי עם !`פקודה`.
• הרשאות: allowed-tools מאשר מראש, disallowed-tools חוסם, וחוקי Skill(...) בהגדרות.
• Skills מהקהילה חוסכים עבודה, אבל קוראים אותם לפני שמתקינים.

בפרק הבא נכיר את האחים הגדולים של ה-Skills: סוכני משנה (Sub-agents). נראה איך Claude מחלק משימות גדולות בין כמה עוזרים שעובדים במקביל, וגם נבין לעומק טוקנים, חלון הקשר ו-Prompt Caching.

בדקו את עצמכם