rizqinrr/get-prd

Dapatkan PRD

Ringkasan

get-prd mengubah permintaan yang samar menjadi PRD yang disetujui dalam satu proses berkelanjutan. Skill ini menggabungkan tiga alur kerja yang biasanya dijalankan secara terpisah:

1. Wawancara pohon keputusan — petakan setiap keputusan sebagai pohon, kerjakan tepi pohon (frontier) per tepi secara berputar, dan berikan rekomendasi untuk setiap pertanyaan. Ini adalah mekanisme yang membuat wawancara menyatu, bukan bertele-tele.
2. Ekstraksi maksud — tangkap apa yang sebenarnya diinginkan pengguna, bukan apa yang mereka pikir harus mereka inginkan, dengan angka keyakinan eksplisit di setiap langkah. Ini adalah disiplin yang menghentikan asisten AI mengisi celah secara diam-diam.
3. Penulisan spesifikasi — tulis persyaratan dalam suatu artefak terstruktur dengan batasan, kriteria keberhasilan, dan gerbang persetujuan. Ini adalah hasil yang dikonsumsi oleh perencanaan downstream.

Alasan untuk menggabungkan ketiganya adalah karena pemisahan akan menghilangkan konteks. Ketika wawancara adalah satu skill dan penulisan spesifikasi adalah skill lain, skill kedua dimulai dengan 'dingin' (tanpa konteks): ia mengulangi pertanyaan yang sudah dijawab di skill pertama, atau secara diam-diam mengasumsikan jawaban yang tidak pernah diberikan. PRD yang ditulis dari ringkasan basi lebih buruk daripada tidak ada PRD, karena terlihat otoritatif.

Dua konsekuensi dari penggabungan ini, keduanya disengaja:

• Skill ini panjang. Skill ini membawa metodologi lengkap dari ketiga fase, bukan mendelegasikannya ke skill lain. Ikuti langkah-langkah secara berurutan; jangan melompat langsung ke templat.
• Skill ini tidak pernah mendelegasikan wawancara. Mekanisme wawancara ada di sini. Jangan panggil skill lain untuk melakukan pertanyaan.

Outputnya adalah PRD komprehensif yang disimpan ke docs/PRD.md (atau docs/prd/<nama>.md), disetujui oleh pengguna, siap untuk get-tasks dan get-design.

Untuk pengguna baru atau konsep tahap awal, get-prd menggabungkan lensa penemuan penyempurnaan ide, pemetaan kendala non-fungsional, dan definisi hubungan entitas inti/data langsung ke dalam dokumen sehingga tidak diperlukan skill skema atau penyempurnaan terpisah.

Kapan Digunakan

Gunakan skill ini ketika:

• Pengguna memulai aplikasi, sistem, fitur, atau perubahan signifikan baru dan belum ada dokumen persyaratan
• Pengguna berkata "get prd", "bikin PRD", "buat PRD", "mau bikin sistem baru", atau "mau develop X"
• Pengguna meminta untuk diwawancarai, diuji, atau di-stress-test untuk menghasilkan spesifikasi
• Permintaan bersifat konvensional dan kurang spesifik ("buatkan saya dashboard", "buat lebih cepat") dan Anda tidak dapat menyatakan apa artinya selesai
• Anda akan merencanakan atau membangun sesuatu yang memakan waktu lebih dari sehari, dan tidak ada persyaratan tertulis

Kapan TIDAK digunakan:

• Perbaikan bug, koreksi typo, penggantian nama, dan operasi mekanis
• PRD atau spesifikasi sudah ada dan pengguna ingin mengubah bagian kecilnya — amandemen dokumen secara langsung
• Permintaan informasi murni ("bagaimana cara kerjanya?")
• Pengguna secara eksplisit ingin melewatkan dokumentasi dan langsung membangun — hargai itu, tetapi sampaikan risikonya sekali
• Konteks non-interaktif (pipeline CI, jadwal berjalan, loop otonom). Skill ini memerlukan pengguna yang responsif secara langsung. Jika permintaan kurang spesifik dalam konteks non-interaktif, tandai sebagai penghalang alih-alih menebak.

Proses

get-prd berjalan dalam delapan fase. Setiap fase memiliki kondisi keluar. Jangan melanjutkan ke fase yang kondisi keluarnya belum terpenuhi.

0. Gerbang lingkup       -> apakah ini satu kemampuan atau beberapa?
1. Benih hipotesis       -> apa yang saya pikir mereka inginkan, dan seberapa yakin saya?
2. Bangun pohon          -> keputusan apa yang ada, dan mana yang berada di tepi (frontier)?
3. Pertanyaan putaran    -> tanyakan tepi pohon, satu putaran pada satu waktu
4. Uji maksud            -> keinginan vs. seharusnya-keinginan
5. Ulang pernyataan       -> katakan kembali, dengan kata-kata mereka
6. Periksa celah          -> apa yang dibutuhkan PRD yang tidak dihasilkan oleh wawancara?
7. Tulis dan gerbang     -> PRD, lalu persetujuan eksplisit

