איך לבנות סקילים ל-Claude Code — מדריך מעשי שלב אחר שלב

כדי לייצר סקילים (Skills) עבור Claude Code, צריך להבין שלושה דברים: מה הכלי מצפה לקבל, איך כותבים הוראות ברורות בקובצי Markdown, ואיך מארגנים אותן בתיקיית .claude/ בפרויקט שלכם. סקיל ב-Claude Code הוא בעצם קובץ Markdown שמלמד את ה-AI איך לפעול בהקשר ספציפי — מסגנון קוד, דרך תהליכי עבודה, ועד ארכיטקטורה שלמה. זה לא קסם. זה הנדסה של הנחיות (Prompt Engineering) ברמת פרויקט, ומי שעושה את זה נכון הופך את Claude לבן זוג פיתוח אמיתי — לא לצ'אטבוט שמנחש.

הגדרה: סקילים הם הזיכרון המוסדי של ה-AI

כשאתם עובדים עם Claude Code, ה-AI מתחיל כל שיחה מדף חלק. הוא לא יודע שבפרויקט שלכם יש קונבנציות ספציפיות, שאתם מעדיפים TypeScript על JavaScript, או שכל קומפוננטה חייבת לעבור דרך תיקיית shared/. סקילים פותרים את הבעיה הזו. הם קבצים שנטענים אוטומטית או לפי דרישה, ומספקים ל-Claude הקשר מדויק על הפרויקט שלכם.

לפי התיעוד הרשמי של Anthropic, ישנם שלושה סוגי סקילים: סקילים ברמת פרויקט (Project-level), סקילים אישיים (User-level), וסקילים שנטענים לפי דרישה (On-demand). כל אחד מהם משרת תפקיד שונה ומוגדר במיקום שונה במערכת הקבצים.

למה מפתחים בישראל חייבים את זה עכשיו

בסקר של Stack Overflow Developer Survey 2024, כ-76% מהמפתחים דיווחו שהם משתמשים בכלי AI בתהליך הפיתוח. אבל רק 29% אמרו שהם "מרוצים מאוד" מהתוצאות. הפער הזה? הוא בדיוק הפער שסקילים מגשרים עליו. כשאתם נותנים ל-AI הקשר מדויק, הקוד שהוא מייצר קופץ מ"בסדר, אני אצטרך לתקן את זה" ל"וואו, הוא הבין בדיוק מה רציתי".

בתעשיית ההייטק הישראלית, שבה צוותים קטנים עושים עבודה של צוותים גדולים, היכולת להאיץ פיתוח באמצעות AI מותאם-פרויקט היא לא מותרות — זה יתרון תחרותי. סטארטאפים ישראליים כמו Wiz ו-Firefly עובדים בקצב שדורש כלים חכמים שמבינים הקשר.

יצירת תיקיית .claude/ והגדרת CLAUDE.md

הצעד הראשון הוא הכי חשוב והכי פשוט. צריך ליצור את מבנה התיקיות שבו Claude Code מחפש סקילים. הקובץ המרכזי נקרא CLAUDE.md והוא יושב בשורש הפרויקט. בנוסף, תיקיית .claude/ מכילה סקילים ייעודיים שנטענים לפי הצורך.

# יצירת מבנה הסקילים בפרויקט קיים
cd /path/to/your/project

# יצירת קובץ CLAUDE.md ראשי בשורש הפרויקט
touch CLAUDE.md

# יצירת תיקיית הסקילים
mkdir -p .claude/skills

# יצירת סקיל ראשון — סגנון קוד
cat > .claude/skills/coding-style.md << 'EOF'
# סגנון קוד בפרויקט

## כללים מחייבים
- השתמש ב-TypeScript תמיד, לא ב-JavaScript
- כל פונקציה חייבת לכלול JSDoc עם תיאור, פרמטרים, וערך חזרה
- שמות משתנים ב-camelCase, שמות קלאסים ב-PascalCase
- כל קומפוננטה מקבלת קובץ טסט עם לפחות 2 תרחישים

## דוגמה לפונקציה תקינה
```typescript
/**
 * Calculates the total price including VAT for Israeli market
 * @param basePrice - The base price in ILS
 * @param vatRate - VAT rate (default: 0.17 for Israel)
 * @returns Total price including VAT
 */
export function calculateTotalPrice(basePrice: number, vatRate: number = 0.17): number {
  if (basePrice < 0) {
    throw new Error('Base price cannot be negative');
  }
  return basePrice * (1 + vatRate);
}
```

