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

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

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

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

לפני שמתחילים: מה בונים ומה צריך להכין

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

הורידו את ערכת ההתחלה ואת כל הקבצים שבמדריך. חלצו את ה-ZIP לתיקייה חדשה ופתחו ב-Claude Code את התיקייה שמכילה את package.json. אפשר לשנות את הדוגמא בהמשך, אבל כדאי לעבור פעם אחת על המסלול כפי שהוא.

נדרשים Claude Code, ‏Node.js בגרסה 20 ומעלה ו-Python 3. הפקודות node, npm ו-python3 צריכות לעבוד בטרמינל שבו Claude רץ. בדוגמא אין חבילות חיצוניות ואין צורך להריץ npm install. קטעי הטרמינל וה-Hook כתובים ל-macOS או Linux. ב-Windows עבדו דרך WSL, או בקשו מקלוד להתאים את פקודת Python לסביבה שלכם.

פתחו טרמינל בשורש התיקייה והריצו:

npm start

השאירו את הטרמינל פועל ופתחו http://localhost:4173 בדפדפן. תראו שלוש משימות. הכפתורים קיימים, אבל הסינון עדיין חסר. אם הפורט תפוס, עצרו את השרת הקודם או בקשו מקלוד לבחור פורט ולעדכן את הכתובות בהתאם.

1. מגדירים מה נחשב הצלחה, לפני שמתקנים קוד

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

שלב 1: קוראים את הדרישות ואת נתוני הפתיחה

פתחו את specs/task-filter/requirements.md. במסמך תמצאו את שלושת המסננים, את מצב ברירת המחדל, את הודעת המצב הריק ואת הדרישה שלא לשנות משימות בזמן סינון. תחילה בדקו שההתנהגות הזאת אכן מתאימה לכם.

אלה נתוני הפתיחה שבהם נשתמש לאורך הבדיקות:

שלב 2: הופכים את הדרישות לבדיקות קבלה

פתחו את specs/task-filter/evals.md. השם Evals מתייחס כאן לבדיקות מוגדרות מראש. כל שורה אומרת מה לעשות, מה צריך לקרות ואיך לבדוק. אלה בדיקות ממוקדות לפיצ'ר הזה:

שימו לב להבדל בין התנהגות לפקודת בדיקה. npm test מריץ חמש בדיקות של פונקציית הסינון. הוא לא מוכיח שהכפתורים מחוברים נכון או שהמסך נוח במובייל. בשביל אלה צריך לפתוח את הממשק ולבדוק אותו.

שלב 3: שומרים את דרך ההכנה כ-Skill

בערכה כבר קיים .claude/skills/write-evals/SKILL.md. Skill הוא אוסף הוראות שאפשר להפעיל שוב. כך לא צריך לזכור בכל פיצ'ר לבקש גם מצב ריק, גם תוצאות צפויות וגם אישור לפני מימוש.

תוכן הקובץ .claude/skills/write-evals/SKILL.md:

---
name: write-evals
description: Prepare reviewable requirements and acceptance checks before implementing a feature.
disable-model-invocation: true
---

עבוד על הפיצ'ר $ARGUMENTS.
1. קרא את הבקשה ואת הפרויקט. שאל רק על מידע שחסר לצורך החלטה.
2. צור specs/<feature>/requirements.md ו-evals.md. תן מזהה לכל בדיקה.
3. לכל בדיקה כתוב נתוני פתיחה, פעולה, תוצאה צפויה ודרך בדיקה.
4. בדוק מסלול תקין, מצב ריק ומעברים בין מצבים.
5. אם יש ממשק, צור mockup.html עם המצבים ועם רוחב מובייל.
6. סמן את המסמכים in-review. הצג החלטות שקיבלת בעצמך.
7. עצור לבדיקת המשתמש. אל תממש ואל תאשר את המסמכים בעצמך.

בשיחה של Claude Code, מתוך התיקייה שפתחתם, הפעילו:

/write-evals task-filter

Claude צריך לקרוא את הקבצים הקיימים, להציג את הדרישות והבדיקות לבדיקה שלכם ולהכין או לעדכן את mockup.html. בערכה כבר יש תצוגת עיצוב שאפשר לפתוח מתוך specs/task-filter/mockup.html. זו תצוגה נפרדת מהאפליקציה, כדי שתוכלו לאשר את הכיוון לפני התיקון.

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

שלב 4: בודקים את מה שקל לפספס, ואז מאשרים

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

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

אני מאשר את הדרישות, את בדיקות E1-E6 ואת תצוגת העיצוב של task-filter.
סמן את מסמכי הדרישות והבדיקות כ-approved.
אל תשנה אותם בזמן המימוש בלי לבקש ממני אישור.
עדיין אל תתחיל במימוש.

