תהליך עיצוב מוצר בינה מלאכותית שלי ללא Figma

עיצוב מוצר ללא Figma עובד כאשר למוצר כבר יש מערכת עיצוב בוגרת. תהליך עיצוב המוצר שלי עם בינה מלאכותית משתמש בשלוש מיומנויות של סוכן: ui-design חוקר תשעה כיוונים, ui-implement הופך את הכיוון הנבחר למוצר, ו-ui-walkthrough סוקר כל מצב דרך Agent Browser המובנה. אני עדיין מקבל את ההחלטות; הסוכן מטפל בייצור ובבדיקה החוזרים.

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

המעצב עדיין מקבל את החלטות המוצר. הסוכן מסיר את רוב ההרכבה והבדיקה החוזרות. זה עובד כי ל-Zero כבר יש מערכת עיצוב בוגרת למדי.

1. התחילו עיצוב מוצר ללא Figma עם מערכת עיצוב

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

עבור Zero, הסוכן יכול לבדוק:

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

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

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

Figma עדיין שימושית כאשר צוות יוצר מותג חדש, מערכת רכיבים חדשה או אינטראקציה שאין לה התייחסות דומה במוצר. אבל כשהמערכת בוגרת, המוצר הרץ יכול להפוך למשטח העיצוב הראשי. זהו היישום בקנה מידה של פיצ'ר של design-as-code workflow שבו השתמשנו לבניית Zero מחדש.

2. השתמשו ב-ui-design כדי לחקור תשעה כיווני עיצוב מוצר

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

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

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

החשיבה העיצובית מאחורי ההוראה הזו

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

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

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

הנה ההוראה המקורית המלאה, מועתקת מילה במילה מתהליך העבודה החי:

הוראת ui-design המקורית המלאה

# vm0 / Zero UI Design Rules

## Workflow — visuals first, code later

**Do not jump to code.** When this skill is invoked, the first deliverable is always a set of rendered mockups for Ming to look at. Implementation happens only after a direction is chosen.

### Step 1 — Capture the "before"

- If a screen already exists, render its current state as the **before** image (screenshot the running app, or render the existing component as a static preview).
- If the request is for a brand-new screen, the "before" is either the closest existing screen or a blank state — make this explicit in the caption.

### Step 2 — Produce a single "after" anchor

- One mockup that represents your best-guess interpretation of the request, fully obeying every rule below (components, sentence case, agent-detail inputs/dropdowns, chat-composer card radii, add-schedule button, IconButton hovers, gray-50 surfaces).
- Pair it with the **before** side-by-side. Label them clearly: `Before` / `After`.

### Step 3 — Generate 9 variant explorations

After the before/after pair, produce **9 distinct variant mockups** for the same screen. Each variant should explore a meaningfully different design axis — not 9 color tweaks. Cover a spread such as:

1. Layout — single column vs. split / sidebar / grid
2. Density — compact vs. spacious
3. Hierarchy — which element leads visually
4. Surface treatment — flat vs. card-grouped vs. divided sections
5. Entry point — inline action vs. dedicated CTA vs. empty-state hero
6. Copy framing — instructive vs. minimal vs. conversational
7. Disclosure — everything visible vs. progressive reveal / accordions
8. Composition — content-led vs. control-led
9. A deliberately unconventional / "wild card" direction worth seeing once

Each variant must still respect the non-negotiables (sentence case, reuse components, agent-detail input/dropdown style, chat-composer radii, add-schedule button, IconButton hover, gray-50 neutrals). Variants explore *layout and emphasis*, not "what if we ignored the design system."

### Step 4 — Present, then wait

- Show all images to Ming in one message: the `Before / After` pair first, then the 9 variants numbered 1–9 with a one-line caption each describing the axis being explored.
- Ask which direction (or which mix) to pursue.
- Do not begin implementation until Ming picks a direction.

### Rendering the images

