אנחנו נכנסים לשלב סיכום סדרת המאמרים במסע ליצירת בסיסי ידע אישיים וארגוניים או כפי שהם מוכרים יותר כיום Second Brain (מוח שני). כזכור הכל התחיל עם הציוץ של אנדריי קרפטי שכבר הגיע ל 21 מיליון צפיות. בפוסט הוא מתאר את מערכת ה Wiki שהוא פרסם ב GitHub בה הוא בנה מערך מבוסס AI שאוסף מקורות גולמיים של מידע כמו מאמרים, מסמכים, דאטה ותמונות, מעליהם מודל שפה (AI) שהופך אותם לוויקי מבוסס Markdown עם סיכומים, מושגים, קישורים ואינדקסים.

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

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

ניהול ידע לסוכני AI שאינו מבוסס על RAG

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

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

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

כאמור, אחד האתגרים הגדולים של מודלי שפה (צ'טים וסוכני AI) היא היכולת שלהם לענות על מידע עדכני או מידע פנימי שהם לא ראו או למדו עליו בעבר. ולכן בכל פעם ששואלים את המודל שאלה ב צ'ט (Session) חדש על מידע שלא נמצא בנתוני האימון של המודל, נדרש מנגנון ניהול זיכרון חיצוני מתמשך (Persistent Memory) כדי לענות על השאלה או לבצע את ההנחיה.

לא רק קריאת מידע, אלא מערכת ידע חיה

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

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

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

אז בואו נצא לדרך ונתחיל להרכיב את ה-"מוח הנוסף" שלנו.

הרכיב הראשון (מומלץ מאד אך לא חובה): סביבת הפעלה בטוחה (ארגז חול).

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

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

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

למימוש שלי בחרתי בטכנולוגיית ה Sandbox של חברת Docker. ראשית Docker היא אחת החברות המובילות להרצה של סביבות הפעלה וירטואליות, שנית היא בנתה את טכנולוגיית ה Sandbox שלה בדיוק לצורך הזה של הרצה מקומית בטרמינל של כלים כמו Claude Code או Codex של OpenAI.

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

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

שלבי ההתקנה וההפעלה:

• 1. ראשית שמרו את כל הקבצים הפתוחים שלכם במחשב - יתכן ותדרשו לאתחול של המחשב פעם או פעמיים במסגרת התהליך.
• 2. לחצו על האייקון של Windows במחשב וחפשו את Windows PowerShell
• 3. לחצו עליו באמצעות העכבר עם הכפתור הימני ובחרו באפשרות Run As Administrator.
• 4. העתיקו את הפקודה הבאה ותריצו אותה.

Enable-WindowsOptionalFeature -Online -FeatureName HypervisorPlatform -All

היא מפעילה ב-Windows את מנגנון הווירטואליזציה (Windows Hypervisor Platform), שמאפשר להריץ סביבות עבודה מבודדות ובטוחות.

• 5. בשלב זה תתבקשו לאתחל את המחשב.
• 6. עכשיו נתקין את Docker Sandbox ( נעשה זאת שוב בסביבת ה Windows PowerShell - חזרו על שלבים 2 + 3 ) ותעתיקו את הפקודה הבאה לטרמינל (חלון) ה Windows PowerShell ולחצו על Enter. זו פעולת ההתקנה של ה MicroVM של Docker.

Winget install -h Docker.sbx

• 7. לאחר ההתקנה יש לבצע רישום חד פעמי של המחשב שלכם לשירות. תריצו את הפקודה הבאה מיד לאחר שההתקנה הקודמת הסתיימה.

sbx login

• 5. אם זו פעם ראשונה שרתם מתחברים ל Docker, תתבקשו ליצור לעצמכם משתמש. עקבו אחר ההוראות עד להשלמת הרישום בקישור הבא. https://docs.docker.com/ai/sandboxes/

להסבר מפורט יותר של התהליך אני ממליץ לכם לצפות בסרטון הבא:

רכיב השני: פלטפורמת ניהול הידע ב "מוח השני" שלנו - אובסידיאן Obsidian

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

הבחירה ב Obsidian שעד לא מזמן הייתה מוכרת בעיקר לפריקים של ניהול פתקים וידע אישי הייתה די טבעית, השילוב של מערכת לניהול ידע (Knowledge Base) המבוססת על קבצי Markdown במחשב האישי לצד יכולת לנהל קשרים בין הרעיונות ולהציג אותם בצורה ויזואלית הפכה את הפלטפורמה לתשתית אידיאלית עבור סוכני בינה מלאכותית כמו Claude Code או Codex שיכולים לרוץ לקרוא ולפעול על ספריות במחשב האישי.

לשימוש ב Obsidian כמה יתרונות מרכזיים:

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

2 היתרון השני של Obsidian הוא מבנה ידע מבוסס קישורים (Knowledge Graph). במקום לארגן מידע בתיקיות בלבד, Obsidian מאפשרת יצרה של קישורים דו-כיווניים בין פרטי הידע השונים במאגר. כך נבנית רשת של ידע, ולא אוסף של קבצים. זה מאפשר למודלי השפה וסוכני ה AI לנווט ברשת הזו בצורה טבעית, להבין את ההקשרים בין הנושאים ולייצר תשובות מדויקות ועשירות יותר.



3 יתרון שלישי הוא מערכת ההרחבות (Plugins) המובנית של Obsidian. אלפי הרחבות קהילתיות מאפשרות להוסיף יכולות כמו עיבוד מסמכים באמצעות AI, חיפוש סמנטי, אוטומציות, תצוגה ויזואלית של הקשרים ועוד. כל אלו מאפשרים להתאים את Obsidian בצורה אופטימלית לניהול נוח של המוח השני שלנו.

4 לבסוף, Obsidian מתאים במיוחד לעידן ה Agentic AI מכיוון שהוא מפריד בין הידע לבין המנוע (מודל השפה) שמעבד אותו. ה-Vault (מאגר ידע או נתיב ספריות ספציפי ב Obsidian) משמש כזיכרון הקבוע שלנו , בעוד שמודל ה AI שמופעל מעל הידע שלנו ניתן להגדרה בהתאם להעדפות שלנו מבלי לשנות את מבנה הידע עצמו. הגישה הזו מבטיחה גמישות גבוהה, מאפשרת לאמץ מודלים חדשים ככל שהם מתפתחים, ושומרת על הנכס החשוב ביותר שלנו, הידע האישי והארגוני.

5 רגע, שכחתי את החלק הכי חשוב, Obsidian הוא כלי חינמי.

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

הרכיב השלישי: סוכן/מודל בינה מלאכותית שמפעיל את ה"מוח השני" שלנו

אם Obsidian הוא בסיס הידע שלנו אז Claude Code או-Codex הם העובדים שמתחזקים אותו ומספקים לנו מענה מתוך הידע שצברנו כשאנו מפנים אותם (Claude Code או-Codex) לספריה (כספת) שלנו ב Obsidian.

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

למדריך זה בחרתי ב Claude Code בטרמינל. המוח יכול לפעול גם עם אפליקציית Claude ל Windows אבל אי אפשר להפעיל אותו בארגז החול של Docker ונדרשת התקנה מורכבת יותר של ארגז החול של מערכת ההפעלה.

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

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

לאחר ההתקנה ניתן לבדוק ש Claude הותקן כמו שצריך במחשב. פתחו את ה Command Line והריצו את הפקודה הבאה:

claude --version

אם יש לכם כבר משתמש באנתרופיק (Claude) עקבו אחר ההוראות באפליקציה והתחברו לחשבון שלכם, אם אין לכם, צרו משתמש חדש. שימו לב, כדי להפעיל את המוח השני שלנו עם Claude Code נדרש מנוי Pro

מחברים את כל הרכיבים יחד.

אז יש לנו את כל הרכיבים הנדרשים, Docker הוא החדר הסגור בו הסוכן שלנו יעבוד. Obsidian הוא הזיכרון המתמשך של הסוכן, ואילו Claude Code או Codex הם הסוכן שמתחזק, מעשיר ומנצל את הזיכרון הזה. ההפרדה הזו היא אחד העקרונות המרכזיים של ארכיטקטורת ה-"מוח השני" - LLM Wiki שלנו , והיא מאפשרת לבנות מערכת ללא תלות במודל AI מסוים.

עכשיו נתחיל לחבר הכל יחד.

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

הקמת הכספת ובניית מבנה הספריות ב Obsidian:

• 1. פתחו את Obsidian שהתקנתם בשלבים הקודמים וצרו כספת (Vault) חדשה (זו בעצם ספריה בה ישמרו כל קבצי ה Markdown על הכונן במחשב שלכם).

• 2. בחלון הראשון שיפתח לחצו על Create 

• 3. בחלונית הבאה תנו לכספת שלכם שם ליד השדה Vault name

• 4. לחצו על Browse וצרו או בחרו ספריה בה תישמר הכספת. - אם בחרתם להשתמש ב SandBox להפרדת הסוכן מהמחשב שלכם אני ממליץ שתיצרו את הספריה בנתיב מופרד משאר הקבצים שלכם במחשב.

• 5. לסיום לחצו על הכפתור Create . 

אני בחברתי בנתיב הבא (כמובן ש DirveLetter זה שם הכונן במחשב שלכם )

[DirveLetter]:\GenAISandbox\ClaudeCode\SecondBrain

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

בניית מבנה הספריות למוח השני שלנו :

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

מבנה הספריות שאני בחרתי נועד לשרת מספר מטרות:

• 1. ניהול כספת אחת (Vault) של Obsidian לכל הידע שלי.
• 2. הפרדה בין קבצים שהסוכן רואה וקבצים שאין לו גישה אליהם (באמצעות ארגז החול) .
• 3. ניהול מערכי ידע שונים באותה כספת (Vault) של Obsidian.
• 4. הפרדה בין 4 שלבים של ידע ומידע - רעיונות גולמיים (שלי), מידע גולמי ממקורות חיצוניים, מידע סרוק, ומידע מעובד.

זה מבנה הספריות שבנתי כדי לענות על המטרות המרכזיות שלי.

• 1. כספת אחת ב Obsidian בשם Second Brain לכל הנושאים שלי. כך הסוכן יוכל לתת לי מענה על כל הידע (שהוא רואה) בנושאים השונים

• 2. הפרדה בין המידע שהסוכן, במקרה שלנו Claude יכול לראות ולא יכול לראות. יצרתי זאת באמצעות שתי ספריות בתוך אותה כספת Second Brain של Obsidian - ספריית AI Included בה נמצאים כל הקבצים שהסוכן יכול לראות וספריית AI Excluded שהסוכן לא יכול לראות. ההפרדה בוצעה באמצעות הגדרת ה SandBox רק על ספריית ה AI Included. כך Claude לא יכול לראות או לפעול על מידע אחר במערכת ההפעלה או בכספת שלי, במקרה זה, הוא לא יכול לראות או לשנות מידע ב ספריית ה AI Excluded, אבל אני כן יכול לראות את המידע הזה בממשק של Obsidian.

• 3. בתוך ספריית ה AI Included יצרתי 4 ספריות מרכזיות.
  • ספריית Brain Dump - כל המידע הגולמי שאני זורק לקבצים, כדוגמת רעיונות, הערות, קישורים, התחלה של פוסטים ועוד. מבחינתי, זה מידע שלא נלקח או נגזר ממקורות חיצוניים.
  • ספריית Raw Content - כל המידע שנלקח או נגזר ממקורות חיצוניים (בעיקר אינטרנט).
  • ספריית Wiki Knowledge - זו הספריה בה הסוכן מסדר ובונה את גרף הידע. (בספריה זו תגדירו את הנושאים שמעניינים אתכם בתתי ספריות).
  • ספריית Process Knowledge - זו ספריה אליה אני מעביר מידע שכבר קראתי, כתבתי בעצמי או עיבדתי ויצרתי לעצמי תובנות, ואני לא רוצה שהסוכן יבצע בה שינויים, אתם יכולים לסדר את המידע שלכם מתחת לספריה זו בתתי ספריות.

• 4. לצד מבנה הספריות אנו זקוקים לעוד 3 קבצי טקסט ריקים עם סיומת md (קבצי markdown) - אלו קבצי ההפעלה של הסוכן שלנו.
  • קובץ index.md - קובץ קטלוג של כל הדפים ב AI Included שהסוכן יכול לראות. את הקובץ הזה הסוכן יתחזק, וקובץ זה יאפשר לו למצוא במהירות אילו נושאים קיימים, לאן לגשת לצורך שינוי התוכן או לפני מתן תשובה.
  • קובץ log.md - קובץ יומן פעילות כרונולוגי שהסוכן מתחזק ובו כל השינויים שהוא מבצע בכספת ("מוח") שלנו, לדוגמה - מקורות, שינויים, תאריכים ועוד. קובץ זה מסייע לנו לעקוב אחר התפתחות בסיס הידע והפעולות שהסוכן ביצע.
  • קובץ overview.md - קובץ כללי המספק תמונת על של בסיס הידע לסוכן ומפנה לנושאים המרכזיים. (בהמשך נסביר כיצד ניתן לשכלל את הקובץ הזה כדי לנהל מספר מאגרי ידע שונים תחת הספריות השונות ב-"מוח השני" שלנו).
  • קובץ CLAUDE.md - שזהו קובץ ההפעלה של הסוכן שלנו, עליו נרחיב בנפרד.

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

D:/../Second Brain
┌────────────────────── Sand Boxed ──────────────────────
│ ├──AI Included      
│ 	├── CLAUDE.md 
│ 	├── index.md  
│ 	├── log.md    
│ 	├── overview.md 
│ 	│                
│ 	├── Brain Dump   ← מידע כללי ורשומות שלי
│ 	│   ├── Web Links 
│ 	│   └── Notes Dump
│ 	│                  
│ 	├── Raw Content   ← מידע גולמי שנגזר ממקורות מידע חיצוניים
│ 	│   ├── Web Clipping
│ 	│   └── Pdf Files
│ 	│                         
│ 	├── Wiki Knowledge   ← מידע וידע שהסוכן יצר - זה גרף הידע שלנו
│ 	│   ├── Knowledge Topic A
│ 	│   ├── Knowledge Topic B
│ 	│   └── Knowledge Topic C
│	│
│ 	└── Process Knowledge   ← מידע וידע שקראתי או עיבדתי - המשך של גרף הידע שלנו (לא לשינוי) 
│     	├── Knowledge Topic A
│     	├── Knowledge Topic B
│     	└── Knowledge Topic C
└──────────────────────────────────────────────────────
├── AI Excluded
│   └── Private ← מידע שאינו נגיש לסוכן

הגדרת קובץ ההפעלה של הסוכן שלנו - Claude.md

לאחר שיצרנו את מבנה הספריות, נותר לנו ליצור את קובץ ההפעלה לסוכן שלנו.

הקובץ CLAUDE.md הוא קובץ מיוחד הכולל את ההנחיות (instruction file) שהסוכן שלנו-Claude קורא אוטומטית בתחילת כל Session או צ'ט שלנו. זה קובץ שמטען ראשון ל-"זיכרון" המיידי של הסוכן שלנו והוא משמש להגדרת ההקשר הקבוע כמו כללי התנהגות, פעולות נפוצות, הוראות לכתיבת קוד, מבנה הספריות, סטנדרטים והעדפות עבודה כך שהמודל יתנהג בצורה עקבית בלי שנצטרך להסביר לו את הכל בכל שיחה מחדש.

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

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

# CLAUDE.md - Second Brain Vault Guide

This document defines the structural, stylistic, and operational standards for managing and maintaining this Second Brain vault.

---

## 1. Structure

The vault is organized around four top-level directories inside `AI Included`, supported by two global tracking files.

```
AI Included/
├── Brain Dump/             # Personal, self-originated information (notes, ideas, links, etc.). Not derived from external sources.
│
├── Raw Content/            # Raw information taken or derived from external sources (mainly the internet). The intake lane to be processed.
│
├── Wiki Knowledge/         # Processed, synthesized evergreen knowledge base.
│      ├── Knowledge Topic A/   # Example topic folder — actual topic folders are defined by the user
│      ├── Knowledge Topic B/   # and grow over time as new subjects are added. There is no fixed
│      ├── Knowledge Topic C/   # or closed list — these three are illustrative names only.
│      └── Archive/             # Retired/inactive notes, moved out of active use (never deleted).
│
├── Process Knowledge/      # Information the user has already read, written, or processed personally.
│      ├── Knowledge Topic A/   # Example topic folder — same open-ended pattern as Wiki Knowledge/.
│      ├── Knowledge Topic B/
│      └── Knowledge Topic C/
│
├── index.md                # Main directory and core visual entry map
└── log.md                  # Vault transaction log and temporal activity audit
```

> **Note on topic folders**: `Knowledge Topic A/B/C` in the tree above are **placeholder examples**, not fixed category names. The agent must treat the actual subfolder names found under `Wiki Knowledge/` and `Process Knowledge/` at any given time as the real topic list, and should create new topic folders as new subjects emerge — never force content into one of the three example names literally.

### Purpose of Core Tracking Files

- **`index.md`**: The primary entry point and high-level table of contents for the vault. It mirrors the **actual current folder structure** — every real topic folder under `Wiki Knowledge/` (and its pages), not a fixed or example set — so it always reflects what topics genuinely exist.
- **`log.md`**: An immutable, append-only journal tracking structural vault changes over time. Every new page created, major synthesis update, archive move, or refactoring step must be logged chronologically with dates and brief change notes.

#### 1.1 `index.md` Structure

`index.md` must be regenerated/updated to reflect the real topic folders present in the vault at the time of the update — the example below shows the _shape_, not fixed section names:

```markdown
# Vault Index

## Wiki Knowledge
### 
- [[Wiki Knowledge//page-name]] — one-line description
### 
- [[Wiki Knowledge//page-name]] — one-line description
### Archive
- [[Wiki Knowledge/Archive/page-name]] — one-line description, original topic noted

## Process Knowledge (read-only reference)
### 
- [[Process Knowledge//page-name]] — one-line description

## Recently Updated
- YYYY-MM-DD — [[page]] — what changed
```

**Update rule**: the agent must add/update the relevant topic section and the "Recently Updated" list every time it creates, edits, or archives a file in `Wiki Knowledge/`. Topic headers in `index.md` must always match the real folder names currently on disk — if a new topic folder is created, add a matching new section; do not reuse or invent example names.

#### 1.2 `log.md` Entry Format

```markdown
## YYYY-MM-DD HH:MM
- Action: Ingest | Wiki-Update | Archive | Query-Synthesis | Index-Update
- Target: [[path/to/file]]
- Summary: one-line description of what changed and why
```

**Update rule**: append-only, one entry per agent action that touches the vault. Never edit or remove past entries.

---

## 2. Page Conventions

To ensure consistency, searchability, and seamless graph connectivity across the vault, all pages in `Wiki Knowledge/` must follow strict formatting guidelines.

### Metadata (YAML Frontmatter)

Every file under `Wiki Knowledge/` **must** begin with a YAML frontmatter block containing the following exact fields:

```yaml
---
title: "Page Title"
note type: Article | Blog Post | BookMark | Code Snippet | Instructions | Links | NewsLetter | Note | Prompt | Social Post
tags:
  - tag-one
  - tag-two
status: Draft | Active | Processed | Archived
created: YYYY-MM-DD
last-updated: YYYY-MM-DD
source: local | Web
domain: example.com
description: "One-line summary of what this page covers"
related:
  - "[[Wiki Knowledge//related-page]]"
---
```

### Field Reference

| Field          | Type         | Description                                                                                                                                           |
| -------------- | ------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------- |
| `title`        | single value | The page's display title.                                                                                                                             |
| `note type`    | single value | The category of the note: `Article`, `Blog Post`, `BookMark`, `Code Snippet`, `Instructions`, `Links`, `NewsLetter`, `Note`, `Prompt`, `Social Post`. |
| `tags`         | list         | Free-form keywords used for classification and search. Unlike `note type`, a page can carry multiple tags.                                            |
| `status`       | single value | The page's lifecycle state: `Draft`, `Active`, `Processed`, `Archived`.                                                                               |
| `created`      | single value | Creation date, in `YYYY-MM-DD` format.                                                                                                                |
| `last-updated` | single value | Date of the most recent substantive edit, in `YYYY-MM-DD` format. Matters for tracking the freshness of nodes in the knowledge graph.                 |
| `source`       | single value | Where the underlying information originated — `local` (self-originated) or `Web` (pulled from an outside/internet source).                            |
| `domain`       | single value | The internet domain the source content came from (e.g. `example.com`), when `source` is `Web`.                                                        |
| `description`  | single value | A short one-line summary of the page's content, used for quick scanning and search.                                                                   |
| `related`      | list         | Wiki-links to other related pages under `Wiki Knowledge/`. Defines explicit edges in the knowledge graph.                                             |

### Linking & Atomicity

- **Wiki-Links**: Always use double brackets `[[page-name]]` or `[[path/to/page|Display Name]]` for linking between vault pages.
- **Atomicity**: Each page must focus on **one single idea, concept, project, or person**. If a page starts covering multiple distinct topics, split it into separate atomic pages and link them.

---

## 3. Style Guide

- **Prose & Tone**: Write in clear, direct, and concise prose. Avoid fluff, passive phrasing, or filler preamble.
- **Formatting**: Use text blocks with paragraphs; prefer bullet points, numbered steps, and structured tables when applicable.
- **Source Attribution**: Attribute every factual claim, stat, or framework to its originating source using source links or inline tags.
- **Contradictions**: When sources or data points conflict, document the discrepancy explicitly (e.g., _"Contradiction Note: Source A claims X, whereas Source B indicates Y under condition Z"_). Do not obscure or force reconciliation of conflicting data without verified resolution.

---

## 4. Operational Guardrails

### Directory Access Rules

|Directory|Agent may read|Agent may write/modify|
|---|---|---|
|`Brain Dump/`|Yes|Only when explicitly requested by the user|
|`Raw Content/`|Yes|Yes — this is the intake lane to be processed|
|`Wiki Knowledge/`|Yes|Yes — this is where the agent builds/updates the knowledge graph|
|`Process Knowledge/`|Yes|**Never**, under any circumstance|

### Additional Rules

- **No Root Leakage**: Never create text files directly inside the root `Wiki Knowledge/` folder. All notes must sit inside a specific topic subdirectory (an existing one, or a new one created for a new subject).
- **Context Preservation**: Retain file names, raw metrics, dates, and direct quotes during synthesis. When relocating a file from `Raw Content/` into `Wiki Knowledge/`, its body content and filename must be preserved exactly as-is - only YAML frontmatter/metadata may be added or edited.
- **Link Integrity**: Only create links to files that exist or that you are actively generating. Do not leave broken placeholders.
* **No Deletion**: The agent must never permanently delete a file. `Wiki Knowledge/Archive/` is used **only** for files explicitly flagged for deletion/removal from active use — it is not the default destination for processed raw files. Any move into `Archive/` must be logged in `log.md`. This rule applies **only** within `Wiki Knowledge/`.
* **No Content or Filename Changes**: When processing a file from `Raw Content/`, the agent may only add or edit its YAML frontmatter (metadata, headers, links). The file's body content and filename must never be altered.
- **`Process Knowledge/` is fully untouchable**: the agent must never move, archive, rename, edit, or delete anything inside `Process Knowledge/`, under any circumstance — not even into its own archive. It is read-only reference material, full stop.
---

## 5. Note Processing Protocol

When asked to process files from `Raw Content/`, apply this sequential workflow:

1. **Analyze**: Evaluate the content to match it to a target topic folder under `Wiki Knowledge/` (an existing topic, or a new one if the subject doesn't fit any current folder).
2. **Scan**: Search existing markdown files in that topic folder for overlapping content.
3. **Write**:
    - **If match exists**: Append new facts into the current note. Update frontmatter metadata (`last-updated`, `tags`, `related`, etc.).
    - **If no match**: Generate a new file using lowercase, hyphen-separated names (e.g., `neural-networks.md`), with full YAML frontmatter as defined in Section 2.
4. **Update Metadata**: Adjust only the raw file's YAML frontmatter — headers, `related` links (using `[[Wiki Knowledge//note-name]]` syntax), `tags`, `status`, etc. Do not modify the file's body content or filename.
5. **Move**: Move the raw file, unchanged in content and filename, into the correct topic subfolder under `Wiki Knowledge/`. * **Exception**: if the file is explicitly flagged for deletion/removal from active use, move it to `Wiki Knowledge/Archive/` instead (per the No Deletion rule in Section 4).
6. **Log**: Append an entry to `log.md` using the format defined in Section 1.2 — noting whether the file was moved into a topic folder or into `Archive/` — and update `index.md` per Section 1.1 to reflect the new or moved page. make the Log and Index update after each file processing and not at the end of the batch.

## 6 Hebrew CLI Safe Rules
- Translate and answer everything natively in Hebrew.
- **CRITICAL**: Never combine English and Hebrew letters on the exact same text line. 
- Always prepend any Hebrew line with a neutral space character to break the terminal RTL-scramble logic.
- Place all terminal syntax and code blocks on entirely isolated, separate lines.

הגדרת ה Sandbox לספריה הזמינה לסוכן (אופציונאלי):

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

• 1. פתחו את ה Command Line עם הרשאת Administrator.
• 2. והקלידו את הפקודה הבאה. כמובן שם ה sandbox-name הוא השם שלכם לארגז החול והנתיב project-path הוא הנתיב בו יצרתם את הכספת שלכם.

sbx run --name  claude 

לדוגמא

sbx create --name ClaudeSecondBrainSandbox claude D:\SecondBrain\AI Included

עכשיו אנחנו מוכנים לריצה הראשונה של הסוכן שלנו. שימו קבצי Markdown בספריה Raw Content או בתתי הספריות שבה ותריצו את claude.

שימו לב ! - אם לא יצרתם מתחת ל Wiki Knowledge את מבנה הספריות המועדף עליכם לפי נושאים, הסוכן יקים ספריות בצורה אוטומטית לפי התוכן שהוא יקרא מהספריה או תתי הספריות ב Raw Content .

טיפ! - אני בחרתי ליצור לעצמי קובץ הפעלה/סקריפט אוטומטי קצר שמפעיל את הסוכן (במקרה שלי Claude) מתוך הספריה הראשית של ה-"מוח השני" שלי SecondBrain. לקובץ קראתי Run_SeconBrain_Sandbox.bat ואלו הפקודות שבו (כמובן שאתם צריכים להתאים אותו לנתיב ולארז החול שלכם):

cd /d 
sbx run --name  claude -- "Run the Raw Folder Notes Analysis Per Your Instructions"

לדוגמה:

cd /d H:/SecondBrain/AI Included
sbx run --name ClaudeSecondBrainSandbox claude -- "Run the Raw Folder Notes Analysis Per Your Instructions"

הסקריפט מבצע את הפעולות הבאות:

• 1. עובר לתיקייה שבה נמצא ה-"המוח השני שלנו" AI Included בכונן H - (שימו את הכונן שלכם).
• 2. הוא מפעיל את הסוכן בסביבת Sandbox כדי להריץ את Claude בצורה מבודדת.
• 3. ההפעלה מבוצעת ב ClaudeSecondBrain שזה השם שנתתי ל Sandbox שלי.
• 4. לאחר מכן מבוצעת קריאה ל Claude.
• 5. יחד עם הפתיחה של Claude אני מריץ אוטומטית את הפקודה "Run the Raw foldernotes analysis per your instructions" - שמבקשת מ-Claude לבצע את ניתוח הקבצים שבתיקיית Raw לפי ההוראות שכבר הוגדרו לו.

לסיכום

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

זו הבעיה שאנדריי קרפתי (Andrej Karpathy), מחלוצי תחום הבינה המלאכותית, ניסה לפתור עם הרעיון שלו למה שזה לכינוי "מוח שני: או ארכיטקטורת LLM Wiki.

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

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

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

לאחר שימוש של מספר שבועות ב-"מוח השני" שלי אני אכן מגיע למידע שאני מחפש מהר יותר, הסוכן מציך לספק לי תשבות לשאלות על בסיס הידע שצברתי או אספתי ב 30 שנה האחרונות. אבל... וזה אבל גדול. המערכת לא באמת עובדת כרגע כגרף ידע כי אומנם יש קשרים בין הקבצים אבל אין תאור לקשרים, וכאשר המאגר גדול מאד (המון קבצים עלפ ני המון ספריות) קבצי ה Log וה Index כל כך גדולים שזלילת הטוקנים של Claude ו Codex מוגזמת בצורה קיצונית.