بهترین شیوه‌های Claude Code

Claude Code یک محیطِ کدنویسیِ ایجنتیک است. برخلافِ یک چت‌بات که به سؤال‌ها جواب می‌دهد و منتظر می‌ماند، Claude Code می‌تواند فایل‌هایت را بخواند، دستورها را اجرا کند، تغییر بدهد و به‌صورت خودگردان مسائل را حل کند — در حالی که تو تماشا می‌کنی، مسیر را عوض می‌کنی، یا کلاً کنار می‌روی.

این، شیوه‌ی کارت را عوض می‌کند. به‌جای اینکه خودت کد بنویسی و از Claude بخواهی بازبینی‌اش کند، چیزی را که می‌خواهی توصیف می‌کنی و Claude راهِ ساختنش را پیدا می‌کند. Claude کاوش می‌کند، نقشه می‌کشد و پیاده‌سازی می‌کند.

اما این خودگردانی هنوز منحنیِ یادگیری دارد. Claude درونِ محدودیت‌هایی کار می‌کند که باید بشناسی‌شان.

این راهنما شیوه‌هایی را پوشش می‌دهد که در تیم‌های داخلیِ Anthropic و برای مهندس‌هایی که از Claude Code روی کدبیس‌ها، زبان‌ها و محیط‌های گوناگون استفاده می‌کنند، مؤثر بوده‌اند. برای اینکه ببینی حلقه‌ی ایجنتیک پشتِ پرده چطور کار می‌کند، طرزِ کارِ Claude Code را ببین.

بیشترِ بهترین شیوه‌ها بر یک محدودیت استوارند: پنجره‌ی کانتکستِ Claude سریع پر می‌شود و با پر شدنش کارایی افت می‌کند.

پنجره‌ی کانتکستِ Claude کلِ گفت‌وگویت را نگه می‌دارد؛ شاملِ هر پیام، هر فایلی که Claude می‌خواند و خروجیِ هر دستور. اما این پنجره می‌تواند سریع پر شود. یک نشستِ عیب‌یابی یا یک کاوشِ کدبیس به‌تنهایی ممکن است ده‌ها هزار توکن تولید و مصرف کند.

این موضوع مهم است چون کاراییِ LLM با پر شدنِ کانتکست افت می‌کند. وقتی پنجره‌ی کانتکست دارد پر می‌شود، ممکن است Claude شروع کند به «فراموش کردن» دستورهای قبلی یا اشتباه‌های بیشتری بکند. پنجره‌ی کانتکست مهم‌ترین منبعی است که باید مدیریتش کنی. برای اینکه در عمل ببینی یک نشست چطور پر می‌شود، یک راهنمای تعاملی را تماشا کن که نشان می‌دهد هنگام راه‌اندازی چه چیزهایی بار می‌شوند و خواندنِ هر فایل چقدر هزینه دارد. مصرفِ کانتکست را به‌صورت پیوسته با یک خط وضعیتِ سفارشی رصد کن و برای راهکارهای کاهشِ مصرفِ توکن، کاهش مصرف توکن را ببین.

به Claude راهی بده تا کارش را راستی‌آزمایی کند

Claude وقتی کار «تمام به‌نظر می‌رسد» متوقف می‌شود. بدونِ محکی که بتواند اجرا کند، «تمام به‌نظر می‌رسد» تنها سیگنالِ موجود است و خودِ تو می‌شوی حلقه‌ی راستی‌آزمایی: هر اشتباه منتظر می‌ماند تا تو متوجهش شوی. به Claude چیزی بده که برون‌دادش قبولی یا ردی باشد، آن‌وقت حلقه خودبه‌خود بسته می‌شود. Claude کار را انجام می‌دهد، محک را اجرا می‌کند، نتیجه را می‌خواند و آن‌قدر تکرار می‌کند تا محک پاس شود.

محک هر چیزی است که سیگنالی برگرداند که Claude بتواند درونِ گفت‌وگو بخواندش: یک مجموعه‌ی تست، کدِ خروجیِ یک build، یک linter، اسکریپتی که خروجی را با یک fixture مقایسه می‌کند، یا یک اسکرین‌شاتِ مرورگر که با یک طرح سنجیده می‌شود.

راهکار	قبل	بعد
معیارِ راستی‌آزمایی بده	”implement a function that validates email addresses"	"write a validateEmail function. example test cases: user@example.com is true, invalid is false, user@.com is false. run the tests after implementing”
تغییرهای UI را بصری راستی‌آزمایی کن	”make the dashboard look better"	"[paste screenshot] implement this design. take a screenshot of the result and compare it to the original. list differences and fix them”
به ریشه بپرداز، نه به نشانه	”the build is failing"	"the build fails with this error: [paste error]. fix it and verify the build succeeds. address the root cause, don’t suppress the error”

وقتی محک وجود داشت، تصمیم بگیر که چقدر سفت جلوِ توقف را بگیرد:

در یک پرامپت: از Claude بخواه که در همان پیام محک را اجرا کند و تکرار کند، مثلِ جدولِ بالا.
در طولِ یک نشست: محک را به‌عنوانِ یک شرطِ /goal تنظیم کن. یک ارزیابِ جداگانه بعد از هر نوبت دوباره آن را وارسی می‌کند و Claude تا برقرار شدنش به کار ادامه می‌دهد.
به‌عنوانِ دروازه‌ی قطعی: یک Stop hook محک تو را به‌صورتِ یک اسکریپت اجرا می‌کند و جلوِ پایانِ نوبت را می‌گیرد تا وقتی پاس شود. اگر هوک ۸ بار پشتِ‌سرِ‌هم مسدود کند، Claude Code آن را نادیده می‌گیرد و نوبت را پایان می‌دهد.
با یک نظرِ دوم: یک ساب‌ایجنتِ راستی‌آزمایی یا یک ورک‌فلوی پویا که یافته‌های خودش را وارسی می‌کند، باعث می‌شود مدلی تازه تلاش کند نتیجه را رد کند؛ پس ایجنتی که کار را انجام داده، همان کسی نیست که نمره می‌دهد.

هر گام، راه‌اندازی را با توجه معاوضه می‌کند. نسخه‌ی پرامپتی همین امروز روی هر کاری جواب می‌دهد. نسخه‌های /goal و Stop hook همان چیزهایی‌اند که می‌گذارند یک اجرای بی‌نظارت بدونِ تو درست به پایان برسد.

از Claude بخواه به‌جای ادعای موفقیت، مدرک نشان بدهد: خروجیِ تست، دستوری که اجرا کرده و آنچه برگردانده، یا اسکرین‌شاتی از نتیجه. بازبینیِ مدرک سریع‌تر از این است که خودت دوباره راستی‌آزمایی را اجرا کنی، و برای نشست‌هایی که تماشایشان نمی‌کردی هم جواب می‌دهد.

اول کاوش، بعد نقشه، بعد کد

اگر بگذاری Claude مستقیم بپرد سراغِ کدنویسی، ممکن است کدی تولید کند که مسئله‌ی اشتباه را حل می‌کند. از plan mode استفاده کن تا کاوش را از اجرا جدا کنی.

ورک‌فلوی پیشنهادی چهار مرحله دارد:

کاوش

واردِ plan mode شو. Claude بدونِ هیچ تغییری فایل‌ها را می‌خواند و به سؤال‌ها جواب می‌دهد.

read /src/auth and understand how we handle sessions and login.
also look at how we manage environment variables for secrets.

نقشه

از Claude بخواه یک نقشه‌ی پیاده‌سازیِ دقیق بسازد.

I want to add Google OAuth. What files need to change?
What's the session flow? Create a plan.

Ctrl+G را بزن تا نقشه در ویرایشگرِ متنت باز شود و پیش از ادامه‌ی Claude بتوانی مستقیم ویرایشش کنی.

پیاده‌سازی

از plan mode خارج شو و بگذار Claude کد بزند، در حالی که با نقشه‌اش می‌سنجد.

implement the OAuth flow from your plan. write tests for the
callback handler, run the test suite and fix any failures.

کامیت

از Claude بخواه با پیامی توصیفی کامیت کند و یک PR بسازد.

commit with a descriptive message and open a PR

در پرامپت‌هایت کانتکستِ مشخص بده

Claude می‌تواند نیت را استنباط کند، اما نمی‌تواند ذهنت را بخواند. به فایل‌های مشخص ارجاع بده، محدودیت‌ها را ذکر کن و به الگوهای نمونه اشاره کن.

راهکار	قبل	بعد
کار را دامنه‌بندی کن. مشخص کن کدام فایل، چه سناریویی و ترجیح‌های تست.	”add tests for foo.py"	"write a test for foo.py covering the edge case where the user is logged out. avoid mocks.”
به منابع اشاره کن. Claude را به منبعی هدایت کن که می‌تواند به سؤال جواب بدهد.	”why does ExecutionFactory have such a weird api?"	"look through ExecutionFactory’s git history and summarize how its api came to be”
به الگوهای موجود ارجاع بده. Claude را به الگوهای کدبیست اشاره بده.	”add a calendar widget"	"look at how existing widgets are implemented on the home page to understand the patterns. HotDogWidget.php is a good example. follow the pattern to implement a new calendar widget that lets the user select a month and paginate forwards/backwards to pick a year. build from scratch without libraries other than the ones already used in the codebase.”
نشانه را توصیف کن. نشانه، محلِ احتمالی و شکلِ «درست‌شده» را بده.	”fix the login bug"	"users report that login fails after session timeout. check the auth flow in src/auth/, especially token refresh. write a failing test that reproduces the issue, then fix it”

پرامپت‌های مبهم وقتی به کار می‌آیند که داری کاوش می‌کنی و می‌توانی از پسِ تصحیحِ مسیر برآیی. پرامپتی مثلِ "what would you improve in this file?" می‌تواند چیزهایی را رو کند که اصلاً فکرش را نمی‌کردی بپرسی.

محتوای غنی بده

می‌توانی به چند روش به Claude داده‌ی غنی بدهی:

با @ به فایل‌ها ارجاع بده به‌جای اینکه توصیف کنی کد کجاست. Claude پیش از پاسخ، فایل را می‌خواند.
تصویرها را مستقیم بچسبان. تصویرها را کپی/پیست یا با کشیدن‌ورها کردن داخلِ پرامپت بینداز.
URL بده برای مستندات و مراجعِ API. از /permissions استفاده کن تا دامنه‌های پرکاربرد را در فهرستِ مجاز بگذاری.
داده را pipe کن با اجرای cat error.log | claude تا محتوای فایل را مستقیم بفرستی.
بگذار Claude خودش هرچه لازم دارد بیاورد. به Claude بگو خودش با دستورهای Bash، ابزارهای MCP، یا با خواندنِ فایل‌ها کانتکست را بکشد.