Prinsip Universal untuk Pewawancara

1. Pencocokan Bahasa Alami: Selalu berbicara dalam bahasa pilihan pengguna. Jika pengguna memulai percakapan dalam bahasa Indonesia (misalnya "bikin PRD aplikasi absensi"), lakukan seluruh wawancara dengan hangat dalam bahasa Indonesia sambil mempertahankan istilah teknis industri standar (acceptance criteria, schema, endpoint, payload). Jika mereka berbicara bahasa Inggris, lakukan dalam bahasa Inggris. Jangan pernah memaksakan wawancara bahasa Inggris kepada pengguna yang bertanya dalam bahasa lain.
2. Nada Empati & Tidak Mengintimidasi: Pengguna sering datang dengan ide mentah dan belum terbentuk. Jangan pernah menginterogasi atau membuat mereka merasa tidak mampu karena kurangnya terminologi teknis. Bimbing mereka dengan sabar: terjemahkan masalah bisnis mereka menjadi pilihan teknis, dan selalu sertakan jawaban rekomendasi Anda (-> Rekomendasi: ...) sehingga mereka hanya perlu bereaksi daripada harus berpikir dari awal.
3. 3 Pertanyaan Emas untuk Ide Samar / Awal: Ketika pengguna menyajikan ide singkat satu kalimat (misalnya "mau bikin SaaS seperti Notion untuk resep masakan"), jangkar tepi pohon di sekitar tiga pilar yang berpusat pada manusia sebelum membahas tumpukan teknologi:
   • Persona Target & Konteks: Siapa yang menggunakan, di mana, dan dalam situasi apa?
   • Perjalanan Pengguna North-Star: Apa satu alur aksi terpenting dari awal sampai tuntas yang wajib sukses di aplikasi ini?
   • Lingkup MVP: Fitur apa yang mutlak harus ada di hari pertama, dan apa yang sengaja ditunda ke tahap berikutnya?

---

Fase 0: Gerbang Lingkup

Sebagian besar permintaan menggambarkan satu kemampuan. Jika ini terjadi, katakan dalam satu baris dan lanjutkan ke Fase 1. Fase ini ada untuk pengecualian.

Deteksi. Dekomposisi sebelum menulis apa pun ketika satu permintaan menggabungkan beberapa kemampuan yang dapat diuji secara independen:

• Permintaan menyebutkan kemampuan berbeda dengan konsumen atau data mereka sendiri (identitas, penagihan, notifikasi, pelaporan)
• Kriteria penerimaan mengelompok ke dalam grup yang dapat dikirim dan diverifikasi secara terpisah
• Satu kemampuan dapat dipotong atau diganti tanpa menulis ulang persyaratan kemampuan lainnya

Ketika terdeteksi, usulkan peta kemampuan sebelum putaran wawancara apa pun. Kecil dan mudah ditinjau — tabel modul ditambah urutan pembangunan, bukan rencana proyek:

# Peta Kemampuan: [Nama Inisiatif]

| Id modul | Tanggung jawab | Bergantung pada |
|---|---|---|
| identity | Akun, sesi, SSO | - |
| billing | Paket, faktur, pembayaran | identity |
| notifications | Email dan fan-out webhook | identity |
| reporting | Dasbor penggunaan | billing, notifications |

Urutan pembangunan: identity -> billing, notifications -> reporting

Aturan untuk peta:

• Id modul stabil. Kebab-case, dipilih sekali, jangan pernah diganti nama. Perencanaan downstream memilih pekerjaan berdasarkan id ini.
• Arah ketergantungan, tanpa siklus. Panah menunjuk satu arah. Jika dua modul masing-masing membutuhkan yang lain, maka mereka adalah satu modul.
• Antarmuka hidup di batas. Peta mencatat bahwa billing bergantung pada identity; kontrak di antara keduanya berada di PRD modul penyedia.

Peta ini memiliki gerbang. Minta pengguna menyetujui batas modul, arah ketergantungan, dan urutan pembangunan sebelum Anda mewawancarai satu modul pun. Mendapatkan peta yang salah itu mahal; meninjau sepuluh baris tidak.

Kemudian jalankan Fase 1-7 sekali per modul, sesuai urutan pembangunan, masing-masing menghasilkan docs/prd/<id-modul>.md sendiri. Jangan menulis PRD monolitik untuk inisiatif multi-modul.

Kondisi keluar: permintaan adalah kemampuan tunggal (nyatakan secara eksplisit), atau peta kemampuan telah disetujui.

---

Fase 1: Benih Hipotesis

