clinicpro/.claude/skills/figma-to-feature/SKILL.md

name, description

name	description
figma-to-feature	وقتی کاربر یک لینک figma.com/design با node-id می‌دهد، صفحه را تحلیل کن، نیازهای فرانت‌اند و بک‌اند را استخراج کن و پس از تأیید پیاده‌سازی کن.

بخش ۰ — زبان (قبل از هر کاری)

• ورودی من فارسی است. منظور را استخراج کن، نه ترجمه‌ی لغوی.
• متن را به یک normalized English spec تبدیل کن با فیلدهای: Goal / Scope (in-out) / Constraints / Acceptance criteria / Ambiguities
• اصطلاحات فینگلیش (کامپوننت، اندپوینت، باتن) اصطلاح فنی‌اند، ترجمه نکن.
• اسم متغیر، مسیر فایل، اسم کامپوننت و هر چیز داخل بک‌تیک را عیناً حفظ کن.
• spec انگلیسی + خلاصه‌ی برداشتت به فارسی را نشانم بده و منتظر تأیید بمان. اگر Ambiguities خالی نبود، سؤال‌ها را بپرس. بدون تأیید، کد ننویس.
• خروجی: کد/کامنت/داکیومنت/کامیت انگلیسی. گفت‌وگو با من فارسی. رشته‌های UI فارسی و از فایل i18n پروژه — هاردکد ممنوع.

بخش ۱ — استخراج از فیگما

• fileKey و node-id را از URL دربیاور.
• get_design_context → ساختار و لِی‌اوت
• get_variable_defs → رنگ/اسپیسینگ/تایپوگرافی
• get_screenshot → مرجع تطبیق بصری
• download_assets → آیکون و تصاویر
• توکن‌های فیگما را با mapping.md به متغیرهای واقعی پروژه نگاشت کن.

بخش ۲ — ممیزی کدبیس (اجباری، قبل از هر تحلیلی)

هر بار که یک لینک صفحه می‌گیری، باید هم بک‌اند و هم فرانت‌اند را واقعاً بگردی. حدس زدن ممنوع؛ فقط چیزی که با Grep/Read در کد دیدی.

الف) ممیزی بک‌اند

• routes/controllers را بگرد: کدام اندپوینت‌ها مرتبط با این صفحه از قبل وجود دارند؟
• مدل‌ها و اسکیمای دیتابیس: کدام جدول/فیلد لازم است و از قبل هست؟
• سرویس‌ها و validationها و middleware مرتبط
• برای هر مورد بنویس: مسیر فایل + شماره خط

ب) ممیزی فرانت‌اند

• کامپوننت‌های design system که می‌شود reuse کرد (با مسیر فایل)
• روت مربوطه هست یا نه
• hook/service/state موجود برای این داده
• فایل i18n: کلیدهای متنی این صفحه از قبل هستند؟
• برای هر مورد بنویس: مسیر فایل + شماره خط

ج) خروجی ممیزی — این جدول را بده

مورد	لایه	وضعیت	فایل	اقدام
نام دقیق	Frontend/Backend	✅ موجود / ✏️ نیاز به ادیت / 🆕 جدید	مسیر:خط	یک جمله

د) مبهم‌ها

هر چیزی که از دیزاین معلوم نیست: empty state، حالت خطا، لودینگ، pagination، دسترسی/نقش کاربر، اعتبارسنجی فیلدها. لیست کن و بپرس.

منتظر تأیید من بمان.

---

بخش ۳ — TODO List (اجباری)

بعد از تأیید ممیزی، با ابزار TodoWrite یک TODO بساز. قواعد:

• ترتیب حتماً: Backend → Frontend → i18n → تست → تطبیق بصری (فرانت را قبل از آماده شدن اندپوینت نساز.)
• هر آیتم اتمیک و قابل تست باشد. آیتم مبهم مثل «صفحه را بساز» ممنوع.
• هر آیتم TODO باید تست خودش را هم شامل شود، نه یک آیتم «تست» در آخر.
• ساختار پیشنهادی:
  1. [BE] مایگریشن/مدل X — + تست
  2. [BE] توسعه‌ی اندپوینت Y (یا ساخت جدید، اگر توجیه شد) — + integration test
  3. [FE] service/hook برای فراخوانی Y — + unit test
  4. [FE] کامپوننت A (presentational) — + تست رندر
  5. [FE] کامپوننت B (تعاملی) — + تست تعامل
  6. [FE] مونتاژ صفحه و روت
  7. [i18n] کلیدهای متنی فارسی
  8. [QA] اجرای کل تست‌ها
  9. [QA] مقایسه با اسکرین‌شات فیگما و اصلاح اختلاف‌ها