- Preferred path: build static HTML/React previews that use real Tailwind tokens from `turbo/apps/platform`, screenshot them, and upload via `okou web upload-file`.
- For quick exploration: the `v0` skill can generate variant mockups from a prompt — but the prompt must explicitly enumerate the rules below (sentence case, agent-detail inputs, chat-composer radius, etc.) so v0 doesn't produce generic SaaS UI.
- If image generation is unavailable for the session, fall back to clearly-labeled ASCII / textual wireframes for all 11 frames (before, after, 9 variants) and call this out — never silently skip the visuals step.

---

# Design Rules

These are the non-negotiable design conventions for any new UI shipped inside the vm0 platform (`turbo/apps/platform`). Apply them before writing components, and audit existing PRs against them during review.

## Core principles

1. **Reuse, don't reinvent.** Always check existing primitives in `turbo/apps/platform/src/components/` and view-level patterns under `src/views/` before introducing a new component. If a similar interaction already ships in agent detail, schedule, or chat composer, copy that pattern rather than designing a parallel one.
2. **Match the Zero design language.** Soft surfaces, neutral grays, generous radii, subtle borders, no harsh shadows. The visual baseline is "calm, opinionated, slightly editorial" — never SaaS-default.
3. **Speak from the user's seat.** Copy should describe what *they* are about to do or see, not what the system is doing. Keep it short — usually a single sentence, max two.

## Reference patterns (copy these directly)

| Element             | Reference source                                  | Why |
|---------------------|---------------------------------------------------|-----|
| Text / textarea input | Agent detail page input (`src/views/agent-detail/`) | Established padding, border, focus state, placeholder treatment |
| Dropdown / select     | Agent detail page dropdown                         | Established trigger style, menu radius, item hover, check mark placement |
| Card / panel radius   | Chat composer card (look for `composer` components) | Sets the canonical card radius and surface style across the app |
| Primary page button   | "Add schedule" button on the schedule page          | The neutral-dark primary used everywhere *outside* of modals |
| Modal primary button  | The brand primary color (only inside dialogs/popovers) | Modals retain the brand-color primary; pages do not |
| Icon-only button      | Existing IconButton with hover background           | Every clickable icon must have a visible hover state |

When in doubt, open the reference component in the codebase, read its props and class names, and mirror them. Do not approximate from memory.

## Copy guidelines

- **User-perspective phrasing.** "Connect your inbox" beats "Inbox connection required". "No agents yet" beats "Agent list is empty".
- **Brevity over completeness.** A short line outperforms a complete sentence. Trim filler ("simply", "please", "in order to").
- **Sentence case for everything.** Labels, headings, buttons, menu items, table columns — all sentence case ("Model providers", "API keys", "Add schedule"). Never Title Case. Never `uppercase` via CSS on section headers. If you find a Title-Case or all-caps label, fix it.
- **No caption-case "decorative" labels** above fields or sections — they read as form-y and dated. Use a normal label or skip the label if the field is self-evident.
- **No trailing punctuation** on standalone labels or buttons. Periods are for body copy and helper text.
- When renaming a string, grep the codebase for the old string and tests for it — labels are referenced in tests and translations.

## Components and structure

- Always build pages out of existing components (`Button`, `Input`, `Select`, `Card`, `IconButton`, dialog primitives, etc.). New components are a last resort and require a reason.
- Look for an existing layout/template (settings page, list page, detail page) and inherit its scaffolding. Don't re-derive page structure.
- When adding to a settings-style page, match the section spacing, divider treatment, and form-row width used by neighboring sections.

## Buttons

- **Page primary** (the main CTA on a page) → match the "Add schedule" button on the schedule page. This is the neutral dark/solid primary used app-wide outside dialogs.
- **Modal primary** (the confirm button inside dialogs/popovers) → uses the brand primary color. Pages do not.
- **Secondary / ghost buttons** → reuse the existing variants; do not invent new ones.
- **Icon buttons** → must have a hover background (typically `hover:bg-gray-50` or the established IconButton hover token). Never ship a bare hoverless icon as a click target.
- All buttons should respect the existing height tokens — don't introduce one-off sizes.

