Claude Code /loop: Workflow Koding Sehari-hari yang Aman

Claude Code /loop: Cara Memakai Loop untuk Workflow Koding Sehari-hari

Ada jenis pekerjaan coding yang tidak sulit, tetapi merepotkan karena kita harus terus kembali untuk mengeceknya.

Build masih berjalan. Deploy belum selesai. Reviewer belum membalas. Sebuah test kadang gagal, tetapi belum ada pola yang jelas. Migrasi sudah masuk batch ketiga, sementara kita belum yakin apakah metrik error tetap aman. Pada situasi seperti ini, masalahnya bukan kekurangan kemampuan untuk menulis kode. Masalahnya adalah perhatian: seseorang harus ingat untuk mengecek lagi, membaca perubahan terbaru, lalu menentukan langkah berikutnya.

Claude Code menyediakan /loop untuk pekerjaan semacam itu. Ia menjalankan prompt berulang kali di dalam sesi Claude Code yang masih aktif. Intervalnya dapat ditentukan, dipilih secara adaptif oleh Claude, atau menggunakan prompt pemeliharaan bawaan. Karena setiap iterasi kembali ke konteks sesi, /loop dapat melakukan lebih dari sekadar menjalankan perintah yang sama: ia bisa melihat status terbaru, menilai apakah kondisi sudah berubah, dan mengambil tindakan yang memang sudah kita izinkan.

Tetapi /loop bukan daemon production, bukan scheduler permanen, dan bukan izin untuk membiarkan coding agent mengubah repo tanpa batas. Ia paling berguna sebagai penjaga pekerjaan sementara: cukup lama untuk menemani CI, pull request, deploy, atau eksperimen, tetapi tetap dekat dengan operator dan konteks sesi.

Artikel ini memisahkan dua hal dengan tegas:

• Fakta dokumentasi resmi: perilaku yang dijelaskan dalam dokumentasi Scheduled Tasks Claude Code.
• Rekomendasi operasional: pola kerja yang saya sarankan agar loop aman, hemat, dan mudah dihentikan. Ini bukan jaminan dari Anthropic.

1. Model mental yang tepat: /loop adalah polling di dalam sesi

Menurut dokumentasi resmi, Scheduled Tasks membuat Claude menjalankan kembali sebuah prompt pada interval tertentu. /loop adalah cara paling cepat untuk membuat scheduled task berulang selama sesi tetap terbuka. Contoh dasarnya:

/loop 5m check whether the deployment finished and report the result

Claude mengubah interval tersebut menjadi jadwal cron, lalu mengonfirmasi cadence dan ID task. Prompt akan dijalankan di antara turn, bukan ketika Claude sedang berada di tengah respons. Jika Claude masih sibuk saat jadwal tiba, task menunggu sampai turn aktif selesai.

Karakter ini penting. /loop bukan proses paralel yang bebas menginterupsi semua pekerjaan. Ia masuk antrean dengan prioritas rendah dan berjalan ketika sesi siap menerimanya.

Dokumentasi juga menyebut task /loop bersifat session-scoped:

• task hidup di percakapan saat ini;
• membuka percakapan baru menghapus scheduled task dari konteks aktif;
• claude --resume atau claude --continue dapat memulihkan task yang belum kedaluwarsa;
• recurring task hanya dipulihkan jika masih berada dalam masa tujuh hari sejak dibuat;
• one-shot task hanya dipulihkan jika waktu jadwalnya belum lewat;
• background Bash dan monitor task tidak dipulihkan ketika resume.

Task hanya fire ketika Claude Code berjalan dan idle. Menutup terminal atau membiarkan sesi berakhir menghentikan eksekusinya. Claude Code dapat membawa task ke background session jika sesi di-background-kan, tetapi itu tetap bukan scheduler independen.

