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

הפוסט הזה הוא פוסט המשך לפוסט הקודם שעוסק בתשתית בינה מלאכותית וחלק מהסדרה של איך הופכים פרויקט ל AI Ready ועל המשמעויות של לעבוד על פרויקט קוד בתקופה הנוכחית שבה משתמשים בעיקר בכלי בינה מלאכותית על מנת לכתוב את הקוד. את הפוסטים כתבתי בסיוע גליה קרופך ואני מודה לה מאד על הרעיון והסיוע. הפוסט הקודם דיבר על חשיבות תשתית ה-CI לעבודה עם סוכנים. הפוסט הזה ידבר על איך מתקשרים עם אייג׳נטים באמצעות סקילים והוראות ומה ההבדל בינהם.

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

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

הקונטקסט: הגביע הקדוש

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

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

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

הוראות

קובץ ההוראות הכללי

הוראות הן המצפן המוסרי והמקצועי של הפרויקט; הן מגדירות את ה"מה" ואת ה"איך" הכללי. כשאתה כותב הוראות, אתה בעצם משרטט את דמותו של השותף האידיאלי/ למשל, כזה שמקפיד על שמות משתנים ברורים, שנמנע מלוגיקה מורכבת מדי או שמעדיף תמיד פתרונות פשוטים על פני מתוחכמים. הוראות אלו שהן לכלל הפרויקט, חיות בכמה מקומות. או בקובץ הוראות פר פרויקט. למשל CLAUDE.md או cursorrules. שנמצאות ממש בקוד של הפרויקט. אפשר להכניס גם הוראות כלליות בהגדרות (של הקלוד קוד או של הקורסור). הבעיה היא שהוראות הן תובעניות. הן תופסות מקום בזיכרון העבודה של המודל, וככל שיש יותר מהן, כך תשומת הלב שלו מתפזרת והוא עלול "לשכוח" חלק מהן או לפרש אותן בצורה יצירתית מדי שלא תמיד משרתת את המטרה. אנחנו חייבים להיות חסכוניים.

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

קובץ הוראות ספציפי

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

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

סקילים

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

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

---
name: github
description: Use this skill for any GitHub operations in the terminal or Claude Code: opening issues, creating pull requests, reviewing PRs, listing issues, adding labels or comments, checking PR status, merging branches, cloning repos, or any other GitHub workflow. Trigger whenever the user mentions issues, PRs, pull requests, tickets, GitHub, wants to interact with a repository, or asks about repo activity.
---

# GitHub Skill

Use the `gh` CLI for all GitHub operations. The token is already set via `GITHUB_TOKEN` env variable.

## Before anything

Always confirm which repo you're in:

```bash
gh repo view
```

---

## Issues

### Create an issue

```bash
gh issue create --title "Bug: X is broken" --body "Steps to reproduce..." --label bug
```

### List open issues

```bash
gh issue list --state open
```

### View a specific issue

```bash
gh issue view 42
```

### Add a comment

```bash
gh issue comment 42 --body "Looking into this now"
```

### Close an issue

```bash
gh issue close 42
```

---

## Pull Requests

### Create a PR

```bash
gh pr create --title "feat: add X" --body "## What\nDescription here" --base main
```

### List open PRs

```bash
gh pr list
```

### View a PR

```bash
gh pr view 42
```

### See a PR's code diff

```bash
gh pr diff 42
```

### Merge a PR

```bash
gh pr merge 42 --squash
```

### Add a comment to a PR

```bash
gh pr comment 42 --body "Looks good, merging tomorrow"
```

---

## Resolving PR Conflicts

When a PR has conflicts with the base branch, resolve them via rebase (preferred over merge commits).

### 1. Check which files conflict

```bash
gh pr view 42          # confirm the base branch
git fetch origin main  # update local knowledge of main
git rebase origin/main # attempt rebase — git will stop at each conflicting file
```

### 2. For each conflicting file

Open the file and look for conflict markers:

```
<<<<<<< HEAD
your branch's version
=======
main's version
>>>>>>> origin/main
```

Edit the file to the correct final state, then stage it:

```bash
git add path/to/file
```

### 3. Continue or abort

```bash
git rebase --continue   # after staging all conflicts in the current commit
git rebase --abort      # to undo everything and return to pre-rebase state
```

### 4. Push the resolved branch

```bash
git push --force-with-lease   # safer than --force: fails if someone else pushed
```

The PR will update automatically.

### Tips

- Prefer `git rebase origin/main` over `git merge origin/main` to keep a linear history.
- If the conflict is in a generated file (e.g. `package-lock.json`), delete it and re-run `npm install` after the rebase, then `git add` and `git rebase --continue`.
- Use `git diff --name-only --diff-filter=U` to list all unresolved files at any point during a rebase.

---

## Tips

- Add `--web` to any command to open it in the browser instead
- Use `gh issue list --assignee @me` to see only your issues
- Use `gh pr list --author @me` to see your own PRs
- Always confirm the current repo with `gh repo view` before running commands

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

סקילים יכולים להכיל, כפי שאנו רואים, גם קוד שהוא בעצם כלים. שימוש בכלים מלווה אותנו כבר הרבה שנים עם LLM ויש כמה דרכים לממש כלים כשהבולט שבהם הוא MCP (Model Context Protocol). המטרה של כלים, מ MCP ועד CLI היא לתת לאייג׳נט "ידיים" לגשת למידע הזה רק כשהוא זקוק לו. האייג׳נט יכול לתשאל מסד נתונים, לקרוא תיעוד משרת מרוחק או לסרוק קבצים ספציפיים על פי דרישה. הכלים האלו יכולים להיות כלים סטנדרטיים או סתם קוד שאתם כותבים.

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

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