compound engineering در Claude Code (کلاد کد) یعنی استفاده از یک روش و یک پلاگین که کار مهندسی را به حلقه‌ای از «فکر کردن، برنامه‌ریزی، اجرا، بازبینی و ثبت درس» تبدیل می‌کند، تا هر تغییر، تغییر بعدی را آسان‌تر کند. پلاگینی که این روش را پیاده می‌کند compound-engineering از تیم Every است و روی Claude Code با دو دستور نصب می‌شود.
این راهنما برای کسی است که اصول گردش‌کار توسعه با Claude Code را خوانده و حالا می‌خواهد یک حلقهٔ واقعی را اجرا کند. می‌خوانید پلاگین چیست، چطور نصب و به‌روز می‌شود، شش مرحلهٔ حلقه هرکدام چه می‌کنند، حالت خودکار /lfg چه خطری دارد و چطور از شلوغ شدن context جلوگیری کنید. همهٔ دستورها از README رسمی ریپوی EveryInc/compound-engineering-plugin است.
ستارهٔ ریپو در ۴ نوامبر ۲۰۲۶: حدود ۲۵٫۹ هزار؛ لایسنس MIT.
حلقهٔ compound engineering را روی Claude Code خودتان اجرا کنید
Claude Code را از داخل ایران با کلید نقطه وصل کنید؛ بدون فیلترشکن و کارت خارجی، با پرداخت ریالی و راه‌اندازی حدود ۵ دقیقه.
پیش از اجرای حلقه‌های طولانی، راهنمای استفادهٔ امن از Claude Code در ایران را ببینید.
compound engineering Claude Code چیست و چرا «انباشته» می‌شود؟
ایدهٔ اصلی ساده است: در توسعهٔ معمول، هر ویژگی تازه پیچیدگی اضافه می‌کند و هر رفع باگ مقداری دانش محلی به جا می‌گذارد که بعداً باید دوباره کشف شود. کد بزرگ‌تر می‌شود، نگه داشتن context در ذهن سخت‌تر می‌شود و تغییر بعدی کندتر. README پلاگین این وضع را وارونه می‌کند و می‌گوید هر واحد کار مهندسی باید کار بعدی را آسان‌تر کند، نه سخت‌تر.
راهکارش تقسیم تلاش است. README می‌گوید سهم برنامه‌ریزی و بازبینی حدود ۸۰٪ است و اجرا حدود ۲۰٪. یعنی پیش از نوشتن کد خوب فکر می‌کنید، پس از نوشتن آن را با چند دید بازبینی می‌کنید و آنچه یاد گرفته‌اید را در فایل می‌نویسید. این فایل‌ها بعداً به‌عنوان زمینه برای عامل خوانده می‌شوند، پس عامل لازم نیست درس قبلی را دوباره از صفر یاد بگیرد.
این پلاگین طبق README مجموعه‌ای از ۳۷ skill برای عامل‌های کدنویسی است و روی ۱۴ میزبان (host) از جمله Claude Code، Cursor و Codex اجرا می‌شود. اگر با تفاوت skill و پلاگین و MCP آشنا نیستید، اول راهنمای پلاگین Claude Code را مرور کنید.
حلقهٔ شش‌مرحله‌ای: از ایده تا درس
قلب پلاگین شش دستور است که پشت‌سر هم اجرا می‌شوند: روشن کردن نیازمندی، برنامه‌ریزی، اجرا، ساده‌سازی، بازبینی و ثبت درس. جدول زیر خلاصهٔ README را با خروجی هر مرحله کنار هم می‌گذارد.
| مرحله | کار | خروجی |
|---|---|---|
/ce-brainstorm |
پرسش‌وپاسخ تعاملی برای روشن کردن نیازمندی | طرح «فقط نیازمندی» |
/ce-plan |
تبدیل به برنامهٔ قابل پیاده‌سازی | فایل برنامه (پیش‌فرض در docs/plans/) |
/ce-work |
اجرای برنامه | تغییر کد، commit |
/ce-simplify-code |
ساده‌سازی کد تازه و حذف تست/کامنت بی‌ارزش | کد تمیزتر |
/ce-code-review |
بازبینی چندعاملی، فقط گزارش | فهرست یافته‌ها |
/ce-compound |
ثبت درس | فایل در docs/solutions/ |
نکتهٔ مهم، فلش برگشت است. /ce-compound درس را در docs/solutions/ می‌نویسد و دور بعد /ce-brainstorm و /ce-plan آن را به‌عنوان پشتوانه می‌خوانند. README همین برگشت را «کل ماجرا» می‌داند: brainstorm برنامه را دقیق‌تر می‌کند، برنامه اجرا را کوچک‌تر، بازبینی الگو را می‌گیرد نه فقط باگ را، و یادداشت درس باعث می‌شود عامل بعدی همان درس را دوباره یاد نگیرد.
قبل از /plugin install، Claude Code آماده باشد
دستورهای نصب داخل Claude Code زده می‌شوند. اگر هنوز وصلش نکرده‌اید، اول با کلید نقطه راهش بیندازید.
نصب compound engineering روی Claude Code
نصب دو مرحله دارد. اول marketplace را اضافه می‌کنید تا Claude Code بداند پلاگین از کجا می‌آید، بعد خود پلاگین را نصب می‌کنید. در Claude Code بزنید:
/plugin marketplace add EveryInc/compound-engineering-plugin
/plugin install compound-engineering
README برای Cursor دستور /add-plugin compound-engineering و برای Codex مسیرهای جدا دارد؛ این مقاله فقط Claude Code را پوشش می‌دهد و در بخش آخر به بقیه اشاره‌ای کوتاه می‌کند.
به‌روزرسانی: اول refresh، بعد update
این نکته را بسیاری از کاربران از دست می‌دهند. README هشدار می‌دهد اگر قبلاً نصب کرده‌اید، پیش از /plugin update باید marketplace را refresh کنید؛ فقط /plugin update شما را روی نسخهٔ قدیمی نگه می‌دارد. README دلیلش را تغییر پلاگین به ساختار «skills-only» می‌گوید. دستورهای دقیق refresh برای هر میزبان در راهنمای Upgrading داخل README آمده است.
پیش از نصب، چک‌لیست امنیتی
هر پلاگین می‌تواند دستور و عامل به Claude Code اضافه کند، پس نصب آن شبیه اجرای کد شخص دیگر است. پیش از نصب چک‌لیست امنیتی نصب امن پلاگین را رد کنید. این پلاگین تعداد زیادی skill و agent دارد؛ در تب Marketplaces عدد «Context cost» را بررسی کنید تا بدانید چه سهمی از context می‌گیرد.
راه‌اندازی در پروژه با /ce-setup
پس از نصب، در ریشهٔ هر پروژه‌ای که می‌خواهید با آن کار کنید یک بار این دستور را بزنید:
/ce-setup
طبق README این دستور سه کار می‌کند: قابلیت‌های اختیاری ابزارها را گزارش می‌دهد، فایل .compound-engineering/config.yaml را در ریپو می‌سازد (اگر نبود) و فایل override محلی را در gitignore می‌گذارد. یعنی تنظیمات مشترک تیم با ریپو commit می‌شود و ترجیح‌های شخصی هر نفر بیرون می‌ماند. اگر هنوز نمی‌دانید کدام دستور را بزنید یا قدم بعدی چیست، /ce-help را بپرسید.
یک نکتهٔ پیکربندی: پوشه‌های docs/plans/ و docs/solutions/ پیش‌فرض‌اند. اگر docs/ ریپوی شما محتوای دیگری دارد (مثلاً مستندات منتشرشده)، README از تنظیم docs_root می‌گوید که همهٔ پوشه‌های پلاگین را زیر یک ریشهٔ دیگر می‌برد.
اولین حلقه گام‌به‌گام
مثال خود README برای شروع این است:
/ce-brainstorm make background job retries safer
/ce-plan
/ce-work
/ce-simplify-code
/ce-code-review
/ce-compound
برای اینکه حلقه را واقعاً بفهمید، هر مرحله را جدا ببینیم.
۱) brainstorm: نیازمندی، نه راه‌حل
/ce-brainstorm با شما گفتگو می‌کند. به‌جای اینکه عامل فوراً کد بنویسد، سؤال می‌پرسد: «کدام شکست‌ها را می‌خواهید پوشش دهید؟ retry باید idempotent باشد؟ سقف تلاش چقدر است؟». خروجی طرحی است که فقط نیازمندی را ثبت می‌کند. پاسخ‌های دقیق در همین مرحله بیشترین بازده را دارند، چون خطای نیازمندی گران‌ترین خطاست.
۲) plan: از نیازمندی به برنامهٔ قابل اجرا
/ce-plan همان فایل را به برنامهٔ پیاده‌سازی تبدیل می‌کند. طبق README یک «artifact» واحد است که از نیازمندی شروع می‌شود و تا برنامهٔ اجرایی رشد می‌کند، نه چند سند جدا. برنامه را حتماً خودتان بخوانید و اصلاح کنید؛ ارزان‌ترین جایی که می‌توانید مسیر را عوض کنید همین‌جاست.
۳) work: اجرا
/ce-work برنامه را اجرا می‌کند و commit می‌زند. README می‌گوید می‌تواند برنامه را به‌صورت بومی یا از طریق یک نویسندهٔ cross-model واجد شرایط اجرا کند، ولی تأیید، commit و تحویل همچنان با میزبان می‌ماند.
۴) simplify: ساده‌سازی پیش از بازبینی
/ce-simplify-code کدی را که همین حالا نوشته شده صاف‌تر می‌کند و تست‌ها و کامنت‌های بی‌ارزش را هرس می‌کند. چون پیش از بازبینی اجرا می‌شود، بازبین‌ها وقتشان را روی پیچیدگی اضافه تلف نمی‌کنند.
۵) review: بازبینی چندعاملی
/ce-code-review کد را با چند عامل در برابر برنامه می‌سنجد و فقط گزارش می‌دهد؛ اعمال تغییرات محلی باید صریح خواسته شود. بعد از گزارش، از خودتان بپرسید چه چیزهایی را من نمی‌دیدم؟ پاسخ این سؤال ارزش واقعی بازبینی است.
۶) compound: ثبت درس
/ce-compound آنچه به دست آمد را در docs/solutions/ می‌نویسد. مثال README یک تله در متغیر محیطی است که ۱۸ روز بعد، روی کاری نامربوط، توسط /ce-plan پیدا شد و قیدهایش وارد برنامهٔ تازه شد. این فایل‌ها را در git نگه دارید تا کل تیم از آن‌ها استفاده کند.
حالت خودکار /lfg: کی و با چه احتیاطی؟
اگر نمی‌خواهید هر مرحله را دستی اجرا کنید، README بعد از /ce-brainstorm دستور /lfg را نشان می‌دهد:
/ce-brainstorm describe the feature
/lfg
طبق README، /lfg مسیر را بدون توقف می‌رود: منبع کار تأییدشده (یک برنامه یا یک رفع‌باگ با ce-debug) را برمی‌دارد، اجرا می‌کند، ساده‌سازی می‌کند، بازبینی را اجرا و اصلاحات را اعمال می‌کند، درس ماندگار را ثبت می‌کند، تست‌های مرورگر را می‌زند و commit می‌کند. اگر remote گیت باشد، push می‌کند، pull request باز می‌کند و CI را با یک حلقهٔ ترمیم محدود زیر نظر می‌گیرد. تا وقتی اجازه ندهید merge نمی‌کند و اگر سهمیهٔ ترمیم تمام شود ممکن است با موارد باقی‌مانده تمام شود. اگر remote نباشد، به commit محلی ختم می‌شود.
پس دو توصیه: اول، /lfg را بعد از /ce-brainstorm بزنید تا بر پایهٔ نیازمندی واقعی برنامه بریزد، نه یک جملهٔ مبهم. دوم، برای ریپوی مهم ابتدا مرحله‌ای کار کنید؛ چون /lfg تا باز کردن pull request پیش می‌رود، باید بدانید چه چیزی را به نام شما به بیرون می‌فرستد.
فراتر از حلقه: ابزارهای دیگر پلاگین
README غیر از شش دستور اصلی چند گروه دیگر هم دارد. لازم نیست همه را یاد بگیرید، ولی دانستن اینکه وجود دارند کمک می‌کند در لحظهٔ نیاز سراغشان بروید.
| گروه | نمونه‌ها | کاربرد |
|---|---|---|
| حول حلقه | ce-strategy، ce-product-pulse، ce-sweep |
نگه داشتن حلقه روی جهت درست |
| در صورت نیاز | ce-ideate، ce-debug، ce-explain، ce-pov، ce-doc-review، ce-prototype |
ایده‌پردازی، رفع باگ، توضیح، قضاوت، بازبینی سند |
| گردش git | ce-commit، ce-commit-push-pr، ce-babysit-pr، ce-worktree |
commit، PR، پیگیری PR |
| تست و طراحی | ce-test-browser، ce-polish |
راستی‌آزمایی و صیقل |
برای شروع، دو مورد از همه مفیدترند. /ce-debug وقتی باگی دارید که علتش معلوم نیست: حلقهٔ تشخیص را قبل از اصلاح اجرا می‌کند. /ce-explain وقتی می‌خواهید بفهمید رفتاری در کد چرا این شکل را دارد. برای تست مرورگر هم می‌توانید ابزارهایی که در راهنمای تست مرورگر و طراحی UI آمده را کنار آن بگذارید.
درس‌ها چطور انباشته می‌شوند؟ از فایل تا Compound Packs
سازوکار انباشت عمداً ساده است: فایل‌های متنی در ریپو. /ce-compound می‌نویسد، /ce-brainstorm و /ce-plan می‌خوانند و چون همه‌چیز فایل است، با git نسخه‌بندی می‌شود، در code review دیده می‌شود و هر عاملی (حتی عاملی از ابزار دیگر) می‌تواند آن را بخواند.
برای تیم‌ها، README قابلیت آزمایشی (experimental) «Compound Packs» را هم دارد: پوشه‌هایی از قوانین دستوری، محلی یا از ریپوی git با ref ثابت، که برنامه‌ریزی به آن‌ها تکیه می‌کند و بازبینی اجرایشان را می‌سنجد و هر استفاده به فایل قانون ارجاع می‌شود. اگر قرار است قوانین امنیتی یا قراردادهای یک stack در چند ریپو یکسان باشد، به‌جای کپی کردن در هر ریپو از این قابلیت استفاده کنید. چون آزمایشی است، پیش از تکیه روی آن README نسخهٔ خودتان را بخوانید.
هزینهٔ context و حجم پلاگین
۳۷ skill یعنی ۳۷ توضیح که ممکن است در context بنشیند. هر skill نصب‌شده بخشی از context را می‌گیرد؛ عدد «Context cost» را در /plugin ببینید. برای شروع فقط شش دستور حلقه را یاد بگیرید و بقیه را وقتی نیاز شد. اگر مصرف توکن برایتان مهم است، راهنمای کاهش مصرف توکن نشان می‌دهد چه چیزهایی را باید زیر نظر داشت.
یک تصمیم عملی: اگر فقط گاهی از پلاگین استفاده می‌کنید، آن را در پروژه‌ای فعال کنید که واقعاً به آن نیاز دارد، نه در همهٔ پروژه‌ها.
خطاهای رایج
- اجرای حلقهٔ کامل برای کار کوچک: تغییر یک‌خطی نیاز به brainstorm و برنامه ندارد؛ زمان و توکن هدر می‌دهد.
- فراموش‌کردن refresh قبل از update: نسخهٔ قدیمی می‌ماند و فکر می‌کنید به‌روز هستید.
- قراردادن
docs/solutions/در.gitignore: درس‌ها قرار است با تیم به اشتراک بروند. - نخواندن برنامه: اگر برنامه را بدون خواندن به
/ce-workبدهید، ارزان‌ترین نقطهٔ تصحیح را از دست داده‌اید. - اجرای
/lfgبا یک جملهٔ مبهم: خروجی بدون نیازمندی دقیق کیفیت پایینی دارد. - ثبت درس‌های بی‌ارزش: هر درس باید چیزی را بگوید که از خود کد پیدا نمی‌شود؛ فهرست بلند و بی‌خاصیت context را شلوغ می‌کند.
تمرین پیشنهادی و میزبان‌های دیگر
یک تغییر کوچک ولی واقعی انتخاب کنید (مثلاً افزودن retry به یک تابع). /ce-brainstorm را اجرا کنید و به پرسش‌ها پاسخ دهید، بعد برنامه را بخوانید و اصلاح کنید. پس از اجرا، خروجی بازبینی را با خودتان مقایسه کنید: چه چیزهایی را شما نمی‌دیدید؟ در آخر /ce-compound را بزنید و فایل docs/solutions/ را بخوانید. اگر درس نوشته‌شده به درد دور بعد می‌خورد، روند برای شما کار می‌کند. اگر نه، شاید پروژه یا کار انتخابی بیش از حد کوچک بوده است.
اگر به Codex یا Cursor هم کار می‌کنید
README برای Cursor و Codex هم مسیر نصب جدا دارد: در Cursor با /add-plugin compound-engineering و در Codex با افزودن یک marketplace سفارشی (codex plugin marketplace add EveryInc/compound-engineering-plugin و سپس codex plugin add compound-engineering@compound-engineering-plugin). در Codex، skillها با $ce-plan و $lfg صدا زده می‌شوند، نه با اسلش. اگر تیم شما چند ابزار را هم‌زمان به کار می‌برد، همین پلاگین می‌تواند خروجی برنامه و درس‌ها را بین آن‌ها یکسان نگه دارد، چون هر دو در پوشه‌های ریپو (docs/plans/ و docs/solutions/) نوشته می‌شوند.
جمع‌بندی
compound engineering بیش از هر چیز یک عادت است: پیش از کد فکر کنید، بعد از کد بازبینی کنید و آنچه فهمیدید را بنویسید. پلاگین این عادت را به شش دستور و چند پوشه تبدیل می‌کند. با نصب دو‌خطی شروع کنید، /ce-setup را بزنید، یک کار کوچک را از brainstorm تا compound ببرید و بعد تصمیم بگیرید چقدر از آن را در کار روزانه نگه می‌دارید. نقشهٔ بزرگ‌تر این مسیر را در راهنمای کامل Claude Code ببینید.
کلید API نقطه با پلن پرو باز می‌شود
حلقهٔ کامل و /lfg چند عامل را اجرا می‌کنند؛ در داشبورد نقطه مصرف هر درخواست را زنده می‌بینید و با یک کلید به Sonnet و Opus می‌رسید.
این مقاله چگونه بررسی شد؟
دستورهای نصب و ویژگی‌ها از README رسمی ابزار (و برای مفاهیم Claude Code از مستندات code.claude.com) برداشته شد و در ۱۳ آبان ۱۴۰۵ (۴ نوامبر ۲۰۲۶) دوباره با نسخهٔ فعلی ریپو مقایسه شد. ستاره‌ها، لایسنس‌ها و تاریخ آخرین به‌روزرسانی از API گیت‌هاب همان روز آمده است. هر جا ادعایی از خود سازنده است (مثل نسبت ۸۰٪ برنامه‌ریزی و بازبینی در برابر ۲۰٪ اجرا) همین را نوشته‌ایم و آن را اندازه‌گیری مستقل نمی‌دانیم. اگر دستوری در نسخهٔ شما فرق داشت، README همان نسخه معتبرتر است.
← گردش‌کار توسعه · راهنمای کامل
منبع: README رسمی github.com/EveryInc/compound-engineering-plugin (بررسی ۱۳ آبان ۱۴۰۵ / ۴ نوامبر ۲۰۲۶).
