Custom Instructions — הקבצים שמשנים הכל

למה הנחיות משנות הכל — הפער בין Copilot גנרי לבין Copilot שמכיר את הפרויקט

נסו לדמיין את התרחיש הבא: מפתח/ת חדש/ה מצטרף/ת לצוות שלכם. ביום הראשון, בלי לקרוא שורה אחת מה-README, בלי לדעת מה ה-coding conventions של הפרויקט, בלי להכיר את מבנה התיקיות ואת הכלים שבשימוש — הוא/היא מתחיל/ה לכתוב קוד. מה תקבלו? קוד שעובד, אולי, אבל בטוח לא קוד שמתאים לפרויקט שלכם. הוא ישתמש בשפה אחרת, בכלים אחרים, בסגנון אחר.

זה בדיוק מה ש-Copilot עושה כשאין לו הנחיות. הוא חכם מאוד, הוא יודע לכתוב קוד איכותי, אבל הוא פשוט לא יודע מה ההעדפות הספציפיות של הפרויקט שלכם. הוא לא יודע שאתם משתמשים ב-camelCase ולא ב-snake_case. הוא לא יודע שצריך לכתוב טסטים ב-Vitest ולא ב-Jest. הוא לא יודע שיש לכם Design System ספציפי עם Tailwind CSS ו-shadcn/ui. הוא לא יודע שאתם עובדים עם Fastify ולא עם Express, או ש-ORM שלכם הוא Prisma ולא TypeORM.

Custom Instructions (הנחיות מותאמות) פותרות את הבעיה הזו מהיסוד. במקום להגיד ל-Copilot בכל פרומפט מחדש "אל תשכח להשתמש ב-TypeScript strict mode" או "תמיד תכתוב error handling" — אתם כותבים את זה פעם אחת בקובץ Markdown, ו-Copilot קורא את זה אוטומטית בכל אינטראקציה. כל שיחת צ'אט, כל סשן של Agent Mode, כל Code Review — ההנחיות שם, בלי שתצטרכו לזכור אותן.

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

כדי להמחיש את ההבדל, הנה ניסוי פשוט: ניקח פרומפט אחד — "Create a new API endpoint for user registration" — ונריץ אותו פעמיים. פעם ראשונה בפרויקט ללא הנחיות, ופעם שנייה באותו פרויקט עם קובץ הנחיות של 15 שורות. ההבדל מדהים:

• בלי הנחיות: Copilot בחר Express (לא Fastify כמו בפרויקט), JavaScript רגיל (לא TypeScript), בלי validation, בלי error handling, ובלי קשר למבנה הקבצים הקיים
• עם הנחיות: Copilot השתמש ב-Fastify, TypeScript strict, Zod validation, try/catch עם AppError, ושם את הקובץ בדיוק בתיקייה הנכונה לפי המבנה שהגדרנו

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

copilot-instructions.md — הקובץ הראשי שכל פרויקט צריך

הקובץ copilot-instructions.md הוא נקודת ההתחלה — הקובץ הראשון שכל מפתח צריך ליצור כשמתחילים לעבוד עם Custom Instructions. הוא יושב בנתיב .github/copilot-instructions.md בשורש הריפוזיטורי, ו-Copilot קורא אותו אוטומטית בכל שיחת צ'אט ובכל סשן של Agent Mode. אין צורך להפעיל שום הגדרה — אם הקובץ קיים במיקום הנכון, Copilot מזהה אותו.

חישבו על הקובץ הזה כעל README פנימי שנכתב במיוחד ל-Copilot. הוא מכיל את הדברים שמתכנת חדש צריך לדעת כדי לכתוב קוד שמתאים לפרויקט:

איפה בדיוק שמים את הקובץ

המיקום המדויק הוא קריטי — טעות של אות אחת בנתיב ו-Copilot לא ימצא את הקובץ:

• נתיב מלא: PROJECT_ROOT/.github/copilot-instructions.md
• תיקייה: .github/ (עם נקודה בהתחלה — תיקייה נסתרת)
• שם הקובץ: בדיוק copilot-instructions.md (עם מקף, לא קו תחתון)

אם התיקייה .github/ כבר קיימת בפרויקט (למשל, בגלל GitHub Actions), פשוט הוסיפו את הקובץ לתוכה. אם לא, צרו אותה:

mkdir -p .github
touch .github/copilot-instructions.md

מבנה קובץ מומלץ

הנה דוגמה לקובץ .github/copilot-instructions.md לפרויקט TypeScript/React:

# Project: TaskFlow — B2B Task Management SaaS

## Tech Stack
- Frontend: React 19 + TypeScript + Vite
- Backend: Fastify + TypeScript + Prisma ORM
- Testing: Vitest for unit, Playwright for E2E
- Styling: Tailwind CSS with custom design tokens

