GitHub Agentic Workflows memindahkan tugas repositori dari jendela percakapan

Setiap pagi, seseorang membuka tab yang sama: isu kemarin, proses build yang gagal, dokumentasi usang, dan pull request yang menunggu perhatian. Sebagian besar pekerjaan itu memerlukan pertimbangan. Hampir tidak ada yang harus dimulai dengan percakapan baru di jendela obrolan AI.

GitHub merilis Agentic Workflows untuk penggunaan umum pada 28 Oktober 2026. Proyek sumber terbuka GitHub Next ini mengubah instruksi Markdown menjadi alur GitHub Actions standar, sehingga agen pemrograman dapat menjalankan tugas repositori berdasarkan peristiwa atau jadwal yang dikonfigurasi. Unit otomatisasinya bergeser dari prompt pribadi menjadi tugas repositori yang memiliki versi. Pengumuman rilis umum GitHub menetapkan tanggal rilis tersebut.

Pertanyaan yang berguna adalah tugas mana yang layak ditangani dengan cara ini. Panduan ini membahas pemilahan isu, diagnosis CI, dan pemeliharaan dokumentasi, lalu menjelaskan penerapan pertama yang memberi pengelola bukti yang dapat diperiksa serta beban peninjauan yang terkendali.

Contoh dokumentasi resmi CI Doctor dari GitHub menampilkan alur kerja yang melaporkan kegagalan CI. Contoh historis, lisensi MIT; ukurannya diubah dengan tambahan margin. Sumber gambar · Lisensi dan catatan gambar.

Tugas repositori membutuhkan lebih dari prompt berulang

Orang yang memakai asisten pemrograman terus memberikan konteks. Mereka menyadari saran yang tidak relevan, mempersempit tugas, dan memutuskan kapan pekerjaan sudah cukup. Alur terjadwal harus menetapkan batas tersebut sebelum eksekusi dimulai.

Hal ini mengubah bentuk instruksi yang baik. “Perbaiki repositori ini” membiarkan agen menentukan prioritas sendiri. “Tinjau isu yang dibuka sejak laporan harian terakhir, kelompokkan laporan terkait, dan usulkan isu yang memerlukan balasan pengelola” memberinya masukan terbatas dan keluaran yang jelas.

Perbedaannya bersifat operasional. Tugas yang berguna membutuhkan pemicu, cakupan, izin alat, tujuan keluaran, dan kondisi berhenti. Juga harus ada orang yang membaca hasilnya. Mengotomatiskan laporan tanpa menetapkan pembacanya bisa sekadar mengganti antrean isu yang terabaikan dengan antrean laporan yang terabaikan.

Halaman utama dokumentasi GitHub, diperiksa pada 2 November, menjelaskan jadwal dan peristiwa yang dikonfigurasi serta perubahan hasil generasi yang ditinjau sebelum digabungkan. Agentic Workflows melengkapi CI dan CD konvensional: agen menyelidiki dan mengusulkan, sedangkan pemeriksaan deterministik tetap memastikan kontrak yang sudah diuji.

Menurut kami, ini seperti antrean pemeliharaan yang dipasangi mesin. Mesin dapat bekerja di antara sesi manusia, tetapi antreannya tetap membutuhkan prioritas, penanggung jawab, dan volume pekerjaan yang wajar.

Markdown mencatat maksud; Actions menyediakan mesin eksekusi

Agentic Workflows memakai Markdown dengan frontmatter konfigurasi. Kompilernya menghasilkan YAML Actions, sehingga tugas penalaran ditempatkan dalam otomatisasi repositori yang sudah dikenal, bukan layanan orkestrasi tersendiri untuk setiap tim.

Ini membantu peninjauan. Pengelola dapat membaca maksud tugas dalam bentuk prosa dan memeriksa konfigurasi eksekusinya. Perubahan tugas mengikuti proses pull request yang sama dengan perubahan alur build. Artefak hasil kompilasi penting karena menyatakan apa yang benar-benar dijalankan runner.

Namun, instruksi dan konfigurasi eksekusi masih dapat berbeda makna. Prompt yang meminta ringkasan mungkin memiliki alat untuk perubahan jauh lebih luas. Izin yang terdengar sepele mungkin membuka materi yang tidak diperlukan. Tinjau tujuan yang dinyatakan sekaligus kemampuan yang diberikan untuk mencapainya.

