Pertanyaan yang sering diajukan

Deep Work Plan mengubah sebuah repositori menjadi lingkungan terstruktur tempat coding agent dapat mengeksekusi pekerjaan panjang dengan andal. Ia terpasang sebagai skill agent, meng-onboard repositori satu kali (indeks `AGENTS.md`, pohon `docs/`, kit skill dan command `.agents/`, area keluaran `.dwp/` yang di-gitignore), dan setelah itu setiap tujuan menjadi rencana: tugas atomik, masing-masing dengan kriteria penerimaan dan gerbang verifikasi, dieksekusi satu per satu, di-commit saat lulus, dan dapat dilanjutkan dari disk oleh agent mana pun. Rencana ditutup dengan Final Review yang mengaudit keamanan dan memvalidasi status akhir. Metodologinya berlisensi MIT dan bekerja dengan coding agent mana pun yang membaca repositori.

Baca metodologinya

Pengembang dan tim yang menyerahkan pekerjaan nyata dan multilangkah kepada coding agent dan ingin pekerjaan itu selesai. Cocok ketika sebuah tugas melintasi lebih dari satu sesi, lebih dari satu kelompok file, atau lebih dari satu agent; ketika rekan tim harus bisa melanjutkan dari tempat agent berhenti; atau ketika "selesai" harus berarti "tervalidasi", bukan "kata agent begitu". Perbaikan satu baris tidak memerlukan rencana, dan metodologinya mengatakannya sendiri: aturan rigor proporsionalnya menyarankan tujuan, kriteria, dan gerbang inline sebagai gantinya.

Mulai Cepat

Pilihan representasi, bukan trade-off rigor. Rencana bawaannya adalah Lite: README ringkas dengan catatan tugas berjangkar yang sudah dapat dieksekusi, bukan draf sebagian. Jika Anda meminta rencana Full dari awal, `create` menulis file tugas Full secara langsung; dan memperluas sebuah rencana ke Full ketika detail instruksi, dependensi, atau kontrak sebuah tugas tidak lagi muat dalam catatan ringkas yang bisa ditinjau. Promosi di kemudian hari menyimpan setiap tugas yang selesai. Kedua format membawa kriteria penerimaan, gerbang verifikasi, bukti, dan Final Review wajib yang sama.

Baca metodologinya

Sebuah metodologi yang dikemas sebagai skill yang dapat dipasang. Tidak ada server, tidak ada akun, tidak ada format proprietary, dan tidak ada runtime selain coding agent yang sudah Anda pakai. Yang terpasang adalah instruksi yang dibaca agent, sejumlah kecil shell script untuk deteksi konteks dan pemeriksaan konformansi, serta konvensi yang diadopsi repositori Anda. Semua yang dihasilkan rencana berupa Markdown dan JSON di repositori Anda, dapat dibaca tanpa tool apa pun.

Baca spesifikasinya

Agent mana pun yang membaca file repositori. Skill ini mengikuti standar Agent Skills terbuka dan konvensi `AGENTS.md`, sehingga Claude Code, Codex, Cursor, Gemini CLI, GitHub Copilot, dan lainnya memuatnya melalui pemuatan skill dan instruksi normal mereka. Evaluasi milik metodologi ini sendiri menunjukkan sebuah rencana yang dimulai oleh agent dari satu vendor dan dilanjutkan oleh agent vendor lain, di kedua arah. Cakupan instalasi dan bukti perilaku didaftar per agent dalam matriks kompatibilitas, dan keduanya tidak pernah dicampuradukkan.

Telusuri kit

Tiga langkah. Pertama, pasang skill Deep Work Plan ke coding agent Anda — jalur tercepat adalah `npx skills add DailybotHQ/deepworkplan-skill` (atau clone repo skill dan jalankan `./setup.sh`). Kedua, onboard repositori sekali agar agent menyesuaikan `AGENTS.md`, `docs/`, kit `.agents/` dan area `.dwp/` yang di-gitignore dengan stack Anda: arahkan ke https://deepworkplan.com/init.md, atau jalankan `/deepworkplan-onboard`. Ketiga, rencanakan dan jalankan pekerjaan dengan command ringan: `/dwp-create <goal>` membangun rencana; `/dwp-execute` menjalankannya per tugas melawan setiap gerbang; `/dwp-refine` mengedit rencana yang sedang berjalan (cakupan, tugas, atau mempromosikan rencana Lite ke Full); `/dwp-resume` melanjutkan setelah gangguan; `/dwp-status` melaporkan progres tanpa mengeksekusi; `/dwp-verify` menghasilkan laporan kesesuaian objektif; `/dwp-upgrade` memindahkan skill yang terinstal ke rilis yang lebih baru tanpa menyentuh rencana yang ada. Agent yang mengintercept `/` sering memakai `#` sebagai gantinya (misalnya `#dwp-execute`). Adoption endpoint dan Mulai Cepat menjelaskan jalur yang sama secara lebih rinci.