محیطت را پیکربندی کن

چند گامِ راه‌اندازی، Claude Code را در همه‌ی نشست‌هایت به‌مراتب مؤثرتر می‌کند. برای مرورِ کاملِ قابلیت‌های گسترش‌دهنده و اینکه کِی کدام‌یک را به کار ببری، گسترشِ Claude Code را ببین.

یک CLAUDE.md مؤثر بنویس

CLAUDE.md یک فایلِ ویژه است که Claude در آغازِ هر گفت‌وگو می‌خواندش. دستورهای Bash، سبکِ کد و قواعدِ ورک‌فلو را در آن بگذار. این به Claude کانتکستی ماندگار می‌دهد که نمی‌تواند تنها از روی کد استنباطش کند.

دستورِ /init کدبیست را تحلیل می‌کند تا سیستم‌های build، چارچوب‌های تست و الگوهای کد را تشخیص بدهد و پایه‌ی محکمی برای پالایش به تو بدهد.

برای فایل‌های CLAUDE.md قالبِ اجباری‌ای وجود ندارد، اما کوتاه و خوانا نگه‌اش دار. برای نمونه:

# Code style
- Use ES modules (import/export) syntax, not CommonJS (require)
- Destructure imports when possible (eg. import { foo } from 'bar')

# Workflow
- Be sure to typecheck when you're done making a series of code changes
- Prefer running single tests, and not the whole test suite, for performance

CLAUDE.md هر نشست بار می‌شود، پس فقط چیزهایی را بگذار که به‌طورِ گسترده صدق می‌کنند. برای دانشِ تخصصی یا ورک‌فلوهایی که فقط گاهی مرتبط‌اند، به‌جایش از skills استفاده کن. Claude آن‌ها را در صورتِ نیاز بار می‌کند، بدونِ اینکه هر گفت‌وگو را باد کند.

موجز نگه‌اش دار. برای هر خط بپرس: «آیا حذفِ این باعث می‌شود Claude اشتباه کند؟» اگر نه، حذفش کن. فایل‌های بادکرده‌ی CLAUDE.md باعث می‌شوند Claude دستورهای واقعی‌ات را نادیده بگیرد!

✅ بگنجان	❌ کنار بگذار
دستورهای Bash که Claude نمی‌تواند حدس بزند	هر چیزی که Claude با خواندنِ کد می‌تواند بفهمد
قواعدِ سبکِ کد که با پیش‌فرض‌ها فرق دارند	قراردادهای استانداردِ زبان که Claude از قبل می‌داند
دستورهای تست و اجراکننده‌های تستِ ترجیحی	مستنداتِ تفصیلیِ API (به‌جایش به docs لینک بده)
آدابِ مخزن (نام‌گذاریِ شاخه، قراردادهای PR)	اطلاعاتی که زیاد تغییر می‌کنند
تصمیم‌های معماریِ خاصِ پروژه‌ات	توضیح‌های طولانی یا آموزش‌ها
خل‌وضع‌های محیطِ توسعه‌دهنده (متغیرهای محیطیِ لازم)	توصیفِ فایل‌به‌فایلِ کدبیس
دام‌های رایج یا رفتارهای ناآشکار	شیوه‌های بدیهی مثلِ «کدِ تمیز بنویس»

اگر Claude با وجودِ قاعده‌ای که خلافش داری، باز کاری را که نمی‌خواهی تکرار می‌کند، احتمالاً فایل زیادی بلند است و قاعده گم می‌شود. اگر Claude سؤال‌هایی می‌پرسد که جوابشان در CLAUDE.md هست، شاید جمله‌بندی مبهم است. با CLAUDE.md مثلِ کد رفتار کن: وقتی چیزی خراب شد بازبینی‌اش کن، مرتب هرسش کن و تغییرها را با مشاهده‌ی اینکه آیا رفتارِ Claude واقعاً عوض می‌شود بسنج.

می‌توانی با افزودنِ تأکید (مثلِ “IMPORTANT” یا “YOU MUST”) دستورها را تنظیم کنی تا بهتر رعایت شوند. CLAUDE.md را در git ثبت کن تا تیمت بتواند مشارکت کند. ارزشِ این فایل در طولِ زمان روی‌هم انباشته می‌شود.

فایل‌های CLAUDE.md می‌توانند فایل‌های دیگری را با نحوِ @path/to/import وارد کنند:

See @README.md for project overview and @package.json for available npm commands.

# Additional Instructions
- Git workflow: @docs/git-instructions.md
- Personal overrides: @~/.claude/my-project-instructions.md

می‌توانی فایل‌های CLAUDE.md را در چند مکان بگذاری:

پوشه‌ی خانه (~/.claude/CLAUDE.md): روی همه‌ی نشست‌های Claude اعمال می‌شود
ریشه‌ی پروژه (./CLAUDE.md): در git ثبت کن تا با تیمت به اشتراک بگذاری
ریشه‌ی پروژه (./CLAUDE.local.md): یادداشت‌های شخصیِ خاصِ پروژه؛ این فایل را به .gitignore اضافه کن تا با تیمت به اشتراک گذاشته نشود
دایرکتوری‌های والد: برای monorepoها مفید است، جایی که هم root/CLAUDE.md و هم root/foo/CLAUDE.md به‌صورت خودکار کشیده می‌شوند
دایرکتوری‌های فرزند: Claude فایل‌های CLAUDE.mdِ فرزند را وقتی فایلی را در آن دایرکتوری‌ها می‌خواند، در صورتِ نیاز می‌کشد