Ada satu batas lain yang sering terlewat: tidak ada catch-up untuk jadwal yang terlewat. Misalnya, loop dijadwalkan setiap lima menit, tetapi Claude sibuk mengerjakan satu turn selama 17 menit. Setelah idle, prompt dijalankan sekali, bukan tiga kali untuk mengganti semua interval yang terlewat.

Itu sebabnya model mental yang sehat bukan "cron production di dalam terminal". Model yang lebih tepat adalah:

Selama sesi ini hidup, minta Claude kembali ke masalah yang sama dari waktu ke waktu dan bereaksi terhadap keadaan terbaru.

Caption: Diagram lifecycle /loop: prompt dijadwalkan, menunggu sesi idle, membaca status terbaru, bertindak sesuai batas, lalu menjadwalkan iterasi berikutnya atau berhenti.

2. Tiga bentuk /loop: fixed, adaptive, dan bare loop

Dokumentasi resmi membedakan perilaku /loop berdasarkan input yang kita berikan.

Fixed loop: interval dan prompt sama-sama ditulis

/loop 10m check CI for PR #418 and summarize only new failures

Ini adalah fixed loop. Claude mengubah interval menjadi cron expression. Unit yang didukung adalah s, m, h, dan d. Interval dapat berada di depan prompt sebagai token, misalnya 30m, atau ditulis di belakang sebagai klausa seperti every 2 hours.

Cron memiliki granularitas satu menit. Nilai detik dibulatkan ke atas ke menit terdekat. Interval yang tidak dapat dipetakan dengan bersih ke cron step--contohnya 7m atau 90m--dibulatkan ke interval terdekat yang bisa digunakan, dan Claude memberi tahu pilihan akhirnya.

Fixed loop cocok ketika sistem yang dipantau punya ritme yang cukup jelas. Build rata-rata selesai sepuluh menit? Cek setiap lima menit masih masuk akal. Dependabot atau security scan yang tidak berubah cepat? Interval satu jam lebih masuk akal daripada satu menit.

Namun fixed loop tidak berhenti sendiri hanya karena kondisi sudah selesai. Berdasarkan dokumentasi, loop fixed terus berjalan sampai dihentikan atau melewati expiry tujuh hari. Karena itu, prompt fixed perlu memuat instruksi pelaporan yang tidak berisik, dan operator tetap harus menghentikannya ketika selesai.

Adaptive loop: prompt ada, interval tidak ada

/loop check whether CI passed and address any review comments

Tanpa interval, Claude memilih delay secara dinamis pada setiap iterasi. Dokumentasi menyebut rentangnya antara satu menit dan satu jam. Ia dapat memilih jeda pendek ketika build hampir selesai atau PR aktif, lalu memperpanjang jeda ketika tidak ada perubahan. Di akhir iterasi, Claude mencetak delay yang dipilih beserta alasannya.

Untuk adaptive loop, Claude juga dapat memakai Monitor tool secara langsung. Monitor menjalankan background script dan mengalirkan setiap baris output kembali ke sesi. Jika masalahnya cocok dengan pemantauan berbasis proses atau stream, pendekatan ini dapat menghindari polling berulang dan, menurut dokumentasi, sering lebih responsif serta lebih hemat token.

Jitter scheduled task biasa tidak berlaku pada adaptive loop. Tetapi batas kedaluwarsa tujuh hari tetap berlaku.

Adaptive loop juga dapat berhenti sendiri ketika tugas selesai. Dokumentasi menjelaskan bahwa Claude dapat memanggil ScheduleWakeup dengan stop: true. Jika satu iterasi berakhir tanpa menjadwalkan ulang atau menghentikan loop, Claude Code membuat fallback wakeup sekitar 20 menit kemudian; loop berakhir bila iterasi berikutnya juga tidak menjadwalkan ulang.

Catatan platform resmi: pada Amazon Bedrock, Claude Platform on AWS, Google Cloud Agent Platform, dan Microsoft Foundry, prompt tanpa interval berjalan dengan jadwal fixed sepuluh menit, bukan adaptive seperti perilaku utama yang dijelaskan di atas.