## מה לא לעשות
- לא להשתמש ב-any אלא אם אין ברירה, ואז לתעד למה
- לא לכתוב פונקציות ארוכות מ-30 שורות
- לא לעשות import * — תמיד named imports
EOF

echo "✅ מבנה סקילים בסיסי נוצר בהצלחה"

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

כתיבת CLAUDE.md — הלב של הפרויקט

הקובץ CLAUDE.md הוא הדבר הראשון ש-Claude Code קורא כשהוא נכנס לפרויקט שלכם. חשבו על זה כמו README, אבל לא בשביל בני אדם — בשביל ה-AI. ככל שהוא ברור ומדויק יותר, כך ה-AI עובד טוב יותר.

# יצירת קובץ CLAUDE.md מקיף
cat > CLAUDE.md << 'HEREDOC'
# Project: MyApp — Israeli Fintech Platform

## Overview
This is a fintech application serving the Israeli market.
Backend: Node.js with Express + TypeScript
Frontend: React 18 with Vite
Database: PostgreSQL with Prisma ORM
Testing: Vitest for unit, Playwright for E2E

## Architecture Rules
- All API routes go in `src/routes/` following RESTful conventions
- Business logic lives in `src/services/` — controllers are thin
- Shared types are defined in `src/types/` and imported by both frontend and backend
- Environment variables are validated at startup using Zod schemas in `src/config/env.ts`

## Development Commands
- `npm run dev` — starts dev server on port 3000
- `npm run test` — runs Vitest
- `npm run test:e2e` — runs Playwright tests
- `npm run db:migrate` — runs Prisma migrations
- `npm run lint` — ESLint + Prettier check