Diagram penjelasan orisinal berdasarkan pengumuman rilis umum GitHub dan dokumentasi keluaran terkendali. Diagram ini menggambarkan alur konseptual, bukan konfigurasi repositori tertentu.

Pengumuman 28 Oktober menyatakan bahwa alur ini memakai kembali kelompok runner dan batas kebijakan yang ada. Ini keuntungan integrasi bagi tim yang sudah mengelola Actions. Artinya, pemilik repositori juga perlu melibatkan penanggung jawab akses runner, rahasia, dan kebijakan organisasi saat alur menyentuh proyek sensitif.

Pemilahan isu harian merupakan awal yang masuk akal

Bayangkan repositori sumber terbuka yang menerima laporan bug, permintaan fitur, dan pertanyaan dukungan. Alur harian mengelompokkan isu baru, menemukan rincian reproduksi yang kurang, lalu membuat satu ringkasan untuk pengelola. Pada tahap awal, alur tidak menutup isu atau mengubah statusnya.

Ini tugas pertama yang baik karena keluarannya menghemat pengumpulan konteks dan mudah ditinjau. Setiap klaim harus menautkan isu sumber. Usulan duplikat harus menjelaskan perilaku yang sama, bukan hanya kemiripan judul.

Tentukan sejauh mana agen boleh menyimpulkan. “Kedua isu tampak terkait karena sama-sama gagal setelah penyegaran token” berguna. Menyatakan akar penyebab tanpa memeriksa kode atau log terkait menimbulkan kepastian palsu. Alur harus membedakan observasi, hipotesis, dan langkah berikutnya.

Tentukan pula yang perlu dihilangkan. Hari tanpa isu baru cukup menghasilkan catatan singkat tanpa perubahan. Isu berulang yang belum selesai dapat tetap ditautkan di tempat yang sama, bukan menuntut perhatian baru setiap pagi. Beban peninjauan juga merupakan metrik produk untuk otomatisasi internal.

Contoh alur GitHub, diperiksa pada 2 November, mencakup status repositori dan pemilahan isu. Jadikan templat sebagai awal: label, harapan respons, dan kebiasaan komunitas tetap menentukan pemilahan yang baik.

Diagnosis CI harus menghasilkan penjelasan yang dapat diuji

Tugas ilustratif kedua dimulai ketika build gagal. Alih-alih meminta pengelola membuka semua log, agen membaca eksekusi gagal dan perubahan terkait, menemukan kegagalan bermakna pertama, lalu mengusulkan penyelidikan terarah. Bukti dapat ditautkan dalam isu atau keluaran lain yang dikonfigurasi.

Kata kuncinya adalah bermakna. Unduhan dependensi gagal, asersi gagal, dan runner kehabisan sumber daya membutuhkan respons berbeda. Log bisa memuat puluhan kesalahan lanjutan setelah masalah sebenarnya. Diagnosis yang berguna menunjuk sinyal relevan paling awal dan menjelaskan artinya.

Wajibkan pemisahan kejadian dari kemungkinan penyebab. “Tes integrasi melewati batas waktu saat menunggu basis data” adalah observasi. “Fixture bersama mungkin membocorkan status antarpekerja paralel” tetap hipotesis sampai didukung bukti. Tes atau perintah reproduksi membuat hipotesis dapat ditindaklanjuti.

Jangan langsung memberi izin menulis ulang aplikasi. Mulailah dengan diagnosis dan deduplikasi. Jika beberapa eksekusi gagal karena alasan sama, perbarui pelacakan yang ada. Jika tidak, otomatisasi justru memperbanyak gangguan dari pemeriksaan yang tidak stabil.

GitHub menyebut penyelidikan kegagalan CI sebagai penggunaan rilis umum dan menyediakan contoh CI Doctor di galeri resmi. Nilai yang perlu diukur ialah seberapa sering penjelasannya membantu keputusan pengelola, bukan jumlah paragraf yang ditulis agen.

Pemeliharaan dokumentasi membutuhkan sumber acuan yang jelas

Dalam skenario ketiga, repositori menambahkan opsi baris perintah tetapi panduan masih memakai sintaks lama. Tugas agentik dapat memeriksa perubahan, membandingkannya dengan dokumentasi, lalu mengusulkan pembaruan kecil melalui pull request.