دسترسی‌ها را پیکربندی کن

به‌صورتِ پیش‌فرض، Claude Code برای کارهایی که ممکن است سیستمت را تغییر دهند مجوز می‌خواهد: نوشتنِ فایل، دستورهای Bash، ابزارهای MCP و غیره. این امن است اما خسته‌کننده. بعد از دهمین تأیید، دیگر واقعاً بازبینی نمی‌کنی، فقط داری کلیک می‌کنی. سه راه برای کاهشِ این مزاحمت‌ها هست:

Auto mode: یک مدلِ طبقه‌بندِ جداگانه دستورها را بازبینی می‌کند و فقط چیزی را که پرخطر به‌نظر می‌رسد مسدود می‌کند: تشدیدِ دامنه، زیرساختِ ناشناخته، یا اقدام‌هایی که محتوای خصمانه راهبری‌شان می‌کند. بهترین حالت وقتی است که به جهتِ کلیِ یک کار اعتماد داری اما نمی‌خواهی هر گام را کلیک کنی
فهرست‌های مجازِ دسترسی: ابزارهای مشخصی را که می‌دانی امن‌اند مجاز کن، مثلِ npm run lint یا git commit
Sandboxing: جداسازیِ سطحِ سیستم‌عامل را فعال کن که دسترسی به فایل‌سیستم و شبکه را محدود می‌کند و به Claude اجازه می‌دهد درونِ مرزهای تعریف‌شده آزادتر کار کند

درباره‌ی حالت‌های دسترسی، قواعدِ دسترسی و sandboxing بیشتر بخوان.

از ابزارهای CLI استفاده کن

ابزارهای CLI کانتکست-کارآمدترین راه برای تعامل با سرویس‌های بیرونی‌اند. اگر از GitHub استفاده می‌کنی، CLIِ gh را نصب کن. Claude بلد است چطور از آن برای ساختنِ issue، باز کردنِ pull request و خواندنِ کامنت‌ها استفاده کند. بدونِ gh، Claude هنوز می‌تواند از API گیت‌هاب استفاده کند، اما درخواست‌های احرازنشده اغلب به محدودیتِ نرخ می‌خورند.

Claude در یاد گرفتنِ ابزارهای CLI‌ای که از قبل نمی‌شناسد هم کارآمد است. پرامپت‌هایی مثلِ این را امتحان کن: Use 'foo-cli-tool --help' to learn about foo tool, then use it to solve A, B, C.

سرورهای MCP را وصل کن

با سرورهای MCP می‌توانی از Claude بخواهی قابلیت‌ها را از issue trackerها پیاده کند، پایگاه‌داده‌ها را پرس‌وجو کند، داده‌های پایش را تحلیل کند، طرح‌ها را از Figma یکپارچه کند و ورک‌فلوها را خودکار کند.

هوک‌ها را راه‌اندازی کن

Hooks اسکریپت‌ها را به‌صورت خودکار در نقاطِ مشخصی از ورک‌فلوی Claude اجرا می‌کنند. برخلافِ دستورهای CLAUDE.md که توصیه‌ای‌اند، هوک‌ها قطعی‌اند و تضمین می‌کنند که کار رخ می‌دهد.

Claude می‌تواند برایت هوک بنویسد. پرامپت‌هایی مثلِ این را امتحان کن: “Write a hook that runs eslint after every file edit” یا “Write a hook that blocks writes to the migrations folder.” برای پیکربندیِ دستیِ هوک‌ها مستقیم .claude/settings.json را ویرایش کن، و برای مرورِ آنچه پیکربندی شده /hooks را اجرا کن.

Skills بساز

Skills دانشِ Claude را با اطلاعاتِ خاصِ پروژه، تیم یا حوزه‌ات گسترش می‌دهند. Claude هنگامِ مرتبط بودن خودکار به کارشان می‌برد، یا می‌توانی با /skill-name مستقیم فراخوانی‌شان کنی.

یک skill بساز با افزودنِ یک دایرکتوری همراهِ یک SKILL.md به .claude/skills/:

---
name: api-conventions
description: REST API design conventions for our services
---
# API Conventions
- Use kebab-case for URL paths
- Use camelCase for JSON properties
- Always include pagination for list endpoints
- Version APIs in the URL path (/v1/, /v2/)

Skills می‌توانند ورک‌فلوهای تکرارپذیری را هم تعریف کنند که مستقیم فراخوانی‌شان می‌کنی:

---
name: fix-issue
description: Fix a GitHub issue
disable-model-invocation: true
---
Analyze and fix the GitHub issue: $ARGUMENTS.

1. Use `gh issue view` to get the issue details
2. Understand the problem described in the issue
3. Search the codebase for relevant files
4. Implement the necessary changes to fix the issue
5. Write and run tests to verify the fix
6. Ensure code passes linting and type checking
7. Create a descriptive commit message
8. Push and create a PR

برای فراخوانی‌اش /fix-issue 1234 را اجرا کن. برای ورک‌فلوهایی که اثرِ جانبی دارند و می‌خواهی دستی راه‌اندازی‌شان کنی از disable-model-invocation: true استفاده کن.

ساب‌ایجنت‌های سفارشی بساز

Subagents در کانتکستِ خودشان و با مجموعه‌ی ابزارهای مجازِ خودشان اجرا می‌شوند. برای کارهایی مفیدند که فایل‌های زیادی می‌خوانند یا به تمرکزِ تخصصی نیاز دارند، بدونِ اینکه گفت‌وگوی اصلی‌ات را شلوغ کنند.

