Prompt Engineering untuk Spec: Teknik Menulis Spesifikasi Presisi dengan Claude Code
Kuasai teknik prompt engineering untuk menulis spesifikasi yang presisi menggunakan Claude Code. Dari deskripsi ambigu ke spec yang siap jadi source of truth untuk Golang projects.
Prompt Engineering untuk Spec: Dari Ambigu ke Presisi
Prompt engineering untuk spec golang adalah keterampilan yang menentukan apakah AI membantu kamu menulis spesifikasi yang tajam — atau justru menghasilkan dokumen yang terlihat rapi tapi kosong substansi. Ada kesenjangan besar antara “saya ingin fitur X” dan spesifikasi yang bisa langsung jadi source of truth. Kesenjangan ini yang sering membuat developer frustrasi: sudah tulis spec, tapi masih banyak yang ambigu. Atau sebaliknya — minta AI bantu tulis spec, hasilnya terlihat lengkap tapi substansinya kosong.
Kuncinya adalah prompt engineering yang tepat untuk konteks spec-writing. Di artikel ini, kita bahas teknik-teknik yang benar-benar bekerja — bukan teori, tapi pattern yang langsung bisa dipakai untuk proyek Golang.
06.1 Mengapa Prompt Generik Menghasilkan Spec Generik
Sebelum masuk ke teknik yang benar, penting melihat dulu pola keliru yang paling umum. Banyak developer melakukan ini saat meminta AI bantu menulis spec — melempar satu kalimat singkat dan berharap output yang matang.
1Prompt generik:
2"Tolong buatkan spec untuk fitur cancel order di e-commerce app."Prompt sesingkat itu tidak memberi AI satu pun batasan konkret, sehingga model hanya bisa menebak — dan tebakannya selalu generik. Hasilnya adalah spec yang terlihat lengkap tapi sebenarnya tidak berguna, seperti berikut.
1# Cancel Order Spec
2
3## User Story
4As a user, I want to cancel my order.
5
6## Acceptance Criteria
7- System should allow users to cancel orders
8- System should validate the request
9- System should update the order status
10- System should notify relevant parties
11
12## Edge Cases
13- Handle errors appropriately
14- Ensure data consistencyPerhatikan bahwa tidak ada satu baris pun yang bisa dijadikan test: “Handle errors appropriately” tidak mendefinisikan error apa, dan “Notify relevant parties” tidak menyebut siapa yang dinotifikasi tentang apa. Ini bukan spec — ini template yang diisi dengan kata-kata tanpa makna. Masalahnya bukan di AI-nya, melainkan di prompt-nya: prompt yang ambigu menghasilkan output yang ambigu.
06.2 Framework CONTEXT untuk Prompt Spec
Untuk menghindari output generik, kita butuh kerangka yang memastikan setiap dimensi penting tercantum di prompt. Gunakan framework CONTEXT berikut sebagai checklist mental setiap kali menulis prompt spec:
C — Context: domain bisnis dan stakeholder yang terlibat O — Operations: apa yang harus dilakukan sistem N — Not included: batasan scope yang eksplisit T — Tech constraints: stack dan arsitektur yang ada E — Examples: contoh konkret dari use case nyata X — eXisting: spec atau kode yang sudah ada sebagai referensi T — Tone: format output yang diharapkan
Agar terasa konkret, berikut contoh prompt yang mengisi ketujuh dimensi di atas untuk fitur cancel order di Santekno Shop.
1[C] Santekno Shop adalah e-commerce B2C Indonesia.
2 Customer adalah pembeli akhir. Merchant adalah penjual yang listing produk.
3 Order lifecycle: PENDING → CONFIRMED → SHIPPED → DELIVERED / CANCELLED
4
5[O] Saya ingin spec untuk fitur "cancel order oleh customer"
6
7[N] TIDAK termasuk:
8 - Cancel oleh admin (spec terpisah)
9 - Proses refund (spec terpisah)
10 - Cancel setelah shipped (tidak dimungkinkan)
11
12[T] Stack: Go 1.22, Echo v4, PostgreSQL (pgx/v5), Kafka
13 Architecture: clean architecture, domain → usecase → repository → handler
14
15[E] Contoh scenario nyata:
16 - Customer order laptop tapi salah alamat, mau cancel sebelum dikirim
17 - Customer order 5 menit lalu, masih PENDING, ingin cancel
18 - Customer coba cancel order yang sudah CONFIRMED → harus gagal
19
20[X] Referensi spec yang sudah ada: specs/order/create-order.md (untuk pola)
21 Domain errors: ErrOrderNotFound, ErrOrderNotCancellable sudah didefinisikan
22
23[T] Format output: Markdown spec mengikuti template di specs/_templates/feature-spec.md
24 Bahasa: Bahasa Indonesia untuk user story dan AC, English untuk technical terms
25 Target: spec bisa langsung di-review dan di-approve tanpa pertanyaan tambahanDengan setiap dimensi terisi eksplisit, AI tidak lagi perlu menebak — ia punya cukup batasan untuk menghasilkan AC yang measurable dan scope yang jelas sejak draft pertama.
06.3 Prompt Pattern 1: Spec dari Requirement Naratif
Pattern pertama menyasar situasi paling umum: requirement datang dalam bentuk narasi bebas dari product team. Berikut contoh requirement mentah yang khas — penuh informasi implisit dan tanpa struktur.
1"Customer harus bisa cancel order. Cuma yang belum diproses saja.
2 Kalau udah diproses merchant, tidak bisa. Stok harus balik.
3 Kasih notifikasi juga. Oh iya, ada batas waktu 15 menit."Narasi seperti ini menyimpan banyak keputusan yang belum dieksplisitkan, jadi tugas prompt adalah memaksa AI mengonversinya menjadi struktur formal tanpa mengarang. Prompt berikut melakukan itu dengan aturan yang ketat.
1Ubah requirement naratif berikut menjadi spec formal dengan format:
2User Story, Acceptance Criteria (happy path dan error cases terpisah),
3Edge Cases, dan Non-Functional Requirements.
4
5Requirement:
6"Customer harus bisa cancel order. Cuma yang belum diproses saja.
7 Kalau udah diproses merchant, tidak bisa. Stok harus balik.
8 Kasih notifikasi juga. Oh iya, ada batas waktu 15 menit."
9
10Konteks sistem:
11- Order status: PENDING → CONFIRMED → SHIPPED → DELIVERED/CANCELLED
12- Notifikasi via Kafka event (bukan direct call ke Notification Service)
13- Stok restore harus atomic
14- Stack: Go 1.22, Echo v4, pgx/v5
15
16Rules untuk AC:
171. Setiap error case HARUS mention HTTP status code yang spesifik
182. Setiap AC harus bisa jadi satu test function
193. Response format harus didefinisikan (field apa saja)
20
21Jika ada yang ambigu dari requirement, TANDAI dengan [AMBIGUOUS: pertanyaan klarifikasi]
22jangan assumsi sendiri.Instruksi [AMBIGUOUS: ...] di baris terakhir adalah kunci pattern ini: ia mengubah AI dari mesin penebak menjadi mitra yang jujur menandai kekosongan, sehingga kamu tidak kaget menemukan asumsi liar di dalam spec.
06.4 Prompt Pattern 2: Spec Review dan Gap Analysis
Setelah spec ditulis — baik oleh kamu maupun AI — langkah berikutnya adalah mereviewnya secara adversarial. Prompt berikut mengarahkan AI untuk mencari lima kategori kelemahan yang paling sering lolos dari mata penulis aslinya.
1Review spec berikut dan identifikasi:
2
31. AC yang tidak measurable (tidak bisa jadi test function)
4 → Berikan contoh bagaimana merevisinya
5
62. Edge cases yang berpotensi terjadi di production tapi belum ada di spec
7 → Fokus pada: concurrent access, external dependency failure, data boundary
8
93. Ambiguitas yang bisa menyebabkan developer mengimplementasikan berbeda
10 → Quote bagian yang ambigu dan jelaskan mengapa
11
124. Konflik antar AC
13 → Jika AC1 dan AC3 bisa contradictory dalam kondisi tertentu
14
155. Missing NFR yang penting untuk production
16 → Terutama: response time, error rate monitoring, rate limiting
17
18Format output:
19## Gap Analysis
20
21### 1. AC yang tidak measurable
22[list]
23
24### 2. Missing edge cases
25[list]
26
27### 3. Ambiguities
28[list]
29
30### 4. Conflicts
31[list]
32
33### 5. Missing NFR
34[list]
35
36### Overall assessment
37[brief summary]
38
39---
40[spec yang akan direview]Dengan format output yang sudah dipaksakan, hasil review datang terstruktur dan actionable — kamu langsung tahu bagian mana yang harus diperbaiki, bukan sekadar “spec-nya kurang lengkap”.
06.5 Prompt Pattern 3: Spec dari Kode yang Sudah Ada
Kadang urutannya terbalik: kode sudah ada, tapi spec-nya tidak pernah ditulis. Untuk reverse-engineer spec dari implementasi, gunakan prompt yang menuntun AI mengekstrak makna bisnis dari setiap cabang logika.
1Buat spec formal berdasarkan implementasi kode berikut.
2
3Instruksi:
41. Deduce user story dari nama function, docstring, dan business logic
52. Extract semua AC dari:
6 - Setiap validation check
7 - Setiap return statement dengan HTTP status
8 - Setiap branch condition yang punya business meaning
93. Identify edge cases dari error handling
104. Note NFR jika ada (timeout values, rate limits, dll)
115. Tandai asumsi dengan [ASSUMPTION: alasan]
126. Tandai hal yang perlu dikonfirmasi dengan [CONFIRM: pertanyaan]
13
14Format output: spec dalam format standar
15(User Story, Acceptance Criteria, Edge Cases, NFR, Changelog)
16
17---
18@internal/delivery/http/handler/order_handler.go, @internal/usecase/order/cancel_order.go, @internal/repository/postgres/order_repository.goAturan penandaan [ASSUMPTION] dan [CONFIRM] mencegah AI mengklaim tahu maksud bisnis yang sebenarnya hanya tersirat dari kode. Sebagai contoh input, perhatikan usecase cancel order berikut.
1// Input ke prompt:
2func (uc *CancelOrderUseCase) Execute(ctx context.Context, input CancelOrderInput) error {
3 order, err := uc.repo.GetByIDAndUserID(ctx, input.OrderID, input.UserID)
4 if err != nil { return fmt.Errorf("cancelOrder: get: %w", err) }
5 if order == nil { return ErrOrderNotFound }
6 if order.Status != StatusPending { return &OrderNotCancellableError{...} }
7 if time.Since(order.CreatedAt) > 15*time.Minute { return ErrCancelWindowExpired }
8 if err := uc.repo.CancelWithStockRestore(ctx, input.OrderID); err != nil { ... }
9 uc.publisher.PublishAsync(ctx, OrderCancelledEvent{...})
10 return nil
11}Dari potongan Go di atas, setiap if menjadi kandidat AC dan setiap error type menjadi kandidat error case. Prompt kemudian menghasilkan spec seperti berikut.
1# Output spec yang dihasilkan:
2
3## User Story
4[ASSUMPTION: berdasarkan fungsi GetByIDAndUserID] Sebagai customer,
5saya ingin cancel order saya yang belum diproses...
6
7## Acceptance Criteria
8- AC1: [CONFIRM: apakah 404 atau 422 untuk order milik user lain?]
9 Berdasarkan GetByIDAndUserID: return 404 (tidak expose existence)
10- AC2: Order status selain PENDING tidak bisa dicancel → 409 Conflict
11- AC3: Lebih dari 15 menit sejak order dibuat → 409 dengan CANCEL_WINDOW_EXPIRED
12- AC4: Cancel berhasil: stok dikembalikan secara atomic
13- AC5: Event ORDER_CANCELLED dipublish asynchronously (best effort)Perhatikan bagaimana AC1 tetap ditandai [CONFIRM] alih-alih diputuskan sepihak — inilah yang membedakan reverse-engineering yang jujur dari yang berbahaya: keputusan bisnis dikembalikan ke manusia, bukan dikarang oleh AI.
06.6 Prompt Pattern 4: Spec untuk Fitur Kompleks yang Perlu Dipecah
Fitur besar seperti “checkout” tidak boleh dipaksakan ke dalam satu spec raksasa. Prompt berikut menugaskan AI untuk memetakan sub-fitur, dependency-nya, dan urutan implementasi yang logis sebelum satu baris spec pun ditulis.
1Fitur "checkout" adalah fitur kompleks. Bantu saya:
2
31. Identifikasi semua sub-fitur yang perlu spec terpisah
42. Tentukan dependency antar sub-fitur
53. Berikan prioritas implementasi yang logical
6
7Deskripsi fitur checkout secara umum:
8- User select items dari cart
9- Masukkan atau pilih shipping address
10- Pilih payment method
11- Preview order total dengan shipping cost
12- Confirm order → create order + payment processing
13- Send confirmations
14
15Konteks:
16- Payment via payment gateway (external)
17- Shipping cost dari external API
18- Stock reservation vs confirmation
19
20Output format:
21## Sub-spec breakdown
221. [nama sub-spec] — priority [high/medium/low]
23 Dependencies: [spec lain yang perlu selesai dulu]
24 Scope: [satu kalimat tentang apa yang dicakup]
25
26## Dependency graph
27[text representation of dependencies]
28
29## Recommended implementation order
30[ordered list]Hasil dari prompt ini bukan spec itu sendiri, melainkan peta jalan: kamu jadi tahu spec mana yang harus ditulis lebih dulu dan mana yang bergantung padanya, sehingga pekerjaan bisa dijadwalkan tanpa deadlock antar-tim.
06.7 Prompt Pattern 5: Spec untuk Edge Cases yang Sulit Diidentifikasi
Edge case yang paling berbahaya adalah yang tidak terpikirkan sama sekali. Untuk memunculkannya, gunakan prompt adversarial yang memerankan AI sebagai QA engineer senior dengan misi mencari celah.
1Kamu adalah QA engineer yang sangat senior dan berpengalaman dengan
2sistem e-commerce high-traffic di Indonesia.
3
4Baca spec berikut dan identifikasi semua edge cases yang bisa terjadi
5dengan mensimulasikan:
6
71. Kondisi concurrent (dua user, dua request bersamaan)
82. Kondisi network (latency tinggi, timeout, partial failure)
93. Kondisi data dirty (data tidak konsisten karena bug sebelumnya)
104. Kondisi volume tinggi (flash sale, 10x normal traffic)
115. Kondisi race condition (state berubah antara check dan action)
12
13Untuk setiap edge case yang ditemukan:
14- Jelaskan scenario konkretnya (siapa melakukan apa kapan)
15- Jelaskan dampaknya jika tidak di-handle (data corruption? wrong status?)
16- Berikan rekomendasi handling
17
18---
19@specs/order/cancel-order.mdDengan memaksa AI menyimulasikan lima kelas kondisi sekaligus, kamu mendapatkan daftar edge case yang jauh lebih dalam daripada brainstorming manual. Contoh output yang benar-benar bernilai terlihat seperti berikut.
1## Edge Cases yang Ditemukan
2
3### EC-CONCURRENT-1: Cancel dan Confirm bersamaan
4Scenario: Customer klik cancel (t=0), merchant klik confirm (t=10ms)
5Status saat cancel mulai: PENDING → SELECT FOR UPDATE
6Status saat confirm sampai: lock acquired oleh cancel → confirm blocked
7Dampak jika tidak di-handle: dua request bisa sama-sama berhasil → inconsistent state
8Rekomendasi: Keduanya pakai SELECT FOR UPDATE, retry jika dapat deadlock
9
10### EC-KAFKA-1: Partial message delivery setelah DB commit
11Scenario: DB commit berhasil (t=0), Kafka publish dalam progress (t=100ms),
12pod restart (t=150ms)
13Status akhir: order CANCELLED di DB, event tidak sampai ke Notification Service
14Dampak: customer tidak dapat email konfirmasi cancel
15Rekomendasi: Outbox pattern atau Kafka dengan transactional producerKedua edge case di atas adalah tipe bug yang biasanya baru muncul di production saat traffic tinggi — dan menangkapnya di fase spec jauh lebih murah daripada menemukannya lewat incident postmortem.
06.8 Prompt Pattern 6: Validasi Spec vs Implementasi
Setelah implementasi selesai, pertanyaan kritisnya adalah: apakah kode benar-benar memenuhi spec? Prompt berikut menjalankan spec compliance audit yang membandingkan setiap AC dan EC dengan kode aktual.
1Lakukan spec compliance audit.
2
3Spec: @specs/order/cancel-order.md
4
5Kode yang diaudit:
6- usecase: @internal/usecase/order/cancel_order.go
7- handler: @internal/delivery/http/handler/order_handler.go
8- repository: @internal/repository/postgres/order_repository.go
9
10Untuk setiap AC dan EC di spec:
111. Tentukan apakah sudah diimplementasikan
122. Jika sudah: tunjukkan di file mana dan di bagian mana
133. Jika belum: tandai sebagai NOT IMPLEMENTED
144. Jika implementasi berbeda dari spec: tandai sebagai DRIFT
15
16Output format:
17| AC/EC | Status | Lokasi Implementasi | Catatan |
18|-------|--------|---------------------|---------|
19| AC1 | ✅ Implemented | usecase L.45 | |
20| AC2 | ❌ Not Implemented | - | |
21| EC1 | ⚠️ Drift | usecase L.78 | Returns 500 instead of 409 |
22
23Kesimpulan: berapa persen AC sudah terimplementasi?Output berupa tabel status ini mengubah pertanyaan subjektif “apakah kode sudah sesuai spec?” menjadi laporan objektif yang bisa dijalankan berulang kali — bahkan bisa dijadikan quality gate sebelum merge.
06.9 Anti-Pattern Prompt yang Harus Dihindari
Sama pentingnya dengan mengetahui pola yang benar adalah mengenali pola yang salah. Empat anti-pattern berikut adalah penyebab paling umum kenapa prompt spec gagal, masing-masing disandingkan dengan versi perbaikannya.
Anti-pattern pertama adalah prompt yang terlalu terbuka tanpa batas scope apa pun.
1❌ "Buatkan spec untuk aplikasi e-commerce saya"
2
3✅ "Buatkan spec untuk fitur 'cancel order yang masih PENDING' di Santekno Shop.
4 Scope: hanya cancel oleh customer, bukan admin. Refund tidak termasuk."Versi yang benar membatasi scope ke satu fitur dengan boundary eksplisit, sehingga AI tidak melebar ke seluruh aplikasi.
Anti-pattern kedua adalah meminta sesuatu tanpa memberi contoh konkret.
1❌ "Include edge cases yang relevan"
2
3✅ "Sertakan edge cases untuk:
4 1. Dua request cancel bersamaan untuk order yang sama
5 2. Kafka publish gagal setelah DB update berhasil
6 3. Order diconfirm merchant saat customer sedang cancel"Dengan menyebut edge case konkret, kamu memberi AI titik anchor sehingga hasilnya tajam dan relevan dengan domainmu.
Anti-pattern ketiga adalah tidak memberikan constraint format sama sekali.
1❌ "Tulis spec yang bagus"
2
3✅ "Tulis spec dengan:
4 - Setiap error AC harus mention HTTP status code
5 - Setiap EC harus ada expected behavior yang explicit
6 - Format changelog: | versi | tanggal | perubahan | author |"Constraint format memaksa output yang konsisten dan bisa langsung dipakai, bukan prosa bebas yang harus dirapikan ulang.
Anti-pattern keempat adalah menggabungkan permintaan spec dan implementasi dalam satu prompt.
1❌ "Buatkan spec dan implementasikan sekaligus"
2
3✅ Prompt pertama: "Buatkan spec"
4 → Review spec
5 → Prompt kedua: "Implementasikan berdasarkan spec yang sudah diapprove"Memisahkan spec dari implementasi memberi kamu titik kontrol untuk review sebelum kode ditulis — inti dari disiplin spec-first.
06.10 Iterasi Prompt: Dari Draft ke Final
Spec yang baik jarang selesai dalam satu iterasi; ia matang melalui beberapa putaran perbaikan yang terarah. Iterasi pertama cukup menghasilkan draft kasar dari deskripsi high-level.
1Draft spec untuk cancel order. Konteks: [...]
2Ini adalah draft awal — saya akan review dan minta revisi.Menyebut eksplisit bahwa ini “draft awal” menurunkan ekspektasi kelengkapan dan membuat AI fokus pada kerangka, bukan detail prematur. Iterasi kedua memperbaiki ambiguitas yang ditemukan saat review.
1Di spec yang sudah di-draft, ada beberapa hal yang perlu diklarifikasi:
2
31. AC3 bilang "cancel dalam 15 menit" — 15 menit dari kapan?
4 → Dari waktu order dibuat (created_at), bukan dari waktu request
5
62. EC2 bilang "best effort" untuk Kafka — apa yang terjadi jika gagal?
7 → Log dengan level WARNING, jangan rollback DB, return 204 ke client
8
9Update spec dengan klarifikasi ini.Dengan memberi jawaban konkret atas setiap ambiguitas, kamu mengunci keputusan agar tidak bergeser lagi di iterasi berikutnya. Iterasi ketiga meminta review edge case dari perspektif QA.
1Spec sudah lebih baik. Sekarang minta review dari perspektif
2QA engineer yang pernah debugging concurrent request issues.
3Apa edge case yang mungkin terlewat?Perspektif QA yang spesifik memancing edge case konkuren yang biasanya tidak terpikirkan oleh penulis spec. Iterasi keempat menutup dengan final review menyeluruh.
1Lakukan final review spec ini:
2- Apakah semua AC bisa jadi test function?
3- Apakah ada kontradiksi antar AC?
4- Apakah NFR sudah realistic dan measurable?Empat iterasi ini membentuk alur draft → klarifikasi → edge case → final check yang secara progresif menutup celah, jauh lebih andal daripada berharap satu prompt tunggal menghasilkan spec sempurna.
06.11 Prompt untuk Spec yang Melibatkan Multiple Service
Fitur yang membentang lebih dari satu service butuh spec yang mendefinisikan kontrak antar-service secara eksplisit. Prompt berikut memastikan event contract, error handling, dan idempotency semuanya tercakup.
1Fitur "send order confirmation email" melibatkan beberapa service:
2- Order Service: publish event setelah order created
3- Notification Service: consume event, kirim email
4- Email Template Service: provide template
5
6Saya ingin spec yang mencakup:
71. Event contract antara Order Service dan Notification Service
82. API contract jika ada synchronous call
93. Error handling di setiap service
104. Idempotency handling (apa yang terjadi jika event diprocess dua kali)
11
12Output: satu spec per service + event spec
13
14Format untuk event spec:
15- Event name dan trigger
16- Kafka topic dan partition key
17- Event schema (JSON)
18- Consumer responsibilities
19- Idempotency approachDengan meminta satu spec per service plus event spec terpisah, kamu memaksa batas tanggung jawab tiap service menjadi jelas — mencegah asumsi tersembunyi yang jadi sumber bug integrasi di sistem terdistribusi.
06.12 Menyimpan dan Mengorganisasi Prompt yang Efektif
Prompt yang terbukti efektif adalah aset tim, bukan sekadar catatan sekali pakai. Struktur direktori berikut menempatkan setiap prompt pattern sebagai file yang bisa di-version bersama kode.
1docs/
2└── prompts/
3 ├── spec-from-requirement.md ← prompt Pattern 1
4 ├── spec-review.md ← prompt Pattern 2
5 ├── spec-from-code.md ← prompt Pattern 3
6 ├── edge-case-finder.md ← prompt Pattern 5
7 └── spec-compliance-audit.md ← prompt Pattern 6Dengan menyimpannya di git, prompt bisa direview, diperbaiki, dan diwariskan seperti kode biasa. Agar konsisten, setiap file prompt sebaiknya mengikuti format standar berikut.
1# [Nama Prompt]
2## Kapan Digunakan
3[Deskripsi situasi penggunaan]
4
5## Prompt Template
6[isi prompt dengan [PLACEHOLDER] untuk bagian yang perlu diisi]
7
8## Contoh Input
9[contoh input yang konkret]
10
11## Contoh Output
12[contoh output yang diharapkan]
13
14## Tips
15- [hal yang perlu diperhatikan]Format berbagian ini membuat prompt mudah dipahami anggota tim baru: mereka langsung tahu kapan memakainya, apa yang perlu diisi, dan seperti apa hasil yang diharapkan.
06.13 Prompt Engineering untuk NFR yang Sulit Dikuantifikasi
NFR seperti “sistem harus fast” tidak bisa jadi test karena tidak measurable. Prompt berikut menuntun AI mengubah keinginan kabur itu menjadi angka konkret berbasis konteks sistem.
1Bantu saya mendefinisikan NFR yang measurable untuk endpoint
2cancel order di Santekno Shop.
3
4Konteks sistem:
5- Platform e-commerce, peak traffic: flash sale dengan 10x normal load
6- Normal load: 100 req/s untuk seluruh platform
7- Cancel order biasanya < 5% dari total request
8- Infrastructure: Kubernetes, PostgreSQL di RDS, Kafka MSK
9
10Untuk setiap dimensi NFR berikut, berikan angka yang realistic
11berdasarkan best practice industry untuk sistem sejenis:
121. Response time (p50, p95, p99)
132. Availability (uptime percentage)
143. Error rate threshold
154. Concurrent request yang harus bisa di-handle
165. Database query timeout
17
18Sertakan alasan di balik setiap angka yang disarankan.Meminta “alasan di balik setiap angka” adalah pengaman penting: ia memaksa AI menjustifikasi rekomendasinya sehingga kamu bisa menilai apakah angka itu masuk akal, bukan sekadar menerima nilai yang terdengar meyakinkan.
06.14 Template Prompt yang Bisa Langsung Dipakai
Agar tidak menyusun ulang prompt dari nol setiap kali, simpan template lengkap berikut sebagai snippet di editor kamu. Template ini merangkum framework CONTEXT ke dalam bentuk isian.
1## SPEC PROMPT TEMPLATE v2.0
2
3Buat spec formal untuk fitur: [NAMA FITUR]
4
5=== CONTEXT ===
6Sistem: [nama sistem dan fungsinya]
7Actor: [siapa yang melakukan action ini]
8Trigger: [apa yang menyebabkan fitur ini dijalankan]
9
10=== SCOPE ===
11Termasuk: [apa yang harus ada di spec ini]
12Tidak termasuk: [apa yang sengaja di-exclude]
13
14=== REQUIREMENT ===
15[Deskripsi requirement dalam bahasa natural]
16
17=== TECH CONSTRAINTS ===
18Stack: [Go version, framework, DB, messaging]
19Architecture: [clean arch / monolith / dll]
20Existing patterns: [referensi ke code yang sudah ada]
21
22=== EXAMPLES ===
23Happy path example: [scenario konkret yang berhasil]
24Error example: [scenario konkret yang gagal]
25
26=== OUTPUT REQUIREMENTS ===
27Format: User Story + AC (happy + error terpisah) + EC + NFR + Changelog
28Bahasa: [Indonesia / English / bilingual]
29Constraint: setiap error AC harus mention HTTP status code
30Constraint: setiap AC harus bisa jadi satu test function
31Flag ambiguitas dengan: [AMBIGUOUS: pertanyaan]
32Flag asumsi dengan: [ASSUMPTION: penjelasan]Karena template ini sudah memaksa struktur, kamu cukup mengisi placeholder dan langsung mendapat prompt berkualitas tinggi tanpa risiko lupa mencantumkan dimensi penting seperti scope atau constraint format.
06.15 Menggunakan Prompt Chaining untuk Spec yang Kompleks
Untuk fitur yang sangat kompleks, satu prompt tidak akan cukup — kamu perlu merantai beberapa prompt yang setiap outputnya jadi input berikutnya:
Prompt 1: Identifikasi sub-feature dan dependencies Prompt 2: Draft spec untuk sub-feature paling kritis Prompt 3: Review dan identifikasi gaps Prompt 4: Generate edge cases dengan adversarial perspective Prompt 5: Final review dan NFR
Agar rantai ini bisa ditelusuri kembali, simpan output setiap langkah sebagai audit trail. Perintah berikut menunjukkan dua cara menyimpannya di Claude Code.
1# Di claude code, simpan conversation
2claude --session-name "spec-cancel-order-2025-07-15"
3
4# Atau gunakan file sebagai history
5echo "[Step 1 output]" >> specs/drafts/cancel-order-spec-draft.md
6echo "[Step 2 output]" >> specs/drafts/cancel-order-spec-draft.mdDengan menyimpan tiap langkah, kamu tidak hanya mendapat spec final tapi juga jejak keputusan — sangat berguna ketika berbulan-bulan kemudian ada yang bertanya “kenapa sub-fitur ini didahulukan?”.
06.16 Prompt untuk Menjaga Konsistensi antar Spec
Saat jumlah spec bertambah, inkonsistensi kecil antar dokumen mulai menumpuk dan membingungkan consumer. Prompt berikut menugaskan AI membandingkan beberapa spec sekaligus untuk menemukan ketidakselarasan.
1Cek konsistensi antara spec-spec berikut:
21. specs/order/create-order.md
32. specs/order/cancel-order.md
43. specs/order/get-order.md
5
6Cek:
71. Apakah error code yang digunakan konsisten? (UNAUTHORIZED vs AUTH_ERROR)
82. Apakah response format konsisten? (apakah semua pakai { data: ... }?)
93. Apakah HTTP status code konsisten untuk case yang sama?
104. Apakah naming field konsisten? (order_id vs orderId?)
115. Apakah domain language konsisten? (cancel vs void vs reverse?)
12
13Output: tabel inconsistencies dengan kolom:
14| Spec 1 | Spec 2 | Issue | Recommendation |Output tabel ini menyoroti persis di mana dua spec bertabrakan — misalnya satu memakai order_id dan lainnya orderId — sehingga kamu bisa menyeragamkannya sebelum inkonsistensi itu merembet ke kode dan API contract.
06.17 Mengukur Kualitas Spec dari Output AI
Bagaimana tahu bahwa spec yang dihasilkan AI benar-benar berkualitas, bukan hanya panjang? Gunakan scoring rubric berikut untuk menilainya secara terukur di skala 100 poin.
1Setelah AI menghasilkan spec, evaluasi dengan rubric ini (total 100 poin):
2
3User Story (20 poin):
4- 5: Role spesifik (bukan "user")
5- 5: Action konkret dan measurable
6- 5: Benefit jelas
7- 5: Konteks relevan disertakan
8
9Acceptance Criteria (40 poin):
10- 10: Semua AC bisa jadi test function
11- 10: Error case dengan HTTP status code explicit
12- 10: Response format didefinisikan
13- 10: Tidak ada AC yang ambigu
14
15Edge Cases (20 poin):
16- 7: Ada concurrent access EC
17- 7: Ada external dependency failure EC
18- 6: Ada boundary condition EC
19
20NFR (10 poin):
21- 5: Performance requirements dengan angka spesifik
22- 5: Observability requirements
23
24Format dan Completeness (10 poin):
25- 5: Scope jelas (apa yang tidak termasuk)
26- 5: Changelog format tersedia
27
28Score < 70: Perlu revisi signifikan
29Score 70-85: Bisa dipakai dengan revisi minor
30Score > 85: Siap untuk review finalRubric ini mengubah penilaian “spec ini bagus atau tidak” menjadi angka yang bisa dibandingkan antar-spec dan antar-iterasi, sehingga tim punya standar objektif kapan sebuah spec layak masuk review final.
06.18 Tips & Gotchas
💡 Tip 1: Selalu berikan domain context di awal prompt — AI tidak tahu bahwa “cancel order” di Santekno Shop berbeda dari “cancel order” di SaaS subscription. Selalu jelaskan domain context di bagian pertama prompt.
💡 Tip 2: Minta AI untuk flag ambiguitas, bukan assume — tambahkan instruksi: “Jika ada yang ambigu, tandai dengan [AMBIGUOUS] dan ajukan pertanyaan klarifikasi. JANGAN assume sendiri.” Ini mencegah AI mengisi kekosongan dengan asumsi yang mungkin salah.
💡 Tip 3: Berikan contoh output yang diinginkan — untuk format yang spesifik, berikan contoh: “AC harus dalam format ini: ‘System [action] ketika [condition] → [HTTP status] dengan error_code [CODE]’”.
💡 Tip 4: Verifikasi setiap angka yang AI berikan — AI kadang memberikan angka performance yang terlihat reasonable tapi tidak evidence-based. Selalu verifikasi NFR dengan benchmarking atau industry reference.
⚠️ Gotcha 1: AI cenderung menambahkan AC yang redundant untuk terlihat komprehensif — review setiap AC: apakah benar-benar perlu? Apakah sudah covered oleh AC lain? Spec yang terlalu panjang sama buruknya dengan yang terlalu pendek.
⚠️ Gotcha 2: AI tidak tahu production constraints spesifik sistem kamu — ia tidak tahu Kafka cluster kamu sering timeout, atau PostgreSQL max connection kamu 50. Berikan context ini secara explicit.
⚠️ Gotcha 3: Spec yang dihasilkan AI mungkin bias ke implementasi familiar — AI cenderung menyarankan pola yang sering terlihat di training data, yang belum tentu optimal untuk kasus spesifikmu.
⚠️ Gotcha 4: Jangan langsung approve spec dari AI tanpa human review — AI-generated spec harus selalu melalui review manusia yang paham domain bisnis. Spec adalah dokumen bisnis, bukan hanya dokumen teknikal.
06.19 Prompt untuk Spec yang Butuh Keputusan Bisnis
Kadang spec tersendat karena ada keputusan bisnis yang tidak bisa kamu putuskan sendiri. Prompt berikut mengubah AI menjadi fasilitator diskusi: ia menyiapkan opsi, trade-off, dan pertanyaan untuk product team.
1Saya sedang menulis spec untuk cancel order.
2Ada beberapa keputusan bisnis yang butuh input dari product team.
3
4Untuk setiap item berikut, berikan:
51. Opsi yang mungkin (A, B, C)
62. Trade-off masing-masing opsi
73. Rekomendasi berdasarkan common practice e-commerce
84. Pertanyaan yang perlu ditanyakan ke product team
9
10Keputusan yang dibutuhkan:
11a) Batas waktu cancel: 15 menit? 1 jam? Tidak ada batas?
12b) Cancel setelah CONFIRMED: tidak bisa sama sekali, atau bisa dengan approval merchant?
13c) Refund policy: otomatis full refund, atau perlu request terpisah?
14d) Notifikasi: email saja, atau juga in-app notification?
15
16Format output untuk setiap item:
17**[Keputusan]:**
18- Opsi A: [deskripsi] — Pro: [...] Kontra: [...]
19- Opsi B: [deskripsi] — Pro: [...] Kontra: [...]
20- Recommendation: [opsi mana dengan alasan]
21- Question untuk product: "[pertanyaan yang konkret]"Alih-alih memaksa AI mengambil keputusan bisnis yang bukan wewenangnya, prompt ini memanfaatkannya untuk mempersiapkan bahan diskusi yang matang — sehingga rapat dengan product team jadi singkat dan terarah pada keputusan, bukan eksplorasi.
06.20 Ringkasan
Prompt engineering untuk spec bukan tentang membuat AI bekerja lebih keras — tapi tentang memberikan AI context yang cukup untuk menghasilkan output yang bermakna.
Framework CONTEXT memastikan prompt kamu mencakup semua dimensi yang diperlukan: context bisnis, operations yang diinginkan, batasan scope, tech constraints, contoh nyata, referensi existing, dan format output.
Enam prompt pattern yang praktis:
- Spec dari requirement naratif
- Spec review dan gap analysis
- Spec dari kode yang sudah ada
- Pemecahan fitur kompleks
- Adversarial edge case finding
- Spec vs implementasi compliance check
Iterasi adalah kunci — spec yang baik hampir tidak pernah selesai dalam satu prompt. Workflow: draft → review → gap analysis → final check.
Simpan prompt yang efektif sebagai aset tim di docs/prompts/. Prompt yang bagus adalah investasi jangka panjang.
Di artikel berikutnya, kita akan membahas teknik yang lebih interaktif: Interview Yourself — metode klarifikasi dengan Claude yang mengubah requirement yang ambigu menjadi spec yang presisi melalui dialog terstruktur.