איך לבנות פרויקט AI בצורה מקצועית מאפס עם ChatGPT, Claude Code, GitHub, Supabase ו־Vercel

כשאני מתחיל לבנות מערכת AI או מוצר תוכנה חדש, אני לא פותח ישר את VS Code ומבקש מ־Claude להתחיל לכתוב קוד.

אני מעדיף לעבוד בצורה מסודרת: קודם להבין בדיוק מה אני בונה, לבדוק שהרעיון בכלל אפשרי, לבחור את ה־Stack המתאים, להקים סביבת Development ו־Production נפרדות, ורק אז להתחיל בפיתוח.

במדריך הזה אני הולך להראות את תהליך העבודה המלא שאני משתמש בו:

רעיון
↓
אפיון ב-ChatGPT
↓
בחירת Stack
↓
ChatGPT Project
↓
Claude Code
↓
GitHub
↓
Supabase Development + Production
↓
Vercel Preview + Production
↓
בדיקת התשתית
↓
CLAUDE.md
↓
פיתוח
↓
בדיקות
↓
Release ל-Production

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

המדריך הזה מתחיל ממש מאפס. גם אם כרגע אין לכם VS Code, Git, Claude Code או שום כלי פיתוח אחר על המחשב, נעבור על הכול.

מה נבנה במדריך?

כדי לבדוק את כל ה־Workflow בלי להסתבך עם מוצר גדול, אני משתמש בפרויקט הדגמה קטן: Task Manager.

המשתמש יוכל:

• להירשם ולהתחבר
• ליצור משימות
• לסמן משימות כהושלמו
• למחוק משימות
• לראות רק את המשימות שלו

המוצר עצמו פשוט בכוונה. מה שמעניין אותנו כאן הוא התהליך שמסביבו: Authentication, Database, הרשאות, Git, Development, Preview ו־Production.

בפרויקט ההדגמה נשתמש ב־Next.js, TypeScript, Supabase, GitHub ו־Vercel.

אבל חשוב להבין: אני לא מחליט מראש שכל פרויקט צריך להשתמש ב־Stack הזה. בחירת ה־Stack מגיעה רק אחרי שאנחנו מבינים מה באמת צריך לבנות.

איך סביבת העבודה שלנו תיראה?

אני משתמש בשני Branches קבועים:

develop = Development
main = Production

כלומר בזמן העבודה:

develop
↓
Supabase Development
↓
Vercel Preview
↓
בדיקות

וכשמוכנים להוציא גרסה:

develop
↓
Pull Request
↓
main
↓
Supabase Production
↓
Vercel Production

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

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

אם אתם מתחילים ממחשב חדש, זה השלב הראשון.

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

1. Visual Studio Code

VS Code הוא סביבת העבודה שבה אני פותח את הפרויקט, רואה את הקבצים ומשתמש ב־Terminal.

חפשו:

Visual Studio Code download

והורידו מהאתר הרשמי.

2. Node.js

Node.js נדרש ל־Next.js, ל־npm ולהרבה מכלי הפיתוח שבהם נשתמש.

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

חפשו:

Node.js LTS download

3. Git

Git מנהל את היסטוריית הקוד שלנו.

בזכותו אנחנו יכולים לעבוד עם Branches, לראות מה השתנה, לבצע Pull Requests ולחזור אחורה במקרה הצורך.

ב־Windows אפשר לחפש:

Git for Windows

4. GitHub

צריך חשבון GitHub.

GitHub יהיה ה־Source of Truth של הקוד שלנו וישמש עבור:

• Repository
• Branches
• Pull Requests
• היסטוריית גרסאות
• חיבור ל־Vercel

5. Supabase

צריך גם חשבון Supabase.

בפרויקט ההדגמה נשתמש בו עבור:

• PostgreSQL Database
• Authentication
• Row Level Security
• Backend capabilities נוספות במידת הצורך

6. Supabase CLI

אני משתמש גם ב־Supabase CLI כדי לנהל migrations ולעבוד בצורה מסודרת מול בסיס הנתונים.

אחרי ההתקנה נבדוק:

supabase --version

7. Vercel

צריך חשבון Vercel.

Vercel יהיה אחראי על:

• Preview deployments
• Production deployment
• Environment Variables
• GitHub integration
• Domain בהמשך

8. Vercel CLI

אפשר להתקין את Vercel CLI באמצעות:

npm i -g vercel

ולאחר מכן להתחבר:

vercel login

9. Claude Code

Claude Code הוא סוכן הפיתוח שאני נותן לו לעבוד ישירות בתוך ה־Repository.