Bare loop: tanpa prompt khusus

/loop

Bare /loop menjalankan maintenance prompt bawaan dengan interval adaptif. Urutannya, menurut dokumentasi:

1. melanjutkan pekerjaan yang belum selesai dari percakapan;
2. menjaga pull request branch aktif: review comment, CI gagal, dan merge conflict;
3. jika tidak ada pekerjaan tertunda, menjalankan cleanup seperti mencari bug atau menyederhanakan kode.

Maintenance prompt tidak memulai inisiatif baru di luar scope tersebut. Aksi irreversible seperti push atau delete hanya boleh dilanjutkan jika transcript sebelumnya memang sudah mengotorisasikannya.

Bare loop berguna setelah sesi implementasi yang sudah memiliki objective dan batas jelas. Ia kurang cocok bila transcript panjang memuat beberapa pekerjaan berbeda atau izin yang ambigu. Dalam kondisi itu, prompt eksplisit lebih mudah diaudit.

Catatan platform resmi yang sama berlaku: pada provider cloud tertentu di atas, bare /loop menampilkan usage, bukan menjalankan maintenance prompt.

3. loop.md: default project yang bisa dibaca manusia

Prompt bare /loop dapat diganti dengan file loop.md. Claude mencari dua lokasi berikut dan memakai yang pertama ditemukan:

.claude/loop.md # level project, prioritas lebih tinggi
~/.claude/loop.md # level user, fallback lintas project

File ini Markdown biasa, tanpa struktur wajib. Isinya diperlakukan seperti prompt yang diketik langsung setelah /loop. Ia mendefinisikan satu default prompt untuk bare loop, bukan daftar banyak scheduled task. Jika kita menulis prompt langsung di command line, loop.md diabaikan.

Perubahan pada file berlaku mulai iterasi berikutnya. Isinya dipotong jika melewati 25.000 byte. Pada provider cloud yang disebut sebelumnya, loop.md tidak dibaca.

Contoh project-level loop.md yang lebih ketat daripada maintenance prompt umum:

Monitor the current branch and its pull request.

On each iteration:
- Read the current CI and review state. Report only changes since the prior check.
- If CI fails, inspect the failing job log and identify the smallest plausible fix.
- Edit code only when the failure is reproducible locally and the fix stays within files changed by this branch.
- Run the narrowest relevant test before proposing a commit.
- Do not push, merge, rebase, resolve review threads, change secrets, or run database migrations without explicit approval in this session.
- Stop after CI is green and there are no unresolved actionable review comments.
- Stop and report if the same failure remains after two fix attempts or if the required permission is unavailable.

Bagian di atas adalah rekomendasi operasional, bukan format wajib Anthropic. Saya sengaja memasukkan scope, bukti, aksi yang boleh dilakukan, aksi yang memerlukan approval, dan stop condition.

Jangan menjadikan loop.md tempat menumpuk semua SOP engineering. Default yang terlalu panjang mudah memuat aturan yang saling bertabrakan. Lebih baik isinya fokus pada satu pekerjaan pemeliharaan yang memang sering dilakukan di project itu. Untuk kebutuhan berbeda, jalankan /loop <prompt> secara eksplisit.

Jika file dimasukkan ke repository, review perubahan loop.md seperti review kode. Ia dapat memengaruhi aksi bare loop pada iterasi berikutnya. Artikel tentang governance AI agent lokal: role, approval, log, dan monitoring relevan di sini: instruksi operasional bukan catatan dekoratif. Ia bagian dari control plane.

4. Anatomi prompt yang aman: observe, decide, act, stop

Prompt loop yang buruk biasanya hanya menyebut aktivitas:

/loop 5m fix CI

Masalahnya, "fix" tidak menjelaskan file mana yang boleh disentuh, bukti apa yang harus dikumpulkan, berapa kali boleh mencoba, dan kapan harus berhenti. Loop bisa terus membaca log yang sama atau melakukan edit demi edit tanpa kemajuan terukur.

