Cursor Otomasyonları: Her Zaman Açık Kodlama Ajanlarına Yönelik Uygulamalı Rehber

Yazılım geliştirmedeki gerçek darboğaz artık kod yazmak değil; çünkü bugün, her ölçekteki ekiplerde neredeyse her geliştiricinin gönderimlerine yardımcı olan en az bir ajanı var. Kodlama ajanları günlük iş akışlarına yerleşti ve uygulama artık sistemin en yavaş parçası değil.

Cursor Otomasyonları bu boşluğu kapatmak için tasarlandı. Bir ajana tekrar tekrar komut vermek yerine, ne zaman harekete geçmesi gerektiğini tanımlarsınız. Bir tetikleyici çalışır, talimatlar ne yapacağını yönlendirir ve otomatik olarak çalışır. Bir pull request açılır, incelenir. Slack’e bir hata raporu düşer, ele alınır. Bir zamanlama çalışır, bir rapor üretilir.

Bu eğitimde, Cursor otomasyonlarını uçtan uca nasıl kuracağınızı göstereceğim. İki otomasyon oluşturacaksınız: bir PR incelemesi ve zamanlanmış bir test kapsama izleyicisi. Bu sırada, talimatları nasıl yapılandıracağınızı ve araçları ile MCP bağlantılarını nasıl kuracağınızı anlatacağım ki otomasyonlar beklediğimiz gibi davransın.

Başlamadan önce bir not. Otomasyonlar hâlâ geliştiriliyor ve cursor.com/automations üzerindeki gösterge paneli evriliyor. Bu yazıyı okuduğunuzda bir menü etiketi veya düğme yer değiştirmiş olsa bile, temel mantık aynı kalacaktır.

Cursor Otomasyonları nedir?

Cursor otomasyonları, geliştirme araçlarınızdaki olaylar veya belirlediğiniz bir zamanlama ile tetiklenen Cursor’un bulut ajanlarını otomatik olarak çalıştıran bir sistemdir.

Cursor’ın Ajan modunda, Software Development with Cursor kursumuzda ele alındığı üzere, her oturuma bir sohbet açıp bir komut yazarak başlarsınız ve ajan, siz yanında oldukça yerel makinenizde çalışır.

Otomasyonlarda ise başlangıç sinyali yığınınızdaki başka bir yerden gelir ve ajan sizden izleme gerektirmeden bir bulut sandbox’ında görevini yapar.

Otomasyonlar, aşağıda özetlediğim tetikleyici olayları içerir; ayrıca web kancalarıyla özel tetikleyiciler de kurabilirsiniz. Bir otomasyonda birden fazla tetikleyici olabilir ve bunlardan herhangi biri çalıştığında otomasyon tetiklenir.

Bu tetikleyici türlerinin her biri, normalde bir şeyi fark etmeniz, Cursor Ajan moduna geçmeniz ve yardım istemeniz gereken bir anın yerini alır. 

Pull request tetikleyicisi, muhtemelen ilk oluşturacağınızdır. Depoyu izlemek üzere bir otomasyon eklemeden önce ve sonra, tek bir PR’nin yaşam döngüsü şöyle görünür:

İkinci sütunda değişen, tek tek adımların hızı değil; dikkatinizin artık tüm sürecin hızını sınırlayan unsur olmamasıdır.

Cursor Otomasyonları kaputun altında nasıl çalışır

Her otomasyon kaputun altında aynı ardışık düzeni izler. Tanımladığınız tetikleyici çalıştığında Cursor yeni bir bulut sandbox’ı başlatır, deponuzu içine klonlar ve yapılandırılmış araçlar, MCP bağlantıları ve model ile talimatlarınızı izleyen bir ajan başlatır. Bu depo GitHub’da olmak zorunda değildir: Cursor Origin, Cursor’un kendi Git hizmetinde barındırılan depolar da bulut ajanları ve otomasyonlarla çalışır.

Ajan, bitirmeden önce çıktısını doğrular, ardından sonucu yapılandırdığınız yere gönderir: PR yorumu, Slack mesajı, Linear bileti veya yeni bir pull request açarak.

Oluşturduğunuz her otomasyonu şekillendiren iki özellik vardır:

• Sandbox tamamen Cursor’un bulutunda çalışır, dizüstü bilgisayarınızda değil. Makineniz kapalıyken bile çalışmaya devam eder.
• Her çalıştırma yalıtım içinde gerçekleşir. Birden fazla otomasyon birbirini etkilemeden paralel çalışabilir. Cursor ayrıca dahili olarak saatte yüzlerce otomasyon çalıştırdığını belirtmiştir.

Ayrıca, aşağıdaki ön izlemede gösterildiği gibi, otomasyonunuzun çalıştırmalar arasında durumu kalıcı kılmasına olanak tanıyan bir bellek aracı vardır; bu, biraz sonra zamanlanmış kapsama izleyicisini oluştururken önemli hale gelecektir.

Zamanlanmış kapsama izleyicisini oluştururken buna geri döneceğim.

Cursor Otomasyonları ve Ajan modu karşılaştırması

Eğer Cursor’ı hâlihazırda düzenli kullanıyorsanız, asıl soru, Ajan modu yerine ne zaman otomasyonları kullanmanız gerektiğidir. Tek seferlik işler için Otomasyonları kullanmazdım. Otomasyonlar, tekrarlayan veya harici olaylara bağlı işler için tasarlanmıştır.

Seçim net olmadığında, aralarındaki farkı karşılaştırmak faydalı olur:

Ben şöyle düşünüyorum: Bir görev “her ne zaman” veya “her seferinde” diye başlıyorsa, Otomasyonlara aittir.

Örneğin: “Her PR açıldığında veya #support kanalına bir hata raporu düştüğünde bir Linear bileti oluştur.” Tetikleyici tekrarlayan ve öngörülebilirdir.

“Şu anda bu modülü refaktör etmem gerekiyor” diye başlıyorsa Ajan moduna aittir. “Şu an”ın ne zaman olduğuna siz karar verirsiniz.

Otomasyonlara dalmadan önce Cursor’ı keşfetmek isterseniz, Cursor 2.0 kapsamlı rehberimiz sizi Ajanlar arayüzü, Composer ve tam bir Python projesiyle çoklu ajan iş akışı üzerinden geçirir.

Otomasyonlar Gösterge Paneline Erişim

Cursor otomasyonları gösterge paneli cursor.com/automations adresinde bulunur. Cursor hesabınızla oturum açın; aşağıda gösterildiği gibi ana panele inersiniz:

Gösterge panelinde gördüklerimizi parçalara ayıralım.

Üstteki özet kutucukları veya durum göstergesi

Kutucuklar, çalıştırdığınız her şeyin anlık sağlık özetini verir. Şunları içerir:

• Toplam otomasyon (kaç tane yapılandırdığınız) 
• Başarılı (tamamlanan çalıştırmalar ve başarı oranı)
• Başarısız (hata veren çalıştırmalar)
• Çalıştırma geçmişi (tıklandığında, zaman içindeki çalıştırma hacmini gösterir)

Komut girişi kutusu

Girdi alanı, tam kurulum formunu açmadan yeni bir otomasyon oluşturmanın en hızlı yoludur. Görevi tanımlarız ve Cursor otomasyon yapısını oluşturur.

Yeni başlıyorsanız, buradan başlamanızı öneririm. Otomatikleştirmek istediğinizi belirleyin, ardından tetikleyici her çalıştığında ajanın takip edeceği yapılandırılmış bir talimat seti yazın. 

Ok düğmesine bastığınızda Cursor, bu talimatları kullanarak otomasyonu sizin için oluşturur; adı, tetikleyicileri ve gerekli araçları önceden doldurur.

Bu talimatları normal bir komut istemi gibi değil, her seferinde ajanın çalıştıracağı bir şartname gibi ele alırdım. İlk otomasyonunuzu nasıl oluşturacağınızı gösterirken buna geri döneceğim.

Bana / ekip geçişi ve + yeni otomasyon düğmesi

Geçiş düğmesi, sizin otomasyonlarınız ve ekip otomasyonları arasında filtreleme yapar. 

+ Yeni düğmesi, yeni bir otomasyonu yapılandırmak için bir yapılandırma sayfası açar:

+ Yeni Otomasyon düğmesi, tetikleyiciyi, talimatları ve araç bağlantılarını en baştan elle yapılandırmak isterseniz satır içi komut kutusuna göre daha uzun bir alternatiftir.

Mevcut otomasyonlar listeniz

Tablo, oluşturduğumuz tüm otomasyonları, kullanılan araçları ve çalıştırma geçmişini gösterir.