## Inputs

- Mirror the agent detail input: same padding, same border, same focus ring (or lack thereof — check the reference before adding a focus ring), same placeholder color.
- Multi-line: use the agent detail textarea pattern (auto-grow or fixed rows as in reference).
- Don't put a colon at the end of field labels.
- Helper text below the input, in muted gray, single line.

## Dropdowns / selects

- Mirror the agent detail dropdown: same trigger appearance, same menu radius, same item padding, same hover/selected states.
- The menu should not be wider than its trigger unless the content demands it.
- Avoid nested submenus unless an existing dropdown already uses them.

## Cards and surfaces

- Card radius and surface style match the chat composer card. Do not introduce a smaller or larger radius without a reason.
- Borders are subtle (single hairline in the existing border token). No drop shadows unless the chat composer uses one.
- Neutral surfaces on mobile / light gray fills (active pill backgrounds, icon container fills, etc.) → `bg-gray-50`. `gray-100` and `gray-200` have repeatedly been called too dark — start at `gray-50`.

## Focus and interaction

- Don't add custom `:focus-visible` box-shadows or outlines to nav/marketing elements — reuse the hover color shift instead. (Same restraint generally applies inside the platform unless a reference component has an explicit focus ring.)
- Every interactive element (button, icon button, row, link) needs a visible hover state. Test by hovering each one before considering the design done.
- Disabled states use the existing disabled tokens; don't hand-roll a faded color.

## Review checklist

Before declaring a UI ready, walk through:

1. Did I reuse existing components instead of building new ones?
2. Did I match an existing page template / layout?
3. Are inputs visually identical to agent detail inputs?
4. Are dropdowns visually identical to agent detail dropdowns?
5. Do cards match the chat composer radius and surface?
6. Is every label sentence case? Any leftover Title Case or all-caps?
7. Is the copy short and written from the user's seat?
8. Is the page primary the "Add schedule"-style button? Is the brand primary used only inside modals?
9. Does every icon button have a hover background?
10. Did I hover every interactive element to confirm feedback?

If any answer is "no", fix it before opening the PR.

## When in doubt

- Open the reference component, read its source, and copy the structure.
- If two reference components disagree, prefer the more recently shipped one (check git log).
- If the design genuinely needs a new primitive, raise it with Ming before building it — bundled redesign work belongs in one PR with him as the reviewer.

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

דוגמה אמיתית: הניווט של Zero

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

תקציר המוצר לחקירה היה:

/ui-design

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

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

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

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

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

התוצר החשוב של ui-design לא היה רק התמונה. זו הייתה תיעוד החלטה קצר:

• שמרו על מסילת יעדים ברוחב 68 פיקסלים ומסילת צ'אט ברוחב 300 פיקסלים
• הציגו חמישה מקומות לסוכנים מוצמדים
• שמרו על בחירה שקטה אך קריאה
• הציגו הנחיות סידור מחדש רק בזמן גרירה
• שמרו על אזור השיחה ומגירת המובייל הקיימת ללא שינוי

זה הספיק כדי להתחיל ביישום.

3. השתמשו ב-ui-implement כדי להפוך את העיצוב הנבחר לקוד

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

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

מה ההוראה הזו מגנה עליו

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

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

הנה ההוראה המקורית המלאה, מועתקת מילה במילה מתהליך העבודה החי:

הוראת ui-implement המקורית המלאה

# vm0 / Zero UI Implementation Rules

## Workflow — implement directly

When this skill is invoked, **skip the mockup and variant exploration phase**. Start implementing in `turbo/apps/platform` immediately, applying every design rule below.

### Step 1 — Locate the reference components

Before writing a line, open the reference components you'll mirror:

- Input / textarea → `src/views/agent-detail/` input
- Dropdown / select → `src/views/agent-detail/` dropdown
- Card / panel radius → chat composer card
- Page primary button → "Add schedule" button on the schedule page
- Icon-only button → existing `IconButton` with hover background

Read their props and class names. Mirror them — do not approximate from memory.

### Step 2 — Find the closest existing page template

Open the nearest existing page of the same shape (settings, list, detail) and inherit its scaffolding: section spacing, divider treatment, form-row width. Don't re-derive page structure.

### Step 3 — Build, then self-audit

Implement the screen with existing primitives from `turbo/apps/platform/src/components/`. When you think it's done, walk the **Review checklist** at the bottom of this skill before reporting back. Fix every "no" answer before declaring the work complete.

### Step 4 — Verify in the browser

For any UI work, start the dev server and exercise the feature in a browser before reporting the task as done. Hover every interactive element, test the golden path and edge cases, and watch for regressions in neighboring screens. Type-check and tests verify code, not feature correctness — if you can't open the browser, say so explicitly.

### When to fall back to ui-design

If the request is open-ended ("design a settings page for X") with no chosen direction, stop and run the `ui-design` skill instead — the before/after + 9 variants exist for exactly that case. `ui-implement` is for when the direction is already decided.

---

# Design Rules

These are the non-negotiable design conventions for any new UI shipped inside the vm0 platform (`turbo/apps/platform`). Apply them while building, and audit your own diff against them before opening the PR.

## Core principles

1. **Reuse, don't reinvent.** Always check existing primitives in `turbo/apps/platform/src/components/` and view-level patterns under `src/views/` before introducing a new component. If a similar interaction already ships in agent detail, schedule, or chat composer, copy that pattern rather than designing a parallel one.
2. **Match the Zero design language.** Soft surfaces, neutral grays, generous radii, subtle borders, no harsh shadows. The visual baseline is "calm, opinionated, slightly editorial" — never SaaS-default.
3. **Speak from the user's seat.** Copy should describe what *they* are about to do or see, not what the system is doing. Keep it short — usually a single sentence, max two.

## Reference patterns (copy these directly)

| Element             | Reference source                                  | Why |
|---------------------|---------------------------------------------------|-----|
| Text / textarea input | Agent detail page input (`src/views/agent-detail/`) | Established padding, border, focus state, placeholder treatment |
| Dropdown / select     | Agent detail page dropdown                         | Established trigger style, menu radius, item hover, check mark placement |
| Card / panel radius   | Chat composer card (look for `composer` components) | Sets the canonical card radius and surface style across the app |
| Primary page button   | "Add schedule" button on the schedule page          | The neutral-dark primary used everywhere *outside* of modals |
| Modal primary button  | The brand primary color (only inside dialogs/popovers) | Modals retain the brand-color primary; pages do not |
| Icon-only button      | Existing IconButton with hover background           | Every clickable icon must have a visible hover state |

When in doubt, open the reference component in the codebase, read its props and class names, and mirror them. Do not approximate from memory.

## Copy guidelines

- **User-perspective phrasing.** "Connect your inbox" beats "Inbox connection required". "No agents yet" beats "Agent list is empty".
- **Brevity over completeness.** A short line outperforms a complete sentence. Trim filler ("simply", "please", "in order to").
- **Sentence case for everything.** Labels, headings, buttons, menu items, table columns — all sentence case ("Model providers", "API keys", "Add schedule"). Never Title Case. Never `uppercase` via CSS on section headers. If you find a Title-Case or all-caps label, fix it.
- **No caption-case "decorative" labels** above fields or sections — they read as form-y and dated. Use a normal label or skip the label if the field is self-evident.
- **No trailing punctuation** on standalone labels or buttons. Periods are for body copy and helper text.
- When renaming a string, grep the codebase for the old string and tests for it — labels are referenced in tests and translations.

## Components and structure