I approve the task-filter requirements, acceptance checks E1-E6, and the design preview.
Mark the requirements and acceptance-check documents as approved.
Do not change them during implementation without my approval.
Do not start implementation yet.

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

2. מפרידים בין הבונה, המאמת והסוקר

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

שלב 1: נותנים לסוקר כללים קצרים

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

תוכן הקובץ REVIEW.md:

# Review rules
- קרא את specs/task-filter/requirements.md ואת evals.md.
- חפש באגים שמשנים התנהגות. אל תדווח על העדפות סגנון.
- בדוק מצב ריק, סימון המסנן הפעיל ושמירת המשימות.
- לכל ממצא: מזהה קבוע, חומרה, קובץ ושורה, דרך שחזור והשפעה על המשתמש.
- אם ממצא כבר דווח, עדכן את מצבו במקום להמציא מזהה חדש.
- אחרי הסבב הראשון בדוק בעיקר את השינוי האחרון ואת השפעותיו.
- אם אין ממצאים כתוב במפורש: לא נמצאו ממצאים חדשים.
- אל תשנה קוד או את בדיקות הקבלה.

ב-CLAUDE.md מופיעה השורה הבאה, שטוענת את כללי הביקורת כחלק מהוראות הפרויקט:

@REVIEW.md

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

שלב 2: בודקים את הגדרות הסוכנים

בערכה יש שלושה קבצים בתיקיית .claude/agents. כל קובץ מגדיר תפקיד אחר. לדוגמא, זה תוכן ההגדרה של המאמת:

תוכן הקובץ .claude/agents/feature-verifier.md:

---
name: feature-verifier
description: Verify the approved acceptance checks and return evidence.
---

אל תממש ואל תשנה קוד או בדיקות. קרא את הדרישות וה-evals. הרץ npm test. בדוק את E1-E6 בדפדפן אם כלי כזה זמין לך. לכל בדיקה החזר PASS, FAIL או NOT_RUN וראיה. העבר את הדוח למנהל הלולאה. אם חסר כלי, דווח עליו. אל תטען שבדיקה עברה בלי שהרצת אותה.

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

שלב 3: מחברים את התפקידים ללולאה מוגבלת

פתחו את .claude/skills/review-loop/SKILL.md. זה הקובץ שמנהל את התהליך. הוא מפעיל את הסוכנים בנפרד, מעביר ממצאים לסבב הבא ושומר התקדמות ב-state.md. הוא גם מגדיר שני סוגי סיום: הצלחה או חסימה שדורשת החלטה שלכם.

תוכן הקובץ .claude/skills/review-loop/SKILL.md:

---
name: review-loop
description: Implement one approved feature with independent verification and review.
disable-model-invocation: true
---

הפיצ'ר: $ARGUMENTS. אתה מנהל הלולאה.
1. ודא שהמשתמש אישר בשיחה את הדרישות, בדיקות הקבלה והעיצוב.
2. קרא את CLAUDE.md ואת REVIEW.md. צור specs/<feature>/state.md. בדוגמא task-filter צור גם specs/task-filter/run-active להפעלת ה-Hook.
3. בכל סבב הפעל בנפרד ובהקשר חדש את feature-builder, feature-verifier, feature-reviewer.
4. העבר לבונה את הדרישות המאושרות והממצאים הפתוחים. אסור לו לשנות בדיקות מאושרות.
5. המאמת מריץ את הבדיקות, בודק בדפדפן ומחזיר PASS/FAIL/NOT_RUN עם ראיות לכל מזהה.
6. הסוקר בודק את השינוי מול הדרישות ו-REVIEW.md, כולל בעיות שלא נכללו בבדיקות.
7. שמור ב-state.md את הסבב, תוצאות הבדיקות, מזהי הממצאים, שינויים והצעד הבא.
8. אם הכל PASS ואין ממצא פתוח, מחק את run-active, הצג ראיות ועצור בהצלחה.
9. לכל היותר 3 סבבים. אם אותו ממצא נשאר אחרי שני ניסיונות תיקון, או אם חסר כלי או אישור, מחק את run-active, עצור כ-blocked והסבר מה נדרש.
10. בסבבים נוספים סקור את התיקון והשפעותיו, בלי לשכפל ממצאים שכבר דווחו.
11. אל תשנה דרישות, אל תעקוף בדיקות ואל תשחרר לפרודקשן.

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

שלב 4: יודעים איפה למצוא כל דבר

זו מפת הקבצים שעליהם נשען התהליך. הדרישות והבדיקות נשמרות ליד הפיצ'ר. כללי העבודה נשמרים בשורש. ה-Skills, הסוכנים וה-Hook נשמרים תחת .claude. אלה הנתיבים בפועל בערכה המצורפת.

3. מוסיפים Hook שמריץ בדיקות לפני עצירה