Saya menyarankan empat blok untuk pekerjaan coding sehari-hari. Ini rekomendasi operasional.

Observe: fakta apa yang harus dibaca

Sebutkan sumber status secara konkret:

• check dan job CI pada PR aktif;
• komentar review baru yang belum ditangani;
• log deploy dari environment tertentu;
• output test dengan seed dan nama test;
• metrik error atau log aplikasi setelah satu batch migrasi.

Minta loop membedakan keadaan baru dari keadaan yang sudah dilaporkan. Tujuannya bukan mengandalkan "memory" abstrak, tetapi menjaga state kerja yang relevan tetap jelas. Pembahasan context vs state vs memory pada AI agent membantu menjelaskan kenapa ketiganya tidak boleh dicampur.

Decide: syarat sebelum bertindak

Contoh:

Only attempt a code fix when the failure is reproducible or the log identifies a deterministic failing assertion.
If the failure is infrastructure-related, report it and do not edit application code.

Blok ini mencegah agent mengubah kode untuk mengobati runner yang kehabisan disk, timeout jaringan, atau service pihak ketiga yang sedang gagal.

Act: tindakan paling sempit

Tentukan urutan:

Make one minimal change, run the narrowest relevant test, then inspect the diff.
Do not broaden the refactor while fixing the failure.

Kita ingin loop agentic dalam diagnosis, tetapi deterministic dalam jalur eksekusi. Prinsip itu dibahas lebih lengkap di Agentic, Tapi Deterministic.

Stop: selesai, buntu, atau berisiko

Stop condition sebaiknya mencakup tiga kategori:

• success: target tercapai;
• stuck: percobaan tidak menghasilkan progres;
• boundary: tindakan berikutnya melewati izin, biaya, atau scope.

Contoh siap pakai:

Stop successfully when the target check is green twice in a row.
Stop as stuck if the same failure remains after two code-fix attempts.
Stop for approval before push, merge, schema migration, dependency major upgrade, secret change, or destructive command.
At stop, report the current state, evidence, files changed, tests run, and the next decision required.

Pola "dua kali green" berguna untuk flaky test, bukan aturan universal. Untuk build deterministic, satu keberhasilan mungkin cukup. Kriteria selesai harus mengikuti risiko. Jika requirement belum cukup testable, rumuskan dulu dengan pola seperti yang dibahas dalam acceptance criteria EARS.

Caption: Matriks stop condition untuk loop coding: success menghentikan pekerjaan, stuck meminta diagnosis manusia, dan boundary meminta approval sebelum aksi berisiko.

5. Prompt siap pakai untuk CI, deploy, dan review PR

Contoh-contoh di bagian ini adalah rekomendasi. Sesuaikan command, tool, permission, branch protection, dan kebijakan repository Anda.

Monitor CI tanpa langsung mengedit

/loop check the current branch PR every time you run. Read only the latest CI state. If a job is newly failing, collect the job name, failing step, decisive log lines, and likely category: code, test, infrastructure, or external dependency. Do not edit files, rerun jobs, push, or resolve threads. Report only state changes. Stop when all required checks pass, or when a failure needs human access or a decision.

Ini cocok sebagai fase observasi. Ia murah dibanding loop yang setiap kali membaca seluruh repository dan mencoba perbaikan.

Monitor CI lalu membuat fix terbatas

/loop check CI and unresolved review comments for the current PR. If a deterministic code or test failure appears, reproduce it with the narrowest command, make one minimal fix within files changed by this branch, and rerun that test. Do not push or merge. Do not change lockfiles unless the failure is directly caused by dependency resolution. Stop when required CI is green and no actionable review comments remain. Stop as stuck after two unsuccessful fix attempts on the same root cause, and summarize the attempts and diff.

Perhatikan batas percobaan. "Dua" bukan angka sakral; ia cost boundary yang mudah diperiksa. Untuk repo mahal atau test suite lambat, satu percobaan mungkin lebih tepat.