- Always build pages out of existing components (`Button`, `Input`, `Select`, `Card`, `IconButton`, dialog primitives, etc.). New components are a last resort and require a reason.
- Look for an existing layout/template (settings page, list page, detail page) and inherit its scaffolding. Don't re-derive page structure.
- When adding to a settings-style page, match the section spacing, divider treatment, and form-row width used by neighboring sections.

## Buttons

- **Page primary** (the main CTA on a page) → match the "Add schedule" button on the schedule page. This is the neutral dark/solid primary used app-wide outside dialogs.
- **Modal primary** (the confirm button inside dialogs/popovers) → uses the brand primary color. Pages do not.
- **Secondary / ghost buttons** → reuse the existing variants; do not invent new ones.
- **Icon buttons** → must have a hover background (typically `hover:bg-gray-50` or the established IconButton hover token). Never ship a bare hoverless icon as a click target.
- All buttons should respect the existing height tokens — don't introduce one-off sizes.

## Inputs

- Mirror the agent detail input: same padding, same border, same focus ring (or lack thereof — check the reference before adding a focus ring), same placeholder color.
- Multi-line: use the agent detail textarea pattern (auto-grow or fixed rows as in reference).
- Don't put a colon at the end of field labels.
- Helper text below the input, in muted gray, single line.

## Dropdowns / selects

- Mirror the agent detail dropdown: same trigger appearance, same menu radius, same item padding, same hover/selected states.
- The menu should not be wider than its trigger unless the content demands it.
- Avoid nested submenus unless an existing dropdown already uses them.

## Cards and surfaces

- Card radius and surface style match the chat composer card. Do not introduce a smaller or larger radius without a reason.
- Borders are subtle (single hairline in the existing border token). No drop shadows unless the chat composer uses one.
- Neutral surfaces on mobile / light gray fills (active pill backgrounds, icon container fills, etc.) → `bg-gray-50`. `gray-100` and `gray-200` have repeatedly been called too dark — start at `gray-50`.

## Focus and interaction

- Don't add custom `:focus-visible` box-shadows or outlines to nav/marketing elements — reuse the hover color shift instead. (Same restraint generally applies inside the platform unless a reference component has an explicit focus ring.)
- Every interactive element (button, icon button, row, link) needs a visible hover state. Test by hovering each one before considering the design done.
- Disabled states use the existing disabled tokens; don't hand-roll a faded color.

## Review checklist

Before declaring a UI ready, walk through:

1. Did I reuse existing components instead of building new ones?
2. Did I match an existing page template / layout?
3. Are inputs visually identical to agent detail inputs?
4. Are dropdowns visually identical to agent detail dropdowns?
5. Do cards match the chat composer radius and surface?
6. Is every label sentence case? Any leftover Title Case or all-caps?
7. Is the copy short and written from the user's seat?
8. Is the page primary the "Add schedule"-style button? Is the brand primary used only inside modals?
9. Does every icon button have a hover background?
10. Did I hover every interactive element in a browser to confirm feedback?

If any answer is "no", fix it before opening the PR.

## When in doubt

- Open the reference component, read its source, and copy the structure.
- If two reference components disagree, prefer the more recently shipped one (check git log).
- If the design genuinely needs a new primitive, raise it with Ming before building it — bundled redesign work belongs in one PR with him as the reviewer.

זו הייתה הנחיית היישום הספציפית לפיצ'ר:

/ui-implement

התחילו מרוויזיה 04d642bb. הוסיפו פיצול שולחני כבוי כברירת מחדל עם מסילת יעדים ברוחב 68px, מסילת צ'אט ברוחב 300px ואזור שיחה ללא שינוי. שמרו על סרגל צד ישן ברוחב 300px כאשר המתג כבוי ובמובייל. הציגו חמישה מקומות מוצמדים, שמרו על סדר שהוגדר על ידי המשתמש, והציגו אפשרות סידור מחדש רק במהלך גרירה פעילה. אל תבדקו את הפיצ'ר ההיסטורי או שיפורים מאוחרים עד שהטלאי, הבדיקות וההוכחה בדפדפן קפואים.

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

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

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

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

