Cursor ऑटोमेशन्स: हमेशा-चालू कोडिंग एजेंट्स के लिए हैंड्स-ऑन गाइड

सॉफ्टवेयर डेवलपमेंट में असली बाधा अब कोड लिखना नहीं रह गई है, क्योंकि किसी भी आकार की टीम में लगभग हर डेवलपर के पास अब कम से कम एक एजेंट होता है जो शिप करने में मदद करता है। कोडिंग एजेंट्स अब रोज़मर्रा के वर्कफ़्लो में शामिल हैं, और इम्प्लीमेंटेशन अब सिस्टम का सबसे धीमा हिस्सा नहीं है।

Cursor Automations इसी गैप को भरने के लिए बनी है। किसी एजेंट को बार-बार प्रॉम्प्ट करने के बजाय, आप तय करते हैं कि उसे कब ऐक्शन लेना चाहिए। एक ट्रिगर फायर होता है, निर्देश बताते हैं कि क्या करना है, और यह स्वतः चलता है। एक पुल रिक्वेस्ट खुलता है, और उसका रिव्यू हो जाता है। Slack में बग रिपोर्ट आती है, और उसका हैंडल हो जाता है। एक शेड्यूल चलता है, और एक रिपोर्ट जेनरेट हो जाती है।

इस ट्यूटोरियल में, मैं आपको Cursor ऑटोमेशन्स को एंड-टू-एंड सेट अप करना सिखाऊंगा। आप दो ऑटोमेशन्स बनाएंगे—एक PR रिव्यू और एक शेड्यूल्ड टेस्ट कवरेज मॉनिटर। इसी दौरान, मैं समझाऊंगा कि निर्देशों को कैसे स्ट्रक्चर करें और टूल्स व MCP को कैसे कनेक्ट करें ताकि ऑटोमेशन्स अपेक्षित व्यवहार करें।

शुरू करने से पहले एक बात। Automations अभी विकासाधीन है, और cursor.com/automations पर डैशबोर्ड विकसित हो रहा है। जब तक आप इसे पढ़ें, अगर किसी मेनू लेबल या बटन में बदलाव हो जाए, तो भी आधारभूत लॉजिक मेल खाएगा।

Cursor Automations क्या हैं?

Cursor automations एक सिस्टम है जो आपके डेवलपमेंट टूल्स की घटनाओं या आपके द्वारा परिभाषित शेड्यूल पर ट्रिगर होकर Cursor के क्लाउड एजेंट्स को स्वचालित रूप से चलाता है।

Cursor के Agent मोड में, जैसा कि हमारे Software Development with Cursor कोर्स में कवर किया गया है, आप हर सत्र की शुरुआत एक चैट खोलकर और प्रॉम्प्ट टाइप करके करते हैं, और एजेंट उतनी देर आपकी लोकल मशीन पर चलता है जितनी देर आप उसके साथ बने रहते हैं।

ऑटोमेशन्स में, शुरुआती संकेत आपके स्टैक में कहीं और से आता है, और एजेंट एक क्लाउड सैंडबॉक्स में बिना आपकी मॉनिटरिंग के अपना काम करता है।

ऑटोमेशन्स में ट्रिगर इवेंट्स शामिल हैं जिनका मैंने नीचे तालिका में सारांश दिया है, लेकिन आप वेबहुक्स का उपयोग करके कस्टम ट्रिगर्स भी सेट कर सकते हैं। एक ऑटोमेशन में एक से अधिक ट्रिगर हो सकते हैं और इनमें से कोई भी फायर होने पर यह चलता है।

इनमें से हर ट्रिगर प्रकार आपके दिन का वह पल बदल देता है जब अन्यथा आपको कुछ नोटिस करना पड़ता, Cursor Agent मोड में कॉन्टेक्स्ट-स्विच करना पड़ता, और मदद मांगनी पड़ती। 

पुल रिक्वेस्ट ट्रिगर वह है जिसे आप सबसे पहले बनाने की सबसे ज्यादा संभावना रखते हैं। यहां एक एकल PR का लाइफसाइकल ऑटोमेशन जोड़ने से पहले और बाद में कैसा दिखेगा:

उस दूसरे कॉलम में बदलता यह है कि किसी एकल कदम की स्पीड नहीं, बल्कि यह तथ्य कि अब आपका ध्यान पूरे प्रोसेस का रेट लिमिटर नहीं रहा।

अंदरखाते Cursor Automations कैसे काम करता है

हर ऑटोमेशन अंदरखाते एक ही पाइपलाइन का पालन करता है। जब आपका परिभाषित ट्रिगर फायर होता है, Cursor एक नया क्लाउड सैंडबॉक्स स्पिन-अप करता है, उसमें आपकी रिपॉजिटरी क्लोन करता है, और एक एजेंट लॉन्च करता है जो कॉन्फ़िगर किए गए टूल्स, MCP कनेक्शन्स और मॉडल का उपयोग करते हुए आपके निर्देशों का पालन करता है। वह रिपॉजिटरी GitHub पर होना अनिवार्य नहीं है: Cursor Origin, जो Cursor का अपना Git फोर्ज है, पर होस्टेड रिपॉजिटरी भी क्लाउड एजेंट्स और ऑटोमेशन्स के साथ काम करती हैं।

एजेंट खत्म करने से पहले अपने आउटपुट को वेरिफाई करता है, फिर जहां आपने कॉन्फ़िगर किया है वहां परिणाम पोस्ट करता है—चाहे वह PR कमेंट हो, Slack संदेश हो, Linear टिकट हो, या एक नई पुल रिक्वेस्ट खोलना हो।

दो गुण हर ऑटोमेशन का स्वरूप निर्धारित करते हैं:

• सैंडबॉक्स पूरी तरह Cursor के क्लाउड में चलता है, आपकी लैपटॉप पर नहीं। यह तब भी चलता रहता है जब आपकी मशीन ऑफ होती है।
• हर रन आइसोलेशन में एग्जीक्यूट होता है। कई ऑटोमेशन्स एक-दूसरे में दखल दिए बिना समानांतर चल सकते हैं। Cursor ने यह भी कहा है कि वह आंतरिक रूप से प्रति घंटा सैकड़ों ऑटोमेशन्स चलाता है।

एक मेमोरी टूल भी है, जैसा कि नीचे दिए प्रीव्यू में दिखाया गया है, जो आपके ऑटोमेशन को रन के बीच स्टेट को पर्सिस्ट करने देता है—यह आगे चलकर शेड्यूल्ड कवरेज मॉनिटर बनाते समय महत्वपूर्ण हो जाता है।

जब आप शेड्यूल्ड कवरेज मॉनिटर बनाएंगे, तब मैं इस पर वापस आऊंगा।

Cursor Automations बनाम Agent मोड

यदि आप पहले से Cursor का नियमित उपयोग करते हैं, तो मुख्य प्रश्न यह है कि Agent मोड के बजाय ऑटोमेशन्स कब उपयोग करें। मैं एक-बारगी कार्यों के लिए Automations का उपयोग नहीं करूंगा। ये ऐसे काम के लिए बने हैं जो दोहराते हैं या बाहरी इवेंट्स पर निर्भर होते हैं।

जब विकल्प स्पष्ट न हो, तो उनके अंतर की तुलना उपयोगी लगती है:

मैं इसे ऐसे सोचता हूं: मान लें कोई कार्य “जब भी” या “हर बार” से शुरू होता है, तो वह Automations में होना चाहिए।

उदाहरण के लिए: “हर बार जब कोई PR खुलता है, या जब भी #support में बग रिपोर्ट आती है, तो एक Linear टिकट बनाएं।” ट्रिगर आवर्ती और पूर्वानुमेय है।

अगर यह “अभी मुझे इस मॉड्यूल को रिफैक्टर करना है” से शुरू होता है, तो वह Agent मोड में होना चाहिए। “अभी” कब है, यह आप तय करते हैं।

यदि आप ऑटोमेशन्स में उतरने से पहले Cursor को एक्सप्लोर करना चाहते हैं, तो हमारा Cursor 2.0 कंप्लीट गाइड आपको Agents इंटरफ़ेस, Composer, और एक पूर्ण Python प्रोजेक्ट के साथ मल्टी-एजेंट वर्कफ़्लो से होकर ले जाता है।

Automations डैशबोर्ड तक पहुँच

Cursor ऑटोमेशन्स डैशबोर्ड यहां रहता है cursor.com/automations। अपने Cursor अकाउंट से साइन इन करें, और आप नीचे दिखाए अनुसार मुख्य डैशबोर्ड पर पहुंचेंगे:

आइए डैशबोर्ड पर जो दिखता है, उसे समझते हैं।

ऊपर के समरी टाइल्स या स्टेटस संकेतक

ये टाइल्स आपके द्वारा चलाए गए सब कुछ का हेल्थ स्नैपशॉट देती हैं। इनमें शामिल हैं:

• कुल ऑटोमेशन्स (आपने कितने कॉन्फ़िगर किए हैं) 
• सफल (पूरे हुए रन, सफलता दर के साथ)
• विफल (ऐसे रन जिनमें एरर आया)
• रन हिस्ट्री (क्लिक करने पर, समय के साथ आपके रन वॉल्यूम का व्यू दिखाती है)

प्रॉम्प्ट इनपुट बॉक्स

इनपुट फ़ील्ड बिना पूरा सेटअप फ़ॉर्म खोले नई ऑटोमेशन बनाने का सबसे तेज़ तरीका है। हम कार्य का वर्णन करते हैं, और Cursor ऑटोमेशन की संरचना जेनरेट कर देता है।

यदि आप अभी शुरुआत कर रहे हैं, तो मैं सुझाव दूंगा कि यहीं से शुरू करें। तय करें कि आप क्या ऑटोमेट करना चाहते हैं, फिर एजेंट के लिए एक संरचित निर्देशों का सेट लिखें जो हर बार ट्रिगर फायर होने पर फॉलो हो। 

जैसे ही आप एरो बटन दबाते हैं, Cursor उन्हीं निर्देशों का उपयोग करके आपके लिए ऑटोमेशन जेनरेट करता है, और नाम, ट्रिगर्स, और आवश्यक टूल्स प्री-फिल कर देता है।

मैं इन निर्देशों को सामान्य प्रॉम्प्ट की तरह नहीं, बल्कि एक स्पेक की तरह ट्रीट करूंगा जिसे एजेंट हर बार चलाता है। जब मैं आपको आगे आपका पहला ऑटोमेशन बनाना दिखाऊंगा, तो इस पर वापस आऊंगा।

Mine / Team टॉगल और + नया ऑटोमेशन बटन

यह टॉगल आपकी ऑटोमेशन्स और टीम ऑटोमेशन्स के बीच फ़िल्टर करता है। 

यह + New बटन एक नया ऑटोमेशन कॉन्फ़िगर करने के लिए कॉन्फ़िग्रेशन पेज खोलता है:

यह + New Automation बटन इनलाइन प्रॉम्प्ट बॉक्स का लंबा-फॉर्म विकल्प है, यदि आप ट्रिगर, निर्देश, और टूल कनेक्शन्स को मैन्युअली शुरू से कॉन्फ़िगर करना चाहते हैं।

आपकी मौजूदा ऑटोमेशन्स की सूची

यह तालिका उन सभी ऑटोमेशन्स को दिखाती है जो हमने बनाई हैं, जिनमें उपयोग किए गए टूल्स और रन हिस्ट्री शामिल हैं।