Mulai Cepat

Skill agent terpasang di mana pun agent Anda memuat skill project atau user. Onboarding kemudian menyesuaikan repositori itu sendiri: ia membuat atau merekonsiliasi `AGENTS.md`, `docs/`, `.agents/`, dan area kerja `.dwp/` yang di-gitignore. Skill mengajari agent metodenya; repositori menyimpan konteks, kit, dan bukti rencana yang dibutuhkan agent lain untuk melanjutkan.

Lihat alur adopsinya

Git direkomendasikan untuk repositori karena riwayatnya menjadi bagian dari permukaan pemulihan dan tinjauan, tetapi metodologinya juga bisa berjalan di workspace agent tanpa repositori Git. Dalam kasus itu, lapisan status terbaca mesin, termasuk checkpoint `state.json` dan catatan gerbang, wajib ada agar pemulihan tidak bergantung pada transkrip chat.

Baca tentang arketipe repositori

Sebuah skill mendeskripsikan cara agent menjalankan sebuah prosedur berulang. Rencana DWP mendeskripsikan perubahan konkret melalui cakupan, kriteria penerimaan, gerbang verifikasi, dan bukti. Spesifikasi produk mendeskripsikan perilaku produk saat ini dan berevolusi lewat delta setelah implementasi; skill dan rencana juga merupakan spesifikasi, tetapi keduanya mendeskripsikan prosedur dan perubahan, bukan merawat kontrak produk kanonis itu.

Baca spesifikasinya

Gerbang itu adalah asersi yang dapat dieksekusi dan dijalankan sendiri oleh agent. Persetujuan manusia mengapit jalannya rencana: seorang manusia menyetujui rencana sebelum eksekusi dan meninjau diff akhir saat pull request; eksekusi di antaranya berjalan otonom. Setiap tugas menyebutkan command konkret, biasanya gerbang kualitas milik repositori itu sendiri, yang dipilih dari permukaan yang disentuh tugas: test dari perilaku yang berubah beserta konsumennya, diperluas ke seluruh suite ketika perubahan bersifat shared atau tidak bisa dibatasi. Sebuah tugas ditandai selesai hanya ketika command itu keluar dengan sukses, dan tugas yang mengubah perilaku wajib memperluas test. Saat gagal, agent lebih dulu memperbaiki apa yang berada di dalam lingkup tugas itu sendiri dan menjalankan kembali gerbangnya; kegagalan yang tidak bisa diperbaiki dalam lingkup itu meninggalkan tugas tertandai terblokir dan menghentikan eksekusi.

Loop inti

Di tiga front. Tugas ditulis sebagai perilaku, bukan editan: sebuah kriteria penerimaan menyatakan apa yang harus dilakukan sistem, sehingga file yang diganti nama atau implementasi yang ditukar tidak membatalkannya. Setiap gerbang dijalankan ulang terhadap repositori apa adanya saat ini, sehingga asumsi yang rusak gagal keras pada eksekusi berikutnya alih-alih menyimpang diam-diam, dan kegagalan itulah isyarat untuk menyempurnakan. Menjaga dokumentasi tetap sinkron juga bagian dari pekerjaan: tugas yang mengubah perilaku turut memperbarui docs dan kit yang menghadap agent yang mendeskripsikannya, di dalam gerbangnya sendiri. Setiap eksekusi semestinya meninggalkan repositori lebih siap dihadapi agent daripada saat ia menemukannya.

Baca metodologinya

Bisa; menyempurnakan rencana yang telah dieksekusi sebagian adalah langkah kelas satu. Definisi tugas dan status eksekusi disimpan terpisah: rencana berupa checklist di disk plus berkas status kecil, sehingga apa yang sudah selesai tetap tercatat terlepas dari teks tugasnya. Ketika sebuah tugas ternyata salah, agent menandainya terblokir dan berhenti alih-alih memaksakan jalan. Anda kemudian mengedit, mengurutkan ulang, memecah, atau menggugurkan tugas yang belum berjalan, sementara tugas yang selesai tetap selesai. Melanjutkan membangun ulang status dari disk dan repositori yang sebenarnya serta menjalankan ulang gerbang yang relevan, sehingga tidak ada pergeseran di bawah permukaan yang lolos begitu saja.