Herhangi birine tıklamak, ayar sayfasını ve çalıştırma geçmişini açar:

Önerilen şablonlar bölümü

Önceki otomasyonlar listesinin altında bir şablon kartları ızgarası bulunur. Şablonlar, sıfırdan başlamadan düzenleyebileceğiniz önceden oluşturulmuş otomasyonlar sağlar.

Cursor otomasyon şablonları, ilk günden bir otomasyonu ayağa kaldırmanın en hızlı yoludur. İlk otomasyonunuzu oluşturuyorsanız, otomatikleştirmek istediğinize uyan bir şablon olup olmadığını kontrol etmenizi ve oradan başlamanızı öneririm.

Şablonlar size iyi talimatların nasıl göründüğüne, hangi araç veya MCP bağlantılarına ihtiyacınız olduğuna dair fikir verebilir.

Hesap ve maliyet hususları

Cursor otomasyonları, ücretli planlara dahil olan bulut ajan erişimi gerektiren Cursor’ın bulut altyapısında çalışır. Her çalışma, model kullanımına ve yürütme süresine bağlı olarak kredileri tüketir.

Otomasyonlar, izinler modeline göre üç görünürlük katmanını destekler:

• Özel: Yalnızca siz görebilirsiniz ve faturası hesabınıza yansır.
• Ekip Görünür: Diğerleri otomasyonlarınızı ve çalıştırma geçmişinizi görebilir, ancak faturalama size yapılır.
• Ekip Sahipli. Otomasyonun faturası ekibin paylaşılan havuzuna yansır ve ekip yöneticileri tarafından yönetilir.

Doğru katmanı seçmek önemlidir; çünkü otomasyon her çalıştığında hangi kredilerin kullanılacağını belirler. Çıktıya güvenene kadar denemeleri özel tutun. Otomasyon ekibinizin iş akışının bir parçası olduğunda, ekip sahibi katmana taşıyabilirsiniz.

Başlıca hata, bir otomasyonu çok erken ve çok geniş kapsamda çalıştırmaktır. Yoğun bir depoda her itmede tetikleniyorsa, farkına varmadan hızla kullanım biriktirebilir. Dar başlayın, birkaç gün çalışmasına izin verin, ne sıklıkta tetiklendiğini gözden geçirin, ardından genişletmeye veya ölçeklendirmeye karar verin.

İlk Cursor Otomasyonunuzu Oluşturma: Otomatik PR Kod İncelemesi

PR kod incelemesi doğru ilk otomasyondur; çünkü geri bildirim döngüsü kısadır ve hatalı bir çalışmanın sonuçları düşüktür. Ajan yararlı bir yorum gönderirse, bunu PR’da hemen görürüz. Alakasız bir şey gönderirse, yok sayarız ve hiçbir şey gönderilmez.

İlk otomasyonunuzu beş adımda nasıl oluşturacağınızı anlatacağım:

1. GitHub deponuzu bağlama
2. GitHub tetikleyicilerini ayarlama
3. Ajan talimatlarını yazma (net yapı ve kaçınılacaklar ile)
4. GitHub Pull Request yorum aracını ekleme
5. Otomasyonu dağıtma

Adım 1: GitHub deponuzu bağlama

Ajan bir pull request’i incelemeden önce bir depoya erişmesi gerekir. Cursor, deponuza yerel bir GitHub Uygulaması entegrasyonu ile erişir. Bu bağlantı olmadan otomasyon ajanı kodunuzu göremez, PR difflerini okuyamaz veya geri bildirim veremez; bu yüzden hiçbir şey gerçekten çalışmaz.

Bunu henüz yapmadıysanız:

1. Cursor GitHub Uygulamasını yükleyin ve otomasyonların izlemesini istediğiniz depolara erişim verin.
2. GitHub hesabınızı gösterge panelinde Integrations sekmesi altında bağlayın. 

Bağlantınız etkinleştikten sonra, otomasyon tetikleyicisini yapılandırırken depolarınız kullanılabilir olacaktır.

Adım 2: Tetikleyicilerinizi ayarlama

Otomasyonlar gösterge panelinden:

1. Bir otomasyon oluşturmaya başlamak için + Yeni Otomasyon’a tıklayın.
2. Otomasyona bir ad verin. PR Code Review – Open & Push – Comment Only adını verebilirsiniz.
3. Tetikleyiciler bölümünde Tetikleyici ekle’ye tıklayıp GitHub’ı seçin. PR açıldı ve PR itildi olaylarını tetikleyici olarak seçin.
4. Hedef depoyu seçin.