מצב מנוחה שולחני

סידור פעיל

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

4. השתמשו ב-ui-walkthrough כדי לסקור את המוצר האמיתי

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

לסוכן יש Agent Browser מובנה, כך שאוכל להעביר לו את העבודה הזו.

לתהליך העבודה שני שלבים עיקריים:

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

מה ההוראה הזו משנה בביקורת

• הסוכן רושם את התרחישים לפני שהוא מתחיל ללחוץ.
• הוא משתמש ברכיב המוצר שפורסם דרך Agent Browser המובנה.
• הוא לוכד צילום מסך לכל מצב משמעותי.
• הוא מסמן כל נקודת ביקורת כ-PASS, FAIL או BLOCKED.
• הוא לעולם לא מסתיר מצב לא זמין מאחורי הוכחה מזויפת.

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

ההוראה המלאה למטה. תרגמתי את שם התלות הפנימית ל-“Agent Browser המובנה” לטובת הקוראים; הלוגיקה לא השתנתה.

הוראת ui-walkthrough המקורית המלאה

# UI Walkthrough

End-to-end visual QA of a vm0/Zero front-end feature in its real per-PR preview. This workflow defines what to verify and how to report the result; it does not define UI-operation tooling.

## Required dependency: built-in Agent Browser

Use the built-in Agent Browser as the single source of truth for every UI interaction, including:

- Discovering and opening the per-PR preview.
- Preview-protection handling and session setup.
- Sign-up, OTP, onboarding, Stripe test checkout, and reaching the live app.
- Enabling feature switches.
- Navigating, interacting with controls, supplying test or mock data, capturing screenshots, uploading artifacts, troubleshooting, and cleanup.

Read and follow the current built-in Agent Browser instructions before taking any UI action. Do not duplicate runtime-specific commands, engine setup, selector mechanics, page-context scripts, session management, or process-cleanup methods in this workflow. If the built-in Agent Browser changes, its current instructions take precedence.

## When to use

- Walk through the UI of a vm0 pull request in its deployed preview.
- Verify an in-app feature that requires authentication, onboarding, billing, feature switches, or a real chat thread.
- Capture faithful screenshots or a short walkthrough video of the feature working in the live application.

## Walkthrough workflow

### 1. Establish the target and scope

- Identify the PR, head commit, changed user-visible behavior, and expected preview.
- Confirm that the deployed preview corresponds to the PR head before testing.
- Read the PR diff and description to derive the critical path and the states that demonstrate the change.
- Do not fix code, resolve conflicts, or change product behavior during a walkthrough unless the user separately requests implementation.

### 2. Reach the feature

Use the built-in Agent Browser to enter the preview and reach the live feature state. Follow its current rules for authentication, onboarding, billing, feature switches, and preview-only bypasses.

If a bypass is used, disclose it in the final report. Never use an onboarding bypass when onboarding itself is under test.

### 3. Define the visual state matrix

Before interacting, list the smallest set of states that proves the feature works. Include the applicable items:

- Initial/default state.
- Open, hover, focus, selected, expanded, or active state.
- Empty and populated states.
- Enabled and disabled states.
- Success, validation, loading, and error states.
- Placement, collision, flip, clipping, and responsive behavior.
- Submission or downstream action when the feature is interactive.

Prefer exercising the actual changed behavior over a generic smoke test.

### 4. Drive the live component

Use the built-in Agent Browser for all interaction and test-data techniques.

Mock or injected content may be used only to place a real application component into a deterministic visual state. The component, styling, and interaction being assessed must remain the live implementation from the PR preview.

For every mocked state:

- Record which content or prerequisite was mocked.
- Distinguish mocked content from real application behavior.
- Never imply that mocked text or data came from a model or production source.
- Exercise the real controls and downstream wiring wherever the environment permits.

### 5. Capture evidence