## Coding Conventions
- Use TypeScript strict mode — no `any` types
- Use Zod for all input validation
- Prefer named exports over default exports
- Use arrow functions for components, regular functions for utilities
- Error handling: always use try/catch with AppError class

## File Structure
- Components: src/components/{feature}/{ComponentName}.tsx
- API routes: src/routes/{resource}.routes.ts
- Database: prisma/schema.prisma + src/db/

## Build & Test
- Dev: `pnpm dev`
- Test: `pnpm test` (vitest) or `pnpm test:e2e` (playwright)
- Lint: `pnpm lint` (ESLint + Prettier)
- Build: `pnpm build` (tsup for backend, vite for frontend)

שימו לב לכמה עקרונות בדוגמה:

• קצר וממוקד — כל הנחיה היא משפט אחד ברור. אין פסקאות ארוכות, אין הסברים מיותרים
• ספציפי — לא "use good practices" אלא "use Zod for validation". ככל שההנחיה ספציפית יותר, כך Copilot מיישם אותה טוב יותר
• bullet points — קל לסרוק, קל ל-Copilot לעבד. הנחיות בתבליטים (bullets) מעובדות טוב יותר מטקסט רצוף
• אנגלית טכנית — Copilot עובד טוב יותר עם הנחיות באנגלית. כתבו את ההנחיות באנגלית גם אם הקוד שלכם בפרויקט ישראלי
• הכל ב-repository — הקובץ נמצא ב-Git, כל הצוות מקבל אותו אוטומטית אחרי git pull

מה לא לכתוב בקובץ הנחיות

חשוב באותה מידה לדעת מה לא לשים בקובץ:

• לא secrets או API keys — הקובץ ב-Git, כולם רואים אותו. השתמשו ב-environment variables
• לא הסברים ארוכים — Copilot לא צריך לדעת למה בחרתם ב-Fastify, רק שאתם משתמשים ב-Fastify
• לא כללים שמשתנים תכופות — אם feature flag משתנה כל שבוע, לא שמים אותו בהנחיות
• לא הנחיות לשפת תשובה — "Answer in Hebrew" הוא כלל אישי, לא ברמת פרויקט. שימו אותו בהנחיות האישיות

.instructions.md — הנחיות ממוקדות עם applyTo

הקובץ הראשי copilot-instructions.md חל על כל הפרויקט. אבל מה אם יש לכם כללים שרלוונטיים רק לקבצי טסטים? או רק ל-React components? או רק ל-API routes?

לשם כך קיימים קבצי .instructions.md — קבצים עם סיומת .instructions.md שנמצאים בתיקיית .github/instructions/. הפיצ'ר הזה נוסף ביולי 2025 והוא אחד השיפורים המשמעותיים ביותר במערכת ההנחיות של Copilot. הקבצים האלה משתמשים ב-YAML frontmatter (כותרת מטא-דאטה) — בלוק מטא-דאטה בתחילת הקובץ שאומר ל-Copilot על אילו קבצים ההנחיה חלה.

הרעיון פשוט: במקום קובץ הנחיות אחד גדול שמנסה לכסות את כל הפרויקט, אתם יוצרים קבצים קטנים וממוקדים. קובץ אחד לכללי TypeScript, קובץ אחד לכללי testing, קובץ אחד לכללי React. כל קובץ מופעל רק כשעובדים על קובץ שמתאים ל-pattern שהגדרתם.

המבנה: YAML frontmatter + הנחיות

כל קובץ .instructions.md מתחיל בבלוק YAML בין שני סימני ---, ואחריו ההנחיות עצמן:

---
applyTo: "**/*.ts,**/*.tsx"
---

# TypeScript Conventions

- Use strict mode — no `any` types
- Prefer `interface` over `type` for object shapes
- Use `readonly` for properties that shouldn't change
- Export types from dedicated `.types.ts` files
- Use discriminated unions for state management

השדה applyTo מקבל glob patterns — כללים שמתארים נתיבי קבצים:

שדות נוספים ב-frontmatter

מעבר ל-applyTo, יש שדות נוספים שאפשר להגדיר:

---
name: "React Component Standards"
description: "Conventions for React components in this project"
applyTo: "src/components/**/*.tsx"
excludeAgent: "coding-agent"
---

• name — שם ידידותי להנחיה (אופציונלי, עוזר לזיהוי ב-Agent Logs)
• description — תיאור קצר (אופציונלי)
• applyTo — glob pattern שמגדיר על אילו קבצים ההנחיה חלה
• excludeAgent — מאפשר להחריג סוכן ספציפי: "code-review" או "coding-agent"

