‏دستور ‎/goal‎ در Claude Code

نویسنده می‌گه بیشتر تعامل‌ها با Claude Code یه الگوی آشنا دارن: یه چیزی می‌خوای، انجامش می‌ده، خروجی رو مرور می‌کنی و می‌ری سراغ کار بعدی. این برای کارهای کوچیک خوبه، ولی برای workflowهای بزرگ و چندمرحله‌ای — مثل اجرای تست تا وقتی پاس بشه، بازنویسی یه کدبیس برای هماهنگی با استایل‌گاید، یا مانیتورینگ مداوم یه build — همین رفت‌وبرگشت تبدیل به گلوگاه می‌شه.

به گفته‌ی این مقاله، دستور ‎/goal‎ این دینامیک رو عوض می‌کنه: به‌جای دادن دستور تک‌به‌تک، یه هدف تعریف می‌کنی و Claude Code به‌صورت مستقل می‌چرخه تا اون هدف برآورده بشه. این دستور برای همین اجرای پایدار و شرط‌محور طراحی شده، جایی که ایجنت کار می‌کنه، پیشرفت خودشو چک می‌کنه و رویکردشو تنظیم می‌کنه تا به یه حالت موفقیتِ تعریف‌شده برسه.

نویسنده مکانیزم حلقه رو این‌جوری توضیح می‌ده: ایجنت هدف و شرط موفقیت رو می‌خونه، یه اقدام انجام می‌ده (فایل ادیت می‌کنه، دستور اجرا می‌کنه، خروجی می‌خونه)، چک می‌کنه شرط برآورده شده یا نه، اگه نه دوباره برمی‌گرده و اقدام دیگه‌ای امتحان می‌کنه، و اگه آره متوقف می‌شه و گزارش می‌ده. به گفته‌ی نویسنده تفاوت اصلیش با یه اجرای ایجنتیک معمولی، همون شرط موفقیتِ صریح و ماشین‌خوانه؛ بدونش ایجنت باید حدس بزنه کِی «تموم» شده.

نویسنده می‌گه شایع‌ترین اشتباه اینه که هدف رو به‌شکل «کاری که باید انجام بشه» بنویسی نه «حالتی که باید بهش رسید». مثلاً «ماژول احراز هویت رو بازنویسی کن» مبهمه، ولی «ماژول احراز هویت همه‌ی تست‌های موجود رو پاس کنه، هیچ تابعی بیشتر از ۳۰ خط نباشه و همه‌جا به‌جای callback از async/await استفاده بشه» سه شرط مشخص می‌ده که ایجنت می‌تونه در هر قدم چک کنه. هدف باید قابل‌بررسی باشه: خروجی قابل‌مشاهده مثل پاس/فیل‌شدن تست، وجود یا نبود فایل، کامپایل‌شدن کد، یا پاسخ مورد انتظار یه API.

یه توصیه‌ی مهم دیگه‌ی نویسنده اینه که هدف رو محدود نگه داری، وگرنه حلقه ممکنه خیلی بیشتر از حد لازم بچرخه و توکن و زمان بسوزونه. مثلاً می‌شه گفت ایجنت فقط روی یه دایرکتوری خاص کار کنه و به فایل‌های تست دست نزنه — چیزی مثل «همه‌ی خطاهای TypeScript تو ‎/src/api‎ حل بشن بدون تغییر هیچ فایل ‎.test.ts‎» — تا ایجنت مشکل رو با پاک‌کردن فایل‌های تست «حل» نکنه.

نویسنده انواع شرط موفقیت رو دسته‌بندی می‌کنه: شرط‌های مبتنی بر خروجی دستور (مثلاً ‎npm test‎ با کد خروجی صفر) که قابل‌اعتمادترینن، شرط‌های وضعیت فایل، شرط‌های ساختار کد (مثل نبودن ‎console.log‎ تو فایل‌های production)، و شرط‌های API/شبکه. توصیه‌ش اینه که روش راستی‌آزمایی رو داخل خود جمله‌ی هدف بذاری تا ایجنت دقیقاً بدونه چه دستوری رو برای بررسی اجرا کنه و آستانه‌ی موفقیت چیه؛ چون تو یه حلقه‌ی خودران، بدون راستی‌آزمایی هیچ سازوکاری نیست که خطاها رو قبل از انباشته‌شدن بگیره.

نکات کلیدی:

• ‎/goal‎ کلود کد رو از دستیار واکنشی به ایجنت خودران تبدیل می‌کنه
• حلقه: خوندن هدف، اقدام، بررسی شرط موفقیت، تکرار تا رسیدن
• هدف خوب یه «حالت» قابل‌اندازه‌گیری رو توصیف می‌کنه، نه صرفاً کاری که باید انجام بشه
• هدف رو محدود کن و بگو ایجنت به چی دست نزنه تا حلقه بی‌پایان نشه
• قابل‌اعتمادترین شرط‌ها مبتنی بر خروجی دستورن، مثل کد خروجی صفرِ تست