בגלל שכלי AI מתעדכנים מהר, אני ממליץ להיכנס לעמוד ההתקנה הרשמי של Claude Code ולהשתמש בשיטת ההתקנה העדכנית שמופיעה שם.

אחרי ההתקנה נבדוק:

claude --version

בודקים שהכול מותקן

אני פותח Terminal ומריץ:

node -v
npm -v
git --version
claude --version
supabase --version

כל פקודה אמורה להחזיר גרסה.

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

האם צריך Docker?

לא בשיטה שבה אני עובד במדריך הזה.

Docker רלוונטי אם רוצים להריץ Supabase מקומית על המחשב, למשל באמצעות:

supabase start

אבל כאן אני עובד מול Supabase בענן עם סביבת Development וסביבת Production נפרדות.

לכן Docker לא חובה.

שלב 1: מתכננים את הפרויקט עם ChatGPT

רק אחרי שכל הכלים מותקנים אני מתחיל לחשוב על המוצר עצמו.

אני לא מבקש מ־Claude ישר "לבנות לי אפליקציה".

קודם אני פותח שיחה רגילה ב־ChatGPT ומבקש ממנו לתפקד כ־Product Architect ו־Technical Lead.

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

ה־Prompt שאני שולח ל־ChatGPT בתחילת פרויקט

אני רוצה לבנות מוצר תוכנה אמיתי ו-Production-ready.

אני רוצה שתפעל כ-Product Architect ו-Technical Lead.

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

אל תתחיל לכתוב קוד.

אני רוצה שתעבוד לפי הסדר הבא:

1. להבין את המוצר
2. לבדוק ישימות
3. להגדיר MVP
4. לבחור Stack מתאים
5. לתכנן Architecture
6. לתכנן Database ואינטגרציות
7. להגדיר סביבת Development ו-Production
8. לפרק את הבנייה למשימות
9. להכין Brief ראשון ל-Claude Code

בשלב האפיון תגדיר:

1. מה המוצר עושה
2. מי המשתמש
3. מה הבעיה שהוא פותר
4. מה ה-MVP
5. מה לא נכנס ל-MVP
6. User Flow מלא
7. Functional Requirements
8. Non-Functional Requirements
9. מקורות מידע
10. APIs ואינטגרציות
11. בדיקת ישימות טכנית
12. מגבלות, סיכונים ותלויות חיצוניות
13. Stack מומלץ ולמה
14. Architecture
15. Database Schema
16. Authentication והרשאות
17. Background Jobs / Scheduled Jobs אם נדרשים
18. AI Layer אם נדרש
19. Security
20. Environment Variables נדרשים
21. עלויות ושירותים חיצוניים
22. Edge Cases
23. Testing Strategy
24. Development Phases
25. Definition of Done
26. Blueprint סופי

עקרונות העבודה הטכניים:

- GitHub ישמש כ-source control.
- main יהיה Production.
- develop יהיה Development.
- הפיתוח יתבצע קודם על develop.
- release ל-Production יתבצע דרך Pull Request מ-develop ל-main.
- יש להפריד בין Development Database לבין Production Database.
- אם משתמשים ב-Supabase Free, אפשר להשתמש בשני Projects נפרדים: Dev ו-Production.
- אם משתמשים ב-Supabase Branching, יש לוודא שהתוכנית תומכת בזה.
- כל שינוי Database Schema צריך להתבצע באמצעות migrations שנשמרות ב-Git.
- Secrets לעולם לא ייכנסו ל-Git.
- יש להפריד Environment Variables בין Development ל-Production.
- Preview deployment ישמש לבדיקות לפני Production.
- יש לבצע lint, typecheck, build ובדיקות רלוונטיות לפני release.
- אין לבצע שינויים ישירות ב-Production בזמן פיתוח.

חוקים חשובים:

- אל תמציא APIs, הרשאות או יכולות שלא קיימים.
- אם אינטגרציה קריטית למוצר, צריך לוודא שהיא אפשרית לפני שמסתמכים עליה.
- אם יש מגבלה טכנית, רגולטורית או של ספק חיצוני, תגיד אותה מראש.
- אם יש Plan B טוב יותר, תציע אותו.
- אל תבחר Stack לפני שהבנת את דרישות המוצר.
- תעדיף את הפתרון הפשוט ביותר שעדיין מתאים ל-Production.
- אל תוסיף Features רק כי אפשר.
- אל תכתוב קוד לפני שה-Blueprint מאושר.
- אל תעמיס עליי הרבה משימות במקביל. בכל שלב תן לי פעולה ברורה אחת.