Tugas ini membutuhkan urutan otoritas eksplisit. Apakah keluaran --help menjadi acuan? Apakah skema dihasilkan dari kode? Apakah panduan publik sengaja hanya menjelaskan opsi stabil? Tanpa aturan, agen mungkin menyalin detail internal atau mempertahankan contoh usang karena muncul di beberapa berkas.

Batasi keluaran awal. Satu opsi, satu contoh, dan satu penjelasan lebih mudah ditinjau daripada penulisan ulang seluruh halaman. Minta tautan ke kode atau keluaran yang mendukung perubahan, beserta validasi yang dilakukan.

Dokumentasi bisa berisi instruksi sekaligus informasi. Agen harus menganggap materi bacaan sebagai data tugas kecuali berasal dari konfigurasi alur yang berwenang. Komentar isu berbahaya atau contoh yang diubah dapat mencoba mengalihkan tugas. Cakupan baik dan izin terbatas mengurangi akibatnya, tetapi tidak membuatnya mustahil.

Pengumuman rilis umum 28 Oktober menyebut pembaruan dokumentasi dan penulisan tes sebagai penggunaan yang didukung. Kegunaannya bergantung pada kejelasan perubahan yang dapat diterima dan bukti yang diperlukan sebelum penggabungan.

Akses baca saja membatasi kuasa, bukan menjamin kebenaran

GitHub menjelaskan perlindungan berlapis: akses baca saja secara default, eksekusi terisolasi, firewall, keluaran terkendali yang divalidasi, dan deteksi ancaman. Kontrol tersebut menangani bagian eksekusi berbeda. Ini bukan jaminan bahwa penalaran agen selalu aman atau benar. GitHub, 28 Oktober 2026.

Referensi keluaran terkendali, diperiksa pada 2 November, mendokumentasikan jenis keluaran seperti pembuatan isu dan pull request. Gagasan pentingnya memisahkan hasil usulan agen dari langkah berhak khusus yang menerapkan operasi yang diizinkan.

Operasi tervalidasi masih bisa membawa kesimpulan buruk. Isu berformat benar dapat mendiagnosis penyebab yang salah. Pull request yang diizinkan bisa menimbulkan regresi. Batas eksekusi dan peninjauan rekayasa menjawab pertanyaan berbeda, sehingga keduanya dibutuhkan.

Daftar periksa adopsi orisinal. Empat pertanyaan membantu menilai tugas repositori, bukan menyertifikasi keamanan eksekusi agen.

Alur pertama harus punya tombol berhenti yang jelas dan anggaran kecil

Panduan mulai cepat resmi, diperiksa pada 2 November, mensyaratkan GitHub CLI, repositori dengan akses tulis, Actions aktif, dan akun AI. Sistem yang didokumentasikan ialah Linux, macOS, atau Windows dengan WSL. Contoh tugasnya berupa laporan harian status repositori.

1. Pilih repositori dan penanggung jawab. Mulailah di tempat yang memungkinkan semua keluaran diperiksa dan tugas mudah dinonaktifkan. Tentukan siapa menangani gangguan atau konten tak terduga.
2. Pastikan akses akun dan Actions. Periksa gh --version dan gh auth status, lalu persyaratan mesin dalam dokumentasi resmi.
3. Pasang ekstensi CLI. Perintahnya ialah gh extension install github/gh-aw.
4. Tambahkan contoh terpandu. Dari akar repositori, jalankan gh aw add-wizard githubnext/agentics/repo-status. Tinjau mesin, autentikasi, dan pilihan eksekusi awal.
5. Tinjau sumber dan alur hasil kompilasi. Periksa Markdown, berkas Actions, izin, jenis keluaran, jadwal, serta akses log dan artefak sebelum menerima perubahan.
6. Jalankan sekali dan baca seluruh hasilnya. Cocokkan tautan dan klaim dengan repositori. Catat temuan berguna, kesalahan, biaya, dan waktu peninjauan.
7. Tetapkan kebijakan operasi terbatas. Tentukan waktu eksekusi, batas pengeluaran, perubahan yang diizinkan, dan kondisi untuk menonaktifkan atau merevisi tugas.