השדה excludeAgent חשוב במיוחד: הוא מאפשר ליצור הנחיות שחלות רק על Code Review אבל לא על Agent Mode, או להפך. לדוגמה, הנחיות סטייל קפדניות שרלוונטיות ל-Code Review אבל מיותרות ב-Agent Mode.

דוגמאות מעשיות לקבצי .instructions.md

הנה שלוש דוגמאות מעשיות שתוכלו להעתיק ולהתאים:

---
applyTo: "**/*.test.*,**/*.spec.*"
name: "Testing Standards"
---

# Testing Conventions

- Use `describe` + `it` blocks, not standalone `test()`
- Name pattern: "should [expected behavior] when [condition]"
- Use `beforeEach` for setup, not `beforeAll` (avoid shared state)
- Mock external services with `vi.mock()` — never call real APIs in tests
- Every test file: at least 1 happy path + 1 error path
- Prefer `toEqual` for objects, `toBe` for primitives
- Async tests: always use `await` — never callbacks

---
applyTo: "src/components/**/*.tsx"
name: "React Component Standards"
---

# React Component Conventions

- Functional components only — no class components
- Props: always define interface, export it from same file
- Hooks: extract to custom hooks when logic exceeds 10 lines
- Naming: PascalCase for components, camelCase for hooks (useXxx)
- State: Zustand for global, useState for local
- Avoid inline styles — use Tailwind classes
- Event handlers: prefix with "handle" (handleClick, handleSubmit)

---
applyTo: "src/routes/**/*.ts"
name: "API Route Standards"
---

# API Route Conventions

- Use Zod schemas for request body and query params validation
- Always return typed responses: { data: T } or { error: string }
- HTTP status codes: 200 OK, 201 Created, 400 Bad Request, 404 Not Found, 500 Internal
- Wrap all handlers in try/catch with AppError
- Log all errors with request ID for traceability
- Rate limiting: apply to all public endpoints
- Authentication: verify JWT in middleware, not in route handler

שימו לב: כל קובץ ממוקד בדומיין אחד. קובץ הטסטים מכיל רק כללי testing. קובץ ה-components מכיל רק כללי React. קובץ ה-API routes מכיל רק כללי backend. ככה Copilot מקבל הנחיות רלוונטיות בדיוק לקובץ שהוא עובד עליו — לא עומס של כללים לא רלוונטיים.

הגישה הזו יותר אפקטיבית מקובץ אחד ענק מכמה סיבות:

• פחות רעש — כשעובדים על קובץ test, Copilot לא קורא כללי styling שלא רלוונטיים
• קל לתחזוקה — שינוי בכללי testing לא דורש עריכה בקובץ גדול
• אפשר לחלק אחריות — מפתח frontend אחראי על instructions של components, מפתח backend על API routes
• excludeAgent — אפשר להחריג סוכנים ספציפיים בקובץ אחד בלי להשפיע על שאר ההנחיות

ארגון קבצים: תיקיות משנה

כשיש לכם יותר מ-5-6 קבצי הנחיות, כדאי לארגן אותם בתיקיות משנה בתוך .github/instructions/:

.github/instructions/
├── lang/
│   ├── typescript.instructions.md
│   └── python.instructions.md
├── testing/
│   ├── unit-tests.instructions.md
│   └── e2e-tests.instructions.md
├── frontend/
│   ├── components.instructions.md
│   └── styles.instructions.md
├── backend/
│   ├── api-routes.instructions.md
│   └── database.instructions.md
└── review/
    └── code-review.instructions.md

Copilot סורק את כל התיקיות בתוך .github/instructions/ באופן רקורסיבי — כל קובץ .instructions.md שנמצא בכל רמת עומק ייטען אוטומטית. לכן ארגון בתיקיות הוא רק עניין של סדר עבורכם, לא משנה את ההתנהגות.

איך ההתמזגות עובדת

נקודה קריטית שצריך להבין: כש-Copilot עובד על קובץ מסוים, הוא מצרף את כל ההנחיות הרלוונטיות — לא מחליף. אם אתם עורכים קובץ UserForm.tsx, Copilot יקרא:

1. את copilot-instructions.md (תמיד)
2. את typescript.instructions.md (כי הקובץ מתאים ל-**/*.tsx)
3. את components.instructions.md (כי הקובץ נמצא ב-src/components/)

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

---
applyTo: "**/*.test.*,**/*.spec.*"
---

# Testing Standards

- Use descriptive test names: "should [action] when [condition]"
- Prefer `it()` over `test()` for consistency
- Use `beforeEach` for common setup, avoid `beforeAll`
- Mock external dependencies, never real APIs
- Each test file must have at least one positive and one negative test

AGENTS.md ו-CLAUDE.md — תאימות צולבת עם כלים אחרים

בעולם הפיתוח של 2026, רוב הצוותים לא משתמשים רק בכלי AI אחד. ובשוק הישראלי, המגמה הזו חזקה במיוחד: סקר של נתיב דיגיטל (Q1 2026) הראה ש-63% מצוותי פיתוח בסטארטאפים ישראליים משתמשים ב-2 כלי AI לפחות. יש מפתחים שעובדים עם Copilot ב-VS Code, אחרים עם Claude Code בטרמינל, ואולי מישהו בצוות משתמש ב-Cursor או ב-Windsurf. השאלה היא: איך שומרים על הנחיות אחידות כשכל כלי קורא קובץ אחר?

AGENTS.md — הקובץ האוניברסלי

הקובץ AGENTS.md הוא תקן פתוח שמזוהה על ידי מספר סוכני AI — לא רק Copilot. הוא יושב בשורש הריפוזיטורי ומכיל את ההנחיות שכל סוכן AI צריך לקרוא.

מה ייחודי ב-AGENTS.md:

• צולב-כלים — Copilot, Claude Code, וכלים נוספים מזהים אותו
• תמיכה בתיקיות משנה — אפשר ליצור AGENTS.md ב-subfolder לפרויקטי monorepo
• frontmatter ייחודי — שדות כמו on, permissions, ו-safe-outputs שנותנים שליטה על ההתנהגות

ניתוח של 2,500 ריפוזיטוריז שמשתמשים ב-AGENTS.md (מחקר של GitHub, 2026) חשף כמה תובנות מעניינות:

• הקבצים הטובים ביותר כוללים: פקודות build/test, project conventions, ומבנה תיקיות
• ריפוזיטוריז עם AGENTS.md מראים 37% פחות review comments על code style (כי ה-AI כבר מיישם את הסטנדרטים)
• רוב הקבצים (68%) הם בין 30 ל-100 שורות — לא קצרים מדי ולא ארוכים מדי
• הטעות הנפוצה ביותר: לכתוב AGENTS.md שנראה כמו README — עם הסברים למפתחים אנושיים במקום הנחיות ל-AI

CLAUDE.md — ספציפי ל-Claude

הקובץ CLAUDE.md הוא ספציפי ל-Claude Code ולכלים מבוססי Claude. הוא יכול לשבת בשורש הריפוזיטורי, בתיקיית .claude/, או בתיקיית הבית של המשתמש.

חדש: VS Code Copilot תומך גם הוא ב-CLAUDE.md דרך ההגדרה chat.useClaudeMdFile. זה אומר שאם אתם כבר משתמשים ב-CLAUDE.md עם Claude Code, גם Copilot יקרא אותו כשהוא עובד באותו workspace. זה פותר בעיה שהייתה מטרידה צוותים ישראליים רבים: לנהל שני קבצי הנחיות נפרדים עם אותו תוכן.

אסטרטגיית 80/20 לצוותים מרובי-כלים

הגישה המומלצת לצוותים שמשתמשים במספר כלי AI:

Claude Code גם קורא את AGENTS.md כ-fallback אם אין CLAUDE.md. כלומר, אם יש לכם רק AGENTS.md, גם Claude יעבוד איתו.

# Project: TaskFlow

## About
B2B task management SaaS — TypeScript monorepo with Fastify backend and React frontend.

## Build & Test
- Install: `pnpm install`
- Dev: `pnpm dev` (starts both backend and frontend)
- Test: `pnpm test` (vitest)
- E2E: `pnpm test:e2e` (playwright)
- Lint: `pnpm lint` (eslint + prettier)

## Project Structure
- `packages/api/` — Fastify backend
- `packages/web/` — React frontend
- `packages/shared/` — shared types and utils
- `prisma/` — database schema and migrations

## Conventions
- TypeScript strict, no `any`
- Zod for runtime validation
- Named exports only
- Error handling: try/catch with AppError class
- Tests next to source files (*.test.ts)

## Important Notes
- Never modify `packages/shared/` without updating both api and web
- Database migrations require `pnpm prisma migrate dev`
- All env vars documented in `.env.example`

שימו לב: הקובץ הזה מכיל מידע שכל סוכן AI צריך — לא משנה אם זה Copilot, Claude, Cursor או כלי אחר. זה הבסיס של גישת ה-80/20.

מתי להשתמש בכל קובץ — סיכום

שלוש הרמות — אישי, פרויקט וארגון

אחד המושגים החשובים ביותר שצריך להבין ב-Custom Instructions הוא ירושת הנחיות (instruction inheritance). Copilot מזהה הנחיות משלוש רמות שונות — אישי, פרויקט, וארגון. ההנחיות מכל הרמות מתמזגות יחד (merged) לקונטקסט אחד שנשלח למודל. הן לא דורסות אחת את השנייה — Copilot מנסה לקיים את כולן בו-זמנית. אבל כשיש סתירה, לרמות הגבוהות יש עדיפות:

רמה 1: הנחיות אישיות (Personal) — עדיפות גבוהה ביותר

הנחיות שמוגדרות ברמת המשתמש ב-VS Code. הן חלות על כל פרויקט שאתם עובדים עליו.

איך להגדיר:

1. פתחו VS Code ← Settings (Ctrl+,)
2. חפשו github.copilot.chat.codeGeneration.instructions
3. לחצו "Edit in settings.json" והוסיפו הנחיות

לחלופין, דרך Command Palette: Ctrl+Shift+P ← חפשו Copilot: Open Custom Instructions.

מתי להשתמש: העדפות אישיות שלא משתנות בין פרויקטים. דוגמאות:

• "Always respond in Hebrew" — שפת התגובה שלכם
• "Prefer functional programming style" — סגנון תכנות אישי
• "Add JSDoc comments to all public functions" — רמת תיעוד שאתם דורשים
• "Use descriptive variable names, avoid single-letter names" — העדפת naming

סנכרון בין מכשירים: VS Code Settings Sync מאפשר לסנכרן את ההנחיות האישיות בין מחשבים שונים. פתחו Command Palette, חפשו Settings Sync: Configure, וסמנו "Prompts and Instructions".

רמה 2: הנחיות פרויקט (Repository) — עדיפות בינונית

כל הקבצים שלמדנו עד עכשיו: copilot-instructions.md, קבצי .instructions.md, ו-AGENTS.md. הם נשמרים בריפוזיטורי ומשותפים עם כל הצוות דרך Git.

היתרון הגדול: כל מפתח בצוות מקבל את ההנחיות אוטומטית. אין צורך בהגדרה ידנית — אחרי git clone או git pull, ההנחיות כבר שם.

מתי להשתמש: כללים ספציפיים לפרויקט — tech stack, conventions, file structure, build commands, testing patterns.

רמה 3: הנחיות ארגוניות (Organization) — עדיפות נמוכה ביותר

הנחיות שמוגדרות על ידי admin של הארגון ב-GitHub, וחלות על כל הריפוזיטוריז בארגון.

חדש! נכון להיום (אפריל 2026), הנחיות ארגוניות הפכו ל-GA (Generally Available) עבור Copilot Business ו-Enterprise. עד עכשיו זה היה ב-Preview. זה אומר שהפיצ'ר יציב, מתועד, ומומלץ לשימוש production.

מי יכול להגדיר: רק Organization Owners (בעלי הארגון ב-GitHub). מפתחים רגילים לא יכולים לשנות את ההנחיות הארגוניות — זה by design, כדי לשמור על אחידות.

איך להגדיר:

1. ב-GitHub.com ← Profile ← Organizations
2. בחרו את הארגון ← Settings
3. בתפריט הצד: Copilot ← Custom Instructions
4. תחת "Preferences and instructions" — כתבו את ההנחיות

מתי להשתמש: כללים שרלוונטיים לכל הריפוזיטוריז בארגון — security standards, logging conventions, compliance rules, coding style basics. דוגמאות ספציפיות:

• Never commit secrets or API keys to source code
• All error messages must be descriptive and actionable
• Use structured logging — no console.log in production
• Follow OWASP top 10 security guidelines
• All public APIs must have rate limiting

שימו לב: הנחיות ארגוניות צריכות להיות טכנולוגיה-אגנוסטיות (technology-agnostic) ככל הניתן — הן חלות על ריפוזיטוריז ב-Python, TypeScript, Go, ושפות אחרות. לכן, כללים כמו "use Zod for validation" לא מתאימים כאן — הם ספציפיים לפרויקטי TypeScript ושייכים ברמת הריפו.

היקף: איפה ההנחיות עובדות ואיפה לא

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

שילוב עם Code Review — הנחיות שמשפרות ביקורת קוד

Copilot Code Review הוא אחד הכלים החזקים ביותר שמשתלבים עם מערכת ההנחיות. כשאתם מבקשים מ-Copilot לסקור Pull Request ב-GitHub.com, הוא קורא את ההנחיות שלכם ומשתמש בהן כבסיס לביקורת. במקום ביקורת גנרית שמחפשת בעיות כלליות, אתם מקבלים ביקורת שמותאמת לסטנדרטים של הפרויקט שלכם — ממש כמו Code Review מחבר צוות ותיק שמכיר את כל הכללים.

איך Copilot Code Review קורא הנחיות

כמה נקודות חשובות:

• מגבלת תווים: Code Review קורא רק את 4,000 התווים הראשונים מכל קובץ הנחיות. כל מה שמעבר — לא ייקרא
• Branch: ההנחיות נקראות מה-base branch של ה-PR (בדרך כלל main), לא מה-feature branch. כלומר, אם הוספתם הנחיות חדשות ב-feature branch, הן לא ישפיעו על ה-Code Review של אותו PR
• excludeAgent: אפשר ליצור הנחיות שחלות רק על Code Review על ידי שימוש ב-excludeAgent: "coding-agent"

---
applyTo: "**/*"
excludeAgent: "coding-agent"
name: "Code Review Standards"
---

# Code Review Focus Areas

- Check for hardcoded secrets, API keys, or credentials
- Verify error handling exists for all async operations
- Flag any `console.log` or debug statements in production code
- Ensure new functions have JSDoc comments
- Check that database queries use parameterized inputs (SQL injection prevention)
- Verify tests exist for new public functions

שימו לב: ה-excludeAgent: "coding-agent" מבטיח שההנחיות האלה ייקראו רק על ידי Code Review ולא יפריעו ל-Agent Mode בעבודה הרגילה.

איך לבקש Code Review מ-Copilot

התהליך המעשי:

1. צרו Pull Request ב-GitHub.com (או נווטו ל-PR קיים)
2. בתפריט Reviewers בצד, בחרו Copilot
3. Copilot יסרוק את הקוד לפי ההנחיות מה-base branch
4. בהערות שלו, יש כפתור "Implement suggestion" — לחיצה תיצור PR חדש עם התיקונים

אפשר גם להגדיר automatic code review — Copilot יסקור כל PR חדש אוטומטית, בלי לבקש ידנית. את ההגדרה עושים בקביעות הריפוזיטורי ב-GitHub.

טיפ מעשי: הנחיות code review מותאמות לשוק הישראלי

בפרויקטים ישראליים, שווה להוסיף כללים ספציפיים:

• Verify RTL support for all user-facing text — בדיקת תמיכה בעברית
• Check date handling uses IL locale (dd/MM/yyyy) — פורמט תאריך ישראלי
• Ensure currency displays in ILS (₪) not USD — מטבע נכון
• Validate phone numbers accept IL format (+972 or 05x) — פורמט טלפון ישראלי

תבניות מוכנות — TypeScript, Python, React

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

תבנית 1: פרויקט TypeScript/Node.js

# Project: [שם הפרויקט]

## Tech Stack
- Runtime: Node.js 22 + TypeScript 5.x
- Framework: Fastify with @fastify/type-provider-typebox
- ORM: Prisma with PostgreSQL
- Validation: Zod for input, TypeBox for Fastify schemas
- Testing: Vitest + Supertest

## Conventions
- Use TypeScript strict mode — no `any`, no `as` casts
- Prefer `interface` for object shapes, `type` for unions
- Named exports only — no default exports
- Use barrel files (index.ts) per feature directory
- Error handling: use `AppError` class from `src/errors/`
- Logging: use `logger` from `src/lib/logger.ts`, never `console.log`

## Commands
- Dev: `pnpm dev`
- Test: `pnpm test`
- Lint: `pnpm lint`
- Build: `pnpm build`
- Migrate: `pnpm prisma migrate dev`

תבנית 2: פרויקט Python/FastAPI

# Project: [שם הפרויקט]

## Tech Stack
- Python 3.12+ with type hints everywhere
- Framework: FastAPI with Pydantic v2
- Database: SQLAlchemy 2.0 + Alembic migrations
- Testing: pytest with pytest-asyncio

## Conventions
- Follow PEP 8, enforced by Ruff
- Use Pydantic BaseModel for all request/response schemas
- Async by default — use `async def` for all endpoints
- Type hints on ALL function signatures and return types
- Docstrings: Google style on all public functions
- Never use `print()` — use `structlog` logger

## Commands
- Dev: `uv run uvicorn main:app --reload`
- Test: `uv run pytest`
- Lint: `uv run ruff check .`
- Format: `uv run ruff format .`
- Migrate: `uv run alembic upgrade head`

תבנית 3: פרויקט React/Next.js

# Project: [שם הפרויקט]

## Tech Stack
- Next.js 15 with App Router + TypeScript
- Styling: Tailwind CSS with shadcn/ui components
- State: Zustand for client state, React Query for server state
- Forms: React Hook Form + Zod validation
- Testing: Vitest + Testing Library

## Conventions
- Functional components only — no class components
- Use `"use client"` directive only when needed
- Prefer Server Components — fetch data on the server
- File naming: PascalCase for components, camelCase for utils
- Co-locate tests next to source: `Button.tsx` + `Button.test.tsx`
- Use absolute imports with `@/` prefix

## File Structure
- Pages: app/(routes)/[route]/page.tsx
- Components: src/components/[feature]/[ComponentName].tsx
- Shared UI: src/components/ui/ (shadcn components)
- Hooks: src/hooks/use[HookName].ts
- API: app/api/[resource]/route.ts

את כל התבניות האלה (ועוד למעלה מ-120 נוספות) אפשר למצוא ב-awesome-copilot — ריפוזיטורי רשמי של GitHub עם תבניות הנחיות, agents, ו-skills: github.com/github/awesome-copilot.

איך להתאים תבנית לפרויקט שלכם

העתקה עיוורת של תבנית היא טעות נפוצה. הנה התהליך הנכון:

1. התחילו מתבנית — בחרו את התבנית הקרובה ביותר לפרויקט שלכם
2. מחקו מה שלא רלוונטי — אם אתם לא משתמשים ב-Prisma, מחקו את שורת Prisma. אם אתם לא ב-Fastify, החליפו ל-Express/Nest
3. הוסיפו כללים ספציפיים לפרויקט — naming conventions מיוחדים, patterns שחשובים לכם, כלים ייחודיים
4. בדקו עם פרומפט — שלחו ל-Copilot בקשה טיפוסית ובדקו אם הפלט תואם את הציפיות
5. תקנו ושפרו — אם Copilot עדיין עושה משהו לא רצוי, הוסיפו כלל ספציפי שמתקן את זה

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

• All user-facing text must support RTL (Hebrew)
• Date format: dd/MM/yyyy (Israeli standard)
• Currency: ILS (₪) with VAT 17% calculations where relevant
• Phone validation: support +972 and 05x formats
• ID validation: support Israeli ID (teudat zehut) 9-digit format with check digit

הנחיות שעובדות vs הנחיות שמבלבלות — השוואה מעשית

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

הנחיה שעובדת הפוך — דוגמה לכישלון

הנה סיפור שקורה לא מעט: מפתחת כתבה את ההנחיה הבאה: "Always add comprehensive error handling with detailed logging and user-friendly messages that explain exactly what went wrong and how to fix it".

התוצאה? Copilot הוסיף 30 שורות של error handling לכל פונקציה של 5 שורות. Error messages ארוכים שחשפו implementation details ללקוח. Logging כל כך מפורט שהקונסול הציף אלפי הודעות.

הגרסה המשופרת: "Use try/catch with AppError class. Log error ID + message. Return generic error to client." — 3 כללים ברורים שנותנים בדיוק את התוצאה הרצויה.

5 טיפים של GitHub לכתיבת הנחיות טובות יותר (מתוך הבלוג הרשמי)

1. כתבו הנחיות כמו לחבר צוות חדש — אם הייתם מסבירים את זה בעל-פה, ככה לכתוב
2. הוסיפו את ה"למה" בקצרה — כשההנחיה מסבירה את הסיבה, Copilot מחליט טוב יותר במקרי קצה. למשל: "Use Zod for validation (runtime safety — TypeScript types don't exist at runtime)"
3. הראו preferred pattern ו-avoided pattern — דוגמה של "עשה כך" ו"לא כך" עובדת טוב יותר מתיאור מילולי
4. התחילו קטן והרחיבו — 5 כללים טובים > 30 כללים בינוניים. הוסיפו כללים רק כשרואים בעיה חוזרת
5. בדקו באופן קבוע — הנחיה שהייתה רלוונטית לפני חודש אולי לא רלוונטית היום

שלוש שאלות לבדיקת איכות הנחיה

ניפוי באגים — איך לוודא שההנחיות נטענו ועובדות

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

1. Agent Logs — Discovery Events

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

1. ב-VS Code: פתחו את Output panel (Ctrl+Shift+U)
2. בתפריט הנפתח למעלה, בחרו "GitHub Copilot Chat" או "Agent"
3. חפשו Discovery events — תראו רשימה של כל קבצי ההנחיות שנטענו
4. אם הקובץ שלכם לא מופיע — יש בעיה במיקום או בפורמט

2. Chat Debug View — System Prompt

כלי מתקדם יותר שמראה את ה-system prompt שנשלח למודל:

1. פתחו Command Palette (Ctrl+Shift+P)
2. חפשו "Chat Debug View"
3. בדקו את ה-System prompt section — ההנחיות שלכם צריכות להופיע שם

3. פקודת /troubleshoot

בצ'אט של Copilot, אפשר לשלוח:

• /troubleshoot list all paths you tried to load customizations — מראה את כל הנתיבים שנבדקו
• /troubleshoot how many tokens did you use — מראה כמה tokens ההנחיות צורכות

צ'קליסט troubleshooting

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

1. מיקום — האם הקובץ ב-.github/copilot-instructions.md? (לא ב-root, לא ב-github/ בלי נקודה)
2. שם — האם השם בדיוק copilot-instructions.md? שגיאות נפוצות: copilot_instructions (קו תחתון), instructions.md (חסר copilot), copilot-instruction.md (חסר s)
3. Frontmatter — לקבצי .instructions.md: האם יש שני סימני --- תקינים? חסרון של אחד מהם שובר את הקובץ
4. Glob pattern — האם ה-applyTo תואם את הקובץ שאתם עובדים עליו? בדקו עם כלי online כמו globster.xyz
5. הגדרה מופעלת — האם ב-VS Code Settings ה-setting github.copilot.chat.codeGeneration.useInstructionFiles מופעל? (ברירת המחדל: כן)
6. VS Code מעודכן — הנחיות .instructions.md עם applyTo דורשות VS Code 1.93+ (יולי 2025 ומעלה)
7. Extension מעודכן — ודאו שה-GitHub Copilot extension מעודכן לגרסה האחרונה

טיפ מנצח: הדרך הכי מהירה לבדוק אם הנחיות עובדות — שאלו את Copilot בצ'אט: "What are the project conventions you know about?". אם הוא מצטט מההנחיות שלכם, הכל עובד.

בניית ספריית הנחיות ארגונית — מהפרויקט האישי לצוות שלם

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

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

שלב 1: הנחיות ארגוניות (Org-level)

הגדירו ב-GitHub Organization Settings הנחיות שחלות על כל הריפוזיטוריז. אלה צריכות להיות כללים אוניברסליים:

# [Company Name] — Copilot Organization Instructions

## Security
- Never hardcode secrets, API keys, or credentials in source code
- Use environment variables for all configuration
- Validate all external input before processing
- Log security-relevant events using structured logging

## Code Quality
- All public functions must have documentation
- Error messages must be descriptive and actionable
- No console.log/print in production code — use the project's logger
- All async operations must have error handling

## Compliance
- Include license headers in new files where required
- Follow GDPR guidelines for personal data handling
- All user-facing text must support RTL (Hebrew) layout

שלב 2: תבניות ברמת פרויקט (Template Repo)

צרו template repository ב-GitHub עם קבצי הנחיות מוכנים. כשיוצרים ריפוזיטורי חדש מהתבנית, ההנחיות כבר שם:

• .github/copilot-instructions.md — תבנית בסיסית שצריך למלא
• .github/instructions/security.instructions.md — כללי אבטחה
• .github/instructions/testing.instructions.md — כללי testing
• AGENTS.md — הנחיות צולבות כלים

שלב 3: סנכרון וניהול שוטף

ברגע שיש לכם ספריית הנחיות ארגונית, צריך לנהל אותה:

סנכרון הנחיות אישיות בין מכשירים:

1. Command Palette → Settings Sync: Configure
2. סמנו Prompts and Instructions ברשימת ההגדרות לסנכרון
3. מעכשיו ההנחיות האישיות שלכם זמינות בכל מכשיר

ניהול שוטף של הנחיות ארגוניות:

• גרסון (versioning) — שמרו את תבנית ההנחיות ב-template repo ב-Git, עם changelog
• תקשורת — כשמעדכנים הנחיות ארגוניות, שלחו Slack/Teams notification לצוות
• בקרה — הגדירו CODEOWNERS על תיקיית .github/instructions/ כדי שרק בעלי הרשאה ישנו הנחיות
• מדידה — בדקו אחת לחודש: האם Code Review output השתפר? האם פחות review comments חוזרים?

דוגמה מהשטח: סטארטאפ ישראלי עם 5 ריפוזיטוריז

הנה מבנה אמיתי (שמות שונו) שעובד היטב בסטארטאפ ישראלי עם צוות של 12 מפתחים:

סך הכל: כל מפתח מקבל כ-40-50 כללים מותאמים כשהוא עובד — משולבים מכל הרמות. ותהליך ההטמעה לקח יום עבודה אחד לצוות שלם. התוצאה: ירידה של 40% ב-review comments על code style, ו-onboarding של מפתח חדש שהתקצר מיומיים ליום אחד — כי Copilot כבר "מלמד" אותו את הסטנדרטים דרך הפלט שהוא מייצר.

הלקח המרכזי: תתחילו קטן. לא צריך ליישם את כל 3 הרמות ביום הראשון. התחילו מ-copilot-instructions.md בפרויקט אחד. אחרי שבוע, הוסיפו 2-3 קבצי .instructions.md ממוקדים. אחרי חודש, הגדירו הנחיות ארגוניות. הגישה המדורגת הזו עובדת הרבה יותר טוב מהגישה של "הכל בבת אחת".