Use the built-in Agent Browser to capture and upload evidence for the key checkpoints. Each image should prove one meaningful state rather than repeat the same view.

If the user asks for a video, assemble a short captioned walkthrough from the verified checkpoints. Captions should identify the user action and expected result without obscuring the UI.

### 6. Deliver and report

Report:

- PR link, exact preview URL, and tested commit when available.
- Exact user flow exercised.
- Test account when one was created.
- `PASS`, `FAIL`, or `BLOCKED` for each checkpoint.
- Screenshot links and an optional video link with short descriptions.
- Feature switches, bypasses, mock data, and other test-only setup used.
- Failed checks, environment blockers, or verification gaps.

Do not claim the feature is verified unless the live preview flow was exercised and evidence was captured. If the preview is unavailable, report `BLOCKED` with the deployment evidence rather than substituting a local or static replica.

זו הייתה הנחיית הסקירה הספציפית לפיצ'ר:

/ui-walkthrough

השתמשו בתצוגה המקדימה שפורסמה דרך Agent Browser המובנה כאמת הדפדפן היחידה. הוכיחו את סרגל הצד כשהפיצ'ר כבוי, את הפיצול 68px ו-300px, סדר היעדים, מצבי ריחוף, חמישה מקומות מוצמדים, ידיות גרירה בלבד, סידור שנשמר, בחירת שרשור, גלילה ומגירת iPhone מלאה. החזירו PASS, FAIL או BLOCKED לכל נקודת ביקורת. אל תחליפו מצב לא נגיש בהעתק.

עבור פיצ'ר זה, הסוכן ארגן את הסקירה סביב השאלות הבאות:

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

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

התוצאה הייתה 11 PASS, 1 FAIL.

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

תרחיש	תוצאה
סרגל צד ישן כשהפיצ'ר כבוי	PASS
פריסת שולחן עבודה תלת-חלקית חדשה	PASS
מצבי ריחוף ובחירה	PASS
חמישה סוכנים מוצמדים	PASS
הנחיית סידור מחדש בגרירה בלבד	PASS
סדר שנשמר לאחר רענון	PASS
בחירת שרשור וגלילה	PASS
מגירת מובייל קיימת	PASS
תוכן וסדר יעדים	FAIL

המסירה הסופית הייתה סט מסודר של צילומי מסך ולא תיקיה של תמונות ללא תווית. צילומי המסך השולחניים הם בגודל 1440 × 900 פיקסלים ולכידת הטלפון היא בגודל 1170 × 2532 פיקסלים. הם מוצגים אחד בכל פעם למען קריאות; לחצו על כל תמונה להגדלה מבלי לצאת מהמאמר.

פיצ'ר כבוי

פיצ'ר מופעל

פריסת שולחן עבודה

ריחוף יעד

ריחוף סוכן מוצמד

גרירה פעילה

סדר שנשמר

מגירת מובייל

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

איך צוות מאמץ את תהליך עיצוב המוצר בינה מלאכותית הזה

התהליך המלא קצר. חברי צוות יכולים לשמור כל שלב כ-Workflow משותף של Zero במקום לבנות אותו מחדש מהזיכרון.

שלב	קלט	פלט
ui-design	מסך נוכחי, בעיה, מטרה ומגבלות	כיוון מומלץ אחד, תשעה חלופות ותיעוד עיצוב נבחר
ui-implement	תיעוד העיצוב הנבחר	שינוי קוד לסקירה וצילומי מסך של המצבים העיקריים
ui-walkthrough	הפיצ'ר שפורסם וההתנהגות הצפויה שלו	רשימת תרחישים מסודרת עם צילומי PASS, FAIL או BLOCKED

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

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

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

שאלות נפוצות

איך בונים תהליך עיצוב מוצר בינה מלאכותית?

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

האם מעצבי מוצר יכולים לעבוד ללא Figma?

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

האם בינה מלאכותית מחליפה מעצבי מוצר?

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