Loop inti

Rencana adalah pemeriksaan berkelanjutan. Agent mengerjakan satu tugas kecil dalam satu waktu dan harus memvalidasi sebelum melanjutkan, sehingga ia bisa melenceng satu langkah, bukan tiga. Setiap tugas membawa kriteria penerimaan plus command persis yang membuktikannya, dan kemajuan ditulis ke repositori seiring berjalannya waktu, dengan status per tugas, sehingga penyimpangan menjadi terlihat oleh Anda, oleh sesi berikutnya, dan oleh agent berikutnya. Sebuah rencana belum selesai sampai semuanya tervalidasi, termasuk Final Review. Catatan yang jujur: metodologi tidak bisa menghentikan agent menulis kriteria penerimaan yang lemah sejak awal; ia menjadikan penyimpangan nyaring alih-alih senyap.

Loop inti

Bukan keduanya. Ia dibuat sekali dari sebuah tujuan, lalu dirawat sebagai bagian dari pekerjaan. Rencana sengaja tidak ditulis ulang dari diff kode, karena spesifikasi yang mengejar kode menjadi cermin yang tertinggal, dan penyimpangan itulah yang ingin dibasmi oleh metodologi ini. Ia berevolusi dengan sengaja: gerbang dijalankan ulang terhadap repositori saat ini, gerbang yang gagal memicu penyempurnaan, dan agent melakukan penyempurnaan itu selama eksekusi sementara Anda menyetujui di awal dan meninjau di akhir. Dokumentasi dan test berevolusi beriringan dengan kode sebagai akibat konstruksinya, karena memperbaruinya berada di dalam gerbang setiap tugas.

Baca metodologinya

Kemajuan hidup di disk, bukan di chat. Centang README, log setiap tugas, indeks kerja yang terbatas, dan berkas status terbaca mesin diperbarui di setiap batas tugas, dan berkas status mencatat checkpoint sebelum setiap jeda yang direncanakan. Sesi baru, atau agent yang berbeda, membaca indeks ringkas itu, merekonsiliasikannya dengan repositori dan riwayat git, lalu melanjutkan dari tugas pertama yang belum selesai tanpa mengulang pekerjaan yang sudah beres. Bahkan pembuatan rencana yang terputus bisa dipulihkan: identitas rencana dan daftar tugas yang dimaksud ditulis sebelum file tugas mana pun, sehingga rencana yang setengah jadi bisa diselesaikan atau dibuang alih-alih ditebak-nebak.

Loop inti

Satu-satunya tugas penutup wajib dari setiap rencana. Secara berurutan: pemeriksaan keamanan atas seluruh kumpulan perubahan yang terkumpul dalam rencana, termasuk tinjauan lokal atas diff yang diwajibkan oleh skill AI Diff Reviewer, dengan temuan kritis memblokir penyelesaian sampai diperbaiki atau diterima secara eksplisit; validasi status akhir, artinya seluruh suite test, lint, type-check, dan format yang berlaku milik repositori pada kode akhir; dan rekonsiliasi keputusan skills yang dicatat setiap tugas. Agent kemudian melaporkan deliverable, bukti, dan keterbatasan, lalu menawarkan Executive Report satu kali, menghasilkannya hanya jika Anda meminta.

Spesifikasinya

Gerbang yang gagal lebih dulu adalah sinyal perbaikan: agent memperbaiki apa yang berada di dalam lingkup tugas itu sendiri dan menjalankan kembali gerbangnya. Kegagalan yang melampaui lingkup itu meninggalkan tugas tercatat sebagai terblokir, dan agent berhenti sebelum mengklaim selesai. Anda bisa memeriksa buktinya, memperbaiki kode, atau menyempurnakan tugasnya, lalu melanjutkan; command yang gagal adalah isyarat untuk menyelesaikan ketidaksesuaian, bukan izin untuk melemahkan gerbangnya.

Baca protokol agent

Ia mengatakannya dengan tegas. Pemeriksa berakhir dengan kode keluar 2 dan vonis `UNVERIFIED` eksplisit — ia tidak pernah mencetak kelulusan yang tidak benar-benar diverifikasinya. Ketika lingkungan kekurangan interpreter yang mampu atau sebuah pemeriksaan tidak bisa berjalan, hasil yang jujur adalah “belum diverifikasi”, bukan “sesuai”; hasil hijau selalu berarti setiap pemeriksaan berjalan dan lulus. Disiplin yang sama menjangkau seluruh metodologi: tidak ada alur yang melemahkan atau memalsukan gerbang untuk mengklaim penyelesaian.