किसी भी पर क्लिक करने से उसकी सेटिंग्स पेज और रन हिस्ट्री खुल जाती है:

सुझाए गए टेम्पलेट्स सेक्शन

पिछली ऑटोमेशन्स की सूची के नीचे टेम्पलेट कार्ड्स की एक ग्रिड है। टेम्पलेट्स पहले से बने ऑटोमेशन्स देते हैं जिन्हें आप स्क्रैच से शुरू करने की बजाय मॉडिफाई कर सकते हैं।

Cursor ऑटोमेशन टेम्पलेट्स पहले दिन ऑटोमेशन स्पिन-अप करने का सबसे तेज़ तरीका हैं। यदि आप अपना पहला ऑटोमेशन बना रहे हैं, तो मैं सुझाव देता हूँ कि देखें क्या कोई टेम्पलेट आपके ऑटोमेशन से मेल खाता है और वहीं से शुरू करें।

टेम्पलेट्स आपको यह राय दे सकते हैं कि अच्छे निर्देश कैसे दिखते हैं, कौन-से टूल या MCP कनेक्शन्स चाहिए।

अकाउंट और लागत संबंधी विचार

Cursor ऑटोमेशन्स, Cursor के क्लाउड इन्फ्रास्ट्रक्चर पर चलते हैं, जिनके लिए क्लाउड एजेंट एक्सेस चाहिए, जो पेड प्लान्स में शामिल होता है। हर रन मॉडल उपयोग और एग्जीक्यूशन टाइम के आधार पर क्रेडिट्स खर्च करता है।

ऑटोमेशन्स अपने permissions मॉडल के अनुसार तीन विजिबिलिटी टियर सपोर्ट करती हैं:

• Private: केवल आप देख सकते हैं, और बिलिंग आपके अकाउंट पर होती है।
• Team Visible: अन्य लोग आपकी ऑटोमेशन्स और रन हिस्ट्री देख सकते हैं, लेकिन बिलिंग अब भी आप पर होती है।
• Team Owned. ऑटोमेशन टीम के साझा पूल से बिल करता है और टीम एडमिन्स द्वारा मैनेज किया जाता है।

सही टियर चुनना मायने रखता है क्योंकि यह तय करता है कि हर रन में ऑटोमेशन किसके क्रेडिट्स का उपयोग करेगा। आउटपुट पर भरोसा बनने तक प्रयोगों को प्राइवेट रखें। एक बार ऑटोमेशन आपकी टीम के वर्कफ़्लो का हिस्सा बन जाए, तो इसे टीम-ओन्ड टियर में मूव कर सकते हैं।

मुख्य फेल्योर मोड है किसी ऑटोमेशन को बहुत व्यापक दायरे में बहुत जल्दी चलने देना। यदि यह किसी व्यस्त रिपो में हर पुश पर ट्रिगर होता है, तो यह बिना आपके जाने जल्दी उपयोग बढ़ा सकता है। संकरा शुरू करें, कुछ दिन चलने दें, देखें यह कितनी बार फायर होता है, फिर तय करें कि विस्तार करना है या स्केल।

अपना पहला Cursor ऑटोमेशन बनाना: स्वचालित PR कोड रिव्यू

PR कोड रिव्यू सही पहला ऑटोमेशन है क्योंकि फीडबैक लूप छोटा है और एक खराब रन के परिणाम कम हैं। यदि एजेंट कोई उपयोगी कमेंट पोस्ट करता है, तो हम उसे तुरंत PR पर देखते हैं। अगर वह गलत बेस पर कुछ पोस्ट करता है, तो हम उसे अनदेखा करते हैं, और कुछ शिप नहीं होता।

मैं आपको पांच चरणों में आपका पहला ऑटोमेशन बनाना सिखाऊंगा:

1. अपनी GitHub रिपॉजिटरी कनेक्ट करना
2. GitHub ट्रिगर्स सेट करना
3. एजेंट निर्देश लिखना (साफ स्ट्रक्चर और क्या न करें सहित)
4. GitHub Pull Request कमेंट टूल जोड़ना
5. ऑटोमेशन को डिप्लॉय करना

चरण 1: अपनी GitHub रिपॉजिटरी कनेक्ट करना

एजेंट को पुल रिक्वेस्ट का रिव्यू करने से पहले रिपॉजिटरी की एक्सेस चाहिए। Cursor आपकी रिपॉजिटरी तक एक नेटिव GitHub App इंटेग्रेशन के जरिए पहुँचता है। इस कनेक्शन के बिना, ऑटोमेशन एजेंट आपका कोड नहीं देख सकता, PR डिफ नहीं पढ़ सकता, या फीडबैक के साथ जवाब नहीं दे सकता, तो कुछ खास काम नहीं होगा।

यदि आपने अभी तक यह नहीं किया है:

1. Cursor GitHub App इंस्टॉल करें अपने GitHub अकाउंट या ऑर्गेनाइज़ेशन पर और उसे उन रिपॉजिटरीज़ तक एक्सेस दें जिन्हें आप ऑटोमेशन्स से वॉच कराना चाहते हैं।
2. अपने GitHub अकाउंट को डैशबोर्ड में Integrations टैब के तहत कनेक्ट करें। 

जैसे ही आपका कनेक्शन सक्रिय होगा, आपकी रिपॉजिटरीज़ ऑटोमेशन ट्रिगर कॉन्फ़िगर करते समय उपलब्ध होंगी।

चरण 2: अपने ट्रिगर्स सेट करना

ऑटोमेशन्स डैशबोर्ड से:

1. एक ऑटोमेशन बनाना शुरू करने के लिए + New Automation पर क्लिक करें।
2. ऑटोमेशन का नाम रखें। आप इसे PR Code Review – Open & Push – Comment Only नाम दे सकते हैं
3. ट्रिगर्स सेक्शन के तहत, Add trigger पर क्लिक करें और GitHub चुनें। PR opened और PR pushed दोनों को ट्रिगर इवेंट्स के रूप में चुनें।
4. टारगेट रिपॉजिटरी चुनें।

