Code Review کوپایلت با Agent Skills و MCP؛ راهنمای تنظیم برای تیم ها
GitHub در 29 ژوئیه 2026 پشتیبانی Agent Skills و MCP را برای Copilot Code Review عمومی کرد. این مقاله نشان می دهد چگونه استانداردهای واقعی تیم، مستندات معماری و داده ابزارهای داخلی را وارد بررسی Pull Request کنید، بدون اینکه Code Review را به انبوهی از Commentهای عمومی و کم اعتماد تبدیل کنید.
فهرست مطالب
در یک نگاه
- دسترسی عمومی برای Copilot Pro، Pro+، Business و Enterprise اعلام شده است.
- هر Skill در مسیر .github/skills/<skill-name>/SKILL.md تعریف می شود.
- MCP می تواند Context ابزارهای ثالث را داخل Review بیاورد، اما Tool Callهای Code Review فقط خواندنی اند.
- پیکربندی MCP موجود برای Copilot Cloud Agent به Code Review نیز اعمال می شود.
- GitHub و Playwright MCP به صورت پیش فرض فعال می شوند؛ تنظیمات و Secretها باید آگاهانه بازبینی شوند.
- Attribution مشخص می کند کدام Comment با Skill یا MCP ساخته شده است.
قابلیت جدید دقیقاً چیست؟
Copilot Code Review پیش از این می توانست Diff و Context خود Repository را تحلیل کند، اما بسیاری از قواعد مهم تیم بیرون از کد زندگی می کنند: قراردادهای معماری در Wiki، الزام های امنیتی در Handbook، شناسه سرویس در Catalog، Acceptance Criteria در Issue Tracker و Runbook در سامانه مستندات. عرضه عمومی Agent Skills و MCP این فاصله را کم می کند. Skill به Reviewer هوشمند می گوید «چگونه فکر کن و چه استانداردی را اعمال کن»؛ MCP به آن اجازه می دهد اطلاعات لازم را از ابزارهای متصل بخواند.
این تغییر نباید با جایگزین شدن Reviewer انسانی اشتباه گرفته شود. Copilot هنوز ممکن است Context را ناقص بفهمد، Rule را بیش ازحد سخت تفسیر کند یا مشکل واقعی را نبیند. ارزش قابلیت زمانی ایجاد می شود که تیم قواعد قابل آزمایش، محدود و نسخه بندی شده بسازد و خروجی را در کنار Test، Static Analysis و Review انسانی استفاده کند. هدف خوب، کاهش بازخورد تکراری و رساندن Context درست به Reviewer است؛ هدف بد، تبدیل هر Pull Request به دیوار Commentهای خودکار است.
Agent Skills چگونه استاندارد تیم را وارد Review می کند؟
Agent Skill یک پوشه دارای فایل SKILL.md است که در .github/skills قرار می گیرد. محتوا می تواند هدف Skill، زمان استفاده، قواعد بررسی، مثال مطلوب و مواردی که نباید Flag شوند را توضیح دهد. تفاوت Skill مفید با یک متن کلی در میزان عملیاتی بودن آن است. جمله «کد باید امن باشد» راهنمای قابل استفاده ای نیست؛ اما Rule مشخصی مانند «Endpoint تغییر وضعیت باید Authorization مبتنی بر Resource داشته باشد و فقط Role عمومی کافی نیست» به Reviewer یک معیار روشن می دهد.
Skill باید Scope محدود داشته باشد. برای مثال، یک Skill برای APIهای ASP.NET Core، یک Skill برای Migrationهای دیتابیس و یک Skill برای React Accessibility بسازید. فایل واحد و بسیار بزرگ احتمال تضاد، مصرف Context و بازخورد نامرتبط را بالا می برد. نام پوشه، توضیح و Triggerهای ضمنی باید کمک کنند Agent بفهمد چه زمانی آن Skill کاربرد دارد. همچنین مثال مثبت و منفی قرار دهید تا Rule فقط واژه ها را تطبیق ندهد و Intent را بفهمد.
---
name: aspnet-api-review
description: Review ASP.NET Core API changes for authorization, validation, and error handling.
---
# ASP.NET Core API review
Use this skill when a pull request changes controllers, endpoints, handlers, or authorization policies.
## Check
- Resource-changing endpoints require explicit authorization.
- Request DTOs have validation and meaningful error responses.
- CancellationToken is propagated to I/O operations.
- Sensitive values are not written to logs.
- Database writes are idempotent when retries are possible.
## Avoid
- Do not demand a new abstraction for a one-off mapping.
- Do not flag public health-check endpoints as missing user authorization.
- Do not suggest UTC storage when the repository policy explicitly requires local server time.این نمونه به جای شعار، حوزه فایل ها، کنترل های اصلی و موارد استثنا را مشخص می کند. نکته آخر مهم است: Ruleها باید با Policy واقعی Repository هماهنگ باشند. اگر سازمان شما درباره زمان، Naming، Exception یا Transaction تصمیم مشخصی دارد، Skill همان تصمیم را منعکس کند؛ Copilot نباید از بهترین عمل عمومی اینترنت، استاندارد متناقضی وارد پروژه کند.
MCP چه Contextی به Code Review می دهد؟
Model Context Protocol یا MCP یک روش استاندارد برای اتصال عامل هوش مصنوعی به ابزار و داده خارجی است. در Code Review، کاربرد اصلی آن خواندن Contextی است که داخل Diff وجود ندارد. Reviewer می تواند Acceptance Criteria تیکت، تعریف مالک سرویس، مستند API یا راهنمای Incident را ببیند و Comment را براساس آن بسازد. GitHub اعلام کرده Tool Callهای MCP در این سطح فقط Read-only هستند؛ بنابراین Code Review از طریق MCP قرار نیست Issue را تغییر دهد یا رکوردی را در سامانه ثالث بنویسد.
Read-only بودن ریسک تغییر ناخواسته را کم می کند، اما به معنی بی خطر بودن نیست. ابزار خواندنی ممکن است داده حساس، اطلاعات مشتری، Secret، URL داخلی یا جزئیات Incident را برگرداند. Scope Token باید فقط مجموعه داده لازم را ببیند و MCP Server باید خروجی را محدود، Audit و Redact کند. اتصال یک Search عمومی به کل Wiki سازمان، صرفاً چون امکان پذیر است، طراحی خوبی نیست. Context باید بر اساس Repository، تیم و نوع Pull Request فیلتر شود.
پیکربندی MCP از بخش Repository Settings، مسیر Copilot و MCP servers انجام می شود و Tokenها در Secrets and variables مربوط به Agents قرار می گیرند. GitHub همچنین می گوید پیکربندی هایی که قبلاً برای Copilot Cloud Agent ساخته شده اند، به Code Review نیز اعمال می شوند. این رفتار برای شروع سریع مفید است، اما قبل از فعال سازی عمومی باید فرضیات قبلی را دوباره بررسی کنید؛ Agent ساخت کد و Agent Review ممکن است به Context یکسان نیاز نداشته باشند.
تفاوت Skills، Instructions و MCP
| ابزار | مسئله ای که حل می کند | نمونه | ریسک رایج |
|---|---|---|---|
| Agent Skill | روش تخصصی بررسی و استاندارد قابل تکرار | قواعد Review API، Migration یا Accessibility | بزرگ و مبهم شدن Ruleها |
| Custom Instructions | ترجیحات عمومی پاسخ در سطح کاربر، Repository یا سازمان | لحن، Naming و قراردادهای کلی | اشتباه گرفتن ترجیح با Policy اجباری |
| MCP | خواندن Context از ابزار بیرونی | تیکت، Wiki، Service Catalog و مستند API | دسترسی بیش ازحد و نشت داده |
| Static Analysis | بررسی قطعی Ruleهای قابل کدنویسی | Lint، CodeQL، Analyzer و Test | False Positive یا پوشش محدود |
| Human Review | قضاوت محصولی، معماری و ریسک | Trade-off، سازگاری بیزینس و Ownership | کمبود زمان و ناهماهنگی Reviewerها |
این ابزارها جای یکدیگر را نمی گیرند. Rule قطعی مانند ممنوعیت API مشخص بهتر است در Linter یا Analyzer اجرا شود، چون نتیجه باید تکرارپذیر و قابل Block باشد. Skill برای قواعدی مناسب است که Context و تفسیر می خواهند. MCP فقط داده می آورد و به تنهایی استاندارد Review نیست. Custom Instruction ترجیح عمومی را تنظیم می کند، نه اینکه کنترل امنیتی تضمین شده بسازد. Reviewer انسانی نیز تصمیم نهایی درباره Trade-off و Intent بیزینس را نگه می دارد.
پیاده سازی مرحله به مرحله
- سه نوع Comment تکراری Reviewerهای انسانی را از Pull Requestهای گذشته استخراج کنید.
- هر Rule را به قطعی، تفسیری یا نیازمند Context بیرونی تقسیم کنید.
- Rule قطعی را به Analyzer یا Test منتقل کنید و Rule تفسیری را در Skill محدود بنویسید.
- برای Context بیرونی، کوچک ترین MCP Server و کم دسترسی ترین Token ممکن را انتخاب کنید.
- Skillها را در Branch آزمایشی اضافه و روی Pull Requestهای تاریخی بدون Merge ارزیابی کنید.
- Commentهای درست، اشتباه، تکراری و بی اثر را برچسب بزنید و Rule را اصلاح کنید.
- ابتدا روی چند Repository نماینده Rollout کنید و بعد به سطح سازمان گسترش دهید.
بهترین نقطه شروع، نوشتن استاندارد جدید از صفر نیست. تاریخچه Review تیم نشان می دهد کدام بازخوردها تکرار می شوند و کدام مشکلات واقعاً هزینه ساخته اند. اگر Reviewerها مرتب درباره Propagation کردن CancellationToken، Authorization یا Migration برگشت پذیر Comment می گذارند، این ها نامزد Skill هستند. در مقابل، تصمیم معماری یک بارمصرف یا بحثی که به Context جلسه وابسته است، احتمالاً نباید به Rule دائمی تبدیل شود.
هر Skill را مانند کد Version Control کنید. Pull Request برای تغییر SKILL.md باید Owner مشخص داشته باشد، دلیل تغییر و مثال قبل/بعد ارائه کند. چون Skill رفتار Reviewer را تغییر می دهد، اصلاح آن می تواند روی صدها Pull Request اثر بگذارد. CODEOWNERS برای پوشه .github/skills، Review تیم امنیت یا معماری برای Skillهای حساس و Changelog کوتاه، Governance را قابل ردیابی می کند.
سناریوهای واقعی
سناریو 1: تطبیق Pull Request با Acceptance Criteria
فرض کنید Pull Request یک وضعیت تازه به Workflow سفارش اضافه می کند. Diff نشان می دهد Enum و Handler تغییر کرده اند، اما معلوم نیست Transition جدید در تیکت مجاز بوده یا نه. MCP می تواند تیکت مرتبط را بخواند و Skill Workflow بررسی کند که Transition، Audit Log و حالت Retry مطابق Acceptance Criteria باشند. Comment خوب باید دقیق بگوید کدام شرط تیکت پوشش داده نشده و روی کدام خط اثر دارد؛ Comment بد فقط می گوید «با تیکت تطبیق دهید».
سناریو 2: مالکیت سرویس و قرارداد API
در Monorepo بزرگ، تغییر یک Client ممکن است Contract سرویس دیگری را بشکند. MCP به Service Catalog یا OpenAPI Registry متصل می شود و Owner، نسخه Contract و Deprecation را می خواند. Skill می تواند بخواهد تغییر Breaking بدون نسخه جدید یا Migration Plan Flag شود. این سناریو ارزشمند است چون Context در Repository مصرف کننده کامل نیست، اما باید مراقب باشید Catalog قدیمی یا ناهماهنگ به منبع حقیقت تبدیل نشود.
سناریو 3: بررسی UI و Playwright
Playwright MCP می تواند Context اجرای مرورگر یا تست را در فرایندهای پشتیبانی شده فراهم کند. برای تغییر فرم، Skill Accessibility ممکن است Label، Keyboard Flow و Error State را بررسی کند و Context تست به تشخیص مسیر واقعی کمک کند. بااین حال، Code Review نباید Screenshot یا اجرای محدود را اثبات کامل کیفیت UI بداند. Matrix مرورگر، تست Responsive و بررسی انسانی تجربه هنوز لازم اند.
امنیت، دسترسی و حاکمیت
اولین اصل، Least Privilege است. Token MCP باید فقط Read داشته باشد، فقط پروژه یا فضای مرتبط را ببیند و دوره انقضا و Rotation مشخص داشته باشد. Secret را در SKILL.md، Workflow یا Log قرار ندهید. Server باید Audit کند چه Repository و چه Pull Requestی کدام Tool را فراخوانده است. اگر داده مشتری یا Incident حساس برمی گردد، Redaction و Policy نگه داری داده را قبل از اتصال بررسی کنید.
دومین اصل، جلوگیری از Prompt Injection از Context بیرونی است. متن Issue، Wiki یا مستند می تواند شامل دستور گمراه کننده باشد؛ عمدی یا تصادفی. Skill باید صریح کند داده MCP «اطلاعات» است، نه دستور اولویت دار. MCP Server نیز بهتر است فیلدهای ساختاریافته برگرداند و محتوای آزاد را محدود کند. Reviewer انسانی باید Attribution را ببیند و بداند Comment از کدام منبع آمده است. قابلیت Attribution عمومی شده دقیقاً برای افزایش این شفافیت مفید است.
سومین اصل، تفکیک Preference از Enforcement است. GitHub درباره Custom Instructions سازمانی نیز تأکید می کند که برای شکل دادن پاسخ است، نه اجرای Policy. اگر Rule باید Merge را متوقف کند، آن را با Branch Protection، Required Check، Analyzer یا Test پیاده کنید. Comment هوش مصنوعی می تواند Signal بدهد، اما نباید تنها سد امنیتی Production باشد.
چگونه کیفیت خروجی را بسنجیم؟
| معیار | روش اندازه گیری | نشانه مشکل |
|---|---|---|
| Precision | درصد Commentهای واقعاً درست از کل Commentها | Reviewerها مرتب Dismiss می کنند |
| Recall نمونه ای | اجرای Review روی PRهای تاریخی دارای Bug شناخته شده | مشکل های مهم قبلی دیده نمی شوند |
| Actionability | درصد Commentهایی که محل، دلیل و اصلاح قابل فهم دارند | بازخورد مبهم یا صرفاً نظری |
| Duplication | تعداد Commentهای تکراری با Analyzer یا Reviewer دیگر | شلوغی و کاهش اعتماد |
| Latency | زمان افزوده شده به چرخه Review | کندشدن Merge بدون ارزش متناسب |
| Security | Tool Call، Scope و رخداد دسترسی غیرضروری | Context حساس یا فراخوانی نامرتبط |
یک Pilot دو تا چهار هفته ای روی Repository نماینده، داده بهتری از فعال سازی همزمان در کل سازمان می دهد. Pull Requestهای Backend، Frontend، Migration و Documentation را جدا بسنجید. Commentها را با دسته های صحیح، مفید ولی غیرضروری، اشتباه، تکراری و امنیتی برچسب بزنید. سپس Skill را کوتاه تر، استثناها را روشن تر و اتصال MCP را محدودتر کنید. هدف افزایش تعداد Comment نیست؛ هدف کاهش Defect و زمان بازخورد با حفظ اعتماد تیم است.
محدودیت ها و خطاهای رایج
- Skill بسیار عمومی که برای هر فایل همان Checklist را تکرار می کند.
- قرار دادن Policy قطعی فقط در متن Skill و نداشتن Required Check قابل اعتماد.
- اتصال MCP به کل Wiki یا Issue Tracker با Token گسترده.
- اعتماد به Context قدیمی بدون تاریخ، Version یا Owner.
- تکرار خروجی Linter و CodeQL در Commentهای هوش مصنوعی.
- نداشتن مسیر Feedback برای اصلاح Skill و خاموش کردن اتصال مسئله دار.
- فرض اینکه Read-only بودن Tool Call، نشت اطلاعات را غیرممکن می کند.
همچنین باید هزینه و محدودیت پلن را در نظر بگیرید. قابلیت برای پلن های اعلام شده Copilot در دسترس است، اما مصرف، ظرفیت و Policy سازمانی می تواند تجربه را تغییر دهد. قبل از طراحی فرایند حیاتی، مستندات جاری حساب خود را بررسی کنید. Previewهای قبلی ممکن است تنظیمات متفاوتی داشته باشند؛ GitHub گفته پیکربندی موجود ادامه می یابد، ولی بازبینی آن بعد از GA همچنان اقدام درستی است.
پرسش های متداول
آیا Agent Skills همان Custom Instructions است؟
خیر. Skill یک بسته تخصصی و قابل فراخوانی برای انجام نوع مشخصی از کار است؛ Custom Instructions ترجیحات عمومی تری را روی پاسخ ها اعمال می کند. برای Ruleهای Review حوزه ای، Skill معمولاً ساختار مناسب تری دارد.
آیا MCP در Code Review می تواند داده را تغییر دهد؟
طبق اعلام GitHub، Tool Callهای MCP در Copilot Code Review به Read-only محدود هستند. بااین حال، دسترسی خواندن نیز باید حداقلی باشد چون می تواند داده حساس را وارد Context کند.
Skill را کجا قرار دهیم؟
در یک زیرپوشه اختصاصی زیر .github/skills و با فایل SKILL.md. بهتر است هر Skill هدف محدود، Description روشن، Ruleهای قابل اقدام و استثناهای مشخص داشته باشد.
آیا Reviewer انسانی دیگر لازم نیست؟
هنوز لازم است. Agent برای بازخورد تکراری و Context قابل بازیابی مفید است، اما Intent بیزینس، Trade-off معماری، ریسک انتشار و درستی نهایی به قضاوت انسانی و تست مستقل نیاز دارند.
چطور جلوی Commentهای زیاد را بگیریم؟
Scope Skill را محدود کنید، Rule قطعی را به Analyzer بسپارید، Commentهای تاریخی را ارزیابی کنید و فقط بازخوردی را نگه دارید که دقیق، جدید و قابل اقدام است. تعداد Comment KPI مناسبی برای موفقیت نیست.
جمع بندی
Agent Skills و MCP می توانند Code Review را از تحلیل عمومی Diff به بازبینی متناسب با استاندارد و Context واقعی تیم نزدیک کنند. مسیر درست از چند Rule پرتکرار، یک اتصال خواندنی محدود و Pilot کوچک آغاز می شود. Skillها را مانند کد Version کنید، MCP را با Least Privilege و Audit راه بیندازید، Attribution را در Review بررسی کنید و Ruleهای قطعی را همچنان در Test و Required Check نگه دارید.