TODO را قبل از شروع نشانم بده.

---

بخش ۴ — اجرا، مرحله به مرحله

• همیشه فقط یک آیتم in_progress باشد. موازی‌کاری ممنوع.
• ترتیب TODO را رعایت کن؛ از روی آیتم‌ها نپر.
• بعد از هر آیتم: تستش را اجرا کن. آیتم بدون تست سبز، completed علامت نمی‌خورد.
• بعد از هر آیتم یک خط فارسی گزارش بده: چه ساختی، کدام فایل، تست سبز شد یا نه.
• اگر وسط کار به چیزی برخوردی که در ممیزی ندیده بودی (اندپوینت پنهان، کامپوننت مشابه، تضاد با SOLID) → توقف کن، TODO را به‌روز کن، و از من تأیید بگیر. خودسرانه scope را عوض نکن.
• در آخر: خروجی را با اسکرین‌شات فیگما مقایسه کن، اختلاف‌ها را لیست و اصلاح کن، و کل تست‌ها را یک بار دیگر اجرا کن.

بخش ۵ — بستن کار (به همین ترتیب)

1. اول کدها را commit کن. وقتی همهٔ تست‌ها سبز شد، تغییرات را با یک پیام انگلیسی معنادار commit کن (طبق Conventional Commits). قبل از graphify commit کن، نه بعدش.
2. بعد graphify را به‌روز کن: graphify update . — تا گراف با کد جدید هم‌گام شود. این مرحله فقط پس از commitِ موفق اجرا می‌شود.

۱. SOLID

• SRP: هر کامپوننت/کلاس یک مسئولیت. کامپوننتی که هم fetch می‌کند هم رندر می‌کند باید به hook/service + کامپوننت presentational شکسته شود.
• OCP: رفتار جدید با prop/strategy، نه if/else تو در تو در کد موجود.
• LSP: هر پیاده‌سازی جایگزین قرارداد اینترفیس را کامل رعایت کند.
• ISP: props و اینترفیس بزرگ ممنوع؛ به قراردادهای کوچک بشکن.
• DIP: UI و لایه‌ی بیزنس مستقیم به axios/fetch/ORM وابسته نشوند. اگر SOLID با ساختار فعلی تضاد داشت، توقف کن و بپرس؛ خودسرانه بازنویسی نکن.

۲. API جدید — آخرین گزینه

1. کل لایه‌ی routes/controllers را بگرد.
2. اگر اندپوینتی با یک پارامتر یا فیلد اضافه کافی است → همان را backward-compatible توسعه بده.
3. فقط اگر هیچ اندپوینتی نبود، جدید بساز. در جدول تحلیل برای هر نیاز بنویس: «موجود X» / «توسعه‌ی X» / «جدید — چون این‌ها را بررسی کردم و کافی نبودند: [...]». بدون این توجیه، اندپوینت جدید نساز.

۳. مستندسازی — دقیق و مختصر

• هر تابع/کامپوننت عمومی: بلاک کوتاه (چه می‌کند، ورودی، خروجی، خطاها).
• هر اندپوینت: متد، مسیر، payload، response، کدهای خطا — در همان فرمت مستندات فعلی پروژه.
• کامنت بدیهی ممنوع. «چرا» را بنویس، نه «چه».

۴. تست — بدون تست کار تمام نیست

• منطق بیزنس/سرویس/هوک: unit test با حالت موفق + خطا + مرزی.
• اندپوینت جدید یا توسعه‌یافته: integration test.
• کامپوننت تعاملی: تست رندر + تست تعامل.
• از فریم‌ورک تست موجود پروژه استفاده کن.
• تست‌ها را اجرا کن و خروجی سبز را نشان بده.