Adım 1’i atladıysanız veya GitHub’ı Cursor otomasyonlarına ilk kez bağlıyorsanız kimlik doğrulaması yapmanız istenir. 

Aşağıdaki ön izlemede, yetkilendirme tamamlandığında nasıl yapılandırılacağını ve hedef deponun nasıl seçileceğini gösteriyorum:

Not: Talimatların, hangi olayın tetiklediğine bağlı olarak değişmediği durumlarda bir otomasyonda birden fazla tetikleyici olayını paketleyebiliriz. Ancak derinlik veya amacın olaya göre değiştiği durumlarda ayrı otomasyonlar tercih ederiz.

Artık otomasyon ne zaman çalışacağını biliyor. Sıradaki adım, ona ne yapacağını söylemektir.

Adım 3: Etkili otomasyon talimatları yazma

Talimatlar, otomasyonumuzun yararlı çıktı üretip üretmeyeceğinin en büyük kaldıraçıdır. Ajan, “iyi”nin neye benzediğini bu talimatlardan öğrenir. Muğlak talimatlar tutarsız sonuçlara yol açar.

Talimatı yazmadan önce ne tanımladığımızı anlamalıyız. Tek seferlik bir komut istemi vermiyoruz. Tetikleyici her çalıştığında ajanın takip edeceği bir davranış belirliyoruz. Otomasyonun kalitesi, bu davranışı ne kadar net belirttiğimize bağlıdır.

Önerdiğim yapı şöyle:

• Rolü tanımlayın: Bakış açısını ve tonu belirler. Örneğin: “Pull request’ler için bir güvenlik inceleyicisisiniz.”
• Amacı tanımlayın: Başarının nasıl göründüğünü netleştirin. Örneğin: “Gerçek güvenlik açıklarını tespit edin ve net şekilde açıklayın.”
• Kapsamı tanımlayın: Ajanın neye odaklanacağını açıkça belirtin. Örneğin: “Yalnızca eklenen veya değiştirilen kodu inceleyin.”
• İş akışını ana hatlarıyla verin: Göreve net bir yaklaşım verin. Örneğin: “Değişiklikleri inceleyin, girdileri izleyin ve korumaları doğrulayın.”
• Hariç tutmaları belirleyin: Gürültüyü azaltmak için nelerin yok sayılacağını açıkça belirtin.
• Davranış ve çıktıyı tanımlayın. Nasıl davranacağı ve sonuçların nasıl görüneceği.
• Sınırları belirleyin: Asla yapmaması gerekenler.

Otomasyon talimatlarını, kabul kriterleri net, sınırları açık, belirli ve sıralı bir çalışma kitapçığı yazar gibi yazın.

İyi bir talimat örneği

Bu PR kod inceleme otomasyonu için kullandığım talimat şöyle. Talimat giriş kutunuza kopyalayabilirsiniz; ancak kendi kullanımınıza göre uyarlayın:

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.

Talimatın talimat giriş kutusundaki görünümü şöyledir:

Bu komut basitleştirilmiştir; ancak yine de net ve belirli bir yapıyı izler. 

Kötü bir talimat örneği

Şu tür muğlak talimatlardan kaçının:

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

Yapı, kısıtlar ve öncelikler olmadan, ajan “sorun”dan ne kastettiğinizi tahmin etmek zorunda kalır; bu da genel-geçer, yüzeysel geri bildirimlere yol açar ve güvenilir çıktılar üretmez.

Adım 4: Araçları ekleme

Otomasyon düzenleyicisi içindeki araçlar panelini açın. Bu otomasyon için GitHub bölümüne gidip Comment on Pull Request aracını seçeceğiz. Aşağıdaki ön izlemede olduğu gibi PR onayının devre dışı olduğundan emin oluruz; böylece otomasyon yalnızca yorum yapabilir, değişiklikleri onaylayamaz.

Comment on Pull Request aracı, ajanın bulguları PR’a geri yorum olarak göndermesine olanak tanır. Ayrı bir bağlantı gerektirmez; çünkü Adım 1’de yetkilendirdiğiniz aynı Cursor GitHub Uygulaması tarafından çalıştırılır.