Kontrak konformansi

Bisa, ketika rencana sudah disetujui sebelumnya, membawa lapisan status yang diwajibkan, dan memberi agent otoritas terbatas. Eksekusi tanpa pengawasan wajib berhenti dan mencatat blocker ketika kenyataan menyimpang, sebuah gerbang gagal di luar cakupan perbaikan yang direncanakan, atau dibutuhkan persetujuan atau kredensial baru.

Baca protokol tanpa pengawasan

Bisa — arketipe hub orkestrator ada persis untuk itu. Repositori hub memegang rencana yang mengoordinasikan, dan setiap repositori anak menjalankan rencananya sendiri di dalam area `.dwp/` terisolasinya sendiri, sehingga anak tidak pernah menulis ke status rencana hub. Kelengkapan anak dibaca dari status tingkat atas dari rencananya sendiri, bukan dengan pencocokan string di dalamnya, dan hub mencatat posisinya sebelum menavigasi ke mana pun. Setiap anak tetap repositori DWP biasa yang juga bisa dipiloti sendirian.

Arketipe repositori

Keduanya memecahkan masalah yang berdampingan. Tool spec-driven unggul dalam menangkap apa yang harus berubah: spesifikasi, kebutuhan, dan proposal perubahan dalam bentuk yang dapat diulang. Deep Work Plan soal bagaimana sebuah agent mengeksekusi berjam-jam tanpa menyimpang: harness hasil onboarding, gerbang verifikasi per tugas yang dipilih dari permukaan yang disentuh, status yang dapat dilanjutkan di disk, Final Review wajib dengan pemeriksaan keamanan, dan pemeriksa konformansi untuk repositorinya sendiri. Keduanya bisa digabungkan, dengan spesifikasi atau proposal perubahan yang menjadi masukan sebuah rencana. Halaman perbandingan menyandingkan kapabilitasnya berdampingan, menurut istilah masing-masing tool.

Lihat perbandingannya

Framework alur kerja agen seperti BMAD, Superpowers, dan Get Shit Done membawa gaya kerja yang kuat: peran, prinsip, langkah test-first, kebiasaan verifikasi. Gentle-AI berada di kategori tetangga sebagai konfigurator ekosistem agen: ia melengkapi agen coding yang sudah Anda gunakan dengan memori persisten lintas sesi (Engram), skill terkurasi, persona, server MCP, Spec-Driven Development opsional, dan review berbasis bukti opsional (Receipt-Driven Development), dengan menulis ke direktori konfigurasi setiap agen. Deep Work Plan berbeda dari keduanya: berfokus pada apa yang tetap ada di repositori dan apa yang bisa diperiksa — harness yang bisa dibaca agen mana pun tanpa konteks sebelumnya, file task dengan kriteria penerimaan dan gate, state yang bertahan melewati sesi, pemeriksa kesesuaian dengan kode keluar yang ramah CI, dan pengukuran yang dipublikasikan tentang berapa banyak byte instruksi yang dimuat setiap flow. Ia agnostik terhadap tool secara konstruksi dan tidak menambahkan layanan, provider, atau secret apa pun ke loop inti. Lapisan-lapisan ini bisa berdampingan: framework dan Gentle-AI membentuk cara kerja agen; Deep Work Plan membuat pekerjaan panjang tahan lama dan dapat diperiksa di dalam repositori. Halaman perbandingan menunjukkan di mana setiap pendekatan bawaan, opsional, atau di luar cakupan.

Lihat perbandingannya

Mode rencana bawaan berguna, dan Deep Work Plan membangun di atas substrat yang sama, konvensi `AGENTS.md` dan standar Agent Skills terbuka. Bedanya ada pada tempat rencana hidup dan apa yang menegakkannya. Rencana native biasanya hidup di luar repositori dan kedaluwarsa bersama sesi; Deep Work Plan menulis rencana, statusnya, dan buktinya ke dalam repositori, sehingga agent lain atau rekan tim bisa melanjutkannya, dan setiap tugas membawa gerbang yang dapat dieksekusi serta log yang tercatat. Anda tetap memakai mode rencana agent Anda untuk berpikir; metodologinya menambahkan loop eksekusi yang tahan lama dan dapat diverifikasi.

Lihat perbandingannya

