Automations Cursor: Panduan Praktis untuk Agen Koding Selalu Aktif

Bottleneck nyata dalam pengembangan perangkat lunak kini bukan lagi menulis kode, karena hampir setiap developer dalam tim, berapa pun ukurannya, kini memiliki sedikitnya satu agen yang membantu mereka merilis. Agen pengodean kini tertanam dalam alur kerja sehari-hari, dan implementasi bukan lagi bagian paling lambat dalam sistem.

Cursor Automations dibuat untuk menutup kesenjangan itu. Alih-alih berulang kali memicu agen dengan prompt, Anda menentukan kapan agen harus bertindak. Sebuah pemicu menyala, instruksi memandu apa yang dilakukannya, dan ia berjalan sendiri. Sebuah pull request dibuka, dan ia langsung ditinjau. Laporan bug masuk ke Slack, dan langsung ditangani. Jadwal berjalan, dan sebuah laporan dihasilkan.

Dalam tutorial ini, saya akan menunjukkan cara menyiapkan automations Cursor dari awal hingga akhir. Anda akan membangun dua automation: review PR, dan pemantau cakupan pengujian terjadwal. Sepanjang proses, saya akan menguraikan cara menyusun instruksi dan menghubungkan tools serta MCP agar automations berperilaku seperti yang kita harapkan.

Satu catatan sebelum Anda mulai. Automations masih dalam pengembangan, dan dasbor di cursor.com/automations terus berevolusi. Jika label menu atau tombol berubah saat Anda membacanya, logika dasarnya tetap sama.

Apa itu Cursor Automations?

Cursor automations adalah sistem untuk menjalankan cloud agent Cursor secara otomatis, dipicu oleh peristiwa di tools pengembangan Anda atau oleh jadwal yang Anda tentukan.

Dalam Agent mode Cursor, seperti yang dibahas di kursus Software Development with Cursor, Anda memulai setiap sesi dengan membuka chat dan mengetik prompt, dan agen berjalan di mesin lokal Anda selama Anda menemaninya.

Dalam automations, sinyal awal datang dari tempat lain dalam stack Anda, dan agen menjalankan tugasnya dalam sandbox cloud tanpa perlu Anda pantau.

Automations mencakup peristiwa pemicu yang saya ringkas dalam tabel di bawah, tetapi Anda juga dapat menyiapkan pemicu kustom menggunakan webhook. Satu automation dapat memiliki lebih dari satu pemicu dan akan berjalan setiap kali salah satunya aktif.

Masing-masing tipe pemicu tersebut menggantikan momen dalam hari Anda ketika sebelumnya Anda harus menyadari sesuatu, berganti konteks ke Agent mode Cursor, dan meminta bantuan. 

Pemicu pull request adalah yang paling mungkin Anda bangun terlebih dahulu. Berikut bagaimana siklus hidup satu PR terlihat sebelum dan sesudah Anda menambahkan automation untuk memantau repositori Anda.

Yang berubah pada kolom kedua bukanlah kecepatan setiap langkah, melainkan fakta bahwa perhatian Anda tidak lagi menjadi pembatas laju seluruh proses.

Cara kerja Cursor Automations di balik layar

Setiap automation mengikuti pipeline yang sama di balik layar. Saat pemicu yang Anda tetapkan menyala, Cursor memutar sandbox cloud baru, mengkloning repositori Anda ke dalamnya, dan meluncurkan agen yang mengikuti instruksi Anda menggunakan tools, koneksi MCP, dan model yang dikonfigurasi. Repositori itu tidak harus berada di GitHub: repositori yang dihosting di Cursor Origin, forge Git milik Cursor, juga berfungsi dengan cloud agent dan automations.

Agen memverifikasi output-nya sebelum selesai, lalu memposting hasilnya ke mana pun Anda konfigurasikan, apakah itu komentar PR, pesan Slack, tiket Linear, atau dengan membuka pull request baru.

Dua sifat membentuk setiap automation yang Anda bangun:

• Sandbox berjalan sepenuhnya di cloud Cursor, bukan laptop Anda. Ia terus berjalan bahkan saat mesin Anda mati.
• Setiap run dieksekusi secara terisolasi. Beberapa automation dapat berjalan paralel tanpa saling mengganggu. Cursor juga menyebutkan mereka menjalankan ratusan automation per jam secara internal.