Memantau deploy

/loop check the deployment for commit <SHA>. On each iteration, read the deployment status and only the new warning or error lines. If it succeeds, report the environment, deployed commit, completion state, and stop. If it fails, classify the failure and show the decisive evidence. Do not redeploy, roll back, edit infrastructure, or change secrets. Stop immediately if the deployed commit differs from <SHA> or if rollback may be required.

Guard terhadap commit berbeda penting. Tanpanya, loop bisa menyimpulkan deploy sukses padahal yang selesai adalah revision lain.

Menangani review comment

/loop review new actionable comments on PR <NUMBER>. For each new comment, verify it against the current diff before editing. If valid and within scope, make the smallest change and run the relevant check. Do not resolve the thread, push, rebase, or dismiss a comment. If a comment conflicts with an earlier requirement or expands scope, stop and ask for a decision. Stop when there are no unresolved actionable comments and local checks for changed files pass.

Skill juga dapat dijadikan prompt, misalnya:

/loop 20m /review-pr 1234

Tetapi dokumentasi resmi memberi batas penting. Sejak Claude Code v2.1.196, scheduled fire hanya mengeksekusi skill yang boleh dipanggil Claude secara mandiri. Built-in command seperti /permissions, /model, dan /clear akan masuk sebagai teks biasa, bukan dieksekusi. Begitu pula skill dengan disable-model-invocation: true--termasuk bundled /verify dan /code-review--skill yang disembunyikan oleh skillOverrides atau deny rule, serta MCP prompt seperti /mcp__github__list_prs.

Jadi, bila loop yang memanggil skill terlihat tidak bekerja, jangan langsung menambah prompt. Periksa lebih dulu apakah skill tersebut memang tersedia untuk model invocation.

6. Flaky test dan test-fix loop tanpa percobaan tak berujung

Flaky test adalah kasus yang menggoda kita untuk memakai loop secara agresif. Jalankan test seratus kali, ubah timing, ulangi lagi. Cara itu bisa mahal dan malah menyamarkan race condition.

Pakai dua fase.

Fase diagnosis

/loop investigate test <TEST_NAME>. Run only that test with the same environment and record the seed, duration, and failure signature. Make no code changes. Stop when the same failure signature is reproduced twice, when five runs pass without reproducing it, or when three distinct failure signatures appear. Return the evidence and the most likely boundary for further investigation.

Di sini cost boundary eksplisit: maksimal lima run sukses tanpa reproduksi, atau cukup bukti lebih awal. Karena /loop adalah scheduled prompt, tiap iterasi perlu tahu jumlah percobaan yang sudah dilakukan dari percakapan atau artefak kerja yang disepakati. Jangan mengandalkan agent untuk menebak apakah ini run ketiga atau kedelapan.

Fase fix terkontrol

/loop work on the reproduced failure signature for <TEST_NAME>. Before editing, restate the observed root-cause hypothesis and the assertion that will disprove it. Make at most one minimal code change per iteration. Run the target test, then the nearest affected test group. Stop successfully after the target test passes ten consecutive runs and the affected group passes once. Stop as stuck after two rejected hypotheses or two fix attempts. Do not increase timeouts, add retries, skip the test, or weaken assertions without explicit approval.

Angka sepuluh di sini adalah contoh kebijakan, bukan fakta dokumentasi atau bukti statistik universal. Sesuaikan dengan tingkat flakiness dan biaya test. Yang penting adalah larangan "memperbaiki" flaky test dengan menambah timeout atau retry tanpa memahami sebabnya.

Untuk loop fix apa pun, saya menyarankan format laporan akhir:

Status: success | stuck | approval-needed
Observed failure:
Root-cause evidence:
Attempts:
Files changed:
Commands and tests run:
Remaining uncertainty:
Next safe action:

Format tetap seperti ini memudahkan operator membedakan progres dari aktivitas. Banyak command yang dijalankan bukan berarti diagnosis makin dekat.