עד עכשיו הגדרנו הוראות עבודה. עכשיו נוסיף פעולה שמתרחשת בזמן קבוע. Hook הוא קוד ש-Claude Code מפעיל באירוע מוגדר. נשתמש באירוע Stop, שמתרחש כשהסוכן הראשי עומד לסיים את התשובה, ונריץ בו את npm test.

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

שלב 1: קוראים את קוד הבדיקה

פתחו את .claude/hooks/check-before-stop.py. הקוד כבר נמצא בערכה:

תוכן הקובץ .claude/hooks/check-before-stop.py:

import json
import os
from pathlib import Path
import subprocess
import sys

payload = json.load(sys.stdin)
root = Path(os.environ.get("CLAUDE_PROJECT_DIR") or payload["cwd"])
if not (root / "specs/task-filter/run-active").exists():
    sys.exit(0)
# A failed check can request one continuation, not an endless loop.
if payload.get("stop_hook_active"):
    sys.exit(0)

try:
    result = subprocess.run(
        ["npm", "test"], cwd=root, capture_output=True,
        text=True, timeout=120
    )
    failed = result.returncode != 0
    evidence = result.stdout + result.stderr
except (OSError, subprocess.TimeoutExpired) as error:
    failed, evidence = True, str(error)

if failed:
    print(json.dumps({
        "decision": "block",
        "reason": "npm test failed. Fix and rerun. If still failing, report blocked, not done.\n" + evidence[-4000:]
    }))

ההגנה האחרונה חשובה: ה-Hook הוא מנגנון עזר עם גבול ברור. אם הבדיקה עדיין נכשלת אחרי ניסיון ההמשך, הדיווח צריך להיות blocked עם הסיבה. עצם סיום התשובה אינו הוכחה להצלחה. תנאי ההצלחה נשארים ב-Skill ובבדיקות הקבלה.

שלב 2: מחברים את הקוד לאירוע Stop

פתחו את .claude/settings.json. כך נראית ההגדרה בערכה:

תוכן הקובץ .claude/settings.json:

{
  "hooks": {
    "Stop": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "python3 \"${CLAUDE_PROJECT_DIR}/.claude/hooks/check-before-stop.py\"",
            "timeout": 150
          }
        ]
      }
    ]
  }
}

אם אתם עובדים בפרויקט קיים, שלבו את ההגדרה בקובץ הקיים ואל תחליפו אותו בשלמותו. סגרו ופתחו שיחה חדשה אחרי שינוי ההגדרות, והשתמשו ב-/hooks כדי לבדוק שה-Stop hook מופיע. הסקריפט צריך להיות מופעל ב-Python הזמין באותה סביבה.

שלב 3: מוודאים שה-Hook באמת מזהה כישלון

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

touch specs/task-filter/run-active
printf '{"cwd":".","stop_hook_active":false}\n' | python3 .claude/hooks/check-before-stop.py
rm specs/task-filter/run-active

בגרסת ההתחלה תקבלו אובייקט JSON עם "decision": "block" וסיבה שמכילה את פלט הבדיקות שנכשלו. אם מתקבלת שגיאה כגון npm not found או python3: command not found, תקנו את סביבת ההרצה לפני שממשיכים. אם הפלט ריק בגרסת ההתחלה, ודאו שיצרתם את הסמן ושאתם בשורש התיקייה.

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

4. מפעילים את התהליך וקוראים את הראיות

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

שלב 1: רואים את הכישלון לפני התיקון

בטרמינל נוסף, מאותה תיקיית פרויקט, הריצו:

npm test

בגרסת ההתחלה E1 ו-E5 עוברות, ו-E2, E3 ו-E4 נכשלות. זה הגיוני: filterTasks מחזירה את כל המשימות לכל מסנן. אם כבר שיניתם את הקוד, התוצאות ייקבעו לפי ההתנהגות הנוכחית שלו. אלה שמות הבדיקות שתראו בפלט:

E1: all shows every task                 PASS
E2: open hides completed tasks          FAIL
E3: done hides open tasks                FAIL
E4: an empty result stays empty         FAIL
E5: filtering leaves the source intact  PASS

הבדיקות משתמשות ב-node:test וב-node:assert/strict שמגיעים עם Node.js. לדוגמא, זו הבדיקה למסנן פתוחות:

test('E2: open hides completed tasks', () => {
  assert.deepEqual(
    filterTasks(tasks, 'open').map(task => task.id),
    [1, 3]
  );
});

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

שלב 2: מפעילים את לולאת הבנייה והביקורת

ודאו שאישרתם בשיחה את הדרישות, הבדיקות והעיצוב. אם פתחו שיחה חדשה, ציינו בה שוב את האישור ואת הנתיבים שאישרתם. ואז הפעילו ב-Claude Code:

/review-loop task-filter