Ada juga tool memori, seperti ditampilkan pada pratinjau di bawah, yang memungkinkan automation Anda menyimpan state antar run, yang akan penting nanti saat kita membangun pemantau cakupan terjadwal.

Saya akan kembali membahasnya saat Anda membangun pemantau cakupan terjadwal.

Cursor Automations versus Agent mode

Jika Anda sudah menggunakan Cursor secara rutin, pertanyaan kunci adalah kapan menggunakan automations alih-alih Agent mode. Saya tidak akan menggunakan Automations untuk tugas sekali jalan. Automations dibuat untuk pekerjaan yang berulang atau bergantung pada peristiwa eksternal.

Perbandingan cara keduanya berbeda berguna saat pilihannya tidak jelas:

Saya memandangnya begini. Jika sebuah tugas dimulai dengan “setiap kali” atau “kapan pun”, itu cocok untuk Automations.

Contohnya: “Setiap kali sebuah PR dibuka, atau kapan pun laporan bug masuk ke #support, buat tiket Linear.” Pemicunya berulang dan terprediksi.

Jika dimulai dengan “sekarang saya perlu me-refactor modul ini,” itu cocok untuk Agent mode. Anda yang menentukan kapan “sekarang”.

Jika Anda ingin menjelajahi Cursor sebelum mendalami automations, panduan lengkap Cursor 2.0 memandu Anda melalui antarmuka Agents, Composer, dan alur kerja multi-agen dengan proyek Python lengkap.

Mengakses Dasbor Automations

Dasbor automations Cursor berada di cursor.com/automations. Masuk dengan akun Cursor Anda, dan Anda akan masuk ke dasbor utama seperti di bawah ini:

Mari kita uraikan apa saja yang terlihat di dasbor.

Tile ringkasan atau indikator status di bagian atas

Tile memberi gambaran kesehatan dari semua yang pernah Anda jalankan. Termasuk:

• Total automations (berapa banyak yang Anda konfigurasikan) 
• Berhasil (run selesai, dengan tingkat keberhasilan)
• Gagal (run yang error)
• Riwayat run (saat diklik, menampilkan volume run dari waktu ke waktu)

Kotak input prompt

Kolom input adalah cara tercepat untuk membuat automation baru tanpa membuka formulir setup lengkap. Kita jelaskan tugasnya, dan Cursor menghasilkan struktur automation.

Jika Anda baru memulai, saya sarankan mulai di sini. Tentukan apa yang ingin Anda otomatisasi, lalu tulis seperangkat instruksi terstruktur untuk diikuti agen setiap kali pemicu aktif. 

Setelah menekan tombol panah, Cursor menggunakan instruksi tersebut untuk membuat automation bagi Anda, mengisi nama, pemicu, dan tools yang dibutuhkan.

Saya tidak akan memperlakukan instruksi ini sebagai prompt biasa, melainkan sebagai spesifikasi yang dijalankan agen setiap kali. Saya akan kembali membahas ini saat menunjukkan cara membangun automation pertama Anda nanti.

Toggle saya / tim dan tombol + automation baru

Toggle memfilter antara automation milik Anda dan automation tim. 

Tombol + New membuka halaman konfigurasi untuk menyiapkan automation baru:

+ New Automation adalah alternatif yang lebih lengkap dibanding kotak prompt inline jika Anda ingin mengonfigurasi pemicu, instruksi, dan koneksi tools secara manual dari nol.

Daftar automation yang sudah ada

Tabel menampilkan semua automation yang telah kita buat, termasuk tools yang digunakan dan riwayat run.

Mengklik salah satu akan membuka halaman pengaturan dan riwayat run-nya:

Bagian templat yang disarankan

Di bawah daftar automation sebelumnya terdapat kisi kartu templat. Templat menyediakan automation siap pakai yang dapat Anda modifikasi alih-alih memulai dari nol.

Templat automation Cursor adalah cara tercepat untuk menyalakan automation di hari pertama. Jika Anda membangun automation pertama, saya sarankan memeriksa apakah ada templat yang cocok dengan yang ingin Anda otomatisasi dan mulai dari sana.

Templat dapat memberi Anda gambaran tentang seperti apa instruksi yang baik, koneksi tool atau MCP apa yang diperlukan.

Pertimbangan akun dan biaya

Automations Cursor berjalan di infrastruktur cloud Cursor, yang memerlukan akses cloud agent, termasuk dalam paket berbayar. Setiap run mengonsumsi kredit berdasarkan penggunaan model dan waktu eksekusi.