Sebelum menanyakan apa pun, tuliskan pemahaman Anda saat ini tentang permintaan dan angka keyakinan yang jujur.

HIPOTESIS: Anda menginginkan cara untuk menjawab "bagaimana kabar kita?" saat standup, dan "dashboard" adalah konvensi yang terlintas.
KEYAKINAN: ~30% - kurang: untuk siapa, apa arti "metrik" di sini, dan seperti apa kesuksesan itu

Aturan:

• Satu kalimat untuk hipotesis. Jika Anda tidak bisa menulisnya dalam satu kalimat, Anda belum memiliki pemahaman.
• Angka keyakinan adalah persentase dari 0 hingga 100. Ini memaksa kejujuran: jika Anda tidak dapat memprediksi reaksi pengguna terhadap tiga pertanyaan berikutnya yang akan Anda ajukan, angkanya salah.
• Di bawah ~70%, lampirkan alasan singkat di baris yang sama yang menyebutkan apa yang masih belum terselesaikan. Ini memberi tahu pengguna dengan tepat apa yang perlu diungkap oleh wawancara.
• Perbarui hipotesis dan keyakinan setelah setiap putaran.

Kondisi keluar: hipotesis dengan angka keyakinan tercatat.

---

Fase 2: Bangun Pohon Keputusan

Petakan ruang keputusan sebelum menanyakan apa pun. Setiap keputusan bercabang menjadi keputusan yang menggantung padanya.

Tujuan: pelacak eksperimen pribadi
    |
    +-- Apa yang dianggap sebagai eksperimen?        (tentukan unitnya)
    |       |
    |       +-- Bidang apa yang mendeskripsikan satu?    (lingkup skema)
    |
    +-- Dari mana data berasal?                           (sumber input)
    |       |
    |       +-- Entri manual atau impor?                  (model interaksi)
    |
    +-- Kapan eksperimen "selesai"?                       (siklus hidup)
            |
            +-- Sinyal apa yang mengakhirinya?           (definisi sukses)

Tepi pohon (frontier) adalah setiap keputusan yang prasyaratnya sudah ditentukan: pertanyaan yang dapat Anda tanyakan sekarang tanpa menebak jawaban yang belum Anda dengar.

Dua aturan yang membuat ini berhasil:

1. Tanyakan seluruh tepi pohon dalam satu putaran. Jangan menanyakan satu pertanyaan per giliran ketika beberapa pertanyaan independen. Pertanyaan independen dijawab lebih cepat bersama-sama, dan pengguna melihat bentuk ruang keputusan.
2. Pertanyaan yang jawabannya bergantung pada pertanyaan terbuka lain termasuk dalam putaran selanjutnya. Menanyakannya sekarang akan mengunci dalam kerangka yang salah.

Fakta adalah tugas Anda, bukan tugas pengguna. Ketika pertanyaan tepi pohon membutuhkan fakta dari lingkungan (sistem file, kode yang ada, API perpustakaan, nilai konfigurasi), kirim sub-agen untuk menemukannya. Jangan menanyakan kepada pengguna apa pun yang dapat Anda cari sendiri. Jangan memblokir putaran karena itu: eksplorasi adalah prasyarat yang belum terselesaikan, jadi hanya pertanyaan downstream yang menunggu. Tanyakan sisa tepi pohon sekarang. Keputusan adalah milik pengguna; fakta adalah milik Anda.

Kondisi keluar: pohon telah dipetakan dan tepi pohon pertama telah diidentifikasi.

---

Fase 3: Pertanyaan Putaran

Tanyakan tepi pohon saat ini. Format setiap pertanyaan persis seperti ini:

**P1 - <judul pertanyaan>**: <isi pertanyaan, mungkin beberapa paragraf, sering kali dengan opsi kandidat yang dijabarkan>

-> <jawaban rekomendasi Anda, dengan alasan yang menghasilkannya>

Aturan:

• Beri nomor setiap pertanyaan. P1, P2, ... Mulai ulang penomoran per putaran.
• Selalu lampirkan rekomendasi. Pengguna bereaksi lebih cepat terhadap rekomendasi yang salah daripada menghasilkan jawaban dari awal. Ini juga mengikat Anda pada hipotesis yang dapat Anda salah secara kasat mata.
• Tunggu jawabannya sebelum mengajukan putaran berikutnya.
• Hitung ulang tepi pohon setelah setiap putaran. Keputusan yang telah ditentukan mendorong tepi pohon keluar dan membuka blokir pertanyaan yang bergantung padanya.
• Catat koreksi. Ketika pengguna menolak rekomendasi, catat baik keputusan maupun alasannya, karena bagian "Keputusan Teknis" PRD menggambarnya dari sini.

Mengapa rekomendasi itu penting, dan mode kegagalannya:

• Pengguna dapat bereaksi terhadap tebakan yang salah dalam hitungan detik tetapi mungkin membutuhkan waktu menit untuk menghasilkan jawaban dari ketiadaan.
• Ini mengekspos asumsi Anda, yang merupakan inti dari wawancara.
• Risikonya adalah penjilatan (sycophancy) — pengguna yang sopan setuju dengan tebakan Anda untuk menyenangkan hati. Mitigasi dengan secara kasat mata bersedia salah, dan sesekali merekomendasikan arah yang Anda harapkan akan ditolak pengguna. Jika setiap rekomendasi diterima pada percobaan pertama, curigai penjilatan.

Mengapa satu putaran pada satu waktu, bukan semuanya sekaligus:

• Pertanyaan ketiga sering bergantung pada jawaban pertanyaan pertama; menanyakan semuanya sekaligus mengunci dalam kerangka yang salah.
• Energi pengguna untuk berpikir hati-hati terbatas. Habiskan putaran demi putaran.
• Sekumpulan lima belas pertanyaan terbaca sebagai survei, bukan wawancara, dan akan dibaca sepintas.

Kondisi keluar: pertanyaan putaran telah dijawab dan tepi pohon telah dihitung ulang.

---

Fase 4: Uji Maksud (keinginan vs. seharusnya-keinginan)

Jawaban paling berbahaya adalah jawaban di mana pengguna mengatakan apa yang terdengar seperti jawaban bijaksana daripada apa yang sebenarnya mereka inginkan. Waspadai:

• Jawaban yang cocok dengan pola pembicaraan praktik terbaik ("Saya ingin itu skalabel", "arsitektur bersih") tanpa spesifikasi
• Jawaban yang mengacu pada konvensi ("cara yang dilakukan sebagian besar aplikasi", "pendekatan standar")
• Frasa seperti "Saya seharusnya mungkin...", "Saya pikir saya seharusnya...", "praktik rekayasa yang baik mengatakan..."
• Kata kunci sebagai tujuan — ketika "modern", "skalabel", atau "kuat" adalah jawabannya alih-alih hasil yang spesifik

Ketika Anda mendengar salah satu dari ini, tanyakan:

"Jika Anda tidak perlu membenarkan ini kepada siapa pun, apa yang sebenarnya Anda inginkan?"

Pertanyaan tunggal itu sering kali melakukan lebih banyak pekerjaan daripada lima pertanyaan sebelumnya. Jalankan setidaknya sekali setiap kali jawaban yang menandakan kecanggihan muncul. Catat baik jawaban yang dinyatakan maupun jawaban yang diuji — PRD harus mencerminkan yang kedua.

Kondisi keluar: setidaknya satu uji berjalan jika ada jawaban yang menandakan kecanggihan muncul, dan jawaban sebenarnya tercatat.

---

Fase 5: Ulang Pernyataan Maksud

Ketika pohon hampir selesai, tulis kembali apa yang sekarang Anda pikir diinginkan pengguna. Buatlah tetap ringkas, gunakan bahasa mereka, dan struktur sehingga mereka dapat mengonfirmasi atau mengoreksi baris demi baris.

Inilah yang sekarang saya pikir Anda inginkan:

- Hasil:      <satu baris>
- Pengguna:   <satu baris - siapa yang diuntungkan>
- Mengapa sekarang: <satu baris - apa yang berubah>
- Keberhasilan: <satu baris - bagaimana kita tahu itu berhasil>
- Kendala:    <satu baris - batasan yang mengikat>
- Di luar lingkup: <satu baris - apa yang secara eksplisit tidak kita lakukan>

Ya / tidak / perbaiki?

Aturan:

• "Di luar lingkup" tidak bisa ditawar. Setengah dari ketidakselarasan adalah ketidaksepakatan diam-diam tentang apa yang tidak sedang dibangun.
• Total lima hingga delapan baris. Jika lebih panjang, wawancara belum selesai.
• Gunakan kata-kata pengguna jika memungkinkan; kosakata mereka adalah kontrak bersama.

Kondisi keluar: pernyataan ulang yang konkret dalam kata-kata pengguna tercatat.

---

Kondisi Berhenti

Anda selesai mewawancarai ketika keduanya ini benar:

1. Dapatkah Anda memprediksi reaksi pengguna terhadap tiga pertanyaan berikutnya yang akan Anda ajukan? Jika ya, Anda memiliki pemahaman bersama.
2. Apakah tepi pohon mengecil? Jika tepi pohon terus tumbuh bukannya mengecil, carilah pertanyaan yang belum Anda ajukan yang mengakarkan sumber ketidakpastian yang lebih dalam. Tepi pohon yang tidak mengecil setelah beberapa putaran adalah sinyal bahwa pohon itu sendiri salah. Tinjau ulang. Satu pertanyaan yang tepat dapat melipatgandakan tepi pohon menjadi satu cabang biasa. Temukan itu.