---
name: security-reviewer
description: Reviews code for security vulnerabilities
tools: Read, Grep, Glob, Bash
model: opus
---
You are a senior security engineer. Review code for:
- Injection vulnerabilities (SQL, XSS, command injection)
- Authentication and authorization flaws
- Secrets or credentials in code
- Insecure data handling

Provide specific line references and suggested fixes.

به Claude صریح بگو از ساب‌ایجنت‌ها استفاده کند: “Use a subagent to review this code for security issues.”

پلاگین نصب کن

Plugins skillها، هوک‌ها، ساب‌ایجنت‌ها و سرورهای MCP را در یک واحدِ نصب‌شدنیِ واحد از سوی جامعه و Anthropic بسته‌بندی می‌کنند. اگر با یک زبانِ تایپ‌دار کار می‌کنی، یک پلاگینِ هوشمندیِ کد نصب کن تا به Claude پیمایشِ دقیقِ نمادها و تشخیصِ خودکارِ خطا پس از ویرایش‌ها را بدهی.

برای راهنماییِ انتخاب بینِ skillها، ساب‌ایجنت‌ها، هوک‌ها و MCP، گسترشِ Claude Code را ببین.

مؤثر ارتباط بگیر

شیوه‌ی ارتباطت با Claude Code تأثیرِ چشمگیری بر کیفیتِ نتیجه‌ها دارد.

درباره‌ی کدبیس سؤال بپرس

هنگامِ آشنایی با یک کدبیسِ تازه، از Claude Code برای یادگیری و کاوش استفاده کن. می‌توانی همان نوع سؤال‌هایی را که از مهندسِ دیگری می‌پرسیدی از Claude بپرسی:

لاگ‌گیری چطور کار می‌کند؟
چطور یک اندپوینتِ API تازه بسازم؟
async move { ... } در خطِ ۱۳۴ـِ foo.rs چه کار می‌کند؟
CustomerOnboardingFlowImpl چه edge caseهایی را هندل می‌کند؟
چرا این کد در خطِ ۳۳۳ به‌جای bar() تابعِ foo() را صدا می‌زند؟

استفاده از Claude Code به این شکل یک ورک‌فلوی آشناسازیِ مؤثر است که زمانِ به‌سرعت‌رسیدن را بهتر می‌کند و بارِ روی دوشِ مهندس‌های دیگر را کم می‌کند. هیچ پرامپتِ ویژه‌ای لازم نیست: مستقیم سؤال بپرس.

بگذار Claude از تو مصاحبه بگیرد

Claude درباره‌ی چیزهایی می‌پرسد که شاید هنوز به‌شان فکر نکرده‌ای؛ از جمله پیاده‌سازیِ فنی، UI/UX، edge caseها و معاوضه‌ها.

I want to build [brief description]. Interview me in detail using the AskUserQuestion tool.

Ask about technical implementation, UI/UX, edge cases, concerns, and tradeoffs. Don't ask obvious questions, dig into the hard parts I might not have considered.

Keep interviewing until we've covered everything, then write a complete spec to SPEC.md.

وقتی spec کامل شد، یک نشستِ تازه شروع کن تا اجرایش کنی. نشستِ جدید کانتکستی تمیز دارد که کاملاً روی پیاده‌سازی متمرکز است، و تو هم یک specِ نوشته‌شده برای مراجعه داری.

مفیدترین specها خودبسنده‌اند: فایل‌ها و رابط‌های درگیر را نام می‌برند، می‌گویند چه چیزی خارج از دامنه است، و با یک گامِ راستی‌آزماییِ سرتاسری که اثبات می‌کند قابلیت کار می‌کند تمام می‌شوند. زمانی که صرفِ دقیق کردنِ spec می‌کنی بیشتر از زمانی که صرفِ تماشای پیاده‌سازی می‌کنی جواب می‌دهد.

نشستت را مدیریت کن

گفت‌وگوها ماندگار و بازگشت‌پذیرند. از این به نفعِ خودت استفاده کن!

زود و مکرر مسیر را اصلاح کن

بهترین نتیجه‌ها از حلقه‌های بازخوردِ تنگ می‌آیند. هرچند Claude گاهی مسائل را در همان تلاشِ اول کامل حل می‌کند، تصحیحِ سریعش معمولاً راه‌حل‌های بهتری را سریع‌تر تولید می‌کند.

Esc: با کلیدِ Esc وسطِ کار Claude را متوقف کن. کانتکست حفظ می‌شود، پس می‌توانی مسیر را عوض کنی.
Esc + Esc یا /rewind: دو بار Esc بزن یا /rewind را اجرا کن تا منوی بازگشت باز شود و حالتِ قبلیِ گفت‌وگو و کد را بازگردانی، یا از یک پیامِ انتخاب‌شده خلاصه‌سازی کنی.
"Undo that": از Claude بخواه تغییرهایش را برگرداند.
/clear: کانتکست را بینِ کارهای نامرتبط ریست کن. نشست‌های طولانی با کانتکستِ نامربوط می‌توانند کارایی را کم کنند.

اگر در یک نشست بیش از دو بار Claude را روی یک مسئله‌ی واحد اصلاح کرده‌ای، کانتکست با رویکردهای شکست‌خورده شلوغ شده. /clear را اجرا کن و با پرامپتی مشخص‌تر که آنچه را آموخته‌ای در خود دارد از نو شروع کن. یک نشستِ تمیز با پرامپتی بهتر تقریباً همیشه از یک نشستِ طولانی با تصحیح‌های انباشته بهتر عمل می‌کند.