यदि आपने चरण 1 छोड़ दिया था या यह पहली बार है जब आप GitHub को Cursor ऑटोमेशन्स से कनेक्ट कर रहे हैं, तो आपको ऑथेंटिकेट करने का संकेत मिलेगा। 

नीचे दिए प्रीव्यू में, मैं दिखाता हूँ कि ऑथराइज़ेशन पूर्ण होने पर इसे कैसे कॉन्फ़िगर करें और टारगेट रिपॉजिटरी कैसे चुनें:

नोट: जब निर्देश इस पर निर्भर नहीं करते कि कौन-सा इवेंट फायर हुआ, तब हम एक ही ऑटोमेशन में कई ट्रिगर इवेंट्स बंडल कर सकते हैं। लेकिन यदि रिव्यू की गहराई या उद्देश्य इवेंट के आधार पर बदलता है, तो हम अलग-अलग ऑटोमेशन्स बनाते हैं।

अब ऑटोमेशन जानता है कि कब चलना है। अगला कदम है यह बताना कि क्या करना है।

चरण 3: प्रभावी ऑटोमेशन निर्देश लिखना

निर्देश ही सबसे बड़ा लीवर हैं जो तय करते हैं कि हमारा ऑटोमेशन उपयोगी आउटपुट देगा या नहीं। एजेंट इन्हीं से सीखता है कि “अच्छा” कैसा दिखता है। अस्पष्ट निर्देश असंगत परिणाम देते हैं।

निर्देश लिखने से पहले, हमें समझना होगा कि हम क्या परिभाषित कर रहे हैं। हम एक-बारगी प्रॉम्प्ट नहीं दे रहे। हम एक व्यवहार सेट कर रहे हैं जिसे एजेंट हर बार ट्रिगर फायर होने पर फॉलो करेगा। ऑटोमेशन की गुणवत्ता इस पर निर्भर है कि हमने उस व्यवहार को कितनी स्पष्टता से बताया।

यहां वह संरचना है जो मैं सुझाऊंगा:

• भूमिका तय करें: यह परिप्रेक्ष्य और टोन सेट करता है। उदाहरण: “आप पुल रिक्वेस्ट्स के लिए सिक्योरिटी रिव्यूअर हैं।”
• लक्ष्य तय करें: सफलता कैसी दिखती है, स्पष्ट रहें। उदाहरण: “वास्तविक कमजोरियों का पता लगाएं और स्पष्ट रूप से समझाएं।”
• स्कोप तय करें: स्पष्ट करें कि एजेंट को किस पर फोकस करना है। उदाहरण: “केवल जोड़ा गया या संशोधित कोड रिव्यू करें।”
• वर्कफ़्लो रेखांकित करें: कार्य को एप्रोच करने का स्पष्ट तरीका दें। उदाहरण: “परिवर्तनों का निरीक्षण करें, इनपुट्स ट्रेस करें, और प्रोटेक्शन्स वेरिफाई करें।”
• बहिष्करण सेट करें: शोर कम करने के लिए स्पष्ट रूप से बताएं कि क्या अनदेखा करना है।
• व्यवहार और आउटपुट तय करें. यह कैसे कार्य करे और परिणाम कैसे दिखें।
• सीमाएँ तय करें: यह क्या कभी न करे।

ऑटोमेशन निर्देश वैसे ही लिखें जैसे आप रनबुक लिखते हैं—विशिष्ट, क्रमबद्ध, स्पष्ट एक्सेप्टेंस क्राइटेरिया और स्पष्ट सीमाओं के साथ।

अच्छे निर्देश का उदाहरण

यहां वह निर्देश है जिसका मैंने इस PR कोड रिव्यू ऑटोमेशन के लिए उपयोग किया। आप इसे अपने निर्देश इनपुट बॉक्स में कॉपी कर सकते हैं, लेकिन अपने उपयोग मामले के अनुसार संशोधित करें:

You are a code reviewer for pull requests triggered on PR open and push. Focus on identifying real issues that could introduce bugs, security vulnerabilities, or maintainability problems if merged. Review only added or modified code, and use surrounding context only when required to validate impact.

Check for:
- Logic errors such as incorrect conditions, edge cases, null handling, or wrong return values
- Security issues including injection, XSS, auth flaws, unsafe deserialization, or hardcoded secrets
- Contract changes such as modified APIs, response shapes, or schemas without corresponding updates
- Missing error handling or tests introduced by the change

Ignore style, formatting, naming preferences, and any pre-existing issues not introduced by this PR. Report only concrete findings with evidence from the diff, and post inline comments directly on changed lines. If no issues are found, respond: “Automated review complete: no issues found in this diff.” Do not approve, merge, push, or open PRs.

यहाँ निर्देश निर्देश इनपुट बॉक्स में है:

यह प्रॉम्प्ट सरल बनाया गया है, लेकिन फिर भी एक स्पष्ट और विशिष्ट संरचना का पालन करता है। 

खराब निर्देश का उदाहरण

ऐसे अस्पष्ट निर्देशों से बचें:

Review this PR and give feedback on any issues you notice.

बिना संरचना, बाध्यताओं, और प्राथमिकताओं के, एजेंट को “issues” का अर्थ अनुमान लगाना पड़ेगा, जिससे सामान्य, सतही फीडबैक मिलेगा, न कि भरोसेमंद आउटपुट।

चरण 4: टूल्स जोड़ना

ऑटोमेशन एडिटर के अंदर टूल्स पैनल खोलें। इस ऑटोमेशन के लिए, हम GitHub सेक्शन में जाएंगे और Comment on Pull Request टूल चुनेंगे। हम सुनिश्चित करते हैं कि PR अप्रूवल डिसेबल्ड हो, जैसा कि नीचे दिए प्रीव्यू में है, ताकि ऑटोमेशन केवल कमेंट कर सके, बदलाव अप्रूव न कर सके।