Automations mendukung tiga tingkat visibilitas sesuai model izin:

• Pribadi: Hanya Anda yang dapat melihatnya, dan tagihannya ke akun Anda.
• Terlihat oleh Tim: Orang lain dapat melihat automations dan riwayat run Anda, tetapi tetap ditagihkan ke Anda.
• Dimiliki Tim. Automation ditagihkan ke pool bersama tim dan dikelola oleh admin tim.

Menentukan tingkat yang tepat penting karena menentukan kredit siapa yang digunakan automation setiap kali berjalan. Simpan eksperimen sebagai privat hingga Anda mempercayai output-nya. Setelah automation menjadi bagian dari alur kerja tim, Anda bisa memindahkannya ke tingkat milik tim.

Mode kegagalan utama adalah membiarkan automation berjalan terlalu luas, terlalu cepat. Jika ia terpicu pada setiap push di repo yang sibuk, penggunaan bisa cepat membengkak tanpa Anda sadari. Mulailah sempit, biarkan berjalan beberapa hari, tinjau seberapa sering ia aktif, lalu putuskan apakah akan memperluas atau menskalakannya.

Membangun Automation Cursor Pertama Anda: Review Kode PR Otomatis

Review kode PR adalah automation pertama yang tepat karena loop umpan baliknya pendek dan konsekuensi run yang buruk rendah. Jika agen memposting komentar yang berguna, kita langsung melihatnya di PR. Jika ia memposting sesuatu yang melenceng, kita abaikan, dan tidak ada yang dirilis.

Saya akan memandu Anda membangun automation pertama dalam lima langkah:

1. Menghubungkan repositori GitHub Anda
2. Menetapkan pemicu GitHub
3. Menulis instruksi agen (dengan struktur jelas dan hal yang harus dihindari)
4. Menambahkan tool komentar GitHub Pull Request
5. Mendeploy automation

Langkah 1: Menghubungkan repositori GitHub Anda

Sebelum agen dapat meninjau pull request, ia memerlukan akses ke repositori. Cursor mengakses repositori Anda melalui integrasi GitHub App native. Tanpa koneksi itu, agen automation tidak dapat melihat kode Anda, membaca diff PR, atau merespons dengan feedback, jadi tidak ada yang benar-benar berfungsi.

Jika Anda belum melakukannya:

1. Instal Cursor GitHub App di akun atau organisasi GitHub Anda dan berikan akses ke repositori yang ingin diawasi automations.
2. Hubungkan akun GitHub Anda di dasbor di tab Integrations. 

Setelah koneksi aktif, repositori Anda akan tersedia saat Anda mengonfigurasi pemicu automation.

Langkah 2: Menyiapkan pemicu

Dari dasbor automations:

1. Klik + New Automation untuk mulai membuat automation.
2. Beri nama automation. Anda bisa menamainya PR Code Review – Open & Push – Comment Only
3. Di bagian pemicu, klik Add trigger dan pilih GitHub. Pilih PR opened dan PR pushed sebagai peristiwa pemicu.
4. Pilih repositori target.

Jika Anda melewatkan langkah 1 atau ini pertama kalinya menghubungkan GitHub ke automations Cursor, Anda akan diminta untuk autentikasi. 

Pada pratinjau di bawah, saya menunjukkan cara mengonfigurasinya dan memilih repositori target setelah otorisasi selesai:

Catatan: Kita bisa menggabungkan beberapa peristiwa pemicu ke dalam satu automation ketika instruksinya tidak berubah bergantung pada peristiwa mana yang menyala. Namun jika kedalaman atau tujuan peninjauan berubah bergantung pada peristiwa, gunakan automation terpisah.

Kini automation mengetahui kapan harus berjalan. Langkah berikutnya adalah memberi tahu apa yang harus dilakukan.

Langkah 3: Menulis instruksi automation yang efektif

Instruksi adalah tuas terbesar untuk menentukan apakah automation kita menghasilkan output yang berguna. Agen menggunakannya untuk memahami seperti apa “baik” itu. Instruksi yang kabur menghasilkan hasil yang tidak konsisten.

Sebelum menulis instruksi, kita harus memahami apa yang kita definisikan. Kita bukan memberi prompt sekali jalan. Kita menetapkan perilaku yang akan diikuti agen setiap kali pemicu menyala. Kualitas automation bergantung pada sejelas apa kita menentukan perilaku tersebut.