کانتکست را جسورانه مدیریت کن

Claude Code وقتی به مرزهای کانتکست نزدیک می‌شوی به‌صورتِ خودکار تاریخچه‌ی گفت‌وگو را فشرده می‌کند، که کد و تصمیم‌های مهم را حفظ می‌کند و در عینِ حال جا باز می‌کند.

در طولِ نشست‌های بلند، پنجره‌ی کانتکستِ Claude ممکن است با گفت‌وگوی نامربوط، محتوای فایل‌ها و دستورها پر شود. این می‌تواند کارایی را کم کند و گاهی حواسِ Claude را پرت کند.

بینِ کارها مرتب از /clear استفاده کن تا پنجره‌ی کانتکست کاملاً ریست شود
وقتی فشرده‌سازیِ خودکار راه می‌افتد، Claude مهم‌ترین چیزها را خلاصه می‌کند، از جمله الگوهای کد، حالتِ فایل‌ها و تصمیم‌های کلیدی
برای کنترلِ بیشتر، /compact <instructions> را اجرا کن، مثلِ /compact Focus on the API changes
برای فشرده‌سازیِ تنها بخشی از گفت‌وگو، از Esc + Esc یا /rewind استفاده کن، یک پیامِ checkpoint را انتخاب کن و Summarize from here یا Summarize up to here را برگزین. اولی پیام‌ها را از آن نقطه به بعد فشرده می‌کند و کانتکستِ پیشین را دست‌نخورده نگه می‌دارد؛ دومی پیام‌های پیشین را فشرده می‌کند و تازه‌ها را کامل نگه می‌دارد. بازگردانی در برابر خلاصه‌سازی را ببین.
رفتارِ فشرده‌سازی را در CLAUDE.md با دستورهایی مثلِ "When compacting, always preserve the full list of modified files and any test commands" سفارشی کن تا مطمئن شوی کانتکستِ حیاتی از خلاصه‌سازی جانِ سالم به‌در می‌برد
برای سؤال‌های سریعی که لازم نیست در کانتکست بمانند، از /btw استفاده کن. جواب در یک overlayِ قابلِ‌بستن ظاهر می‌شود و هرگز واردِ تاریخچه‌ی گفت‌وگو نمی‌شود، پس می‌توانی جزئیاتی را وارسی کنی بدونِ اینکه کانتکست رشد کند.

برای بررسی از ساب‌ایجنت‌ها استفاده کن

چون کانتکست محدودیتِ بنیادی‌ات است، ساب‌ایجنت‌ها یکی از قدرتمندترین ابزارهای موجودند. وقتی Claude یک کدبیس را بررسی می‌کند فایل‌های زیادی می‌خواند که همه‌شان کانتکستت را مصرف می‌کنند. ساب‌ایجنت‌ها در پنجره‌های کانتکستِ جداگانه اجرا می‌شوند و خلاصه‌ها را گزارش می‌کنند:

Use subagents to investigate how our authentication system handles token
refresh, and whether we have any existing OAuth utilities I should reuse.

ساب‌ایجنت کدبیس را کاوش می‌کند، فایل‌های مرتبط را می‌خواند و با یافته‌ها برمی‌گردد، همه بدونِ شلوغ کردنِ گفت‌وگوی اصلی‌ات.

می‌توانی پس از اینکه Claude چیزی را پیاده کرد هم از ساب‌ایجنت‌ها برای راستی‌آزمایی استفاده کنی:

use a subagent to review this code for edge cases

با checkpointها به عقب برگرد

Claude پیش از هر تغییر به‌صورتِ خودکار از فایل‌ها snapshot می‌گیرد تا یک checkpoint بتواند بازشان گرداند. دو بار Escape بزن یا /rewind را اجرا کن تا منوی بازگشت باز شود. می‌توانی فقط گفت‌وگو را بازگردانی، فقط کد را، هر دو را، یا از یک پیامِ انتخاب‌شده خلاصه‌سازی کنی. برای جزئیات Checkpointing را ببین.

به‌جای اینکه دقیق برای هر حرکت نقشه بکشی، می‌توانی به Claude بگویی چیزی پرریسک را امتحان کند. اگر جواب نداد، به عقب برگرد و رویکردِ دیگری را امتحان کن. checkpointها بینِ نشست‌ها باقی می‌مانند، پس می‌توانی ترمینالت را ببندی و بعداً همچنان به عقب برگردی.

گفت‌وگوها را ازسرگیری کن

Claude Code گفت‌وگوها را محلی ذخیره می‌کند، پس وقتی یک کار چند نشست طول می‌کشد لازم نیست کانتکست را دوباره توضیح بدهی. claude --continue را اجرا کن تا تازه‌ترین نشست را از سر بگیری، یا claude --resume تا از یک فهرست انتخاب کنی. به نشست‌ها نام‌های توصیفی مثلِ oauth-migration بده تا بعداً پیدایشان کنی. برای مجموعه‌ی کاملِ کنترل‌های ازسرگیری، شاخه‌بندی و نام‌گذاری مدیریت نشست‌ها را ببین.

خودکار کن و مقیاس بده

وقتی با یک Claude کارآمد شدی، با نشست‌های موازی، حالتِ غیرتعاملی و الگوهای fan-out خروجی‌ات را چند برابر کن.