Comment on Pull Request टूल एजेंट को निष्कर्ष वापस PR पर पोस्ट करने देता है। इसके लिए अलग कनेक्शन की आवश्यकता नहीं है क्योंकि यह उसी Cursor GitHub App द्वारा संचालित है जिसे आपने चरण 1 में अधिकृत किया था।

यदि हम आउटपुट को अन्य सेवाओं पर भेजना चाहते (जैसे Slack पर पोस्ट करना), तो हम संबंधित टूल चुनते या एक MCP कनेक्शन जोड़ते। इस ऑटोमेशन के लिए कमेंट टूल पर्याप्त है।

चरण 5: अपना पहला रन डिप्लॉय और मॉनिटर करना

जैसे ही ट्रिगर्स, निर्देश, और टूल्स सेट हो जाएं, हम Create पर क्लिक करके ऑटोमेशन सेव करते हैं, जो ऑटोमेशन का सेटिंग्स पेज खोलता है, जैसा आप नीचे देख सकते हैं:

चूंकि हमने ऑटोमेशन डिप्लॉय कर दिया है, हमें एक रन ट्रिगर करना है और देखना है कि एजेंट क्या आउटपुट देता है।

अपनी कनेक्टेड रिपॉजिटरी में एक ड्राफ्ट पुल रिक्वेस्ट खोलें। इससे PR opened ट्रिगर फायर होगा, और कुछ ही सेकंड में रन हिस्ट्री में एक नई एंट्री दिखनी चाहिए, जैसा आप नीचे देख सकते हैं:

उस रन को खोलें और तीन चीजें जांचें:

• एग्जीक्यूशन टाइम: रन में कितना समय लगा। यह डिफ आकार, मॉडल्स, और निर्देशों की जटिलता के आधार पर बदलता है।
• टूल कॉल्स: कौन-सी फाइलें और टूल्स उपयोग हुए? यदि एजेंट असंबंधित फाइलें पढ़ता है, तो अपने निर्देशों की समीक्षा करें।
• आउटपुट: GitHub पर क्या पोस्ट हुआ। इसे अपने निर्देशों के खिलाफ तुलना करें।

नीचे मेरे ऑटोमेशन के रन का ओवरव्यू है। आप देख सकते हैं कि यह छह मिनट चला, कुछ कार्रवाइयाँ कीं, और PostReviewCommentOnPr टूल का उपयोग करके PR रिव्यू पोस्ट किया:

नीचे, वह उदाहरण कमेंट है जो एजेंट ने मेरे PR पर पोस्ट किया:

कभी-कभी आउटपुट गलत हो सकता है, और जब ऐसा होता है, तो आम तौर पर समस्या निर्देशों में होती है। हम उस निर्देश को समायोजित करते हैं जो बदले हुए व्यवहार को नियंत्रित करता है, एक नया कमिट पुश करते हैं ताकि अगला रन ट्रिगर हो, और परिणाम की समीक्षा करते हैं।

इन शुरुआती रनों के लिए, हमें कम जोखिम बनाए रखने हेतु सरल शुरुआत करनी चाहिए। इस मामले में, हम ऑटोमेशन को केवल कमेंट्स तक सीमित रखते हैं, जो हमें इसके व्यवहार को सुरक्षित रूप से कन्फर्म करने देता है। एक बार आउटपुट सुसंगत हो जाए, तो हम इसे वास्तविक उपयोग में ले जाते हैं और फिर GitHub से परे अन्य टूल्स कनेक्ट करते हैं ताकि यह और कार्य कर सके।

MCP के साथ और टूल्स कनेक्ट करना

जो PR रिव्यू ऑटोमेशन हमने अभी बनाया, वह GitHub पर चलता है। यह डिफ पढ़ता है और GitHub Comment on Pull Request टूल का उपयोग करते हुए पुल रिक्वेस्ट पर कमेंट्स पोस्ट करता है। लेकिन यदि हम चाहते हैं कि एजेंट कोड रिव्यू से अधिक कार्य करे, तो हमें अन्य टूल्स कनेक्ट करने होंगे। इसके लिए ही Model Context Protocol (MCP) है।

MCP एक मानक इंटरफ़ेस है जो एजेंट्स को बिना कस्टम इंटीग्रेशन्स के बाहरी टूल्स का उपयोग करने देता है। इसके बिना, हर टूल के लिए अपना अलग सेटअप और मेंटेनेंस चाहिए होता। 

MCP के साथ, जैसे ही हम ऑटोमेशन के टूल्स पैनल में किसी समर्थित टूल को कनेक्ट करते हैं, एजेंट उसे उसी इंटरफ़ेस के जरिए उपयोग कर सकता है।

MCP एक ही ऑटोमेशन को और अधिक करने देता है और अन्य टूल्स में ऐक्शन लेने देता है। आपका PR रिव्यू ऑटोमेशन पहले से GitHub पर कमेंट करता है। Slack जोड़ें, और यह किसी चैनल पर अपडेट्स पोस्ट कर सकता है। Linear जोड़ें, और यह टिकट बना सकता है। Datadog जोड़ें, और यह लॉग्स खींच सकता है। हर कनेक्शन ऑटोमेशन की क्षमताओं का विस्तार करता है बिना उसकी कोर लॉजिक बदले।

Cursor ऑटोमेशन्स में इन-बिल्ट MCP इंटीग्रेशन्स का सेट शामिल है, जैसे Slack, Linear, ClickUp, Datadog, Notion, और भी बहुत कुछ। क्योंकि MCP एक ओपन स्टैंडर्ड है, हम किसी भी कम्पैटिबल टूल को उसी तरह कनेक्ट कर सकते हैं।