ה-Skill צריך ליצור את run-active, לפתוח סבב עבודה ולתעד אותו ב-specs/task-filter/state.md. מנהל הלולאה שולח את הבונה להשלים את הפיצ'ר, מבקש מהמאמת להריץ בדיקות ומעביר את השינוי לסוקר בהקשר חדש. אם חסרים כלי דפדפן, הוא צריך לדווח על כך ולבקש שתשלימו את הבדיקות האלה.

כדי לחדד מה אתם רוצים לראות בדוח, אפשר להוסיף אחרי הפקודה:

# התוצאה שאני צריך לראות
השלם את task-filter לפי המסמכים שאישרתי.

# הראיות
- הפקודה שהרצת ופלט npm test האחרון.
- תוצאה וראיה לכל בדיקה E1-E6.
- צילום מסך של המסנן פתוחות ושל המסך ברוחב 390px, אם כלי הדפדפן זמין.
- רשימת הממצאים שנפתרו והממצאים שעדיין פתוחים.

# תנאי סיום
אל תשנה את הדרישות או את בדיקות הקבלה.
אם בדיקה לא הורצה, סמן NOT_RUN.
אם חסר כלי או שאין התקדמות, עצור כ-blocked והסבר מה צריך ממני.

# Required outcome
Complete task-filter according to the documents I approved.

# Evidence
- The command you ran and the latest npm test output.
- A result and evidence for every acceptance check E1-E6.
- A screenshot of the Open filter and the screen at 390px width, if browser tools are available.
- Findings resolved and findings still open.

# Completion
Do not change the requirements or acceptance checks.
Mark checks that were not executed as NOT_RUN.
If a tool is missing or progress stalls, stop as blocked and explain what you need from me.

שלב 3: פותחים את דוח ההתקדמות

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

# task-filter
Round: 1
Status: running

## בדיקות
- npm test: 5/5 PASS. הפקודה והפלט מצורפים.
- E1-E5 בדפדפן: תוצאה ופעולות לכל בדיקה.
- E6 ברוחב 390px: PASS / FAIL / NOT_RUN, עם הסבר וראיה.

## ממצאים
- R1: תיאור הממצא, מיקום בקוד, מצב התיקון ודרך האימות.
- אם אין: לא נמצאו ממצאים חדשים.

## הצעד הבא
סבב תיקון ממוקד, השלמת בדיקה חסרה או הצגת ראיות לאישור.

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

שלב 4: מוודאים שהתיקון עובד גם בממשק

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

תוכן הקובץ src/filter-tasks.mjs:

export function filterTasks(tasks, status) {
  if (status === 'open') return tasks.filter(task => !task.done);
  if (status === 'done') return tasks.filter(task => task.done);
  return tasks;
}

רעננו את http://localhost:4173 ובצעו את הפעולות של E1, E2, E3 ו-E5. לאחר מכן פתחו את http://localhost:4173/?fixture=all-open ולחצו הושלמו. הכתובת הזאת פותחת רשימה שבה כל המשימות פתוחות, כך שאפשר לבדוק את מצב E4 בלי למחוק משימות. לבסוף פתחו את כלי המפתחים בדפדפן, הפעילו תצוגת מכשיר ובחרו רוחב 390 פיקסלים לבדיקת E6.

סיימתם כשחמש בדיקות הפונקציה עברו, כל שש בדיקות הקבלה בוצעו והסוקר לא השאיר ממצא פתוח. בקשו דוח סופי עם הראיות. אם חלק מהבדיקות חסרות, שמרו את המצב כ-blocked או waiting-for-verification והשלימו אותן לפני שאתם מאשרים שהפיצ'ר מוכן.

לוקחים את המבנה לפיצ'ר הבא

התוצר כאן הוא גם דרך עבודה: requirements.md מגדיר מה בונים, evals.md מגדיר איך מוכיחים הצלחה, REVIEW.md מכוון את הביקורת ו-state.md מראה מה קרה בפועל. ה-Hook מפעיל בדיקה ברגע קבוע, והלולאה חוזרת לתיקון רק כל עוד יש התקדמות.

בפיצ'ר הבא התחילו שוב מ-/write-evals והתאימו את הנתיבים ואת פקודת הבדיקה. אל תעתיקו את E1-E6 או את הנתיב הקבוע ב-Hook בלי להתאים אותם. אם אותה תקלה חוזרת, הוסיפו בדיקה ממוקדת או כלל קצר ב-REVIEW.md אחרי שבדקתם שהוא מתאר בעיה אמיתית.

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

מקורות וקבצים

• Anthropic: איך צוות Claude Code מנהל ביקורת קוד
• התיעוד הרשמי: Skills
• התיעוד הרשמי: סוכני משנה
• התיעוד הרשמי: Hooks ואירוע Stop
• התיעוד הרשמי: הוראות פרויקט וייבוא קבצים
• ערכת ההתחלה: כל הקבצים, האפליקציה והבדיקות