## Israeli Market Context
- Currency is ILS (₪), always use Intl.NumberFormat('he-IL')
- VAT rate is 17% (as of 2024)
- Date format: DD/MM/YYYY, timezone: Asia/Jerusalem
- RTL support is mandatory for all UI components
- Bank integration uses Shva (שב"א) protocols

## Code Review Checklist
Before suggesting any code, verify:
1. TypeScript strict mode compatibility
2. Error messages are user-friendly in Hebrew
3. All monetary calculations use decimal.js (never floating point)
4. API responses follow our standard envelope: { success, data, error }

## Skills
Load additional skills from `.claude/skills/` as needed:
- `coding-style.md` — coding conventions
- `testing-patterns.md` — how we write tests
- `deployment.md` — CI/CD and deployment procedures
- `api-design.md` — API design guidelines
HEREDOC

echo "✅ CLAUDE.md נוצר בהצלחה"

קובץ CLAUDE.md טוב הוא ספציפי, לא כללי. שימו לב שהוא מזכיר את שוק ישראל, את מטבע השקל, את שיעור המע"מ, ואת התמיכה ב-RTL. אלה בדיוק הדברים שה-AI היה מפספס בלעדיהם.

סקילים לתהליכי עבודה (Workflow Skills)

סקיל של סגנון קוד זה בסיס. הרמה הבאה היא סקילים שמלמדים את Claude תהליכי עבודה שלמים. למשל: איך אתם רוצים שהוא יגשר ל-Code Review, איך הוא צריך לגשת לדיבוג, או איך לבנות פיצ'ר חדש מאפס.

# סקיל לפיתוח פיצ'ר חדש
cat > .claude/skills/new-feature-workflow.md << 'EOF'
# Workflow: Building a New Feature

When asked to build a new feature, follow these steps IN ORDER:

## Step 1: Understand
- Ask clarifying questions if the requirement is vague
- Identify affected modules in `src/`
- List potential breaking changes

## Step 2: Plan
- Create a brief implementation plan (3-7 bullet points)
- Identify which files need to change
- Note any new dependencies needed
- Present plan for approval BEFORE writing code

## Step 3: Implement
- Start with types/interfaces in `src/types/`
- Then implement service layer in `src/services/`
- Then add routes/controllers in `src/routes/`
- Then update frontend components
- Each file change should be a logical unit

## Step 4: Test
- Write unit tests alongside implementation
- Cover happy path + at least 2 edge cases
- For API endpoints: test validation, auth, and business logic
- Test file goes next to source file: `myFile.ts` → `myFile.test.ts`

## Step 5: Document
- Update relevant JSDoc comments
- If API changed, update the API docs in `docs/api/`
- Add migration notes if database schema changed

## Anti-Patterns (DO NOT DO)
- Never implement everything in one giant code block
- Never skip the planning step
- Never add a dependency without explaining why
- Never modify test utilities without discussing first
EOF

echo "✅ סקיל workflow נוצר"

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

סקילים לאינטגרציות ספציפיות

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

# סקיל לאינטגרציה עם מערכת תשלומים
cat > .claude/skills/payment-integration.md << 'EOF'
# Payment Integration: Tranzila API

## Overview
We use Tranzila (טרנזילה) as our payment gateway for the Israeli market.
API Base URL: https://secure5.tranzila.com/cgi-bin/tranzila71u.cgi

## Authentication
- Terminal name is stored in env var: TRANZILA_TERMINAL
- API password in: TRANZILA_API_PASSWORD
- Never log or expose these values

## Standard Charge Request
```typescript
interface TranzilaChargeRequest {
  supplier: string;      // terminal name
  TranzilaPW: string;    // API password
  sum: number;           // amount in ILS (agorot precision: 100 = 1₪)
  ccno: string;          // card number (in production, use tokenized)
  expdate: string;       // MMYY format
  currency: 1;           // 1 = ILS
  cred_type: 1 | 8;      // 1 = regular, 8 = installments
  mycvv: string;         // CVV
  myid: string;          // Israeli ID number (for verification)
}
```

## Important Rules
- All amounts are in agorot (multiply ILS by 100)
- Always validate Israeli ID (teudat zehut) checksum before sending
- Transaction responses: Response code "000" = success, anything else = failure
- Store transaction index (tranmode) for refunds
- PCI compliance: never store full card numbers, use tokenization

## Error Handling
Map Tranzila error codes to Hebrew user messages:
- "004" → "הכרטיס נדחה, נא לפנות לחברת האשראי"
- "006" → "שגיאת CVV, נא לבדוק את הספרות בגב הכרטיס"
- "033" → "הכרטיס לא תקף, נא להשתמש בכרטיס אחר"
EOF

echo "✅ סקיל payment integration נוצר"

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

מבנה תיקיות מומלץ לפרויקט גדול

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

# מבנה תיקיות מומלץ לפרויקט בינוני-גדול
tree .claude/

.claude/
├── skills/
│   ├── general/
│   │   ├── coding-style.md
│   │   ├── git-conventions.md
│   │   └── error-handling.md
│   ├── workflows/
│   │   ├── new-feature.md
│   │   ├── bug-fix.md
│   │   ├── code-review.md
│   │   └── refactoring.md
│   ├── integrations/
│   │   ├── payment-tranzila.md
│   │   ├── sms-inforu.md
│   │   └── auth-firebase.md
│   ├── infrastructure/
│   │   ├── docker-setup.md
│   │   ├── ci-cd-github-actions.md
│   │   └── aws-deployment.md
│   └── domain/
│       ├── israeli-regulations.md
│       ├── banking-terms.md
│       └── tax-calculations.md
└── settings.json

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

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

אחרי שעבדתי עם עשרות צוותים שמטמיעים Claude Code, אני רואה את אותן טעויות חוזרות. הנה הגדולות:

טעות #1: סקילים ארוכים מדי. אם סקיל אחד ארוך מ-500 שורות, תפצלו אותו. Claude עובד טוב יותר עם מספר סקילים ממוקדים מאשר עם מסמך אחד ענק. לפי מחקר של Anthropic עצמם, הנחיות ממוקדות מייצרות תוצאות מדויקות ב-40% יותר מאשר הנחיות כלליות.

טעות #2: הנחיות סותרות. אם ב-coding-style.md כתוב "השתמש ב-camelCase" ובסקיל אחר כתוב "השתמש ב-snake_case" — Claude יתבלבל ויבחר באקראי. עשו ביקורת חוצת-סקילים פעם ברבעון.

טעות #3: אין דוגמאות. כלל בלי דוגמה הוא כלל חלש. תמיד הוסיפו קטע קוד שמראה את ה-do וה-don't. Claude לומד מדוגמאות הרבה יותר טוב מאשר מהסברים מילוליים.

טעות #4: שוכחים לעדכן. סקילים שמתארים מציאות ישנה גרועים יותר מאין סקילים בכלל. אם שיניתם ספריית UI מ-Material UI ל-shadcn/ui, עדכנו את הסקילים באותו PR.

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

#!/bin/bash
# claude-skills-init.sh
# סקריפט אתחול סקילים עבור Claude Code
# שימוש: ./claude-skills-init.sh [project-name] [language]

set -euo pipefail

PROJECT_NAME="${1:-my-project}"
LANGUAGE="${2:-typescript}"

echo "🚀 מאתחל מבנה סקילים עבור: $PROJECT_NAME"

# יצירת מבנה תיקיות
mkdir -p .claude/skills/{general,workflows,integrations,infrastructure,domain}

# יצירת CLAUDE.md ראשי
cat > CLAUDE.md << EOF
# Project: ${PROJECT_NAME}

## Tech Stack
- Language: ${LANGUAGE}
- Node version: $(node -v 2>/dev/null || echo "N/A")
- Package manager: $([ -f "pnpm-lock.yaml" ] && echo "pnpm" || ([ -f "yarn.lock" ] && echo "yarn" || echo "npm"))

## Project Structure
$(find src -type d 2>/dev/null | head -20 | sed 's/^/- /' || echo "- src/ (not yet created)")

## Development Commands
- Install: $([ -f "pnpm-lock.yaml" ] && echo "pnpm install" || echo "npm install")
- Dev: $([ -f "pnpm-lock.yaml" ] && echo "pnpm dev" || echo "npm run dev")
- Test: $([ -f "pnpm-lock.yaml" ] && echo "pnpm test" || echo "npm test")
- Build: $([ -f "pnpm-lock.yaml" ] && echo "pnpm build" || echo "npm run build")

## Key Conventions
- All code must be in ${LANGUAGE}
- Follow existing patterns in the codebase
- Write tests for all new functionality
- Use meaningful commit messages (Conventional Commits)

## Skills Directory
Additional context is available in \`.claude/skills/\`:
$(ls .claude/skills/*/*.md 2>/dev/null | sed 's/^/- /' || echo "- (skills will be added)")
EOF

# יצירת סקיל סגנון קוד
cat > .claude/skills/general/coding-style.md << EOF
# Coding Style for ${PROJECT_NAME}

## Naming Conventions
- Variables and functions: camelCase
- Classes and types: PascalCase
- Constants: UPPER_SNAKE_CASE
- File names: kebab-case.${LANGUAGE##*script}

## Import Order
1. Node.js built-in modules
2. External dependencies
3. Internal modules (absolute paths)
4. Relative imports
5. Type imports (with \`type\` keyword)

## Error Handling
- Always use custom error classes extending base AppError
- Include error codes for API responses
- Log errors with structured logging (pino/winston)
- Never expose stack traces to clients in production
EOF

# יצירת סקיל Git
cat > .claude/skills/general/git-conventions.md << EOF
# Git Conventions

## Branch Naming
- feature/TICKET-123-short-description
- fix/TICKET-456-bug-description
- chore/update-dependencies

## Commit Messages (Conventional Commits)
- feat: new feature
- fix: bug fix
- docs: documentation only
- refactor: code change that neither fixes a bug nor adds a feature
- test: adding or updating tests
- chore: maintenance tasks

## PR Guidelines
- Title matches the main commit message
- Description includes: What, Why, How, Testing steps
- Max 400 lines changed per PR (split larger changes)
EOF

# יצירת סקיל תהליך דיבוג
cat > .claude/skills/workflows/debugging.md << EOF
# Debugging Workflow

When asked to debug an issue:

1. **Reproduce**: Ask for steps to reproduce if not provided
2. **Isolate**: Identify the smallest code path that causes the issue
3. **Hypothesize**: List 2-3 possible causes, ranked by likelihood
4. **Verify**: Add targeted console.log/debugger statements
5. **Fix**: Apply the minimal change that fixes the root cause
6. **Prevent**: Add a test that would have caught this bug
7. **Document**: Add a code comment explaining the non-obvious fix

## Common Pitfalls in This Project
- Timezone issues: always use \`dayjs\` with \`utc\` plugin, convert to Asia/Jerusalem for display
- Decimal precision: monetary values use \`decimal.js\`, never native floats
- Async race conditions: check for proper \`await\` usage in Promise chains
EOF

# ספירת קבצים שנוצרו
SKILL_COUNT=$(find .claude/skills -name "*.md" | wc -l)

echo ""
echo "✅ אתחול הושלם בהצלחה!"
echo "📁 נוצרו ${SKILL_COUNT} קבצי סקילים"
echo "📄 CLAUDE.md ראשי נוצר בשורש הפרויקט"
echo ""
echo "📝 הצעדים הבאים:"
echo "   1. ערכו את CLAUDE.md והתאימו אותו לפרויקט שלכם"
echo "   2. הוסיפו סקילים ספציפיים בתיקיות המתאימות"
echo "   3. הוסיפו את .claude/ ל-Git (אל תוסיפו ל-.gitignore!)"
echo "   4. הריצו: git add .claude/ CLAUDE.md && git commit -m 'chore: init Claude Code skills'"

הסקריפט הזה עושה משהו חכם — הוא מזהה אוטומטית את מנהל החבילות (npm/pnpm/yarn), את גרסת Node, ואת מבנה התיקיות הקיים, ומשלב את המידע הזה ישירות ב-CLAUDE.md. זו לא תבנית גנרית — זה מידע אמיתי מהפרויקט שלכם.

סקילים דינמיים — כשהפרויקט גדול מדי

בפרויקטי מונורפו או בפרויקטים עם מאות קבצים, לא הגיוני לטעון את כל הסקילים בכל שיחה. לפי מחקר של Google על Context Window Efficiency, טעינת מידע לא רלוונטי מורידה את איכות התוצאות ב-15-25%. הפתרון: סקילים בתתי-תיקיות.

כל תיקייה בפרויקט יכולה לכלול קובץ CLAUDE.md משלה. כש-Claude עובד על קובץ בתיקיית src/payments/, הוא יטען אוטומטית גם את src/payments/CLAUDE.md בנוסף ל-CLAUDE.md הראשי. זה מאפשר הקשר מדויק בלי עומס.

# יצירת סקיל ברמת תיקייה
cat > src/payments/CLAUDE.md << 'EOF'
# Payments Module

This module handles all payment processing for the Israeli market.

## Key Files
- `processor.ts` — main payment processing logic
- `validators.ts` — input validation (card numbers, Israeli ID)
- `tranzila-client.ts` — Tranzila API wrapper
- `types.ts` — shared payment types

## Testing Payments
- Use Tranzila test terminal: `test_terminal`
- Test card number: 4111111111111111
- Any future expiry date works
- CVV: 123

## Security Rules
- NEVER log card numbers, even partially
- All PCI-sensitive data goes through `sanitize()` before logging
- Payment tokens expire after 24 hours
- Always validate Israeli ID checksum before processing
EOF

מדידת אפקטיביות הסקילים

איך יודעים אם הסקילים שלכם עובדים? הנה מספר מדדים פרקטיים:

מדד 1: שיעור "הקוד הראשון תקין" (First-attempt accuracy). כמה פעמים Claude מייצר קוד שעובר lint ו-build בניסיון הראשון? עם סקילים טובים, זה צריך לעלות מ-40-50% ל-70-80%.

מדד 2: מספר שאלות הבהרה. אם Claude שואל פחות שאלות טריוויאליות ("באיזו ספריית בדיקות אתם משתמשים?") ויותר שאלות משמעותיות ("האם הפיצ'ר הזה צריך לתמוך גם בתשלומים בדולרים?"), הסקילים עובדים.

מדד 3: זמן ל-PR מוכן. עקבו אחרי הזמן מרגע שמתחילים לעבוד עם Claude על פיצ'ר ועד שה-PR מוכן ל-review. עם סקילים מותאמים, הצוותים שעבדתי איתם ראו ירידה ממוצעת של 35% בזמן הזה.

האם סקילים של Claude Code עובדים גם עם Claude בצ'אט הרגיל?

לא. סקילים (קבצי CLAUDE.md ו-.claude/skills/) הם מנגנון ייחודי ל-Claude Code — הכלי שרץ בטרמינל ומתממשק ישירות עם מערכת הקבצים. בצ'אט הרגיל של Claude (claude.ai) אין גישה לקבצים מקומיים. אם אתם רוצים אפקט דומה בצ'אט, תצטרכו להדביק את ההנחיות ידנית ב-System Prompt דרך ה-API או להשתמש ב-Projects של Claude.

כמה סקילים זה יותר מדי? יש מגבלת גודל?

אין מגבלה טכנית קשיחה על מספר קבצי הסקילים, אבל יש מגבלת Context Window. כל מה שנטען לשיחה תופס מקום בחלון ההקשר (200K tokens ב-Claude 4 Sonnet). הכלל שלי: שמרו על CLAUDE.md הראשי עד 200 שורות, וכל סקיל בודד עד 150 שורות. אם יש לכם יותר מ-20 סקילים, ודאו שהם מאורגנים בתתי-תיקיות כדי שרק הרלוונטיים ייטענו.

האם כדאי לשמור את תיקיית .claude/ ב-Git?

בהחלט כן — זו אחת הנקודות החשובות. סקילים הם חלק מתיעוד הפרויקט, ולכל הצוות כדאי ליהנות מהם. שמרו אותם ב-Git, עשו להם Code Review כמו לכל קובץ אחר, ועדכנו אותם כחלק מתהליך הפיתוח. היוצא מהכלל: הקובץ ~/.claude/CLAUDE.md (ברמת המשתמש) — הוא אישי ולא שייך ל-Git של הפרויקט.

אפשר לכתוב סקילים בעברית?

טכנית כן, Claude מבין עברית מצוין. אבל בפרקטיקה, רוב הצוותים כותבים סקילים באנגלית ממספר סיבות: (1) מונחים טכניים נשארים בהירים, (2) Claude מייצר פלט עקבי יותר מהנחיות באנגלית, (3) צוותים מגוונים עם דוברי שפות שונות יכולים לקרוא אותם. לעומת זאת, הודעות שגיאה למשתמש, תיעוד UI, וסקילים שעוסקים בהקשר ישראלי ספציפי (רגולציה, מע"מ) — כן הגיוני לכתוב חלקית בעברית.

מה ההבדל בין סקיל ל-System Prompt?

סקיל הוא קובץ Markdown שחי בפרויקט ונטען אוטומטית על ידי Claude Code. System Prompt הוא הנחיה שנשלחת דרך ה-API בכל בקשה. ההבדל המעשי: סקילים מנוהלים בגיט, משתנים עם הפרויקט, ויכולים להיטען באופן קונטקסטואלי (רק כשעובדים על מודול ספציפי). System Prompt הוא סטטי וגלובלי. חשבו על סקילים כ"ידע שגדל עם הפרויקט" ועל System Prompt כ"כללים קבועים".

איך מעדכנים סקילים כשהטכנולוגיה בפרויקט משתנה?

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

האם אפשר לשתף סקילים בין פרויקטים שונים?

כן, וזו פרקטיקה מומלצת. סקילים שקשורים לסגנון הארגוני (קונבנציות Git, כללי Code Review, מדיניות אבטחה) יכולים לחיות ב-repo נפרד ולהיות מיובאים כ-Git submodule או להיות מועתקים דרך סקריפט אתחול. סקילים ספציפיים לפרויקט (אינטגרציות, מבנה תיקיות, פקודות build) צריכים להישאר בפרויקט עצמו. ארגונים גדולים יותר יוצרים "ספריית סקילים" פנימית שמשמשת כבסיס לכל פרויקט חדש.

אז מה עכשיו? לא צריך ליצור 50 סקילים היום. תתחילו עם CLAUDE.md אחד בשורש הפרויקט. תכתבו 10-15 שורות שמתארות את הסטאק, הקונבנציות, ופקודת ה-build. תעבדו ככה שבוע. תשימו לב איפה Claude עדיין "לא מבין" — ושם תוסיפו סקיל ממוקד. בניית סקילים טובה היא תהליך איטרטיבי, בדיוק כמו כתיבת קוד טוב. אף אחד לא כותב את המערכת המושלמת ביום הראשון. אבל מי שמתחיל היום, עוד חודש ירגיש את ההבדל — ואחרי שלושה חודשים לא יבין איך עבד בלי זה. אם אתם רוצים להעמיק, התיעוד של Anthropic הוא מקום מצוין להמשיך. ואם אתם רוצים ללמוד את זה עם ליווי מעשי, עם פרויקטים אמיתיים ומנטורים שחיים את זה — אנחנו כאן. הדלת פתוחה.

• קורס סייבר ואבטחת מידע
• קורס Real Time Embedded
• קורס דאטה סיינס
• קורס למידת מכונה AI
• קורס דאטה אנליסט
• קורס DEVOPS
• קורס IT
• קורס אוטומציה
• קורס Full Stack
• קורס בניית אתרים