आपको MCP, ऑटोमेशन सेटिंग्स पेज पर Tools -> MCP server के तहत मिलेगा। + New Connection बटन पर क्लिक करके ब्राउज़ करें, फिर आवश्यक टूल इंस्टॉल और कनेक्ट करें।

उन्हें जोड़ने का एक प्रीव्यू यहां है:

अगले सेक्शन में, मैं आपको PR कोड रिव्यू ऑटोमेशन में Slack MCP कनेक्शन जोड़ना सिखाऊंगा।

Slack MCP कनेक्शन जोड़ना

GitHub हमारे ऑटोमेशन को हमारा कोड पढ़ने और उस पर कमेंट करने देता है। Slack इसे टीम से बात करने देता है।

Tools पैनल से, Add Tool या MCP पर क्लिक करें, MCP Server चुनें, फिर +New Connection चुनें। जो पैनल खुले उसमें Slack सर्च करें और Slack MCP सर्वर चुनें। 

Slack पहले से इंस्टॉल आता है, लेकिन यदि नहीं, तो इसे इंस्टॉल करें और अपने वर्कस्पेस को ऑथराइज़ करने के लिए OAuth फ्लो का पालन करें। कनेक्ट हो जाने पर, यह आपके टूल्स पैनल में दिखाई देगा, जैसा कि नीचे ओवरव्यू में दिखाता हूं:

कनेक्शन सेटअप के दौरान हम टारगेट चैनल नहीं चुनते। MCP ऑटोमेशन एजेंट को वर्कस्पेस-लेवल पर सभी पब्लिक चैनल्स की एक्सेस देता है। ठीक कहां पोस्ट करना है, यह हम निर्देशों में चैनल का नाम लेकर नियंत्रित करते हैं, जैसे, "यदि कोई critical इश्यू मिले तो #pr-alerts पर Slack संदेश भेजें।"

नोट: Slack MCP केवल पब्लिक चैनल्स के साथ काम करता है, और टारगेट चैनल में ऑटोमेशन के पोस्ट करने से पहले Cursor बॉट को इनवाइट करना होगा। OAuth फ्लो के बाद, आपके Slack वर्कस्पेस में Cursor बॉट दिखना चाहिए। चैनल पर जाएं और /invite @Cursor चलाकर उसे जोड़ें।

यदि आपको @Cursor बॉट नहीं दिखता, तो ऑथराइज़ेशन विफल हो सकता है। डैशबोर्ड ->  इंटीग्रेशन्स में जाएं, Slack के आगे Manage पर क्लिक करें, और OAuth फिर से चलाएं।

यदि आप MCP पर और गहराई में जाना चाहते हैं, तो हमारा FastMCP 2.0 ट्यूटोरियल स्क्रैच से एक कस्टम MCP सर्वर बनाकर Cursor में इंटीग्रेट करना दिखाता है।

ट्रिगर्स और टूल्स को संयोजित करना

Slack MCP कनेक्ट होने पर, हम PR कोड रिव्यू ऑटोमेशन को विस्तारित कर सकते हैं। हम वही GitHub PR ट्रिगर्स और GitHub comment on PR टूल रखेंगे। लेकिन अब एजेंट Slack MCP के जरिए #pr-alerts में क्रिटिकल निष्कर्ष भी पोस्ट कर सकता है।

स्टेप 3 में लिखे निर्देशों के अंत में, जब हमने पहला ऑटोमेशन बनाया था, यह ब्लॉक जोड़ें:

Additionally:  
If you find any issue at severity high or critical, send a Slack message to #pr-alerts containing: the PR title, the author, a one-sentence description of the most severe finding, the severity label, and a link to the PR. If no high or critical issues are found, do not post to Slack at all.

वह अंतिम पंक्ति दिखाई देने से ज्यादा महत्वपूर्ण है। उसके बिना, #pr-alerts जल्दी ही “सब ठीक” सूचनाओं से भर सकता है और अपनी वैल्यू खो सकता है। मेरे लिए, एजेंट को यह बताना कि कब ऐक्शन नहीं लेना है, उतना ही महत्वपूर्ण है जितना बताना कि कब लेना है।

नीचे मेरे रिपॉजिटरी पर एक टेस्ट PR रन के आउटपुट हैं।

GitHub पर PR ओपन पर ऑटोमेशन एजेंट द्वारा पोस्ट किए गए कमेंट का दृश्य (GitHub PR कमेंट टूल के जरिए):

उसी रन के लिए मेरे #pr-alerts Slack चैनल में ऑटोमेशन एजेंट द्वारा भेजे गए Slack नोटिफिकेशन का दृश्य (Slack MCP कनेक्शन के जरिए):

इस बिंदु पर, आपके पास एक कार्यशील ऑटोमेशन है जो हर PR की समीक्षा करता है, GitHub पर कमेंट्स पोस्ट करता है, और क्रिटिकल इश्यूज़ को Slack तक एस्केलेट करता है। यही कोर पैटर्न है। 

अगले सेक्शन में, हम उसी फ़्लो का पालन करते हुए दूसरा ऑटोमेशन बनाएंगे: एक ट्रिगर, निर्देश, और एजेंट को आउटपुट देने के लिए जिन टूल्स की आवश्यकता है।

दूसरा ऑटोमेशन बनाना: शेड्यूल्ड टेस्ट कवरेज मॉनिटर

जो PR कोड रिव्यू ऑटोमेशन हमने बनाया, वह GitHub इवेंट्स पर प्रतिक्रिया देता है। शेड्यूल्ड ऑटोमेशन्स अलग तरह से काम करते हैं। हम परिभाषित करते हैं कि एजेंट को कब चलना चाहिए, और वह उस समय रिपो में क्या हुआ इससे परे चल जाता है।