לאחר שה-Blueprint הושלם, תכין גם:

A. Project Instructions שאוכל להדביק ב-ChatGPT Project חדש.

B. Brief ראשון ל-Claude Code באנגלית.

ה-Brief הראשון ל-Claude Code צריך להיות מיועד להקמת תשתית בלבד, לפני פיתוח Features.

הוא צריך להנחות את Claude Code:
- לבדוק את הסביבה הקיימת
- להקים את הפרויקט לפי ה-Stack שנבחר
- להכין Git ו-GitHub
- להכין develop ו-main
- להכין Development ו-Production environments
- להכין Supabase / Database לפי הארכיטקטורה
- להכין migrations
- להכין Environment Variables בצורה בטוחה
- להכין Vercel / deployment infrastructure אם רלוונטי
- לעצור ולבקש ממני פעולה אם נדרשת authentication, הרשאה, בחירת account/team/project או secret שאין לו גישה אליו
- לא לנחש credentials, project IDs או secrets
- לא להתחיל לבנות Features עדיין

כל Prompt או Brief שמיועד ל-Claude Code צריך להיות כתוב באנגלית מקצועית וברורה.

הרעיון שלי:

[כתבו כאן את הרעיון]

בדוגמה שלנו: Task Manager

במקום [כתבו כאן את הרעיון] אני מכניס:

אני רוצה לבנות אפליקציית Task Manager פשוטה שתשמש כפרויקט הדגמה למדריך הקמת פרויקט תוכנה מקצועי.

המשתמש יוכל:
- להירשם ולהתחבר
- ליצור משימות
- לסמן משימות כהושלמו
- למחוק משימות
- לראות רק את המשימות שלו

המטרה היא לבנות MVP קטן אבל Production-ready שיאפשר לנו לבדוק בפועל workflow נכון עם:
ChatGPT
VS Code
Claude Code
GitHub
Supabase
Vercel

אל תוסיף פיצ'רים שלא נדרשים לצורך הדגמת התהליך.

שלב 2: מאשרים את ה־Blueprint ואת ה־Stack

רק עכשיו ChatGPT יכול להמליץ על ה־Stack.

בפרויקט ההדגמה בחרנו:

• Next.js
• TypeScript
• Supabase
• GitHub
• Vercel

אבל אם הייתי בונה Agent שרץ ברקע, Backend ב־Python, אפליקציה לנייד או Extension לדפדפן, יכול להיות שהבחירה הייתה שונה לגמרי.

זה בדיוק למה אני לא מתחיל את הפרויקט מ־"בוא נקים Next.js".

שלב 3: פותחים ChatGPT Project

אחרי שה־Blueprint מוכן ומאושר, אני פותח Project חדש ב־ChatGPT עבור המוצר.

המטרה היא שכל האפיון, ההחלטות, התשובות מ־Claude והמשימות הבאות יישארו באותו Context.

בהוראות של ה־Project אני מדביק את הטקסט הבא.

הוראות להדבקה ב־ChatGPT Project

המטרה של הפרויקט היא ללוות בנייה של מוצר תוכנה אמיתי ו-Production-ready מתחילת האפיון ועד Production.

ChatGPT משמש כ-Product Architect ו-Technical Lead.
Claude Code משמש כסוכן הפיתוח בתוך ה-Repository.

עקרונות עבודה:

- קודם להבין ולתכנן, אחר כך לבצע.
- לעבוד לפי ה-Blueprint שאושר בפרויקט.
- לא להוסיף Features שלא הוגדרו בלי סיבה טובה.
- לא להמציא APIs, הרשאות או יכולות שלא קיימים.
- אם יש ספק לגבי אינטגרציה קריטית, לבדוק אותה לפני שמסתמכים עליה.
- לבחור בפתרון הפשוט ביותר שמתאים ל-Production.
- כל שינוי Database Schema צריך לעבור דרך migrations שנשמרות ב-Git.
- Secrets לעולם לא נכנסים ל-Git.
- Development ו-Production חייבים להיות מופרדים.
- develop משמש לפיתוח.
- main משמש ל-Production.
- Release עובר מ-develop ל-main בצורה מסודרת.
- לפני Production יש לבצע את הבדיקות הרלוונטיות ולבדוק Preview.
- לא לבצע שינויים ישירות ב-Production במהלך פיתוח.

כאשר אני מדביק תשובה מ-Claude Code:

1. נתח מה Claude ביצע בפועל.
2. בדוק אם המשימה הושלמה.
3. זהה טעויות, סיכונים או דברים שחסרים.
4. אל תחזור על כל הפרויקט אם אין צורך.
5. תן לי רק את הפעולה או המשימה הבאה שאני צריך לבצע.
6. אם צריך לשלוח משימה ל-Claude Code, כתוב אותה באנגלית מקצועית וברורה ומוכנה להעתקה.

כל תקשורת איתי יכולה להיות בעברית.

כל Prompt, Brief, debugging request או הוראה שמיועדים ל-Claude Code צריכים להיות באנגלית.

אם פעולה דורשת ממני login, הרשאה, בחירת account/team/project, תשלום או מידע רגיש, תגיד לי בדיוק מה אני צריך לעשות ואל תנחש.

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

אחרי ששמרתי את ההוראות, אני מעביר ל־Project גם את ה־Blueprint שיצרנו בשיחה הראשונה.

מכאן והלאה אני משתמש ב־Project הזה בתור ה־Technical Lead של העבודה.

שלב 4: יוצרים תיקייה חדשה במחשב

אני יוצר תיקייה עבור הפרויקט.

לדוגמה:

AI Project Starter

אחר כך אני פותח את VS Code:

File → Open Folder

ובוחר את התיקייה שיצרתי.

רק אחרי שהיא פתוחה ב־VS Code אני פותח:

Terminal → New Terminal

שלב 5: מפעילים Claude Code

בתוך התיקייה של הפרויקט אני מריץ:

claude

עכשיו אני יכול לתת ל־Claude את ה־Brief הראשון שקיבלתי מ־ChatGPT Project.

המטרה כרגע היא דבר אחד בלבד:

להקים את תשתית העבודה.

עדיין לא בונים את ה־Task Manager.

Brief להקמת התשתית

Set up the project infrastructure only.

We are currently inside the project folder.

Please inspect the current environment and prepare a clean professional development setup based on the approved project blueprint and selected stack.

Do the following:

1. Scaffold the application using the stack defined for this project.
2. Initialize Git if needed.
3. Check GitHub authentication and create/connect the repository.
4. Set up the permanent Git workflow:
   - main = Production
   - develop = Development
5. Set up the database infrastructure required by the approved architecture.
6. If using Supabase:
   - prepare the Supabase project structure;
   - create and manage database changes through migrations stored in Git;
   - keep Development and Production databases isolated.
7. Prepare a safe environment variable structure for Development and Production.
8. Ensure secrets are never committed to Git.
9. Prepare and connect Vercel or the deployment platform defined in the blueprint.
10. Configure Preview and Production deployments appropriately.
11. Run the relevant infrastructure/build checks.
12. Do not implement any application features yet.

Important:

- Inspect the current environment before making assumptions.
- Do not guess credentials, account names, project IDs, repository names, URLs, team scopes or secrets.
- If authentication is required, stop and tell me exactly what I need to do.
- If I need to create or choose a cloud project, organization, repository, team or billing option, stop and ask me.
- If there are multiple valid targets, stop and ask instead of choosing one.
- Do not make destructive changes.
- Do not expose secrets in responses or logs.

When finished or when you need my input, summarize:

- what was created
- what is connected
- what is still missing
- current Git branch/status
- current Development/Production environment status
- the next required action

Do not begin feature development.

מה Claude אמור לעשות עכשיו?

בהתאם ל־Stack שבחרנו, Claude יכול לבצע את רוב העבודה בעצמו.

לדוגמה:

• ליצור את אפליקציית Next.js
• להתקין Dependencies
• לאתחל Git
• ליצור GitHub Repository
• לעשות Commit ראשוני
• ליצור את main וה־develop
• להכין Supabase migrations
• להכין את קבצי ה־env
• לחבר Vercel
• להריץ lint, typecheck ו־build

אבל יש דברים שאני דווקא רוצה שהוא יעצור בשבילם.

איפה Claude צריך לעצור ולבקש ממני פעולה?

לדוגמה אם צריך:

• Login בדפדפן
• הרשאת GitHub
• בחירת Organization
• בחירת Vercel Team
• יצירת Cloud Project
• בחירת תוכנית בתשלום
• Secret שאין לו גישה אליו
• פעולה שעלולה למחוק מידע

אני רוצה שהוא יעצור ויגיד לי בדיוק מה לעשות.

אני לא רוצה שסוכן AI ינחש לאיזה Production Project התכוונתי.

שלב 6: GitHub וה־Branches

בסוף ההקמה אני רוצה שני Branches:

main
develop

`main` הוא Production.

`develop` הוא Development.

אני לא חייב ליצור מראש:

feature/login
feature/tasks
feature/dashboard

אם הפרויקט גדל ואצטרך Feature Branches בעתיד, תמיד אפשר להוסיף.

אבל למבנה שאני עובד איתו עכשיו:

develop → Pull Request → main

מספיק.

שלב 7: מפרידים בין Supabase Development ל־Production

בשלב הזה אני רוצה לוודא שהפיתוח שלי לא נוגע ב־Production Database.

האפשרות האידיאלית תלויה בתוכנית Supabase שלכם.

אם יש לכם Supabase Branching

אפשר לעבוד עם Primary Branch ל־Production ו־Development Branch נפרד.

אם אתם עובדים עם Supabase Free

אפשר לעבוד בצורה פשוטה מאוד עם שני Supabase Projects נפרדים:

my-project
my-project-dev

אחד ל־Production ואחד ל־Development.

זה בדיוק המבנה שבו השתמשתי בפרויקט ההדגמה.

אפשר לעבור ל־Supabase Branching אחר כך?

כן.

כל עוד אנחנו שומרים את כל שינויי ה־Database כ־migrations בתוך Git, אנחנו לא נועלים את עצמנו למבנה הזה.

בהמשך אפשר לעבור מ:

develop → Dev Project
main → Prod Project

ל:

develop → Development Branch
main → Primary Branch

בלי לבנות מחדש את כל האפליקציה.

Migrations הן מקור האמת של בסיס הנתונים

זה כלל חשוב מבחינתי.

אני לא רוצה ליצור Table ידנית ב־Dev ואז לנסות לזכור לעשות בדיוק אותו דבר ב־Production.

כל Schema change צריך להיות Migration שנשמרת ב־Repository.

לדוגמה:

supabase/
└── migrations/
    ├── 20261012133446_init.sql
    ├── 20261013090000_create_tasks.sql
    └── 20261013120000_add_task_status.sql

ככה Dev ו־Prod יכולים לקבל את אותו Schema בצורה נשלטת.

מבחינתי ה־Database Schema לא חי רק בתוך Supabase Dashboard. הוא חי בתוך Git.

שלב 8: Environment Variables

גם ה־Environment Variables צריכים להיות מופרדים.

למשל:

.env.development.local
.env.production.local
.env.example

.env.development.local

מכיל את החיבור ל־Supabase Development.

.env.production.local

מכיל את ערכי Production עבור פעולות מקומיות שבהן באמת נדרש Production build.

.env.example

מכיל רק את שמות המשתנים.

לדוגמה:

NEXT_PUBLIC_SUPABASE_URL=
NEXT_PUBLIC_SUPABASE_PUBLISHABLE_KEY=
SUPABASE_SECRET_KEY=

בלי הערכים עצמם.

Secrets לא נכנסים ל־Git

לעולם לא מעלים ל־GitHub:

• Passwords
• API Secrets
• Database passwords
• Private tokens
• Service keys
• Secrets של ספקים חיצוניים

קבצים שמכילים אותם צריכים להיות ב־`.gitignore`.

שלב 9: מחברים Vercel

אחרי ש־GitHub ו־Supabase מוכנים, אני מחבר את Vercel.

אם עדיין לא התחברתי דרך ה־CLI:

vercel login

לאחר מכן Claude יכול להשלים את החיבור.

המבנה שאנחנו רוצים ב־Vercel

כלומר:

develop
→ Vercel Preview
→ Development Database

main
→ Vercel Production
→ Production Database

אם Vercel לא מצליח לגשת ל־Repository

נתקלתי בזה בזמן ההקמה.

Vercel GitHub App היה מותקן אצלי, אבל היה מורשה לגשת רק ל־Repositories מסוימים.

במקרה כזה נכנסים ב־GitHub ל:

Settings
→ Applications
→ Installed GitHub Apps
→ Vercel
→ Configure

ומוסיפים את ה־Repository החדש ל־Repository access.

אחרי שההרשאה ניתנת, Claude יכול להמשיך את החיבור.

שלב 10: עושים Release ראשון של התשתית

אחרי שכל שינויי התשתית נמצאים ב־develop, אני רוצה להכניס אותם ל־main בצורה מסודרת.

אני לא מתחיל Features לפני שאני יודע שהתשתית עצמה יכולה לעבור את אותו תהליך Release שנשתמש בו בהמשך.

אני יכול לשלוח ל־Claude:

Please open a pull request from develop into main for the infrastructure changes only.