7. Migrasi incremental, dependency check, dan log monitoring

Migrasi incremental

Migrasi besar tidak selalu cocok dikerjakan seluruhnya oleh /loop. Untuk fan-out lintas puluhan file dan verifikasi berlapis, Claude Code Dynamic Workflows lebih pas karena pekerjaan dipecah menjadi fase dan subagent. /loop berguna sebagai cadence controller setelah setiap batch kecil selesai.

Prompt contoh:

/loop continue the migration in batches of at most 5 files under <PATH>. Before each batch, read the migration checklist and verify the previous batch tests are green. Apply only the documented mechanical transformation; do not redesign APIs. After the batch, run the focused test and inspect the diff for unrelated changes. Stop when all in-scope files are migrated and the acceptance checks pass. Stop immediately on a behavior change, schema ambiguity, public API break, or two consecutive failing batches. Never commit, push, or run production migrations.

Rekomendasi saya: jangan memakai interval satu menit untuk migrasi yang tiap batch-nya memakan waktu 20 menit. Scheduled fire yang datang ketika Claude sibuk hanya menunggu dan tidak catch up. Pilih adaptive loop atau interval yang mendekati waktu batch realistis.

Dependency dan security check

/loop 1h check the current dependency and security scan results for this branch. Report only new advisories, status changes, or remediation updates. For each advisory, identify the affected package, installed path, direct or transitive status, vulnerable range, and available fixed version from the scan evidence. Do not upgrade, edit lockfiles, suppress findings, or claim exploitability without evidence. Stop when the scan is green or when remediation requires a major upgrade or architectural decision.

Kata "dari scan evidence" penting. Loop tidak boleh mengarang tingkat risiko atau memastikan exploitability hanya dari nama CVE. Jika tindakan membutuhkan major upgrade, hentikan dan jadikan itu keputusan terpisah.

Log monitoring setelah perubahan

/loop monitor new error and warning logs for service <SERVICE> in environment <ENV> after commit <SHA>. Compare only the time window after deployment. Group repeated messages by signature and report count changes, first seen, last seen, and one representative line with secrets and personal data redacted. Do not modify infrastructure, restart services, or change alert thresholds. Stop after <WINDOW> with no new target errors, or immediately when the error rate crosses <APPROVED_THRESHOLD> or a data-integrity signature appears.

Threshold harus berasal dari SLO, runbook, atau keputusan operator--bukan dibuat agent saat loop berjalan. Jika log mengandung secret atau data pribadi, redaction perlu menjadi aturan eksplisit. Untuk monitoring production yang harus terus hidup, gunakan sistem observability dan alerting, bukan /loop.

Pola ini sama dengan perjalanan dari prompt manual ke workflow yang dibahas pada artikel Jago Hermes Agent: repetisi baru bernilai ketika ada state, batas, dan output yang dapat ditindaklanjuti.

8. Batas scheduler: jitter, timezone, expiry, dan jumlah task

Beberapa detail scheduler resmi memengaruhi desain loop.

Local timezone

Semua waktu ditafsirkan dalam timezone lokal tempat Claude Code berjalan. Cron 0 9 * * * berarti pukul 09.00 lokal, bukan otomatis UTC. Untuk tim lintas zona waktu, tulis zona yang diharapkan dalam dokumentasi operasional walaupun scheduler memakai local timezone.

Jitter

Scheduler menambah offset deterministic agar banyak sesi tidak menghantam API pada waktu dinding yang sama.

• Recurring task dapat fire sampai 30 menit setelah waktu terjadwal, atau sampai setengah interval untuk task yang lebih sering daripada satu jam.
• One-shot task yang dijadwalkan tepat pada menit :00 atau :30 dapat fire hingga 90 detik lebih awal.
• Offset diturunkan dari task ID, sehingga task yang sama mendapatkan offset yang sama.
• Jika waktu one-shot harus lebih presisi, dokumentasi menyarankan menit selain :00 atau :30, misalnya 3 9 * * * alih-alih 0 9 * * *.