تا اینجا همه‌چیز یک انسان، یک Claude و یک گفت‌وگو را فرض می‌کرد. اما Claude Code افقی مقیاس می‌گیرد. تکنیک‌های این بخش نشان می‌دهند چطور می‌توانی کارِ بیشتری انجام بدهی.

حالتِ غیرتعاملی را اجرا کن

با claude -p "your prompt" می‌توانی Claude را غیرتعاملی، بدونِ نشست، اجرا کنی. حالتِ غیرتعاملی راهی است که Claude را در خط‌لوله‌های CI، هوک‌های pre-commit یا هر ورک‌فلوی خودکار یکپارچه می‌کنی. قالب‌های خروجی می‌گذارند نتیجه‌ها را برنامه‌ای تجزیه کنی: متنِ ساده، JSON، یا JSONِ استریم‌شونده.

# One-off queries
claude -p "Explain what this project does"

# Structured output for scripts
claude -p "List all API endpoints" --output-format json

# Streaming for real-time processing
claude -p "Analyze this log file" --output-format stream-json --verbose

چند نشستِ Claude را اجرا کن

رویکردِ موازی‌ای را برگزین که با میزانِ هماهنگی‌ای که می‌خواهی خودت انجام بدهی جور است:

Worktrees: نشست‌های CLIِ جداگانه را در checkoutهای جداگانه‌ی git اجرا کن تا ویرایش‌ها به هم نخورند
اپلیکیشنِ دسکتاپ: چند نشستِ محلی را به‌صورت بصری مدیریت کن، هرکدام در worktreeِ خودش
Claude Code روی وب: نشست‌ها را روی زیرساختِ ابریِ مدیریت‌شده‌ی Anthropic در VMهای جداگانه اجرا کن
Agent teams: هماهنگیِ خودکارِ چند نشست با کارهای مشترک، پیام‌رسانی و یک سرپرستِ تیم

فراتر از موازی کردنِ کار، چند نشست ورک‌فلوهای کیفیت‌محور را هم ممکن می‌کنند. یک کانتکستِ تازه بازبینیِ کد را بهتر می‌کند، چون Claude به سمتِ کدی که تازه نوشته جانب‌داری نخواهد کرد.

برای نمونه، از یک الگوی نویسنده/بازبین استفاده کن:

نشستِ A (نویسنده)	نشستِ B (بازبین)
`Implement a rate limiter for our API endpoints`
	`Review the rate limiter implementation in @src/middleware/rateLimiter.ts. Look for edge cases, race conditions, and consistency with our existing middleware patterns.`
`Here's the review feedback: [Session B output]. Address these issues.`

می‌توانی کارِ مشابهی با تست‌ها بکنی: بگذار یک Claude تست بنویسد، بعد دیگری کدی بنویسد که از آن‌ها پاس شود.

روی فایل‌ها fan-out کن

برای مهاجرت‌ها یا تحلیل‌های بزرگ، می‌توانی کار را روی فراخوانی‌های موازیِ متعددِ Claude توزیع کنی:

یک فهرستِ کار بساز

بگذار Claude همه‌ی فایل‌هایی را که باید مهاجرت کنند فهرست کند (مثلاً list all 2,000 Python files that need migrating)

اسکریپتی بنویس که در فهرست حلقه بزند

for file in $(cat files.txt); do
  claude -p "Migrate $file from React to Vue. Return OK or FAIL." \
    --allowedTools "Edit,Bash(git commit *)"
done

روی چند فایل تست کن، بعد در مقیاس اجرا کن

پرامپتت را بر پایه‌ی آنچه با ۲ تا ۳ فایلِ اول اشتباه پیش می‌رود پالایش کن، بعد روی کلِ مجموعه اجرا کن. پرچمِ --allowedTools آنچه را Claude می‌تواند انجام دهد محدود می‌کند، که وقتی بی‌نظارت اجرا می‌کنی مهم است.

می‌توانی Claude را در خط‌لوله‌های موجودِ داده/پردازش هم یکپارچه کنی:

claude -p "<your prompt>" --output-format json | your_command

هنگامِ توسعه برای عیب‌یابی از --verbose استفاده کن، و در محیطِ تولید خاموشش کن.

با auto mode خودگردان اجرا کن

برای اجرای بی‌وقفه با وارسی‌های ایمنیِ پس‌زمینه، از auto mode استفاده کن. یک مدلِ طبقه‌بند پیش از اجرای دستورها بازبینی‌شان می‌کند و تشدیدِ دامنه، زیرساختِ ناشناخته و اقدام‌هایی را که محتوای خصمانه راهبری‌شان می‌کند مسدود می‌کند، در حالی که می‌گذارد کارِ روزمره بدونِ پرامپت پیش برود.

claude --permission-mode auto -p "fix all lint errors"

برای اجراهای غیرتعاملی با پرچمِ -p، اگر طبقه‌بند پشتِ‌سرِ‌هم اقدام‌ها را مسدود کند auto mode متوقف می‌شود، چون کاربری نیست که بشود به آن رجوع کرد. برای آستانه‌ها کِی auto mode عقب‌نشینی می‌کند را ببین.

یک گامِ بازبینیِ خصمانه اضافه کن

هرچه Claude بیشتر بی‌نظارت کار کند، یک وارسیِ مستقل پیش از اینکه کار را تمام‌شده بشماری مهم‌تر می‌شود. یک بازبین که در کانتکستِ یک ساب‌ایجنتِ تازه اجرا می‌شود فقط diff و معیارهایی را که به آن می‌دهی می‌بیند، نه استدلالی را که تغییر را تولید کرده، پس نتیجه را با ملاکِ خودش ارزیابی می‌کند.