Do not implement any application features.

Before merging:

1. Review the full diff.
2. Confirm there are no secrets, passwords, tokens or unrelated changes.
3. Confirm the infrastructure changes are safe.
4. Verify the relevant checks pass.

Then:

5. Merge the pull request into main.
6. Verify GitHub triggers a Vercel Production deployment.
7. Verify the Production deployment reaches READY.
8. Confirm develop remains the Development branch.
9. Confirm main remains the Production branch.
10. Bring develop back in sync with main after the release if needed.

Do not implement product features.

When finished, summarize the release result and anything still missing.

שלב 11: בדיקת End-to-End אמיתית של התשתית

Deployment שעולה עם HTTP 200 עדיין לא מוכיח שכל התשתית מחוברת נכון.

לדוגמה, יכול להיות ש־Preview עולה אבל משתמש בטעות ב־Production Database.

לכן לפני שאני מכריז שהתשתית מוכנה, אני נותן ל־Claude לבצע בדיקת End-to-End אמיתית.

Prompt לבדיקת התשתית

Before we consider the infrastructure setup complete, perform an end-to-end infrastructure verification.

Do not implement any product features.

Verify that:

1. Local development connects to the Development database/environment.
2. The Vercel Preview deployment from develop connects to the Development database/environment.
3. The Vercel Production deployment from main connects to the Production database/environment.
4. No secrets are exposed in responses, logs, Git or client-side code.
5. Both database environments have the expected migration state.
6. develop still deploys automatically to Preview.
7. main still deploys automatically to Production.
8. Git branches and remote branches are in the expected state.
9. The production and development environments are clearly isolated.

You may create a minimal temporary infrastructure health check if needed.

The health check must expose only safe, non-secret information that is sufficient to confirm the environment/database connection.

Do not expose credentials or sensitive configuration.

After verification, remove any temporary diagnostic code that should not remain in the product.

Do not implement any product features.

When finished:

- report the result of every check;
- explain any issue found;
- clearly state whether the infrastructure is ready for feature development.

רק אחרי שהבדיקה הזאת עוברת אני מבחינתי אומר:

התשתית מוכנה.

שלב 12: רק עכשיו יוצרים CLAUDE.md

אני לא יוצר את `CLAUDE.md` בתחילת התהליך.

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

למה?

כי בשלב הזה Claude כבר יודע בפועל:

• איזה Stack יש בפרויקט
• איך ה־Repository בנוי
• מה ה־branches
• איזה Supabase הוא Dev
• איזה Supabase הוא Production
• מה ה־Project Refs
• איך migrations עובדות
• איך Vercel מחובר
• איך Preview עובד
• איך Production עובד
• איך מתבצע Release

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

Prompt ליצירת CLAUDE.md

The project infrastructure is now complete and verified.

Before we begin feature development, create a CLAUDE.md file at the repository root that documents the actual working rules and infrastructure of this project.

Use only information you have verified from the current repository and connected services.

Include:

- the selected stack
- repository structure
- branch roles
- develop as Development
- main as Production
- the Development and Production environment model
- Development database/project reference
- Production database/project reference
- migration workflow
- environment variable conventions
- Vercel Preview behavior
- Vercel Production behavior
- release workflow from develop to main
- required checks before release
- rules for secrets
- production safety rules
- when you must stop and ask me before continuing

Important rules:

- Do not include secret values, passwords, tokens, private keys or sensitive credentials.
- Non-secret project references and identifiers may be documented.
- Do not guess infrastructure details.
- Inspect the repository and current configuration before writing the file.
- Keep CLAUDE.md concise, practical and specific to this project.
- CLAUDE.md should be maintained and updated if the infrastructure or workflow changes later.

Do not implement any product features yet.

When finished:

- summarize what CLAUDE.md contains;
- confirm that no secrets were added;
- confirm that the repository is ready for feature development.

מה התפקיד של CLAUDE.md?

`CLAUDE.md` הוא בעצם ספר החוקים של Claude בתוך ה־Repository.

הוא מאפשר לי לא לחזור בכל Prompt על דברים כמו:

develop is Development
main is Production
don't commit secrets
use migrations
don't touch Production directly
run tests before release

Claude כבר מכיר את כל זה מהפרויקט עצמו.

אם בהמשך הארכיטקטורה או ה־workflow משתנים, צריך לעדכן גם את `CLAUDE.md`.

בנקודה הזאת התשתית באמת מוכנה

עכשיו יש לנו:

• VS Code
• Node.js
• Git
• Claude Code
• GitHub Repository
• develop
• main
• Development Database
• Production Database
• Migrations
• Development Environment Variables
• Production Environment Variables
• Vercel Preview
• Vercel Production
• GitHub → Vercel integration
• Pull Request workflow
• End-to-End infrastructure verification
• CLAUDE.md שמתעד את צורת העבודה האמיתית

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

שלב 13: מתחילים את הפיצ'ר הראשון

אני חוזר ל־ChatGPT Project.

לפי ה־Blueprint, ChatGPT נותן לי את המשימה הבאה.

כל Brief שמיועד ל־Claude אני מעדיף לקבל באנגלית.

אם צריך, אפשר להזכיר בתחילת המשימה:

The project infrastructure is complete and verified.

Follow the repository's CLAUDE.md.

Work on develop only.

Do not make direct changes to main or Production.

All database schema changes must be created through migrations stored in Git.

Test and verify the implementation before considering the task complete.

ואחריו מגיע ה־Feature עצמו.

איך אני עובד עם ChatGPT ו־Claude Code ביחד?

אני נותן לכל אחד תפקיד אחר.

ChatGPT

• אפיון
• Product Thinking
• Architecture
• בדיקת ישימות
• פירוק העבודה למשימות
• בדיקת התשובות של Claude
• זיהוי בעיות
• בחירת המשימה הבאה

Claude Code

• קורא את ה־Repository
• כותב ומשנה קוד
• יוצר migrations
• מריץ בדיקות
• עובד עם Git
• עובד עם CLI tools
• בודק את התוצאה
• מסכם מה בוצע

הלולאה שלי

ChatGPT מגדיר את המשימה

↓

אני שולח את ה-Brief ל-Claude

↓

Claude מבצע ובודק

↓

Claude מסכם

↓

אני מעביר את הסיכום ל-ChatGPT

↓

ChatGPT בודק את העבודה

↓

מקבלים את המשימה הבאה

שגרת העבודה בזמן פיתוח

אחרי שהתשתית קיימת, התהליך הופך להרבה יותר פשוט:

develop
↓
Claude מבצע משימה
↓
lint / typecheck / tests / build
↓
Database migration אם נדרש
↓
Push
↓
Vercel Preview
↓
בדיקה אמיתית
↓
תיקונים
↓
Pull Request
↓
main
↓
Production migration אם נדרש
↓
Vercel Production
↓
Smoke Test

Database migrations בזמן Release

חשוב להבין ש־Vercel Deploy לא בהכרח מעדכן עבורנו את Production Database.

אם Release כולל שינוי Database, צריך לוודא שגם המיגרציה מוחלת על Production בצורה נשלטת.

העיקרון:

Migration
↓
Development Database
↓
בדיקה
↓
Commit ל-Git
↓
Release ל-main
↓
Production Database
↓
Production deployment / verification

אני לא רוצה לבצע שינוי ב־Production Database רק כי קובץ SQL קיים ב־Repository.

Production משתנה כחלק מ־Release מודע ומסודר.

בדיקות שאני רוצה לפני Release

זה משתנה בין פרויקט לפרויקט, אבל בפרויקט Web טיפוסי אני רוצה לפחות:

• Lint
• Typecheck
• Tests רלוונטיים
• Production build
• Migration status
• Authentication check
• Preview deployment
• בדיקת ה־User Flow הרלוונטי

אחרי שהגרסה עולה ל־Production אני עושה גם Smoke Test קצר.

האם צריך GitHub Branch Protection?

Branch Protection מאפשר לכפות כללים על `main`.

לדוגמה:

• אי אפשר לעשות Push ישיר
• חייבים Pull Request
• Checks חייבים לעבור
• אפשר לדרוש Approval

זה מעולה, במיוחד כשיש צוות.

אבל זה לא תנאי להתחלת העבודה.

גם בלי Branch Protection אפשר לעבוד בצורה נכונה:

develop
↓
Pull Request
↓
main

פשוט צריך לשמור על הכלל ולא לפתח ישירות על `main`.

מה זה npm audit?

בפרויקטי Node.js יכול להיות שתראו הודעות על vulnerabilities.

`npm audit` בודק Dependencies ומזהה חולשות אבטחה ידועות.

זה לא אומר אוטומטית שהאפליקציה שלכם נפרצה או אפילו שהחולשה רלוונטית אליכם.

צריך לבדוק:

• איזו חבילה מושפעת
• איפה היא משמשת
• האם יש Patch בטוח
• האם עדכון ישבור Dependencies אחרים