Çıktıyı başka servislere göndermek isteseydik (ör. Slack’e gönderme), ilgili aracı seçer veya bir MCP bağlantısı eklerdik. Bu otomasyon için yorum aracı yeterlidir.

Adım 5: İlk çalıştırmayı dağıtma ve izleme

Tetikleyiciler, talimatlar ve araçlar ayarlandıktan sonra Oluştur’a tıklayıp otomasyonu kaydederiz; bu da aşağıda görebileceğiniz gibi otomasyonun ayar sayfasını açar:

Otomasyonu dağıttığımıza göre, bir çalıştırmayı tetikleyip ajanın ne ürettiğini gözlemlememiz gerekir.

Bağlı deponuzda bir taslak pull request açın. Bu, PR açıldı tetikleyicisini çalıştırır ve saniyeler içinde Çalıştırma geçmişinde yeni bir giriş görünmelidir; aşağıda görebileceğiniz gibi:

Bu çalıştırmayı açın ve üç şeyi kontrol edin:

• Yürütme süresi: Çalıştırmanın ne kadar sürdüğü. Bu, diff boyutlarına, modellere ve talimat karmaşıklığına göre değişir.
• Araç çağrıları: Hangi dosyalar ve araçlar kullanıldı? Ajan ilgisiz dosyaları okuyorsa, talimatlarınızı gözden geçirin.
• Çıktı: GitHub’a ne gönderildi. Talimatlarınızla karşılaştırın.

Aşağıda otomasyonumun çalıştırmasına genel bir bakış var. Altı dakika çalıştığını, bazı işlemler yaptığını ve PostReviewCommentOnPr aracını kullanarak PR incelemesini gönderdiğini görebilirsiniz:

Aşağıda, ajanın PR’ımda paylaştığı örnek bir yorum var:

Bazen çıktı beklenenden sapabilir; bu olduğunda, sorun genellikle talimatlardadır. Davranışını değiştirmek istediğimiz kısmı kontrol eden talimatı ayarlarız, yeni bir commit iterek başka bir çalıştırma tetikler ve sonucu inceleriz.

Bu erken çalıştırmalar için, riski düşük tutmak adına basit başlamalıyız. Bu durumda otomasyonu yalnızca yorumla sınırlandırıyoruz; böylece davranışını güvenle doğruluyoruz. Çıktı tutarlı hale geldiğinde, gerçek kullanıma alır ve yapabileceklerini genişletmek için GitHub’ın ötesinde diğer araçları bağlarız.

MCP ile Daha Fazla Araç Bağlama

Az önce oluşturduğumuz PR inceleme otomasyonu GitHub üzerinde çalışır. Diffi okur ve GitHub Pull Request’e Yorum Yap aracıyla pull request’e yorum gönderir. Ancak ajanın kod incelemenin ötesinde şeyler yapmasını istiyorsak, diğer araçları bağlamamız gerekir. Bunun için Model Context Protocol (MCP) vardır.

MCP, ajanların özel entegrasyonlara gerek duymadan harici araçları kullanmasına olanak tanıyan standart bir arayüzdür. MCP olmadan her araç için ayrı kurulum ve bakım gerekirdi. 

MCP ile, otomasyonun araçlar panelinde desteklenen bir aracı bağladığımızda, ajan onu aynı arayüz üzerinden kullanabilir.

MCP, aynı otomasyonun daha fazlasını yapmasını ve diğer araçlarda eylem almasını sağlar. PR inceleme otomasyonunuz zaten GitHub’da yorum yapıyor. Slack ekleyin, bir kanala güncellemeler paylaşabilir. Linear ekleyin, bilet oluşturabilir. Datadog ekleyin, günlükleri çekebilir. Her bağlantı, çekirdek mantığı değiştirmeden otomasyonun yeteneklerini genişletir.

Cursor otomasyonları, Slack, Linear, ClickUp, Datadog, Notion ve daha fazlası gibi yerleşik bir MCP entegrasyonları kümesi içerir. MCP açık bir standart olduğundan, uyumlu herhangi bir aracı aynı şekilde bağlayabiliriz.

Otomasyon ayar sayfasında Araçlar -> MCP sunucusu altında MCP’yi bulacaksınız. + Yeni Bağlantı düğmesine tıklayıp göz atın; ardından ihtiyacınız olan aracı yükleyip bağlayın.

Nasıl ekleneceklerine dair bir ön izleme burada:

Bir sonraki bölümde, PR kod inceleme otomasyonuna bir Slack MCP bağlantısının nasıl ekleneceği konusunda sizi yönlendireceğim.

Slack MCP bağlantısı ekleme

GitHub, otomasyonun kodumuzu okumasını ve yorum yapmasını sağlar. Slack ise ekip ile iletişimi sağlar.

Araçlar panelinden Araç veya MCP Ekle’ye tıklayın, MCP Server’ı seçin, ardından +Yeni Bağlantı’yı seçin. Açılan panelde Slack’i arayın ve Slack MCP sunucusunu seçin. 

Slack çoğu zaman kurulu gelir; değilse yükleyin ve çalışma alanınızı yetkilendirmek için OAuth akışını izleyin. Bağlandıktan sonra, aşağıdaki genel bakışta gösterdiğim gibi araçlar panelinizde görünür:

Bağlantı kurulumunda hedef kanalı seçmeyiz. MCP, otomasyon ajanına herkese açık tüm kanallar için çalışma alanı düzeyinde erişim verir. Tam olarak nereye mesaj göndereceğini talimatlarda kanalın adını belirterek kontrol ederiz; örneğin, “Yüksek önemde bir sorun bulunursa #pr-alerts kanalına bir Slack mesajı gönder.”

Not: Slack MCP yalnızca herkese açık kanallarla çalışır ve otomasyonun mesaj gönderebilmesi için hedef kanala Cursor botunun davet edilmesi gerekir. OAuth akışından sonra Slack çalışma alanınızda bir Cursor botu görünmelidir. Kanala gidip /invite @Cursor komutunu çalıştırarak ekleyin.

Eğer @Cursor botu görünmüyorsa yetkilendirme başarısız olmuş olabilir. dashboard ->  integrasyonlar bölümüne gidin, Slack’in yanında Manage’a tıklayın ve OAuth’u yeniden çalıştırın.

MCP’nin kendisine daha derinlemesine dalmak isterseniz, FastMCP 2.0 eğitimimiz sıfırdan özel bir MCP sunucusu oluşturmayı ve Cursor’a entegre etmeyi anlatır.

Tetikleyicileri ve araçları birleştirme

Slack MCP bağlandıktan sonra PR kod inceleme otomasyonunu genişletebiliriz. Aynı GitHub PR tetikleyicilerini ve GitHub PR’a yorum yap aracını koruyacağız. Ancak artık ajan, Slack MCP aracılığıyla kritik bulguları #pr-alerts kanalına da iletebilir.

İlk otomasyonu oluştururken adım 3’te yazdığımız talimatların sonuna şu bloğu ekleyin:

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.

O son satır göründüğünden daha önemlidir. O olmadan, #pr-alerts çok hızlı şekilde “temiz” bildirimleriyle dolar ve değerini kaybeder. Bana göre, ajana ne zaman harekete geçmemesi gerektiğini söylemek, ne zaman geçmesi gerektiğini söylemek kadar önemlidir.

Aşağıda, depomdaki bir test PR çalıştırmasından çıktılar yer alıyor.

Aşağıda, otomasyon ajanının GitHub’ımda PR açılışında (GitHub PR yorum aracıyla) gönderdiği bir yorum görünümü var:

Aşağıda ise aynı çalıştırma için otomasyon ajanının Slack MCP bağlantısı aracılığıyla #pr-alerts Slack kanalına gönderdiği bildirim görünümü var:

Bu noktada, her PR’ı inceleyen, GitHub’da yorum paylaşan ve kritik sorunları Slack’e yükselten çalışan bir otomasyona sahipsiniz. Bu, çekirdek örüntüdür. 

Sıradaki bölümde, aynı akışı izleyen ikinci bir otomasyon oluşturacağız: bir tetikleyici, talimatlar ve ajanın çıktıyı üretmesi için gereken araçlar.

İkinci Bir Otomasyon Oluşturma: Zamanlanmış Test Kapsama İzleyicisi

Oluşturduğumuz PR kod inceleme otomasyonu GitHub olaylarına tepki verir. Zamanlanmış otomasyonlar farklı çalışır. Ajanın ne zaman çalışacağını tanımlarız ve depo içinde ne olduğundan bağımsız olarak o zamanda çalışır.

Burada oluşturduğumuz otomasyon her gün saat 9:00’da çalışır, son 24 saatte ana dala (main) birleştirilen kodu inceler, yetersiz test kapsamı olan alanları belirler ve #repo-coverage kanalına bir özet gönderir.