Berikut struktur yang saya rekomendasikan:

• Tentukan peran: Menetapkan perspektif dan nada. Misalnya: “Anda adalah peninjau keamanan untuk pull request.”
• Tentukan tujuan: Jelaskan dengan jelas seperti apa keberhasilan. Misalnya: “Deteksi dan jelaskan dengan jelas kerentanan nyata.”
• Tentukan ruang lingkup: Tegaskan fokus agen. Misalnya: “Tinjau hanya kode yang ditambahkan atau diubah.”
• Uraikan alur kerja: Beri pendekatan yang jelas. Misalnya: “Inspeksi perubahan, telusuri input, dan verifikasi proteksi.”
• Tetapkan pengecualian: Nyatakan secara eksplisit apa yang harus diabaikan untuk mengurangi noise.
• Tentukan perilaku dan output. Bagaimana harus bertindak dan seperti apa hasilnya.
• Tetapkan batasan: Apa yang tidak boleh dilakukan.

Tulis instruksi automation seperti menulis runbook: spesifik, berurutan, dengan kriteria penerimaan yang jelas dan batasan eksplisit.

Contoh instruksi yang baik

Berikut instruksi yang saya gunakan untuk automation review kode PR ini. Anda dapat menyalinnya ke kotak input instruksi Anda, tetapi sesuaikan dengan kasus Anda:

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.

Berikut instruksinya di kotak input instruksi:

Prompt ini disederhanakan, tetapi tetap mengikuti struktur yang jelas dan spesifik. 

Contoh instruksi yang buruk

Hindari instruksi yang kabur seperti:

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

Tanpa struktur, batasan, dan prioritas, agen akan terpaksa menebak arti “isu”, yang menghasilkan umpan balik generik dan permukaan alih-alih output yang andal.

Langkah 4: Menambahkan tools

Buka panel tools di dalam editor automation. Untuk automation ini, kita akan pergi ke bagian GitHub dan memilih tool Comment on Pull Request. Pastikan persetujuan PR dinonaktifkan, seperti pada pratinjau di bawah, sehingga automation hanya dapat berkomentar, bukan menyetujui perubahan.

Tool Comment on Pull Request memungkinkan agen memposting temuan kembali ke PR. Tidak memerlukan koneksi terpisah karena didukung oleh Cursor GitHub App yang sama yang Anda otorisasi pada Langkah 1.

Jika kita ingin mengirim output ke layanan lain (seperti memposting ke Slack), kita akan memilih tool yang sesuai atau menambahkan koneksi MCP. Untuk automation ini, tool komentar sudah cukup.

Langkah 5: Mendeploy dan memantau run pertama Anda

Setelah pemicu, instruksi, dan tools ditetapkan, kita klik Create untuk menyimpan automation, yang akan membuka halaman pengaturan automation, seperti terlihat di bawah:

Karena kita sudah mendeploy automation, kita perlu memicu run dan mengamati apa yang dihasilkan agen.

Buka draft pull request di repositori Anda yang terhubung. Ini memicu pemicu PR opened, dan entri baru akan muncul di Riwayat run dalam hitungan detik, seperti terlihat di bawah:

Buka run tersebut dan periksa tiga hal:

• Waktu eksekusi: Berapa lama run berlangsung. Ini bervariasi berdasarkan ukuran diff, model, dan kompleksitas instruksi.
• Pemanggilan tool: File dan tools apa yang digunakan? Jika agen membaca file yang tidak terkait, tinjau instruksi Anda.
• Output: Apa yang diposting kembali ke GitHub. Bandingkan dengan instruksi Anda.

Di bawah ini adalah gambaran run automation saya. Anda dapat melihat ia berjalan selama enam menit, melakukan beberapa aksi, dan memposting ulasan PR menggunakan tool PostReviewCommentOnPr:

Di bawah ini contoh komentar yang diposting agen pada PR saya:

Terkadang output bisa melenceng, dan ketika itu terjadi, biasanya masalahnya ada pada instruksi. Kita sesuaikan instruksi yang mengendalikan perilaku yang ingin diubah, push commit baru untuk memicu run lain, dan tinjau hasilnya.

Untuk run awal ini, kita harus mulai sederhana agar risikonya rendah. Dalam kasus ini, kita batasi automation hanya berkomentar, yang memungkinkan kita memastikan perilakunya dengan aman. Setelah output konsisten, kita pindahkan ke penggunaan nyata lalu hubungkan tools lain selain GitHub untuk memperluas kemampuannya.