यहां जो ऑटोमेशन हम बना रहे हैं, वह हर दिन सुबह 9 बजे चलता है, बीते 24 घंटों में मेन ब्रांच में मर्ज हुए कोड की समीक्षा करता है, अपर्याप्त टेस्ट कवरेज वाले क्षेत्रों की पहचान करता है, और #repo-coverage पर Slack में एक सारांश पोस्ट करता है।

क्रॉन ट्रिगर और टूल सेट करना

ऑटोमेशन्स डैशबोर्ड से:

• एक नया ऑटोमेशन बनाने के लिए + New पर क्लिक करें।
• इसे नाम दें Daily Coverage Check – Main Branch.

ट्रिगर कॉन्फ़िगर करें

• Triggers के तहत, Scheduled चुनें।
• Every... > Day चुनें और समय सेट करें 9:00 AM।
• यदि आपको अलग फ़ॉर्मेट चाहिए, जैसे केवल वीकडेज, तो Custom (cron) का उपयोग करें
• चूंकि शेड्यूल्ड ट्रिगर्स किसी रिपॉजिटरी का अनुमान नहीं लगाते, टारगेट रिपॉजिटरी और ब्रांच चुनें (main)।

Send to Slack टूल जोड़ें

यहाँ मैं आपको ऑटोमेशन सेटिंग्स में उपलब्ध Send to Slack टूल से परिचित कराऊंगा। यह पहले उपयोग किए गए Slack MCP से अलग है। हम इसे किसी विशिष्ट चैनल पर संदेश भेजने के लिए उपयोग करते हैं, जबकि Slack MCP वर्कस्पेस-लेवल एक्सेस देता है और एजेंट को निर्देशों में परिभाषित किसी भी चैनल पर पोस्ट करने देता है।

Send to Slack टूल जोड़ने के लिए, टूल्स सेक्शन से इसे चुनें और ऑटोमेशन के आउटपुट के लिए टारगेट चैनल निर्दिष्ट करें। इसे ऐसा दिखना चाहिए:

शेड्यूल्ड टास्क के निर्देश लिखना

PR रिव्यू ऑटोमेशन में, एजेंट पुल रिक्वेस्ट पर प्रतिक्रिया देता है और फीडबैक पोस्ट करता है। शेड्यूल्ड ऑटोमेशन्स में कोई इनकमिंग इनपुट नहीं होता। एजेंट स्वयं कार्य शुरू करता है, इसलिए हमें स्पष्ट होना चाहिए कि कहां से शुरू करना है, क्या जांचना है, और क्या पोस्ट करना है।

यहां मेमोरी टूल महत्वपूर्ण है। कवरेज तुलना तभी काम करती है जब एजेंट को कल के नंबर पता हों। हमें बताना होगा कि किस की से पढ़ना है, क्या तुलना करनी है, और अंत में क्या स्टोर करना है। यदि हम इसे अस्पष्ट छोड़ देंगे, तो रनों के बीच परिणाम बदल सकते हैं।

यह निर्देश सेट मैंने उपयोग किया:

You are a daily test coverage monitor for this repository. Run every day at 9 AM on the main branch.
Identify PRs merged to main in the last 24 hours.For modified files, check if changed code paths have test coverage.Run tests with coverage:  pytest --cov=src --cov-report=json.Parse the report and record the overall coverage and per-file coverage for modified files.Read yesterday's coverage from memory (daily_coverage_latest: If none exists, post a green status and skip comparison.Compare coverage: If it drops by >1%, post a warning to #repo-coverage Slack Channel with today's value, yesterday's value, delta, and affected files. Otherwise, post a green status with today’s value and delta.Save today’s coverage to memory (daily_coverage_latest).

नीचे, मैं आपको सुबह 9 बजे मेरे शेड्यूल्ड ऑटोमेशन के आउटपुट दिखाता हूँ।

यह ऑटोमेशन ओवरव्यू है। मेरे मामले में, कवरेज थ्रेसहोल्ड से ऊपर रहा, इसलिए इसने Slack चैनल में सिर्फ एक हरा स्टेटस पोस्ट किया:

यह Slack संदेश है। यह पहला टेस्ट कवरेज रन है, इसलिए मैंने बहुत उम्मीद नहीं की थी। आप यह भी देख सकते हैं कि रन को अगले तुलना के लिए बेसलाइन के रूप में मेमोरी में सेव किया गया:

ऊपर दिए रन को देखते हुए, निर्देशों के दो हिस्से खास नज़र आते हैं। 

पहला, यह चेतावनी पथ और हरे पथ दोनों को परिभाषित करता है। हरा पथ आवश्यक है। यदि हम केवल तब परिभाषित करें जब कुछ गलत हो, तो सब कुछ ठीक होने पर ऑटोमेशन चुप रहता है। एक मॉनिटरिंग चैनल में, वह चुप्पी फेल्योर जैसी लगती है। हरा स्टेटस कन्फर्म करता है कि रन पूरा हुआ।

दूसरा, मेमोरी रीड और सेव स्पष्ट हैं। एजेंट के पास मेमोरी टूल है, लेकिन तुलना के लिए वह इसे तब तक भरोसेमंद रूप से उपयोग नहीं करेगा जब तक निर्देशित न किया जाए। यदि हम इसे इम्प्लिसिट छोड़ेंगे, तो रनों में परिणाम बदल सकते हैं। हमें ठीक-ठीक बताना होगा कि कौन-सी की पढ़नी है, क्या तुलना करनी है, और क्या सेव करना है।

नीचे की छवि में, आप देख सकते हैं कि एजेंट ने मेरे ऑटोमेशन को सेव किया:

अगले सेक्शन में, मैं सामान्य गलतियाँ और बेस्ट प्रैक्टिसेज कवर करूंगा ताकि आप अपनी ऑटोमेशन्स से अधिक हासिल कर सकें।