Cron tetikleyicisi ve aracı ayarlama

Otomasyonlar gösterge panelinden:

• Yeni bir otomasyon oluşturmak için + Yeni’ye tıklayın.
• Adını Daily Coverage Check – Main Branch koyun.

Tetikleyiciyi yapılandırın

• Tetikleyiciler altında Scheduled’ı seçin.
• Every... > Day seçin ve saati 9:00 AM olarak ayarlayın.
• Yalnızca hafta içi gibi farklı bir format gerekiyorsa Custom (cron) kullanın
• Zamanlanmış tetikleyiciler bir depoyu türetmediği için hedef depoyu ve dalı (main) seçin.

Send to Slack aracını ekleyin

Burada, otomasyon ayarlarında bulunan Send to Slack aracını tanıtacağım. Bu, daha önce kullanılan Slack MCP’den farklıdır. Bunu belirli bir kanala mesaj göndermek için kullanırız; Slack MCP ise çalışma alanı düzeyinde erişim sağlar ve ajanın talimatlarda tanımlanan herhangi bir kanala mesaj göndermesine olanak tanır.

Send to Slack aracını eklemek için araçlar bölümünden seçin ve otomasyon çıktısı için hedef kanalı belirtin. Görünümünün şöyle olması gerekir:

Zamanlanmış bir görev için talimat yazma

PR inceleme otomasyonunda ajan bir pull request’e tepki verir ve geri bildirim gönderir. Zamanlanmış otomasyonlarda gelen bir girdi yoktur. Ajan göreve kendi başına başlar; bu nedenle nereden başlayacağını, neyi kontrol edeceğini ve neyi paylaşacağını netleştirmeliyiz.

Burada bellek aracı önemlidir. Kapsam karşılaştırması, ajanın dünkü sayıları bilmesi durumunda işe yarar. Hangi anahtarın okunacağını, neyin karşılaştırılacağını ve sonunda neyin saklanacağını belirtmeliyiz. Bunu net bırakmazsak, sonuçlar çalıştırmalar arasında değişkenlik gösterebilir.

Kullandığım talimat seti şöyle:

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).

Aşağıda, saat 9:00’daki zamanlanmış otomasyonumun çıktıları var.

İşte otomasyona genel bakış. Benim durumumda kapsama eşik üzerinde kaldı; bu nedenle Slack kanalına yalnızca yeşil bir durum gönderildi:

İşte Slack mesajı. Bu ilk test kapsama çalıştırması olduğu için çok bir şey beklemiyordum. Ayrıca çalıştırmanın, bir sonraki karşılaştırma için temel olarak belleğe kaydedildiğini de görebilirsiniz:

Yukarıdaki çalıştırmaya bakıldığında, talimatların iki kısmı öne çıkıyor. 

İlki, hem uyarı yolunu hem de yeşil yolu tanımlar. Yeşil yol gereklidir. Yalnızca bir şeyler yanlış gittiğinde ne olacağını tanımlarsak, her şey yolundayken otomasyon sessiz kalır. Bir izleme kanalında bu sessizlik bir hata gibi görünür. Yeşil durum, çalıştırmanın tamamlandığını doğrular.

İkincisi, bellek okuma ve kaydetme açıkça belirtilmiştir. Ajanın bir bellek aracı vardır; ancak karşılaştırmalar için talimat verilmedikçe bunu güvenilir şekilde kullanmaz. Bunu örtük bırakırsak, sonuçlar çalıştırmalar arasında değişkenlik gösterebilir. Hangi anahtarın okunacağını, neyin karşılaştırılacağını ve neyin kaydedileceğini tam olarak belirtmeliyiz.

Aşağıdaki görselde, ajanın otomasyonumu kaydettiğini görüyorsunuz:

Bir sonraki bölümde, otomasyonlarınızdan daha fazla verim almanıza yardımcı olacak yaygın tuzakları ve en iyi uygulamaları ele alacağım.

Cursor Otomasyonları: Yaygın Tuzaklar ve En İyi Uygulamalar

Otomasyonlarla ilgili sorunların çoğu, öngörülebilir birkaç hatadan kaynaklanır. Bunları bir kez öğrendiğinizde kaçınması kolaydır; ancak bilmediğinizde hataları ayıklamak maliyetlidir.

Kaçınılacak yaygın hatalar