Onboarding bersifat non-destruktif: ia mendeteksi `AGENTS.md`, `docs/`, `.agents/`, atau `CLAUDE.md` yang sudah ada, merekonsiliasi alih-alih menimpa, dan bertanya sebelum mengganti apa pun. Ia menulis indeks `AGENTS.md` dengan command nyata, pohon `docs/` yang beralasan, dokumentasi per modul, kit `.agents/` dengan command `dwp-*` yang tipis, area keluaran `.dwp/` yang di-gitignore, peta pengujian yang terverifikasi, dan tinjauan kode lokal yang diwajibkan (skill AI Diff Reviewer plus ekstensi review yang disesuaikan repo). Ia kemudian menjalankan self-check dan pemeriksa konformansi agar Anda bisa melihat apa yang dihasilkan. Repositori yang di-onboard di bawah standar sebelumnya mendapat upgrade harness tertarget yang merekonsiliasi hanya apa yang kurang atau usang.

Endpoint adopsi

Ada dua upgrade berbeda, dan alurnya menjaga keduanya tetap terpisah. Harness repositori — `AGENTS.md`, `docs/`, kit `.agents/` — direkonsiliasi dengan menjalankan kembali onboarding, yang hanya mengisi apa yang kurang atau usang. Skill itu sendiri bergerak lewat `/dwp-upgrade`: pemeriksaan read-only atas rilis terbaru yang dipublikasikan, instalasi tag persis yang Anda terima, terverifikasi, lalu onboarding kembali sebagai satu proses segar. Alur bergantung pada persetujuan eksplisit di setiap langkah, adaptasi lokal dibandingkan dan dipertahankan alih-alih ditimpa, dan `.dwp/` tidak pernah dimigrasi — rencana yang ada mempertahankan bentuk tercatatnya dan terus berjalan.

Endpoint adopsi

Bisa. Add-on adalah lapisan opt-in, dan repositori tanpa add-on apa pun tetap sepenuhnya konform DWP. Devcontainer, pelaporan Dailybot, upgrade dependensi, dukungan design-system, dan tinjauan CI opsional hanya ditawarkan ketika cocok dengan repositori Anda dan Anda menerimanya secara eksplisit.

Telusuri add-on

DWP tidak memperlakukan absennya toolchain sebagai jalan bebas. Selama onboarding, agent mengusulkan setup validasi yang sesuai dengan stack, mencatat command tersebut di dokumentasi repositori, dan memakai command itu sebagai target gerbang di masa depan; usulan itu tetap terlihat agar Anda bisa meninjaunya.

Baca protokol agent

Metodologi dan skill-nya berlisensi MIT dan gratis; tidak ada service, tidak ada kunci API, dan tidak ada telemetri di alur inti. Efisiensi dilaporkan sebagai jumlah byte instruksi yang dimuat setiap alur **saat masuk** — paket awalnya di permulaan sesi — dipublikasikan berdampingan dengan **jalur end-to-end** bernama yang menambahkan apa yang benar-benar dimuat oleh pemicu alur itu sendiri saat pekerjaan sungguh berlanjut (misalnya, resume yang berlanjut ke eksekusi biasanya memuat beberapa kali lipat paket masuknya). Tak satu pun dari kedua angka ini membatasi sebuah sesi: eksekusi nyata juga membaca file repositori itu sendiri, keluaran tool, dan file kerja rencana, yang tak satu pun dihitung dalam ledger ini. Kedua angka diukur oleh script yang di-commit bersama skill, diukur ulang pada setiap baseline rilis dan dipublikasikan dalam ledger evaluasi, dengan kenaikan dilaporkan sejujur penurunannya. Efisiensi tidak dilaporkan sebagai persentase token atau penghematan biaya, karena inventarisasi byte tidak menetapkan hal itu. Evaluasi publik dengan agen segar kini telah dijalankan di bawah protokol beku: dua fitur yang sama dibangun dari klon bersih tanpa harness, dengan versi mayor sebelumnya, dan dengan versi saat ini. Evaluasi menemukan bahwa agen pada pohon berkemampuan-harness membaca lebih sedikit byte pada kedua tugas, dan bahwa sesi fitur versi saat ini mengonsumsi lebih sedikit masukan dan keluaran model daripada versi mayor sebelumnya pada kedua tugas — sebagaimana dilaporkan harness, pada satu beban kerja. Evaluasi juga menemukan batas-batasnya yang jujur: onboarding adalah biaya sekali bayar yang hanya terbayar kembali saat alurnya digunakan, arah token bersih per beban kerja bersifat campuran, tidak ada klaim keunggulan waktu dinding, dan agen segar tidak memasuki alur dengan sendirinya — alur adalah perintah yang Anda atau agen yang tahu memanggilnya.

Kepercayaan dan pengungkapan