Cursor Automations: आम गलतियाँ और बेस्ट प्रैक्टिसेज

ऑटोमेशन्स से जुड़ी ज्यादातर समस्याएँ कुछ अनुमानित गलतियों के छोटे सेट से आती हैं। इन्हें एक बार जान लेने पर बचना आसान है, लेकिन न जानने पर डिबग करना महंगा पड़ता है।

इन आम गलतियों से बचें

• अस्पष्ट निर्देश: यह एक सामान्य फेल्योर मोड है। “कोड की समीक्षा करें,” “समस्याएँ जाँचें,” या “परिवर्तनों का सारांश दें” जैसी बातें एजेंट को आपके अर्थ का अनुमान लगाने को मजबूर करती हैं, जिससे आउटपुट असंगत होता है। यदि किसी वाक्य में क्रिया है पर स्पष्ट ऑब्जेक्ट या कंडीशन नहीं, तो डिप्लॉयमेंट से पहले उसे फिर से लिखें।
• ओवर-स्कोपिंग:. सिक्योरिटी चेक्स, स्टाइल चेक्स, परफॉर्मेंस चेक्स, और टेस्ट कवरेज को एक ही ऑटोमेशन में न मिलाएं। इससे फेल्योर डिबग करना कठिन हो जाता है। संकरे ऑटोमेशन्स पर तर्क करना आसान होता है। 
• कैलिब्रेशन फेज़ छोड़ना: शुरुआत में auto-approve या auto-merge जैसी सेटिंग्स सक्षम न करें। शुरुआती रनों को कम से कम कमेंट-ओनली रखें। ये रन आपके कोडबेस में एज केस उजागर करते हैं। इस फेज़ को प्रोडक्शन से पहले वेलिडेशन की तरह ट्रीट करें।
• Slack चैनल कॉन्फ़िगरेशन: Slack ट्रिगर्स केवल पब्लिक चैनल्स पर काम करते हैं, इसलिए यदि कोई Slack ऑटोमेशन कुछ नहीं करता दिखे, तो अपने चैनल की विजिबिलिटी जांचें और सुनिश्चित करें कि @Cursor बॉट उस चैनल में इनवाइटेड हो।

भरोसेमंद ऑटोमेशन्स के लिए बेस्ट प्रैक्टिसेज

• प्रति ऑटोमेशन एक ही काम: हर ऑटोमेशन को एक स्पष्ट रूप से परिभाषित काम करना चाहिए। इससे फेल्योर को अलग करना और फिक्स लगाना आसान हो जाता है।
• क्लीन स्टेट से शुरू करें: एजेंट को बदलाव करने देने से पहले अपनी वर्किंग ट्री कमिट करें ताकि हमेशा तुलना के लिए एक साफ डिफ़ हो।
• पहले कुछ रन को कैलिब्रेशन मानें: शुरुआत में कुछ शोर की उम्मीद करें, आउटपुट की समीक्षा करें, निर्देश समायोजित करें, और तब तक फिर से चलाएं जब तक व्यवहार स्थिर न हो जाए।
• स्पष्ट, वर्णनात्मक नामों का उपयोग करें: PR Code Review – Open & Push – Comment Only जैसे नाम, बाद में वापस देखने पर जेनेरिक लेबल्स से अधिक उपयोगी होते हैं।
• रन हिस्ट्री को जल्दी-जल्दी देखें: शुरुआती कुछ हफ्तों में, यह “नॉर्मल” व्यवहार की समझ बनाता है, जिससे बाद में इश्यूज़ पहचानना आसान होता है।

अंतिम विचार

Cursor Automations एजेंटिक कोडिंग को इंटरएक्टिव वर्कफ़्लो से इवेंट-ड्रिवन सिस्टम में ले जाता है। Cursor Agent मोड में, हम एक चैट खोलते हैं और एजेंट को कोड रिव्यू, फंक्शन्स रिफैक्टर करने, या इश्यूज इन्वेस्टिगेट करने के लिए प्रॉम्प्ट करते हैं। ऑटोमेशन्स में, हम काम सीधे शुरू नहीं करते। पुल रिक्वेस्ट, Slack संदेश, या शेड्यूल जैसे ट्रिगर्स एजेंट को स्वतः शुरू करते हैं, और वह कार्य स्वयं पूरा करता है। मुख्य बदलाव यह है कि रूटीन काम मैनुअल कतार से बैकग्राउंड में चलने वाले सिस्टम में शिफ्ट हो जाता है।

इस लेख में, मैंने आपको दो ऑटोमेशन्स बनाना सिखाया: एक PR कोड रिव्यू और एक शेड्यूल्ड कवरेज मॉनिटर। ये जानबूझकर सरल हैं, लेकिन यह सही शुरुआती बिंदु देते हैं क्योंकि वे बिना अतिरिक्त जटिलता के सिस्टम का व्यवहार दिखाते हैं। एक बार सहज होने के बाद, आप उन्नत वर्कफ़्लो लागू कर सकते हैं।

कोर विचार है—एक संकरे ऑटोमेशन से शुरू करें, निर्देश रनबुक की तरह लिखें, इसे कम-जोखिम मोड में चलाएं, और केवल तब विस्तार करें जब यह भरोसेमंद रूप से व्यवहार करे। मूल्य इस बात से कम आता है कि आप कितनी ऑटोमेशन्स बनाते हैं और अधिक इस बात से कि हर एक कितनी सुसंगत है।

जो कुछ हमने इस लेख में कवर किया, उस पर आगे निर्माण जारी रखने के लिए, ये हमारे अनुशंसित अगले कदम हैं:

• Agent मोड और व्यापक Cursor वर्कफ़्लो की समझ गहरी करें हमारे Software Development with Cursor कोर्स के साथ।
• यह देखें कि Cursor 3.0 में नया क्या है।