Menghubungkan Lebih Banyak Tools dengan MCP

Automation review PR yang baru kita bangun berjalan di GitHub. Ia membaca diff dan memposting komentar ke pull request menggunakan tool GitHub Comment on Pull Request. Tetapi jika kita ingin agen melakukan lebih dari sekadar meninjau kode, kita perlu menghubungkan tools lain. Di situlah Model Context Protocol (MCP) berperan.

MCP adalah antarmuka standar yang memungkinkan agen menggunakan tools eksternal tanpa integrasi kustom. Tanpanya, setiap tool memerlukan setup dan pemeliharaan sendiri. 

Dengan MCP, setelah kita menghubungkan tool yang didukung di panel tools automation, agen dapat menggunakannya melalui antarmuka yang sama.

MCP memungkinkan automation yang sama melakukan lebih banyak dan bertindak di tools lain. Automation review PR Anda sudah berkomentar di GitHub. Tambahkan Slack, maka ia bisa memposting pembaruan ke kanal. Tambahkan Linear, maka ia bisa membuat tiket. Tambahkan Datadog, maka ia bisa menarik log. Setiap koneksi memperluas apa yang dapat dilakukan automation tanpa mengubah logika intinya.

Automations Cursor menyertakan rangkaian integrasi MCP bawaan seperti Slack, Linear, ClickUp, Datadog, Notion, dan lainnya. Karena MCP adalah standar terbuka, kita dapat menghubungkan tool yang kompatibel dengan cara yang sama.

Anda akan menemukan MCP di Tools -> MCP server pada halaman pengaturan automations. Klik tombol + New Connection untuk menelusuri, lalu instal dan hubungkan tool yang Anda butuhkan.

Berikut pratinjau cara menambahkannya:

Di bagian berikutnya, saya akan memandu Anda menambahkan koneksi MCP Slack ke automation review kode PR.

Menambahkan koneksi MCP Slack

GitHub membuat automation membaca dan mengomentari kode kita. Slack membuatnya berkomunikasi dengan tim.

Dari panel Tools, klik Add Tool or MCP, pilih MCP Server, lalu pilih +New Connection. Di panel yang terbuka, cari Slack dan pilih MCP server Slack. 

Slack biasanya sudah terinstal, tapi jika belum, instal dan ikuti alur OAuth untuk mengotorisasi workspace Anda. Setelah terhubung, ia akan muncul di panel tools Anda, seperti yang saya tunjukkan pada gambaran berikut:

Kita tidak memilih kanal target saat setup koneksi. MCP memberikan agen automation akses tingkat workspace ke semua kanal publik. Kita mengontrol lokasi postingan dengan menyebutkan nama kanal dalam instruksi, misalnya, "Kirim pesan Slack ke #pr-alerts jika ditemukan isu kritis."

Catatan: MCP Slack hanya berfungsi dengan kanal publik, dan kanal target harus sudah mengundang bot Cursor sebelum automation dapat memposting. Setelah alur OAuth, bot Cursor akan muncul di workspace Slack Anda. Buka kanal dan jalankan /invite @Cursor untuk menambahkannya.

Jika Anda tidak melihat bot @Cursor , otorisasi mungkin gagal. Buka dashboard ->  integrations, klik Manage di sebelah Slack, dan jalankan ulang OAuth.

Jika Anda ingin memperdalam MCP itu sendiri, tutorial FastMCP 2.0 kami membahas pembuatan MCP server kustom dari nol dan mengintegrasikannya ke Cursor.

Menggabungkan pemicu dan tools

Dengan MCP Slack terhubung, kita dapat memperluas automation review kode PR. Kita akan tetap menggunakan pemicu PR GitHub yang sama dan tool komentar PR GitHub. Namun kini agen juga dapat memposting temuan kritis ke #pr-alerts melalui MCP Slack.

Tambahkan blok ini ke akhir instruksi yang kita tulis di langkah 3 saat membangun automation pertama:

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.

Baris terakhir itu lebih penting dari kelihatannya. Tanpanya, #pr-alerts bisa cepat penuh dengan notifikasi “semua aman” dan kehilangan nilainya. Bagi saya, memberi tahu agen kapan tidak bertindak sama pentingnya dengan kapan harus bertindak.

Di bawah ini adalah output dari run PR uji di repositori saya.

