استفاده از AI برای برنامه‌نویسی دیگه به کپی کردن یک پیام خطا در پنجره چت و پرسیدن «چطور این مشکل را برطرف کنم؟» محدود نمی‌شود.
ایجنت‌های کدنویسی مدرن می‌توانند یک Repository را بررسی کنند، دستورالعمل‌های پروژه را بخوانند، چندین فایل را تغییر دهند، تست‌ها را اجرا کنند، دلیل خطاها را پیدا کنند و نتیجه نهایی را اعتبارسنجی کنند. بااین‌حال، صرفاً دادن دسترسی به Codebase کافی نیست. بدون دستورالعمل‌های شفاف، Context مناسب و ابزارهای کارآمد، حتی یک ایجنت قدرتمند نیز ممکن است زمان و Token زیادی مصرف کند و تغییراتی انجام دهد که با معماری پروژه هماهنگ نیستند.
در این مقاله بررسی می‌کنیم که چگونه می‌توان یک Workflow مؤثرتر برای کار با Coding Agentها ساخت. برای این کار از فایل‌های AGENTS.md، تنظیمات سطح پروژه و سطح ایجنت و ابزارهایی مانند Caveman، RTK و Codebase Memory MCP استفاده می‌کنیم. همچنین می‌بینیم که چگونه می‌توان همین Workflow را در Codex، Claude Code و Hermes Agent اجرا کرد.
هدف ساده است: به‌جای استفاده از هوش مصنوعی صرفاً به‌عنوان یک ابزار پرسش‌وپاسخ، آن را به بخشی قابل‌اعتماد از فرایند توسعه نرم‌افزار تبدیل کنیم.
از ایجنت‌های کدنویسی برای انجام کامل تسک‌ها استفاده کنید، نه صرفاً پاسخ دادن به پرسش‌ها.
به ایجنت اجازه دسترسی به Repository، ترمینال، تست‌ها، مستندات و تاریخچه Version Control را بدهید.
دستورالعمل‌های دائمی پروژه را در فایل‌هایی مانند AGENTS.md، CLAUDE.md یا فایل‌های قوانین اختصاصی هر ایجنت نگهداری کنید.
قوانین مشترک پروژه را از ترجیحات شخصی مربوط به ایجنت جدا کنید.
از Codebase Memory MCP برای درک ساختار Repository بدون اسکن مداوم تمام فایل‌ها استفاده کنید.
از RTK برای کاهش خروجی‌های شلوغ ترمینال، پیش از ورود آن‌ها به Context مدل استفاده کنید.
از Caveman برای حذف توضیحات غیرضروری از پاسخ‌های ایجنت استفاده کنید.
معیارهای پایان تسک را شفاف تعریف کنید: پیاده‌سازی، تست، اعتبارسنجی، مستندسازی و گزارش نهایی.
فایل‌های دستورالعمل را کوتاه و کاربردی نگه دارید. یک بیانیه ۹۰۰ خطی درباره نام‌گذاری متغیرها باعث باهوش‌تر شدن ایجنت نمی‌شود؛ فقط سردرگمی گران‌تری تولید می‌کند.
تمام تغییرات تولیدشده را با تست، Static Analysis، Build و بازبینی انسانی بررسی کنید.
گفت‌وگو با یک LLM زمانی مفید است که به توضیح، مثال یا یک پاسخ سریع نیاز دارید.
برای نمونه ممکن است بپرسید:
چگونه این Exception را برطرف کنم؟
این کلاس چه کاری انجام می‌دهد؟
برای این تابع یک Unit Test بنویس.
آیا این معماری درست است؟
این سؤال‌ها می‌توانند پاسخ‌های مفیدی تولید کنند، اما مدل همچنان بیرون از فرایند واقعی توسعه قرار دارد. مدل معمولاً نمی‌تواند کل Repository را با اطمینان بررسی کند، پیاده‌سازی‌های مرتبط را ببیند، پروژه را اجرا کند، فرضیات خود را اعتبارسنجی کند یا مطمئن شود که کد پیشنهادی واقعاً کامپایل می‌شود.
یک Coding Agent به شکل متفاوتی کار می‌کند.
به‌جای اینکه بپرسید:
How should I fix timeout handling in this API client?
یک تسک کامل به ایجنت بدهید:
Inspect the networking module, identify the current timeout behavior, implement typed timeout errors, update the affected tests, run the networking test suite, and report any remaining risks.
در این حالت، ایجنت کدنویسی می‌تواند یک چرخه کامل را اجرا کند:
دستورالعمل‌های Repository را بخواند.
معماری مرتبط را بررسی کند.
کلاس‌ها و Call Chainهای تحت‌تأثیر را پیدا کند.
یک برنامه کوتاه تهیه کند.
کد را تغییر دهد.
تست‌ها و ابزارهای Static Analysis را اجرا کند.
خطاها را بررسی کند.
پیاده‌سازی را اصلاح کند.
Diff نهایی را بازبینی کند.
تغییرات انجام‌شده را خلاصه کند.
برای مثال، Claude Code برای خواندن Codebase، ویرایش فایل‌ها، اجرای دستورات و ارتباط با ابزارهای توسعه طراحی شده است. بنابراین برخلاف یک رابط گفت‌وگوی ساده، می‌تواند مستقیماً داخل فرایند توسعه فعالیت کند.
تفاوت اصلی ساده است:
یک پاسخ چتی به شما پیشنهاد می‌دهد. یک ایجنت تغییر را انجام می‌دهد و آن را اعتبارسنجی می‌کند.
حتی یک مدل قدرتمند نیز در صورت دریافت Context ضعیف، خروجی ضعیفی تولید می‌کند؛ فقط با اعتمادبه‌نفس بیشتر و واژه‌های گران‌تر.
یک محیط مناسب برای Coding Agent به چهار لایه نیاز دارد:
دستورالعمل‌ها: پروژه چگونه باید تغییر کند؟
شناخت Codebase: Repository چه ساختاری دارد؟
ابزارها: ایجنت چگونه فایل‌ها را می‌خواند، ویرایش می‌کند، Build می‌گیرد و تست اجرا می‌کند؟
اعتبارسنجی: ایجنت چگونه ثابت می‌کند که تسک کامل شده است؟
سه ابزاری که در این مقاله بررسی می‌شوند، بخش‌های مختلفی از این محیط را بهبود می‌دهند:
Caveman: حجم توضیحات ایجنت را کاهش می‌دهد.
RTK: خروجی دستورات ترمینال را فشرده می‌کند.
Codebase Memory MCP: نیاز به جست‌وجو و بررسی تکراری Repository را کاهش می‌دهد.
این ابزارها جایگزین یکدیگر نیستند. یکی پاسخ‌های ایجنت را کوتاه می‌کند، دیگری نویز دستورات ترمینال را کاهش می‌دهد و سومی از کشف مکرر ساختار Codebase جلوگیری می‌کند.
AGENTS.md به‌عنوان قرارداد پروژه استفاده کنیدنام استاندارد این فایل AGENTS.md و به‌صورت جمع است. مگر اینکه ابزار خاصی به‌طور مشخص از AGENT.md پشتیبانی کند، از نام مفرد استفاده نکنید.
Codex پیش از شروع کار، فایل‌های AGENTS.md را به‌صورت خودکار پیدا و بارگذاری می‌کند.
یک فایل AGENTS.md در سطح پروژه باید شامل موارد زیر باشد:
معماری پروژه
مرزهای مهم ماژول‌ها
دستورات Build
دستورات اجرای تست
قواعد کدنویسی
الزامات امنیتی
انتظارات مربوط به مستندسازی
Definition of Done
فایل‌ها یا دایرکتوری‌هایی که نباید تغییر کنند
مراحل ضروری بازبینی
برای مثال:
# AGENTS.md ## Architecture - UI modules depend on domain modules. - Domain modules must not depend on Android APIs. - Data modules implement repository interfaces defined in domain. - Use Kotlin Coroutines and Flow for asynchronous operations. ## Implementation Rules - Keep changes limited to the requested feature. - Do not introduce a new dependency without approval. - Preserve backward compatibility for public APIs. - Add tests for changed behavior. - Do not suppress compiler or lint warnings without documenting the reason. ## Validation Run the following before completing a task: ```bash ./gradlew test ./gradlew lint ./gradlew assembleDebug ``` ## Completion Report Include: - Files changed - Tests added or updated - Commands executed - Remaining risks
Repositoryهای بزرگ می‌توانند داخل هر ماژول، دستورالعمل‌های اختصاصی‌تری داشته باشند:
project/ ├── AGENTS.md ├── app/ ├── core/ └── features/ └── payment/ └── AGENTS.override.md
Codex دستورالعمل‌ها را از ریشه پروژه تا دایرکتوری جاری بارگذاری می‌کند. فایل‌هایی که به دایرکتوری کاری نزدیک‌تر هستند، اولویت بیشتری دارند.
Codex از موارد زیر پشتیبانی می‌کند:
فایل سراسری AGENTS.md
فایل AGENTS.md در سطح Repository
فایل‌های تو‌در‌توی AGENTS.override.md
به این ترتیب، فایل ریشه می‌تواند قوانین عمومی پروژه را تعریف کند و ماژول پرداخت قوانین سخت‌گیرانه‌تری داشته باشد:
# features/payment/AGENTS.override.md - Never log card, token, or payment-response data. - All payment-result states must be represented with typed models. - Run `./gradlew :features:payment:test` after each behavioral change. - Do not modify callback URLs without explicit approval.
قوانین پروژه باید همراه Repository نگهداری شوند. ترجیحات شخصی توسعه‌دهنده باید در تنظیمات محلی ایجنت باقی بمانند.
سطحکاربردنمونه‌هاسطح پروژهمعماری مشترک، دستورات و قوانین کیفیتAGENTS.md، فایل CLAUDE.md پروژه، .claude/rules/سطح ماژولقوانین مربوط به یک Feature یا دایرکتوریفایل‌های تو‌در‌توی AGENTS.md و AGENTS.override.mdسطح ایجنتترجیحات شخصی مربوط به Workflow~/.codex/AGENTS.md و ~/.claude/CLAUDE.mdتنظیمات ابزارMCP Serverها، Hookها، Permissionها و مدل‌هاconfig.toml، settings.json، config.yaml و .mcp.jsonSkillهافرایندهای قابل استفاده مجدد برای تسک‌های مشخصدایرکتوری Skillهای ایجنت
Codex از ساختار زیر پشتیبانی می‌کند:
~/.codex/AGENTS.md ~/.codex/AGENTS.override.md ~/.codex/config.toml project/AGENTS.md project/module/AGENTS.override.md
از فایل سراسری برای ترجیحات شخصی و قابل استفاده در پروژه‌های مختلف استفاده کنید:
# ~/.codex/AGENTS.md - Inspect existing implementations before introducing abstractions. - Prefer small, reviewable changes. - Run targeted tests before the entire test suite. - Do not modify generated files manually. - Keep final reports concise.
اطلاعات خاص هر پروژه باید در فایل AGENTS.md همان Repository قرار بگیرد.
Claude Code از CLAUDE.md برای نگهداری دستورالعمل‌های دائمی استفاده می‌کند.
این ابزار از Scopeهای مختلف پشتیبانی می‌کند:
پروژه
کاربر
سازمان
همچنین می‌توان از .claude/rules/ برای تعریف قوانینی استفاده کرد که فقط به فایل‌ها، زبان‌ها یا بخش‌های مشخصی از پروژه مربوط هستند.
Claude این فایل‌ها را به‌عنوان Context در نظر می‌گیرد، نه یک محدودیت تضمین‌شده. بنابراین برای قوانینی که باید همیشه اجرا یا مسدود شوند، بهتر است از Hookها استفاده کنید.
یک ساختار کاربردی می‌تواند به شکل زیر باشد:
~/.claude/CLAUDE.md project/CLAUDE.md project/.claude/rules/kotlin.md project/.claude/rules/testing.md ~/.claude/settings.json
از CLAUDE.md برای دستورالعمل‌ها و از settings.json برای Permissionها، Hookها، Pluginها و تنظیمات ابزارها استفاده کنید.
Hermes از Workspace Instruction، Skillهای قابل استفاده مجدد، Pluginها، حافظه و فایل تنظیمات کاربر پشتیبانی می‌کند.
Skillها در مسیر زیر نگهداری می‌شوند:
~/.hermes/skills/
این Skillها فقط هنگام نیاز بارگذاری می‌شوند. Hermes از رویکرد Progressive Disclosure استفاده می‌کند؛ یعنی تنها دستورالعمل مرتبط با تسک جاری وارد Context می‌شود.
یک ساختار کاربردی برای Hermes:
project/AGENTS.md ~/.hermes/config.yaml ~/.hermes/skills/ ~/.hermes/plugins/
کاربرد هر بخش:
AGENTS.md برای قوانین Repository
config.yaml برای تنظیمات ایجنت و Pluginها
skills/ برای Workflowهای قابل استفاده مجدد
حافظه Hermes برای نگهداری دانشی که طی Sessionهای مختلف آموخته شده است
Hermes همچنین از Subagentها، حافظه دائمی، Tool Use، چندین Model Provider و ساخت Skill از کارهای قبلی پشتیبانی می‌کند.
Coding Agentها معمولاً بسیار بیشتر از مقدار لازم توضیح می‌دهند.
از آن‌ها می‌خواهید نام یک تابع را تغییر دهند، اما در پاسخ تاریخچه ادبی نام‌گذاری، تأملی درباره Maintainability و سه پاراگراف تبریک به خودشان بابت تغییر دوازده کاراکتر تحویل می‌دهند.
Caveman یک Skill و Plugin است که ایجنت‌های کدنویسی را وادار می‌کند پاسخ‌هایی فشرده و مستقیم ارائه دهند، بدون اینکه کدها، دستورات، مسیر فایل‌ها و پیام‌های خطا حذف شوند.
Caveman از ابزارهای مختلفی پشتیبانی می‌کند، از جمله:
Claude Code
Codex
Hermes Agent
بسیاری از ابزارهای کدنویسی دیگر
Caveman در موارد زیر مفید است:
کوتاه‌تر شدن پاسخ‌های ایجنت
کاهش مصرف Output Token
حذف توضیحات و تعارف‌های غیرضروری
بررسی سریع‌تر روند انجام کار
کوچک‌تر شدن فایل‌های دائمی دستورالعمل و حافظه
باقی ماندن فضای بیشتر در Context Window برای کد واقعی
Caveman فقط نحوه ارتباط ایجنت را فشرده می‌کند. این ابزار توانایی استدلال، شناخت Repository یا کیفیت پیاده‌سازی مدل را افزایش نمی‌دهد.
این تفاوت مهم است. کوتاه‌تر کردن یک پاسخ اشتباه، آن را درست نمی‌کند؛ فقط باعث می‌شود زمان کمتری برای خواندن همان پاسخ اشتباه تلف شود.
برای Claude Code:
claude plugin marketplace add JuliusBrussee/caveman claude plugin install caveman@caveman
برای Codex:
npx skills add JuliusBrussee/caveman -a codex
برای فعال کردن آن در یک Session مربوط به Codex:
/caveman
برای Hermes Agent:
npx -y github:JuliusBrussee/caveman -- --only hermes
نصب Hermes از سیستم Skill بومی آن استفاده می‌کند و Skill هنگام بارگذاری فعال می‌شود.
از Caveman در موارد زیر استفاده کنید:
خلاصه پیاده‌سازی
گزارش روند انجام کار
کامنت‌های Code Review
تولید Commit Message
Debug روزمره
تسک‌های طولانی با گزارش‌های متعدد ایجنت
در شرایط زیر، فشرده‌سازی بیش از حد مناسب نیست:
توضیح معماری
تحلیل Incident
گزارش مشکلات امنیتی
مستندات Migration
بررسی Trade-offهای مهم
هدف این نیست که پاسخ ایجنت مبهم و رمزآلود شود. هدف، حذف توضیحات اضافی است.
بخش بزرگی از Context ایجنت ممکن است توسط خروجی دستورات ترمینال مصرف شود:
هزاران خط مربوط به تست‌های موفق
فهرست‌های بسیار بزرگ دایرکتوری‌ها
خروجی‌های طولانی Git Diff
لاگ‌های تکراری Build
Stack Traceهایی با Frameهای تکراری
پیام‌های پیشرفت Package Manager
خروجی Docker با ستون‌های غیرضروری
RTK دستورات Shell را رهگیری می‌کند و خروجی آن‌ها را پیش از رسیدن به Coding Agent فیلتر می‌کند.
این ابزار می‌تواند:
Directory Treeها را فشرده کند.
نتیجه Searchها را گروه‌بندی کند.
خروجی Git را کاهش دهد.
تست‌های موفق را جمع کند.
جزئیات Failureها را نگه دارد.
برای مثال:
git status
ممکن است به این دستور تبدیل شود:
rtk git status
همچنین اجرای دستور زیر:
./gradlew test
می‌تواند به‌جای ارسال تمام تست‌های موفق به مدل، یک خروجی کوتاه و متمرکز بر Failureها تولید کند.
RTK به ایجنت کمک می‌کند:
Token کمتری برای خواندن خروجی ترمینال مصرف کند.
خطاها را سریع‌تر پیدا کند.
Context Window را با لاگ تست‌های موفق پر نکند.
Sessionهای طولانی را قابل استفاده نگه دارد.
دستورات اعتبارسنجی بیشتری را با بودجه Context یکسان اجرا کند.
درصد کاهش خروجی Shell که RTK گزارش می‌کند، الزاماً برابر با همان درصد کاهش هزینه کل API نیست.
Promptها، تاریخچه Conversation، پاسخ‌های مدل و سایر Tool Resultها نیز Token مصرف می‌کنند. مستندات RTK نیز کاهش خروجی Bash را از کاهش کل هزینه استفاده از مدل جدا می‌کند.
در macOS:
brew install rtk
برای Codex:
rtk init --global --codex
این دستور، راهنمای استفاده از RTK را به فایل سراسری AGENTS.md مربوط به Codex اضافه می‌کند.
Codex برخلاف برخی ایجنت‌های دیگر، Hook شفافی برای بازنویسی خودکار تمام دستورات ندارد. بنابراین این روش به رعایت دستورالعمل‌ها توسط مدل وابسته است.
برای Claude Code:
rtk init --global
Claude Code از Hook مربوط به PreToolUse استفاده می‌کند و می‌تواند دستورات Bash پشتیبانی‌شده را به‌صورت خودکار بازنویسی کند.
ابزارهای داخلی Claude مانند موارد زیر از Hook مربوط به Bash عبور نمی‌کنند:
Read
Grep
Glob
برای Hermes Agent:
rtk init --agent hermes
این دستور یک Plugin برای Hermes در مسیر زیر ایجاد می‌کند:
~/.hermes/plugins/rtk-rewrite/
سپس Plugin از طریق تنظیمات Hermes فعال می‌شود و دستورات پشتیبانی‌شده ترمینال را پیش از اجرا تغییر می‌دهد.
RTK عمداً خروجی‌ها را فیلتر، گروه‌بندی، کوتاه و Deduplicate می‌کند.
در موارد زیر بهتر است RTK را دور بزنید و خروجی خام را بررسی کنید:
Parse کردن JSON خام
مقایسه خروجی در سطح Byte
بررسی مشکلات مربوط به ترتیب داده‌ها
مشاهده Stack Trace کامل
ارسال خروجی به Parser دیگر
بررسی مشکلی که احتمال دارد خود RTK خروجی آن را تغییر داده باشد
بهره‌وری باید نویز را حذف کند، نه شواهد را.
بدون ابزارهای Code Intelligence، یک ایجنت معمولاً Repository را به این شکل بررسی می‌کند:
دایرکتوری‌ها را فهرست می‌کند.
نام یک کلاس را جست‌وجو می‌کند.
چند فایل را باز می‌کند.
محل استفاده از کلاس را جست‌وجو می‌کند.
فایل‌های بیشتری باز می‌کند.
Interfaceها را جست‌وجو می‌کند.
پس از Context Compaction تمام مراحل را دوباره تکرار می‌کند.
در Session بعدی نیز دوباره همین کار را انجام می‌دهد، چون ظاهراً کشف مجدد معماری به یک سنت معتبر مهندسی نرم‌افزار تبدیل شده است.
Codebase Memory MCP یک Repository را Index کرده و آن را به یک Knowledge Graph دائمی تبدیل می‌کند.
این Graph می‌تواند موارد زیر را نمایش دهد:
Functionها
Classها
Call Chainها
Routeها
Dependencyها
ارتباط میان سرویس‌ها
به‌جای بررسی مداوم فایل‌ها به‌صورت جداگانه، ایجنت می‌تواند این ساختار را Query کند.
این ابزار می‌تواند به پرسش‌هایی مانند موارد زیر پاسخ دهد:
چه کلاس‌هایی این تابع را فراخوانی می‌کنند؟
چه کلاس‌هایی این Interface را پیاده‌سازی کرده‌اند؟
تغییر این Method چه بخش‌هایی را تحت‌تأثیر قرار می‌دهد؟
کدام Route به این Service می‌رسد؟
این Data Model در کجا تبدیل می‌شود؟
آیا این Function بدون استفاده است؟
چه ماژول‌هایی به این Component وابسته‌اند؟
چه فایل‌هایی بخشی از این Call Chain هستند؟
این ابزار به‌خصوص در شرایط زیر مفید است:
Repositoryهای Legacy و بزرگ
پروژه‌های چندماژوله Android
Monorepoها
سیستم‌های Microservice
پروژه‌هایی با چند Coding Agent
Refactorهای طولانی
Repositoryهایی با مستندات محدود
این Server از Codex، Claude Code، Hermes و بسیاری از Clientهای دیگر پشتیبانی می‌کند.
Installer آن می‌تواند فایل‌های تنظیمات MCP، دستورالعمل‌ها، Skillها و Lifecycle Hookهای مربوط به ایجنت‌های شناسایی‌شده را پیکربندی کند.
در macOS یا Linux:
curl -fsSL \ https://raw.githubusercontent.com/DeusData/codebase-memory-mcp/main/install.sh \ | bash
پس از نصب، Coding Agent را مجدداً اجرا کنید و از آن بخواهید:
Index this project.
Installer می‌تواند موارد زیر را تنظیم کند:
Codex از طریق config.toml
Claude Code از طریق تنظیمات MCP
Hermes از طریق config.yaml
یک Workflow مناسب برای ایجنت:
Graph را Query کند تا مسیر احتمالی کد مشخص شود.
فایل‌های Source معرفی‌شده توسط Graph را مستقیماً بررسی کند.
ارتباط‌های مهم را با خواندن کد واقعی تأیید کند.
تغییر را انجام دهد.
دوباره Impact تغییر را Query کند.
تست‌ها و Static Analysis را اجرا کند.
نتیجه Graph را حقیقت قطعی در نظر نگیرید.
موارد زیر می‌توانند باعث ایجاد نقص در Index شوند:
کدهای تولیدشده
Syntaxهای پشتیبانی‌نشده
دایرکتوری‌های Ignoreشده
Index قدیمی
رفتارهای Dynamic
این پروژه سطح‌هایی مانند Scout، Verify و Auditor تعریف می‌کند که شواهد Graph را با بررسی مستقیم Source Code و پوشش Index ترکیب می‌کنند.
از Graph برای Navigation و Impact Analysis استفاده کنید. Source Code و تست‌ها باید شواهد نهایی باشند.
فرض کنید تسک زیر را داریم:
Add typed timeout handling to an Android networking module. Preserve the public API, add unit tests, and verify all call sites.
فایل زیر را در ریشه Repository ایجاد کنید:
# AGENTS.md ## Project Context - This is a multi-module Android project. - Networking code is located under `core/networking`. - Repository interfaces belong in domain modules. - Data modules implement domain repository interfaces. - Kotlin is the primary language. - Minimum Android SDK is 21. ## Coding Rules - Preserve source and binary compatibility for public APIs. - Use sealed interfaces for typed networking failures. - Do not expose Ktor-specific exceptions outside the networking module. - Use Coroutines for asynchronous code. - Do not add dependencies without approval. ## Agent Workflow 1. Query Codebase Memory MCP before broad repository searches. 2. Verify graph results by reading the relevant source files. 3. Use RTK for noisy shell commands. 4. Use raw commands when exact output is required. 5. Add or update unit tests for behavioral changes. 6. Review the final Git diff before completion. ## Validation Run: ```bash ./gradlew :core:networking:test ./gradlew lint ./gradlew assembleDebug ``` ## Completion Criteria Report: - Root cause - Files changed - API compatibility - Tests executed - Remaining risks
برای Claude Code می‌توانید همین اطلاعات را از طریق یک فایل کوتاه CLAUDE.md بازاستفاده کنید یا قوانین اختصاصی Claude را در .claude/rules/ قرار دهید.
brew install rtk curl -fsSL \ https://raw.githubusercontent.com/DeusData/codebase-memory-mcp/main/install.sh \ | bash
npx skills add JuliusBrussee/caveman -a codex rtk init --global --codex
Codex را اجرا کنید:
codex
سپس Prompt زیر را وارد کنید:
/caveman Index this project using Codebase Memory MCP. Implement typed timeout handling in core/networking. First identify the public API, implementations, callers, and existing tests. Then provide a short plan. Preserve compatibility, implement the change, add tests, run the required validation commands, inspect the final diff, and report remaining risks. Do not stop after suggesting code.
claude plugin marketplace add JuliusBrussee/caveman claude plugin install caveman@caveman rtk init --global
Claude Code را داخل Repository اجرا کنید:
claude
از همان تسک استفاده کنید:
Use Codebase Memory MCP to map the timeout-related call chain before editing. Implement typed timeout handling in core/networking. Preserve the public API, update unit tests, run the commands from AGENTS.md, review the diff, and finish only when the completion criteria are satisfied.
Claude Code از دستورالعمل‌های پروژه، ابزارهای MCP، دسترسی ترمینال و Hookهای خود استفاده می‌کند.
Caveman پاسخ‌های Claude را کوتاه می‌کند و RTK خروجی دستورات Bash پشتیبانی‌شده را پیش از ورود به Context مدل کاهش می‌دهد.
npx -y github:JuliusBrussee/caveman -- --only hermes rtk init --agent hermes
Hermes را داخل Repository اجرا کنید:
hermes
سپس Prompt زیر را وارد کنید:
Use the repository AGENTS.md as the task contract. Use Codebase Memory MCP to find the timeout implementation, its callers, repository boundaries, and related tests. Implement typed timeout handling without exposing networking-library exceptions. Add tests, execute the validation commands, review the final diff, and provide a concise completion report.
Hermes می‌تواند Caveman را به‌عنوان Skill بارگذاری کند، از Plugin ترمینال RTK استفاده کند، به تنظیمات MCP دسترسی داشته باشد و دانش مفید را از طریق سیستم Skill و حافظه خود نگهداری کند.
یک Prompt ضعیف:
Fix the timeout problem.
یک Prompt بهتر:
Investigate the timeout problem in core/networking. Before editing: - Identify the public API. - Find all implementations and callers. - Find current timeout tests. - Explain the root cause in no more than five lines. Implementation: - Add typed timeout handling. - Preserve API compatibility. - Do not expose Ktor exceptions outside the module. - Add tests for timeout, cancellation, and non-timeout failures. Validation: - Run the networking tests. - Run lint. - Build the debug application. - Review the final Git diff. Finish with: - Files changed - Commands executed - Test results - Compatibility impact - Remaining risks
این Prompt هم خود تسک و هم شواهد موردنیاز برای کامل در نظر گرفتن آن را مشخص می‌کند.
عملکرد یک Coding Agent را فقط بر اساس جذاب یا حرفه‌ای بودن توضیحاتش ارزیابی نکنید.
این موارد را بررسی کنید:
آیا مسیر درست کد را پیدا کرده است؟
آیا معماری پروژه را رعایت کرده است؟
آیا پیاده‌سازی کامپایل می‌شود؟
آیا رفتار تغییرکرده توسط تست‌ها پوشش داده شده است؟
آیا Diff نهایی محدود و متمرکز است؟
آیا تصمیم‌های مهم مستند شده‌اند؟
آیا ایجنت می‌تواند برای نتیجه‌گیری‌های خود مدرک ارائه کند؟
از ابزارها و فایل‌ها به شکل زیر استفاده کنید:
AGENTS.md برای تعریف انتظارات پروژه
فایل‌های سطح ایجنت برای تعریف Workflow شخصی
Skillها برای بسته‌بندی فرایندهای قابل استفاده مجدد
Codebase Memory MCP برای پیمایش ساختار Repository
RTK برای کاهش نویز ترمینال
Caveman برای کاهش نویز پاسخ‌های ایجنت
تست، Build، Lint و بازبینی برای اعتبارسنجی نتیجه
بهترین Workflow برای Coding Agent، یک گفت‌وگوی طولانی‌تر نیست.
بهترین Workflow یک سیستم تکرارپذیر است که در آن ایجنت:
Context مناسب را دریافت می‌کند.
از ابزارهای درست استفاده می‌کند.
تسک را انجام می‌دهد.
نتیجه را اعتبارسنجی می‌کند.
فقط اطلاعات مهم را گزارش می‌دهد.
ایجنت‌های کدنویسی زمانی واقعاً کاربردی می‌شوند که آن‌ها را بخشی از فرایند مهندسی نرم‌افزار بدانیم، نه فقط یک ابزار چت باهوش‌تر.
کار را با یک فایل AGENTS.md شفاف شروع کنید، ابزارهایی را اضافه کنید که پروژه واقعاً به آن‌ها نیاز دارد و مشخص کنید هر تسک چگونه باید اعتبارسنجی شود. فرایند را ساده نگه دارید، نتایج را بررسی کنید و به‌مرور Workflow خود را بهبود دهید.
ممنون که این مقاله را خواندید؛ امیدوارم تجربه بهتر و مؤثرتری از کار با ایجنت‌های کدنویسی داشته باشید.