برای یک وارسیِ درستی، skillِ بسته‌بندی‌شده‌ی /code-review را اجرا کن، که diffِ فعلی را برای باگ‌ها در یک ساب‌ایجنتِ تازه بازبینی می‌کند و یافته‌ها را به نشست برمی‌گرداند. برای اینکه به‌جایش diff را با نقشه‌ات بسنجی، پرامپتِ بازبینی را خودت بنویس. کاری که باید وارسی شود، نقشه‌ای که باید با آن سنجیده شود و آنچه به‌حساب یک یافته می‌آید را نام ببر:

Use a subagent to review the rate limiter diff against PLAN.md. Check that
every requirement is implemented, the listed edge cases have tests, and
nothing outside the task's scope changed. Report gaps, not style preferences.

چون بازبین به‌عنوانِ یک ساب‌ایجنت اجرا می‌شود، نشستِ پیاده‌ساز کاستی‌ها را مستقیم دریافت می‌کند و می‌تواند بدونِ اینکه تو یافته‌ها را بینِ پنجره‌ها کپی کنی رفعشان کند و دوباره بازبینی کند. برای اجراهای خودگردانِ بلندتر، یک agent team می‌تواند این حلقه را در طولِ کارهای متعدد ادامه بدهد، در حالی که تو یافته‌های ثبت‌شده را به‌صورتِ نمونه‌ای وارسی می‌کنی.

از الگوهای رایجِ شکست پرهیز کن

این‌ها اشتباه‌های رایج‌اند. زود شناختنشان وقت می‌خرد:

نشستِ همه‌چیز-با-هم. با یک کار شروع می‌کنی، بعد چیزی نامرتبط از Claude می‌پرسی، بعد به کارِ اول برمی‌گردی. کانتکست پر از اطلاعاتِ نامربوط است.

چاره: بینِ کارهای نامرتبط /clear بزن.
تصحیحِ پشتِ‌سرِ‌هم. Claude کاری را اشتباه انجام می‌دهد، اصلاحش می‌کنی، باز اشتباه است، باز اصلاح می‌کنی. کانتکست با رویکردهای شکست‌خورده آلوده می‌شود.

چاره: بعد از دو تصحیحِ ناموفق، /clear بزن و یک پرامپتِ اولیه‌ی بهتر بنویس که آنچه را آموخته‌ای در خود دارد.
CLAUDE.mdِ بیش‌از‌حد-مشخص. اگر CLAUDE.mdت زیادی بلند باشد، Claude نیمی از آن را نادیده می‌گیرد چون قواعدِ مهم در سروصدا گم می‌شوند.

چاره: بی‌رحمانه هرس کن. اگر Claude کاری را بدونِ دستور هم درست انجام می‌دهد، حذفش کن یا به یک هوک تبدیلش کن.
شکافِ اعتماد-بعد-راستی‌آزمایی. Claude پیاده‌سازی‌ای محتمل‌به‌نظر تولید می‌کند که edge caseها را هندل نمی‌کند.

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

چاره: بررسی‌ها را تنگ دامنه‌بندی کن یا از ساب‌ایجنت‌ها استفاده کن تا کاوش کانتکستِ اصلی‌ات را مصرف نکند.

شهودت را پرورش بده

الگوهای این راهنما سنگ‌نوشته نیستند. نقطه‌های شروعی‌اند که به‌طورِ کلی خوب کار می‌کنند، اما شاید برای هر موقعیت بهینه نباشند.

گاهی باید بگذاری کانتکست انباشته شود چون عمیقاً درگیرِ یک مسئله‌ی پیچیده‌ای و تاریخچه ارزشمند است. گاهی باید نقشه‌کشی را رد کنی و بگذاری Claude خودش حلش کند چون کار اکتشافی است. گاهی یک پرامپتِ مبهم دقیقاً درست است چون می‌خواهی ببینی Claude پیش از اینکه محدودش کنی مسئله را چطور تفسیر می‌کند.

به آنچه جواب می‌دهد توجه کن. وقتی Claude خروجیِ عالی تولید می‌کند، دقت کن چه کردی: ساختارِ پرامپت، کانتکستی که دادی، حالتی که در آن بودی. وقتی Claude به مشکل می‌خورد، بپرس چرا. آیا کانتکست زیادی پرسروصدا بود؟ پرامپت زیادی مبهم؟ کار زیادی بزرگ برای یک پاس؟

با گذرِ زمان، شهودی پیدا می‌کنی که هیچ راهنمایی نمی‌تواند ثبتش کند. خواهی دانست کِی مشخص باشی و کِی پایان‌باز، کِی نقشه بکشی و کِی کاوش کنی، کِی کانتکست را پاک کنی و کِی بگذاری انباشته شود.

منابعِ مرتبط

طرزِ کارِ Claude Code: حلقه‌ی ایجنتیک، ابزارها و مدیریتِ کانتکست
گسترشِ Claude Code: skillها، هوک‌ها، MCP، ساب‌ایجنت‌ها و پلاگین‌ها
ورک‌فلوهای رایج: دستورالعمل‌های گام‌به‌گام برای عیب‌یابی، تست، PR و بیشتر
CLAUDE.md: قراردادهای پروژه و کانتکستِ ماندگار را ذخیره کن