• Muğlak talimatlar: Bu yaygın bir başarısızlık biçimidir. “Kodu incele”, “sorunları kontrol et” veya “değişiklikleri özetle” gibi ifadeler, ajanın ne demek istediğinizi tahmin etmesine neden olur; bu da tutarsız çıktılar üretir. Bir cümlede net bir nesne veya koşul olmadan bir fiil varsa, canlıya almadan önce yeniden yazın.
• Aşırı kapsam:. Güvenlik kontrolleri, stil kontrolleri, performans kontrolleri ve test kapsamını tek bir otomasyonda birleştirmeyin. Bu, hataları ayıklamayı zorlaştırır. Dar otomasyonlar daha kolay anlaşılır. 
• Kalibrasyon aşamasını atlama: Erken aşamada otomatik onay veya otomatik birleştirme gibi ayarları etkinleştirmeyin. Erken çalıştırmaları en azından yalnızca yorum olacak şekilde yapın. Bu çalıştırmalar, kod tabanınızdaki uç durumları ortaya çıkarır. Bu aşamayı üretim öncesi doğrulama olarak görün.
• Slack kanal yapılandırması: Slack tetikleyicileri yalnızca herkese açık kanallarda çalışır; bu nedenle bir Slack otomasyonu hiçbir şey yapmıyormuş gibi görünüyorsa, kanal görünürlüğünü kontrol edin ve @Cursor botunun o kanala davet edildiğinden emin olun.

Güvenilir otomasyonlar için en iyi uygulamalar

• Otomasyon başına tek iş: Her otomasyon, net şekilde tanımlanmış tek bir işi yapmalıdır. Bu, hataların yalıtılmasını ve düzeltmelerin uygulanmasını kolaylaştırır.
• Temiz bir durumdan başlayın: Bir ajan değişiklik yapmadan önce çalışma ağacınızı commit’leyin ki her zaman karşılaştıracak net bir diff’iniz olsun.
• İlk birkaç çalıştırmayı kalibrasyon olarak görün: Başlarda bir miktar gürültü bekleyin; çıktıları gözden geçirin, talimatları ayarlayın ve davranış sabitlenene kadar yeniden çalıştırın.
• Açık, açıklayıcı adlar kullanın: PR Code Review – Open & Push – Comment Only gibi adlar, sonradan baktığınızda genel etiketlere göre daha kullanışlıdır.
• Çalıştırma geçmişini erken ve sık gözden geçirin: İlk birkaç haftada, bu, normal davranışın nasıl göründüğüne dair sezgi oluşturur; böylece ileride sorunları tespit etmek kolaylaşır.

Son Düşünceler

Cursor Otomasyonları, ajansal kodlamayı etkileşimli bir iş akışından olay güdümlü bir sisteme taşır. Cursor Ajan modunda, bir sohbet açıp ajandan kod incelemesini, fonksiyonları yeniden düzenlemesini veya sorunları araştırmasını isteriz. Otomasyonlarda ise işi doğrudan biz başlatmayız. Pull request, Slack mesajı veya bir zamanlama gibi tetikleyiciler ajanı otomatik başlatır ve ajan görevi kendi başına tamamlar. Esas değişim, rutin işin manuel kuyruktan arka planda çalışan bir sisteme taşınmasıdır.

Bu yazıda, iki otomasyonun nasıl oluşturulacağını anlattım: bir PR kod incelemesi ve zamanlanmış bir kapsama izleyicisi. Bunlar bilerek basittir; ancak sisteme ek karmaşıklık olmadan nasıl davrandığını gösterdikleri için doğru başlangıç noktasıdır. Rahat ettiğinizde gelişmiş iş akışlarını uygulayabilirsiniz.

Temel fikir; dar bir otomasyonla başlamak, talimatları bir çalışma kitapçığı gibi yazmak, düşük riskli modda çalıştırmak ve yalnızca güvenilir davrandığında kapsamı genişletmektir. Değer, kaç otomasyon oluşturduğunuzdan çok, her birinin ne kadar tutarlı olduğundan gelir.

Bu yazıda ele aldıklarımızın üzerine inşa etmeye devam etmek için önerilen sonraki adımlarımız şunlar:

• Ajan modu ve daha geniş Cursor iş akışı kavrayışınızı Software Development with Cursor kursumuzla derinleştirin.
• Cursor 3.0’da nelerin yeni olduğuna bakın.