סקיל Writing Great Skills
writing-great-skills הוא סקיל לקלוד קוד שמלמד אותו לכתוב ולערוך סקילים בצורה שהופכת אותם צפויים ואמינים. הרעיון המרכזי: סקיל קיים כדי לחלץ דטרמיניזם ממערכת סטוכסטית, והערך העליון הוא צפיוּת, שהסוכן ינקוט אותו תהליך בכל הרצה. הסקיל מתעד את אוצר המילים והעקרונות שמשרתים את הצפיוּת: איך לכתוב description, איך לבנות היררכיית מידע, מתי לפצל סקיל, מתי לגזום, ומהן תקלות נפוצות. בפרויקטי הפיתוח שאני מוביל, סקיל שכתוב נכון הוא ההבדל בין כלי שעובד תמיד לבין כלי שמתנהג אחרת בכל פעם. במדריך תקבלו את העקרונות המלאים, ארבעה תרחישי שימוש, וצ'קליסט לעבודה נכונה.
פקודת התקנה
npx skills add mattpocock/skills@writing-great-skills -g -y
ההתקנה מתבצעת דרך מנהל החבילות הרשמי של הסקילים בפקודה אחת. הסקיל הוא קובץ Markdown פתוח מהמאגר של מאט פוקוק, ומופעל במפורש כפקודה. אפשר להוריד ולבדוק את הקוד דרך הכפתורים שבראש העמוד.
מה הסקיל כולל?
הסקיל מתעד את עקרונות הכתיבה של סקיל טוב, סביב ערך הצפיוּת: כתיבת description, היררכיית מידע, מתי לפצל, גיזום, מילים מובילות, ותקלות נפוצות שכדאי להכיר.
קוד הסקיל המלא
---
name: writing-great-skills
description: Reference for writing and editing skills well — the vocabulary and principles that make a skill predictable.
disable-model-invocation: true
---
A skill exists to wrangle determinism out of a stochastic system. **Predictability** — the agent taking the same _process_ every run, not producing the same output — is the root virtue; every lever below serves it.
**Bold terms** are defined in [`GLOSSARY.md`](GLOSSARY.md); look them up there for the full meaning.
## Invocation
Two choices, trading different costs:
- A **model-invoked** skill keeps a **description**, so the agent can fire it autonomously _and_ other skills can reach it (you can still type its name too). It contributes to **context load** — the description sits in the window every turn. Mechanics: omit `disable-model-invocation`, and write a model-facing description with rich trigger phrasing ("Use when the user wants…, mentions…").
- A **user-invoked** skill strips the description from the agent's reach: only you, typing its name, can invoke it — and no other skill can. Zero context load, but it spends **cognitive load**: _you_ are the index that must remember it exists. Mechanics: set `disable-model-invocation: true`; the `description` becomes human-facing — a one-line summary, trigger lists stripped.
Pick model-invocation only when the agent must reach the skill on its own, or another skill must. If it only ever fires by hand, make it user-invoked and pay no context load.
When user-invoked skills multiply past what you can remember, that piled-up cognitive load is cured by a **router skill**: one user-invoked skill that names the others and when to reach for each.
## Writing the description
A model-invoked **description** does two jobs — state what the skill is, and list the **branches** that should trigger it. Every word increases **context load**, so a description earns even harder pruning than the body:
- **Front-load the skill's leading word** — the description is where it does its invocation work.
- **One trigger per branch.** Synonyms that rename a single branch are **duplication** — "build features using TDD … asks for test-first development" is one branch written twice. Collapse them; keep only genuinely distinct branches.
- **Cut identity that's already in the body.** Keep the description to triggers, plus any "when another skill needs…" reach clause.
## Information hierarchy
A skill is built from two content types — **steps** and **reference** — that mix freely: a skill can be all steps, all reference, or both. The core decision is which to use and where each sits on the **information hierarchy**, a ladder ranked by how immediately the agent needs the material:
1. **In-skill step** — an ordered action in `SKILL.md`, the primary tier: what the agent does, in order. Each step ends on a **completion criterion**, the condition that tells the agent the work is done. Make it _checkable_ (can the agent tell done from not-done?) and, where it matters, _exhaustive_ ("every modified model accounted for", not "produce a change list") — a vague criterion invites **premature completion**.
2. **In-skill reference** — a definition, rule, or fact in `SKILL.md`, consulted on demand. Often a legitimately flat peer-set (every rule of a review on one rung) — a fine arrangement, not a smell. _This skill is all reference._
3. **External reference** — reference pushed out of `SKILL.md` into a separate file, reached by a **context pointer**, loaded only when the pointer fires. (Spans _disclosed_ reference — a sibling file like `GLOSSARY.md`, still part of the skill — through fully **external reference** that lives outside the skill system and any skill can point at.)
A demanding completion criterion drives thorough **legwork** — the digging the agent does within the work — whether the skill has steps or not, since "every rule applied" binds flat reference just as "every step done" binds a sequence.
Push too little down and the top bloats; push too much and you hide material the agent actually needs. That tension is the whole decision.
**Progressive disclosure** is the move down the ladder — out of `SKILL.md` into a linked file — so the top stays legible. Mechanics: a linked `.md` file in the skill folder, named for what it holds (this skill discloses its full definitions to `GLOSSARY.md`). Some skills are used in more than one way, and each distinct way is a **branch** — different runs taking different paths through the skill. Branching is the cleanest disclosure test: inline what every branch needs, and push behind a pointer what only some branches reach. A **context pointer**'s _wording_, not its target, decides when and how reliably the agent reaches the material.
Where the ladder decides _how far down_ a piece sits, **co-location** decides _what sits beside it_ once there: keep a concept's definition, rules, and caveats under one heading rather than scattered, so reading one part brings its neighbours with it.
## When to split
**Granularity** is how finely you divide skills, and each cut spends one of the two loads, so split only when the cut earns it. Two cuts:
- **By invocation** — split off a **model-invoked** skill when you have a distinct **leading word** that should trigger it on its own, or another skill must reach it. You pay **context load** for the new always-loaded **description**, so that independent reach has to be worth it.
- **By sequence** — split a run of **steps** when the steps still ahead (a step's **post-completion steps**) tempt the agent to rush the one in front of it (**premature completion**). Keeping them out of view encourages the agent to do more **legwork** on the current task.
## Pruning
Keep each meaning in a **single source of truth**: one authoritative place, so changing the behaviour is a one-place edit.
Check every line for **relevance**: does it still bear on what the skill does?
Then hunt **no-ops** sentence by sentence, not just line by line: run the no-op test on each sentence in isolation, and when one fails, delete the whole sentence rather than trim words from it. Be aggressive — most prose that fails should go, not be rewritten.
## Leading words
A **leading word** is a compact concept already living in the model's pretraining that the agent thinks with while running the skill (e.g. _lesson_, _fog of war_, _tracer bullets_). Repeated throughout the text (though not necessarily - a strong leading word might only be needed once), it accumulates a distributed definition and anchors a whole region of behaviour in the fewest tokens, by recruiting priors the model already holds.
It serves predictability twice. In the body it anchors _execution_: the agent reaches for the same behaviour every time the word appears. In the description it anchors _invocation_: when the same word lives in your prompts, docs, and code, the agent links that shared language to the skill and fires it more reliably.
Hunt for opportunities to refactor skills to use leading words. A triad spelled out at three sites (**duplication**), a description spending a sentence to gesture at one idea — each is a passage begging to **collapse** into a single token. Examples include:
- "fast, deterministic, low-overhead" -> _tight_ — one quality restated across a phase — into a single pretrained word (a _tight_ loop).
- "a loop you believe in" -> _red_ — converts a fuzzy gate into a binary observable state (the loop goes _red_ on the bug, or it doesn't).
You win twice over: fewer tokens, _and_ a sharper hook for the agent to hang its thinking on. Assume every skill is carrying restatements that leading words retire — go find them.
## Failure modes
Use these to diagnose issues the user may be having with the skill.
- **Premature completion** — ending a step before it's genuinely done, attention slipping to _being done_. Defence, in order: sharpen the completion criterion first (cheap, local); only if it is irreducibly fuzzy _and_ you observe the rush, hide the post-completion steps by splitting (the sequence cut).
- **Duplication** — the same meaning in more than one place. Costs maintenance and tokens, and inflates a meaning's prominence on the ladder past its real rank.
- **Sediment** — stale layers that settle because adding feels safe and removing feels risky. The default fate of any skill without a pruning discipline.
- **Sprawl** — a skill simply too long, even when every line is live and unique. Hurts readability and maintainability and wastes tokens. The cure is the ladder: disclose **reference** behind pointers, and split by **branch** or sequence so each path carries only what it needs.
- **No-op** — a line the model already obeys by default, so you pay load to say nothing. The test: does it change behaviour versus the default? A weak leading word (_be thorough_ when the agent is already thorough-ish) is a no-op; the fix is a stronger word (_relentless_), not a different technique.
מה זה writing-great-skills ולמה הסקיל הזה שונה?
writing-great-skills פותר בעיה שמתגלה רק כשמתחילים לכתוב סקילים: רובם לא עובדים בצורה אמינה. סקיל שכתוב רע מתנהג אחרת בכל הרצה, מתעלם מההנחיות, או נכשל בהפעלה. הסיבה היא שכתיבת סקיל טובה היא מיומנות בפני עצמה, עם עקרונות ברורים. הסקיל הזה מלמד אותם.
מה שמייחד אותו הוא המיקוד בצפיוּת. העיקרון המרכזי שלו הוא שסקיל קיים כדי להוציא דטרמיניזם ממערכת סטוכסטית, וכל החלטה משרתת את המטרה שהסוכן ינקוט אותו תהליך בכל פעם. מתוך זה נגזרים כל הכלים: איך לכתוב description שמפעיל נכון, איך לסדר היררכיית מידע, מתי לפצל סקיל גדול, מה לגזום, ואיך להשתמש במילים מובילות. הוא גם מתעד את התקלות הנפוצות, כך שלומדים גם ממה להימנע.
ההבדל מורגש באמינות הסקילים שתכתבו. במקום סקיל שמתנהג אחרת בכל פעם, מקבלים כלי צפוי שעובד. בשילוב עם סקיל grill-with-docs לחידוד, אפשר לכתוב סקילים מדויקים שמחזיקים לאורך זמן.
מה writing-great-skills נותן לקלוד קוד?
הסקיל מוסיף לקלוד את היכולת לכתוב סקילים אמינים: כלים שעובדים אותו דבר בכל הרצה, עם description נכון, מבנה ברור, וגיזום מדויק.
צפיוּת כעיקרון מנחה
העיקרון המרכזי הוא שסקיל נועד להוציא דטרמיניזם ממערכת סטוכסטית. כל החלטה בכתיבת הסקיל נמדדת מול השאלה אם היא עוזרת לסוכן לנקוט אותו תהליך בכל הרצה. זה ההבדל בין כלי אמין לכלי הפכפך.
description שמפעיל נכון
ה-description הוא מה שמחליט מתי הסקיל יופעל. הסקיל מלמד איך לכתוב אותו כך שהסוכן ידע בדיוק מתי לשלוף את הסקיל, בלי הפעלות שגויות ובלי החמצות. זה אחד ההבדלים הגדולים בין סקיל שעובד לסקיל שיושב ולא נקרא.
היררכיית מידע ופיצול
הסקיל מלמד איך לסדר את המידע בתוך הסקיל כך שהחשוב בולט, ומתי לפצל סקיל גדול לכמה קטנים. מבנה נכון שומר על הסקיל קריא לסוכן ומונע ממנו ללכת לאיבוד בתוך טקסט ארוך.
גיזום ותקלות נפוצות
הסקיל מלמד לגזום כל מה שלא משרת את התהליך, כי כל מילה מיותרת מוסיפה רעש. הוא גם מתעד את התקלות הנפוצות בכתיבת סקילים, כך שלומדים גם ממה להימנע, לא רק מה לעשות.
ארבע היכולות הופכות את קלוד לכותב סקילים מיומן. בעבודות שלי, סקיל שכתוב לפי העקרונות האלה עובד אותו דבר בכל פעם, וזה ההבדל בין כלי שאפשר לסמוך עליו לבין כזה שצריך לבדוק כל הרצה.
למי הסקיל הזה מתאים?
מי שכותב סקילים משלו: זה הקהל המובהק. הסקיל מלמד את העקרונות שהופכים סקיל מאמין, וזה חיוני למי שבונה כלים לעצמו או לצוות. השילוב עם סקיל teach עוזר ללמוד את הנושא לעומק.
צוותים שבונים ספריית סקילים: כשארגון מתחזק כמה סקילים, עקביות ואמינות קריטיות. הסקיל נותן סטנדרט כתיבה משותף, כך שכל הסקילים עובדים באותה רמה.
מפתחים שהסקילים שלהם לא עובדים טוב: מי שכתב סקיל שמתנהג אחרת בכל פעם ימצא כאן את הסיבה ואת הפתרון. הסקיל מאבחן את התקלות הנפוצות ומלמד איך לתקן.
יוצרי תוכן טכני: העקרונות של description ברור, היררכיית מידע וגיזום רלוונטיים גם לכתיבה טכנית בכלל. גם בעבודות אוטומציה שלי, הנחיה כתובה היטב היא הבסיס לתהליך אמין.
מובילי קהילות סקילים: מי שמפרסם סקילים לקהילה מרוויח מסטנדרט איכות. הסקיל עוזר לוודא שכל סקיל שמתפרסם הוא צפוי ושימושי.
מי שפחות יתאים: מי שרק משתמש בסקילים ולא כותב אותם פחות יזדקק לסקיל הזה. הוא מבריק דווקא ליוצרים ולעורכים של סקילים שרוצים שהם יעבדו אמין.
איך writing-great-skills עזר לי בפרויקטים אמיתיים
סקיל שעבר מהפכפך לאמין
כתבתי סקיל שהתנהג אחרת בכל הרצה. העקרונות של הסקיל הראו לי שהבעיה במבנה ובניסוח, לא בלוגיקה. אחרי שסידרתי היררכיית מידע וגזמתי את המיותר, הסקיל התחיל לעבוד אותו דבר בכל פעם. הצפיוּת הפכה אותו לכלי שאפשר לסמוך עליו.
description שתיקן הפעלות שגויות
סקיל שלי הופעל בזמנים הלא נכונים, או לא הופעל כשהיה צריך. הסקיל לימד אותי לכתוב description מדויק שמגדיר בבירור מתי לשלוף אותו. אחרי התיקון, ההפעלות היו מדויקות, והסקיל נקרא בדיוק כשצריך.
פיצול סקיל גדול מדי
בניתי סקיל ענק שניסה לעשות יותר מדי, והסוכן הלך בו לאיבוד. הסקיל לימד מתי לפצל, ופירקתי אותו לכמה סקילים ממוקדים. כל אחד הפך ברור ואמין יותר, והסוכן ידע בדיוק במה להשתמש.
סטנדרט כתיבה אחיד לצוות
בצוות, כל אחד כתב סקילים אחרת ובאיכות משתנה. אימצנו את העקרונות של הסקיל כסטנדרט, וכל סקיל חדש נכתב לפיהם. הספרייה הפנימית הפכה עקבית ואמינה, וזה הקל על כולם להשתמש בסקילים של האחרים.
ארבעת המקרים מראים שכתיבת סקיל טובה היא מיומנות עם עקרונות, לא עניין של מזל. כשכותבים לפי הצפיוּת, הסקילים עובדים אותו דבר בכל פעם, והופכים לכלים שאפשר באמת לסמוך עליהם.
סיכום
סקיל writing-great-skills הוא כלי חובה לכל מי שכותב סקילים. הוא מלמד את העקרונות שהופכים סקיל לצפוי ואמין: description נכון, היררכיית מידע, פיצול נבון, גיזום, וזיהוי תקלות נפוצות, הכול סביב ערך הצפיוּת.
אם אתם מתחילים, בפעם הבאה שתכתבו סקיל, השתמשו בעקרונות שלו: כתבו description מדויק, סדרו את המידע, וגזמו את המיותר. תראו איך הסקיל מתנהג אותו דבר בכל הרצה. משם, כל כלי שתבנו יהיה אמין יותר.
בפוסטים הבאים אמשיך לסקור סקילים שמשדרגים את העבודה עם בינה מלאכותית. האתר של דביר נעמן מרכז את כל הכלים, השיטות והליווי שאני מציע לעסקים שרוצים לעבוד חכם עם בינה מלאכותית.
שיתוף הסקיל
שאלות ותשובות
מה זה בעצם הסקיל writing-great-skills?
זה סקיל לקלוד קוד שמלמד אותו לכתוב ולערוך סקילים בצורה שהופכת אותם צפויים ואמינים. הוא מתעד את אוצר המילים והעקרונות של כתיבת סקיל טובה: description, היררכיית מידע, מתי לפצל, גיזום ותקלות נפוצות. המטרה היא סקילים שעובדים אותו דבר בכל הרצה.
מה זאת צפיוּת ולמה היא העיקרון המרכזי?
צפיוּת פירושה שהסוכן נוקט אותו תהליך בכל הרצה, לא בהכרח מייצר אותו פלט. זה העיקרון המרכזי כי סקיל נועד לחלץ דטרמיניזם ממערכת סטוכסטית. כל החלטה בכתיבת הסקיל נמדדת מול השאלה אם היא עוזרת לצפיוּת, וזה מה שהופך סקיל לאמין במקום הפכפך.
איך מתקינים את הסקיל בקלוד קוד?
בפקודה אחת דרך מנהל החבילות הרשמי של הסקילים, כפי שמופיע בקופסת ההתקנה למעלה. הסקיל הוא קובץ Markdown פתוח מהמאגר של מאט פוקוק, ומופעל במפורש כפקודה. כשאתם כותבים או עורכים סקיל, מפעילים אותו והוא מנחה לפי העקרונות.
למה ה-description כל כך חשוב?
ה-description הוא מה שמחליט מתי הסקיל מופעל. אם הוא מעורפל, הסקיל יופעל בזמנים הלא נכונים או לא יופעל כשצריך. הסקיל מלמד לכתוב description שמגדיר בבירור את תנאי ההפעלה, וזה אחד ההבדלים הגדולים בין סקיל שנקרא נכון לבין סקיל שיושב ולא בשימוש.
מתי כדאי לפצל סקיל לכמה סקילים?
כשסקיל מנסה לעשות יותר מדי, הסוכן מתקשה לעקוב והאמינות יורדת. הסקיל מלמד מתי לפצל סקיל גדול לכמה ממוקדים, כל אחד עם תפקיד ברור. פיצול נכון שומר על כל סקיל קריא וצפוי, ומאפשר לסוכן לדעת בדיוק במה להשתמש לכל מצב.
מה זה גיזום בהקשר של סקילים?
גיזום הוא הסרת כל מה שלא משרת את התהליך מהסקיל. כל מילה מיותרת מוסיפה רעש ומקשה על הסוכן להתמקד בעיקר. הסקיל מלמד לזהות ולהסיר תוכן עודף, כך שהסקיל נשאר רזה וממוקד. סקיל מגוזם היטב צפוי ואמין יותר מסקיל עמוס.
מה ההבדל בין הסקיל הזה ל-skill-creator?
skill-creator מתמקד ביצירת סקיל מאפס, כולל המבנה והקבצים. writing-great-skills מתמקד בעקרונות הכתיבה שהופכים כל סקיל לצפוי ואמין: description, היררכיה, גיזום ותקלות. השניים משלימים: אחד בונה את השלד, השני מלמד איך לכתוב את התוכן נכון.
האם הסקיל מתאים גם למתחילים בכתיבת סקילים?
במיוחד. דווקא מי שרק מתחיל לכתוב סקילים ירוויח מהעקרונות, כי הם מונעים את הטעויות הנפוצות מראש. במקום ללמוד בדרך הקשה למה הסקיל לא עובד, מתחילים עם המבנה והניסוח הנכונים. זו דרך מצוינת לכתוב סקילים אמינים כבר מההתחלה.