Gunakan mekanisme kredensial yang didukung penyedia dan kontrol rahasia repositori. Token tidak perlu ditempel ke isi Markdown. Aksesnya harus sesuai tugas dan kebijakan organisasi.

Pengumuman menyediakan produk di github.com bagi paket Free, Team, dan Enterprise, dengan lisensi Copilot untuk mesin default Copilot CLI. Ketersediaan paket bukan janji panggilan model atau waktu runner gratis tanpa batas. Mesin lain memiliki pengaturan dan penagihan sendiri. Sumber: GitHub.

Otomatisasi bisa menambah peninjauan jika yang diukur keliru

Rilis umum mencakup prakiraan anggaran lebih baik melalui gh aw forecast, pilihan mesin baru, dan perutean model. Fitur ini membantu perencanaan, tetapi prakiraan bukan batas pengeluaran atau tagihan akhir. Rincian rilis.

Dalam uji coba, ukur keluaran berguna yang diterima, waktu meninjau, duplikasi, dan klaim salah. Jumlah eksekusi adalah konteks, bukan ukuran keberhasilan. Sepuluh laporan bermanfaat bisa lebih bernilai daripada seratus percobaan otonom yang perlu dibereskan.

Alur perlu dipelihara ketika repositori berubah. Label berganti nama, perintah build berpindah, dan proses rilis berkembang. Versi tugas memungkinkan perubahan ditinjau secara sengaja. Penanggung jawab mencegah otomatisasi yang dahulu berguna menjadi sumber saran usang permanen.

Perubahan alur sama pentingnya dengan perubahan tugas rekan kerja

Tinjau perubahan tanggung jawab secara eksplisit. Ringkasan harian yang berubah menjadi pelabelan otomatis memperluas dampak. Diagnosis yang berubah menjadi usulan kode memperluasnya lagi. Setiap tahap membutuhkan alasan, penanggung jawab peninjauan, dan bukti dari cakupan sebelumnya.

Uji dengan situasi yang dikenal: hari tenang, isu tidak lengkap, kegagalan CI berulang, dan tugas yang tidak dapat diselesaikan. Kasus terakhir harus menyebut bukti atau akses yang kurang dan berhenti pada batas tepat. Rekayasa cerita yang meyakinkan lebih buruk daripada hasil yang jelas belum lengkap.

Rencanakan pemulihan. Jika alur membuka isu salah atau mengusulkan perubahan tidak sesuai, tim harus tahu cara menghentikan eksekusi mendatang dan menemukan keluaran konfigurasi terdampak. Riwayat dan catatan eksekusi menghubungkan perilaku dengan instruksi serta izin tertentu.

Itu juga alasan tidak menyalakan banyak templat sekaligus. Dengan satu tugas, manfaat dan beban mudah dikenali. Dengan tugas tumpang tindih, isu yang sama bisa diringkas, dilabeli ulang, didiagnosis, dan ditulis ulang sebelum ada keputusan mengenai intervensi berguna. Perluas berdasarkan nilai terbukti, bukan slot otomatisasi tersedia.

Otomatisasi dipercaya ketika keputusan berikutnya lebih jelas

Agentic Workflows menjadikan penalaran berulang sebagai aset repositori yang memiliki konfigurasi, riwayat, catatan, dan penanggung jawab. Ini langkah berguna melampaui meminta asisten memeriksa antrean yang sama berulang kali.

Alur pertama terbaik ialah yang keluarannya dapat dinilai besok pagi. Jika menunjuk bukti tepat, mematuhi cakupan, dan menyisakan keputusan kecil yang konkret bagi pengelola, tugas itu berguna. Izin lebih luas dapat menunggu sampai pola ini andal.

Sumber

• GitHub: Agentic Workflows tersedia secara umum, 28 Oktober 2026.
• Dokumentasi dan contoh GitHub Agentic Workflows, diperiksa pada 2 November 2026.
• Panduan mulai cepat resmi, diperiksa pada 2 November 2026.
• Referensi keluaran terkendali, diperiksa pada 2 November 2026.
• Rilis proyek, untuk perubahan per versi; tanggal rilis umum 28 Oktober berbeda dari tanggal rilis paket masing-masing.

Hubungkan peninjauan dengan sumbernya

Telli.sh merupakan salah satu pilihan untuk menyimpan materi sumber yang diizinkan dan catatan di balik keputusan teknis. Buat ruang catatan.