Jitter berarti /loop tidak cocok untuk tindakan yang harus terjadi tepat pada detik tertentu. Adaptive loop tidak terkena aturan jitter ini.

Seven-day expiry

Recurring task otomatis kedaluwarsa tujuh hari setelah dibuat. Ia fire satu kali terakhir lalu menghapus dirinya. Batas ini mencegah loop yang terlupakan berjalan tanpa ujung. Jika pekerjaan harus berulang lebih lama, dokumentasi menyarankan membatalkan dan membuat ulang sebelum expiry, atau beralih ke Routines maupun Desktop scheduled tasks.

Maksimal task

Satu sesi dapat menyimpan maksimal 50 scheduled task. Setiap task mempunyai ID delapan karakter. Claude menggunakan CronCreate, CronList, dan CronDelete di balik layar; pengguna dapat meminta daftar atau pembatalan dalam bahasa natural:

what scheduled tasks do I have?
cancel the deploy check job

Tidak ada catch-up

Sekali lagi, task yang terlewat karena Claude sibuk tidak dijalankan berkali-kali. Ia fire sekali setelah sesi idle. Maka jangan merancang counter, billing, backup, atau proses integritas data yang bergantung pada jumlah fire /loop.

Penyimpanan dan symlink

Sejak versi 2.1.216, daftar scheduled task disimpan di direktori .claude milik project. Pembuatan task gagal jika direktori tersebut atau file task di dalamnya merupakan symlink. Ini detail troubleshooting yang relevan bila /loop gagal dibuat pada setup dotfile atau monorepo tertentu.

Caption: Timeline scheduler yang memperlihatkan local timezone, deterministic jitter, satu eksekusi setelah sesi kembali idle, tanpa catch-up untuk interval yang terlewat, dan expiry pada hari ketujuh.

9. /loop vs Dynamic Workflows vs /goal vs automation durable

Keempatnya menjawab masalah berbeda.

Kebutuhan	Pilihan yang lebih tepat	Alasan
Mengecek status berkala selama sesi aktif	/loop	Prompt dijalankan kembali berdasarkan waktu atau interval adaptif
Terus bekerja turn demi turn sampai kondisi terpenuhi	/goal	Dokumentasi /loop mengarahkan pekerjaan kontinu berbasis kondisi ke /goal, bukan polling interval
Memecah pekerjaan besar menjadi fase dan banyak subagent	Dynamic Workflows	Orchestration, fan-out, intermediate result, dan verifikasi lintas agent
Job harus bertahan tanpa sesi aktif	Routines, Desktop scheduled tasks, atau GitHub Actions	Scheduler durable, tidak bergantung pada percakapan /loop yang sedang hidup
Event dapat dikirim langsung oleh CI	Channels atau integrasi event	Push event menghindari polling

/loop dan Dynamic Workflows

Gunakan /loop ketika masalah utamanya adalah kapan perlu mengecek lagi. Gunakan Dynamic Workflows ketika masalah utamanya adalah bagaimana pekerjaan besar dipecah dan dikoordinasikan.

Keduanya bisa berurutan. Dynamic Workflow mengaudit 100 file dan menghasilkan patch terstruktur. Setelah PR dibuat, /loop menjaga CI serta komentar review. Jangan memakai 20 iterasi loop untuk meniru fan-out workflow, dan jangan membuat workflow besar hanya untuk mengecek status deploy setiap lima menit.

/loop dan /goal

Dokumentasi Scheduled Tasks menyatakan: bila sesi harus terus bekerja turn demi turn sampai suatu kondisi terpenuhi, gunakan /goal. /loop menunggu interval. Jadi test-fix yang membutuhkan siklus aktif tanpa jeda mungkin lebih cocok sebagai goal. Sebaliknya, menunggu reviewer atau deployment memang punya idle time alami; /loop cocok.

/loop dan durable automation

Dokumentasi membandingkan tiga scheduler utama:

• Cloud/Routines berjalan di infrastruktur Anthropic, tidak memerlukan mesin atau sesi aktif, tetapi bekerja pada fresh clone dan bukan filesystem lokal sesi;
• Desktop scheduled tasks berjalan di mesin pengguna, membutuhkan mesin aktif tetapi tidak membutuhkan sesi Claude Code terbuka, serta memiliki akses file lokal;
• /loop berjalan di mesin pengguna, membutuhkan mesin dan sesi terbuka, mewarisi MCP server serta permission sesi, dan dapat dipulihkan lewat resume jika belum expired.

Minimum interval yang dicantumkan adalah satu jam untuk cloud tasks, satu menit untuk Desktop tasks, dan satu menit untuk /loop.

Untuk pekerjaan unattended yang harus reliabel, dokumentasi juga menunjuk GitHub Actions. Itu pilihan masuk akal untuk dependency scan harian, test terjadwal, atau automation repository. Jangan memperpanjang /loop tiap tujuh hari hanya agar terlihat seperti scheduler permanent.

10. Checklist sebelum menekan Enter

Berikut checklist operasional yang dapat dipakai untuk menilai prompt /loop.

Objective

• Apakah satu loop hanya punya satu objective utama?
• Apakah target branch, PR, service, environment, commit, atau test disebut jelas?

Observation

• Status apa yang dibaca pada setiap iterasi?
• Apakah loop hanya melaporkan perubahan baru?
• Apakah bukti yang diperlukan disebut konkret?

Action boundary

• Bolehkah membaca saja, mengedit lokal, menjalankan test, atau membuat commit?
• Apakah push, merge, rebase, rollback, migration, secret, dan destructive command dipisahkan sebagai approval gate?
• Apakah perubahan dibatasi pada file atau scope tertentu?

Stop condition

• Apa definisi sukses?
• Berapa percobaan maksimal untuk root cause yang sama?
• Kondisi apa yang harus dianggap stuck?
• Risiko apa yang harus menghentikan loop sebelum tindakan berikutnya?

Cost boundary

• Apakah interval sebanding dengan laju perubahan sistem?
• Apakah command yang dijalankan adalah test paling sempit?
• Apakah ada batas run, batch, waktu observasi, atau jumlah fix?
• Apakah event push atau Monitor lebih hemat daripada polling prompt penuh?

Scheduler reality

• Apakah sesi dan mesin akan tetap aktif?
• Apakah jitter masih dapat diterima?
• Apakah no catch-up merusak logika pekerjaan?
• Apakah pekerjaan memang selesai dalam tujuh hari?
• Apakah task durable seharusnya dipindahkan ke Routines, Desktop, atau GitHub Actions?

Prompt ringkas yang merangkum pola tersebut:

/loop <INTERVAL OPTIONAL> monitor <TARGET>.
Observe: read <AUTHORITATIVE STATUS> and report only changes.
Decide: act only when <EVIDENCE CONDITION> is met.
Act: make at most <NARROW ACTION> and verify with <CHECK>.
Success: stop when <MEASURABLE CONDITION>.
Stuck: stop after <ATTEMPT LIMIT> on the same root cause.
Safety: do not <PROHIBITED ACTIONS>; ask before <APPROVAL ACTIONS>.
Cost: inspect only <SCOPE>, run at most <LIMIT>, and avoid full-suite work unless the focused check passes.
Final report: status, evidence, attempts, diff, checks, remaining risk, and next decision.

/loop paling berguna ketika diperlakukan sebagai penjaga sementara, bukan pekerja tanpa jam pulang. Ia mengambil alih pekerjaan mengingat dan mengecek ulang. Operator tetap menentukan sasaran, sumber kebenaran, izin, biaya, dan titik berhenti.

Itu garis pembatas antara loop yang membantu dan loop yang hanya menghabiskan token sambil mengulang ketidakpastian yang sama.

Referensi resmi

• Claude Code Docs -- Run prompts on a schedule