אני לא מריץ אוטומטית:

npm audit fix --force

בלי להבין מה הוא עומד לשנות.

טעויות שאני מנסה למנוע

להתחיל לכתוב קוד לפני שהמוצר ברור

AI יכול לכתוב מהר מאוד הרבה קוד שלא הייתם צריכים.

להחליט מראש על Stack בלי להבין את הדרישות

Next.js הוא לא הפתרון לכל דבר.

לתת ל־Claude לנחש לאיזה חשבון או Project התכוונתי

אם יש ספק, הוא צריך לעצור ולשאול.

לחבר Development ל־Production Database

בדיוק בשביל זה אנחנו מפרידים סביבות.

לשנות Schema ידנית בלי Migration

אחרי כמה חודשים אין דרך טובה לדעת מה באמת השתנה.

להכניס Secrets ל־GitHub

Keys ו־Passwords לא שייכים ל־Repository.

לבדוק רק שה־Deployment עולה

HTTP 200 לא מוכיח שה־Database הנכון מחובר.

לכן הוספנו בדיקת End-to-End אמיתית.

ליצור CLAUDE.md מוקדם מדי

אני מעדיף ליצור אותו אחרי שהתשתית מוכנה, כדי שהוא יתאר את המערכת האמיתית ולא תוכנית תיאורטית.

לבנות Infrastructure מסובך מדי

לא כל פרויקט צריך עשר סביבות, Kubernetes ועשרים Microservices.

אני רוצה את הפתרון הפשוט ביותר שעדיין בטוח ומתאים ל־Production.

מתי הייתי משתמש ב־Stack אחר?

המדריך הזה מלמד Workflow ולא Stack קבוע.

אם הייתי בונה Agent שרץ כולו ברקע, יכול להיות שהייתי משתמש ב־Python.

אם מדובר ב־Automation בלי ממשק, יכול להיות שאין צורך בכלל ב־Next.js.

אם מדובר באפליקציית מובייל, הארכיטקטורה תהיה אחרת.

לכן הסדר תמיד נשאר:

דרישות
↓
ארכיטקטורה
↓
Stack

ולא להפך.

ה־Workflow המלא שלי

רעיון
↓
Prompt ראשון ב-ChatGPT
↓
בדיקת ישימות
↓
Blueprint
↓
בחירת Stack
↓
ChatGPT Project
↓
Project Instructions
↓
תיקייה חדשה במחשב
↓
VS Code
↓
Claude Code
↓
הקמת תשתית
↓
GitHub
↓
main + develop
↓
Database Dev + Prod
↓
Migrations
↓
Environment Variables
↓
Vercel Preview + Production
↓
Release ראשון של התשתית
↓
End-to-End Verification
↓
CLAUDE.md
↓
Feature Development
↓
Preview
↓
Testing
↓
Pull Request
↓
Production
↓
Smoke Test

למה בכלל להשקיע בכל זה?

היום אפשר לכתוב ל־AI:

Build me an app

ולקבל משהו שנראה עובד תוך זמן קצר.

אבל כשאני בונה מוצר אמיתי, אני רוצה לדעת הרבה יותר מזה.

אני רוצה לדעת:

• איפה הקוד נמצא
• איזה קוד נמצא ב־Production
• איפה אני מפתח
• איזה Database שייך לכל סביבה
• איך Schema changes מגיעים ל־Production
• מה Claude רשאי לעשות
• מה הוא לא רשאי לעשות
• איך בודקים שינוי לפני שהוא מגיע למשתמשים
• איך ממשיכים לפתח את המוצר בעוד חצי שנה

AI יכול להאיץ את הפיתוח בצורה קיצונית.

אבל בלי תהליך עבודה נכון הוא גם יכול להאיץ טעויות.

המטרה שלי היא לשלב:

מהירות של AI עם תשתית של מוצר תוכנה אמיתי.

מה השלב הבא?

עכשיו, כשהתשתית מוכנה, אנחנו יכולים להתחיל לבנות את המוצר עצמו.

ב־Task Manager שלנו השלבים הבאים יהיו לדוגמה:

• Authentication
• Tasks table
• Row Level Security
• יצירת משימות
• סימון משימה כהושלמה
• מחיקת משימות
• בדיקות
• Preview
• Release ל־Production

אבל בשלב הזה החלק הקשה של "איך בכלל עובדים נכון על הפרויקט" כבר מאחורינו.

התשתית קיימת.

עכשיו פשוט בונים.

רוצים לבנות מערכת AI או מוצר תוכנה לעסק שלכם?

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

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