Tampilan komentar yang diposting agen automation pada PR open di GitHub saya (via tool komentar PR GitHub):

Tampilan notifikasi Slack yang dikirim agen automation di kanal Slack #pr-alerts untuk run yang sama via koneksi MCP Slack:

Pada titik ini, Anda memiliki automation yang berfungsi untuk meninjau setiap PR, memposting komentar di GitHub, dan mengeskalasi isu kritis ke Slack. Itulah pola intinya. 

Di bagian berikutnya, kita akan membangun automation kedua mengikuti alur yang sama: sebuah pemicu, instruksi, dan tools yang dibutuhkan agen untuk menghasilkan output.

Membangun Automation Kedua: Pemantau Cakupan Uji Terjadwal

Automation review kode PR yang kita bangun bereaksi terhadap peristiwa GitHub. Automation terjadwal bekerja berbeda. Kita menentukan kapan agen harus berjalan, dan ia dieksekusi pada waktu itu terlepas dari apa yang terjadi di repo.

Automation yang kita bangun di sini berjalan setiap hari pukul 9 pagi, meninjau kode yang di-merge ke branch main dalam 24 jam terakhir, mengidentifikasi area dengan cakupan pengujian yang tidak memadai, dan memposting ringkasan ke #repo-coverage di Slack.

Menyiapkan pemicu dan tool cron

Dari dasbor automations:

• Klik + New untuk membuat automation baru.
• Namai Daily Coverage Check – Main Branch.

Konfigurasikan pemicu

• Di bawah Triggers, pilih Scheduled.
• Pilih Every... > Day dan setel waktu ke 9:00 AM.
• Jika Anda membutuhkan format lain, seperti hanya hari kerja, gunakan Custom (cron)
• Karena pemicu terjadwal tidak menyimpulkan repositori, pilih repositori dan branch target (main).

Tambahkan tool Send to Slack

Di sini, saya akan memperkenalkan tool Send to Slack yang tersedia di pengaturan automations. Ini berbeda dari MCP Slack yang digunakan sebelumnya. Kita menggunakannya untuk mengirim pesan ke kanal spesifik, sementara MCP Slack memberikan akses tingkat workspace dan memungkinkan agen memposting ke kanal mana pun yang didefinisikan dalam instruksi.

Untuk menambahkan tool Send to Slack, pilih dari bagian tools dan tentukan kanal target untuk output automation. Berikut tampilannya:

Menulis instruksi untuk tugas terjadwal

Dalam automation review PR, agen bereaksi terhadap pull request dan memposting umpan balik. Pada automations terjadwal, tidak ada input masuk. Agen memulai tugas sendiri, jadi kita harus jelas tentang dari mana memulai, apa yang diperiksa, dan apa yang diposting.

Tool memori penting di sini. Perbandingan cakupan hanya berfungsi jika agen mengetahui angka kemarin. Kita harus memberi tahu kunci mana yang dibaca, apa yang dibandingkan, dan apa yang disimpan di akhir. Jika ini tidak jelas, hasil dapat bervariasi antar run.

Berikut set instruksi yang saya gunakan:

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

Di bawah ini, saya tunjukkan output dari automation terjadwal saya pada pukul 9 pagi.

Berikut gambaran automation. Dalam kasus saya, cakupan tetap di atas ambang, jadi hanya memposting status hijau di kanal Slack:

Berikut pesan Slack-nya. Ini adalah run cakupan uji pertama, jadi saya tidak berharap banyak. Anda juga dapat melihat bahwa run disimpan ke memori sebagai baseline untuk perbandingan berikutnya:

Melihat run di atas, dua bagian instruksi menonjol. 

Pertama, ia mendefinisikan jalur peringatan dan jalur hijau. Jalur hijau wajib. Jika kita hanya mendefinisikan apa yang terjadi saat ada masalah, automation akan diam saat semuanya baik-baik saja. Di kanal monitoring, keheningan itu terlihat seperti kegagalan. Status hijau mengonfirmasi run selesai.

Kedua, pembacaan dan penyimpanan memori eksplisit. Agen memiliki tool memori, tetapi ia tidak akan menggunakannya secara andal untuk perbandingan kecuali diinstruksikan. Jika kita biarkan implisit, hasil dapat bervariasi antar run. Kita harus menentukan dengan tepat kunci mana yang dibaca, apa yang dibandingkan, dan apa yang disimpan.

Pada gambar di bawah, Anda dapat melihat bahwa agen menyimpan automation saya:

Pada bagian berikutnya, saya akan membahas kesalahan umum dan praktik terbaik agar Anda mendapatkan lebih banyak manfaat dari automations.

Cursor Automations: Jebakan Umum dan Praktik Terbaik

Sebagian besar masalah pada automations berasal dari satu set kecil kesalahan yang dapat diprediksi. Mudah dihindari setelah Anda mengetahuinya, tetapi mahal untuk di-debug jika tidak.

Kesalahan umum yang harus dihindari

• Instruksi kabur: Ini adalah mode kegagalan umum. Kalimat seperti “tinjau kodenya,” “periksa isu,” atau “ringkas perubahan” memaksa agen menebak maksud Anda, yang menghasilkan output tidak konsisten. Jika sebuah kalimat memiliki verba tanpa objek atau kondisi yang jelas, tulis ulang sebelum deployment.
• Ruang lingkup terlalu luas:. Jangan gabungkan pemeriksaan keamanan, gaya, performa, dan cakupan uji dalam satu automation. Ini membuat kegagalan lebih sulit di-debug. Automation yang sempit lebih mudah dipahami. 
• Melewati fase kalibrasi: Jangan aktifkan pengaturan seperti auto-approve atau auto-merge terlalu awal. Jadikan run awal minimal hanya komentar. Run ini mengungkap edge case di basis kode Anda. Perlakukan fase ini sebagai validasi sebelum produksi.
• Konfigurasi kanal Slack: Pemicu Slack hanya bekerja pada kanal publik, jadi jika automation Slack tampak tidak melakukan apa-apa, periksa visibilitas kanal Anda dan pastikan bot @Cursor diundang ke kanal tersebut.

Praktik terbaik untuk automations yang andal

• Satu pekerjaan per automation: Setiap automation harus melakukan satu hal yang didefinisikan dengan jelas. Ini membuat kegagalan lebih mudah diisolasi dan perbaikan lebih mudah diterapkan.
• Mulai dari state bersih: Commit working tree Anda sebelum membiarkan agen membuat perubahan sehingga Anda selalu memiliki diff yang jelas untuk dibandingkan.
• Perlakukan beberapa run pertama sebagai kalibrasi: Harapkan sedikit noise di awal, tinjau output, sesuaikan instruksi, dan jalankan ulang hingga perilaku stabil.
• Gunakan nama yang jelas dan deskriptif: Nama seperti PR Code Review – Open & Push – Comment Only lebih berguna dibanding label generik saat Anda meninjaunya nanti.
• Tinjau riwayat run secara dini dan sering: Dalam beberapa minggu pertama, ini membangun intuisi tentang seperti apa perilaku normal, yang memudahkan mendeteksi masalah nanti.

Penutup

Cursor Automations memindahkan pengodean berbasis agen dari alur kerja interaktif ke sistem berbasis peristiwa. Di Agent mode Cursor, kita membuka chat dan mem-prompt agen untuk meninjau kode, me-refactor fungsi, atau menginvestigasi isu. Di automations, kita tidak memulai pekerjaan secara langsung. Pemicu seperti pull request, pesan Slack, atau jadwal memulai agen secara otomatis, dan ia menyelesaikan tugas sendiri. Pergeseran utamanya adalah pekerjaan rutin berpindah dari antrean manual ke sistem yang berjalan di latar belakang.

Dalam tulisan ini, saya telah memandu Anda membangun dua automation: review kode PR dan pemantau cakupan terjadwal. Keduanya sengaja dibuat sederhana, tetapi memberi titik awal yang tepat karena menunjukkan bagaimana sistem berperilaku tanpa kompleksitas tambahan. Setelah Anda nyaman, Anda dapat menerapkan alur kerja lanjutan.

Gagasan utamanya adalah mulai dengan satu automation yang sempit, tulis instruksi seperti runbook, jalankan dalam mode berisiko rendah, dan hanya perluas setelah perilakunya andal. Nilainya lebih berasal dari seberapa konsisten setiap automation, bukan dari seberapa banyak yang Anda bangun.

Untuk terus membangun dari yang kita bahas di tulisan ini, berikut langkah lanjutan yang kami rekomendasikan:

• Perdalam pemahaman Anda tentang Agent mode dan alur kerja Cursor yang lebih luas dengan kursus Software Development with Cursor kami.
• Lihat apa yang baru di Cursor 3.0.