spec-driven

Artefak dari alur kerja bawaan: urutannya, formatnya, dan folder perubahan yang dihasilkannya.

spec-driven adalah skema bawaan bawaan OpenSpec. schema.yaml mendefinisikan bidang-bidang yang ditetapkannya.

Artefak

Alur kerja menyusun draf empat artefak:

Artefak	Berkas	Tujuan
proposal	proposal.md	Mengapa perubahan diperlukan
specs	specs/<capability-path>/spec.md, satu per kapabilitas	Perilaku apa yang berubah
design	design.md	Cara membangunnya
tasks	tasks.md	Daftar periksa implementasi

             ┌─ specs ──┐
proposal ────┤          ├── tasks ── apply
             └─ design ─┘

Proposal selalu diutamakan. Specs dan design menyusul dengan urutan bebas, dan tasks membutuhkan keduanya. Implementasi (apply) dimulai setelah tasks.md tersedia.

Dua artefak dapat dilewati:

• design: ketika tidak ada kondisinya yang terpenuhi, agen akan melewatkan artefak ini dan tetap menyusun tasks.
• specs: set skip_specs: true di .openspec.yaml perubahan tersebut.

Contoh folder perubahan

Perubahan bernama add-user-auth, dengan semua artefak yang disusun:

openspec/changes/add-user-auth/
├── .openspec.yaml      metadata perubahan, ditulis saat perubahan dibuat
├── proposal.md
├── specs/
│   └── user-auth/
│       └── spec.md     satu delta spec per capability
├── design.md
└── tasks.md

proposal.md

Menetapkan mengapa perubahan tersebut diperlukan.

Struktur

Template yang diterima agen sebagai format output (templates/proposal.md):

# Proposal

## Why

<!-- Jelaskan motivasi di balik perubahan ini. Masalah apa yang dipecahkan? Mengapa sekarang? -->

## What Changes

<!-- Jelaskan apa yang akan berubah. Spesifikkan tentang kapabilitas baru, modifikasi, atau penghapusan. -->

## Capabilities

### New Capabilities
<!-- Kapabilitas yang diperkenalkan. Berikan nama untuk setiap kapabilitas yang mewakili
     perilaku sistem yang koheren dan dapat memiliki persyaratan terkait seiring berkembangnya sistem. Jangan menamai
     tugas implementasi atau bagian proposal. Hindari nama umum yang terlalu luas. Gunakan
     kebab-case untuk segmen path yang Anda perkenalkan (misalnya, user-auth atau identity/user-auth)
     yang mengikuti organisasi spec yang sudah ada di proyek. Setiap kapabilitas membuat
     specs/<capability-path>/spec.md. -->
- `<capability-path>`: <deskripsi singkat tentang cakupan kapabilitas ini>

### Modified Capabilities
<!-- Kapabilitas yang sudah ada di mana REQUIREMENTS-nya berubah (bukan sekadar implementasi).
     Hanya daftarkan di sini jika ada perubahan perilaku di level spec. Setiap item membutuhkan file delta spec.
     Gunakan path yang sudah ada secara tepat di bawah openspec/specs/. Biarkan kosong jika tidak ada perubahan
     requirement. Perubahan tanpa kapabilitas sama sekali (refactor murni, tooling, docs)
     harus set `skip_specs: true` di .openspec.yaml - openspec validate akan menolak
     perubahan zero-delta tanpa penanda tersebut. Jangan mengarang requirement hanya untuk
     memenuhi validasi. -->
- `<existing-capability-path>`: <requirement apa yang berubah>

## Impact

<!-- Kode, API, dependensi, dan sistem yang terpengaruh -->

Instruksi

Instruksi yang dikirim ke agen saat ia menyusun artefak ini (dari schema.yaml):

Buat dokumen proposal yang menetapkan MENGAPA perubahan ini diperlukan.

Bagian-bagian:
- **Why**: 1-2 kalimat tentang masalah atau peluang. Masalah apa yang dipecahkan? Mengapa sekarang?
- **What Changes**: Daftar poin perubahan. Spesifikkan tentang kapabilitas baru, modifikasi, atau penghapusan. Tandai perubahan breaking dengan **BREAKING**.
- **Capabilities**: Identifikasi spec mana yang akan dibuat atau dimodifikasi:
  - **New Capabilities**: Daftarkan kapabilitas yang diperkenalkan. Setiap kapabilitas menjadi `specs/<capability-path>/spec.md` baru. Berikan nama untuk perilaku sistem yang permanen (misalnya, `user-auth`), bukan pekerjaan di perubahan ini (misalnya, `add-login-endpoint`). Pilih batas yang koheren yang dapat memiliki persyaratan terkait seiring berkembangnya sistem; hindari kapabilitas yang terlalu luas. Gunakan kebab-case untuk segmen path yang Anda perkenalkan (misalnya, `user-auth` atau `identity/user-auth`) dan ikuti organisasi spec yang sudah ada di proyek.
  - **Modified Capabilities**: Daftarkan kapabilitas yang sudah ada di mana REQUIREMENTS-nya berubah. Hanya sertakan jika ada perubahan perilaku di level spec (bukan detail implementasi). Setiap item membutuhkan file delta spec. Gunakan path yang sudah ada secara tepat di bawah `openspec/specs/`. Biarkan kosong jika tidak ada perubahan requirement.
- **Impact**: Kode, API, dependensi, atau sistem yang terpengaruh.

PENTING: Bagian Capabilities sangat penting. Bagian ini menciptakan kontrak antara
fase proposal dan specs. Riset spec yang sudah ada sebelum mengisi bagian ini:
jalankan `openspec list --specs` untuk inventaris kapabilitas proyek, lalu
`openspec show "<spec-id>" --type spec --json --no-scenarios` untuk yang
tampak terkait - hal ini mengembalikan tujuan dan teks requirement kapabilitas
tanpa menarik file spec lengkap ke dalam konteks. Tambahkan `--store "<id>"` ke
kedua perintah hanya untuk store standalone yang terdaftar, dan pertahankan `--type
spec`: perubahan dan spec yang berbagi nama sama akan menghasilkan error item ambigu
jika tidak. `openspec list` tanpa `--specs` akan melisting perubahan yang sedang berlangsung, bukan
spec - tidak pernah menunjukkan apa yang sudah dicakup oleh proyek. Gunakan ulang
path persis dari kapabilitas yang sudah ada daripada memperkenalkan nama yang hampir duplikat.
Pembacaan terfilter ini hanyalah tinjauan. Sebelum memutuskan apa yang sudah
dicakup atau apa yang harus diubah, baca setiap spec terkait secara lengkap, termasuk
scenarios, dengan `openspec show "<spec-id>" --type spec` (aturan `--store` yang sama).
Setiap kapabilitas yang terdaftar di sini akan membutuhkan file spec yang sesuai.

Setiap perubahan harus mendeklarasikan minimal satu kapabilitas (baru atau
termodifikasi) atau secara eksplisit memilih keluar dari specs: `openspec validate` akan menolak
perubahan dengan zero delta kecuali `.openspec.yaml` perubahan tersebut menyetel
`skip_specs: true`. Gunakan `skip_specs: true` hanya jika tidak ada perubahan
perilaku di level spec (refactor murni, tooling, docs) - spec menggambarkan
perilaku, jadi jika perilaku tidak berubah, spec pun tidak boleh berubah.
Jangan mengarang requirement hanya untuk memenuhi validasi.

Jaga agar ringkas (1-2 halaman). Fokus pada "mengapa" bukan "bagaimana" -
detail implementasi ada di design.md.

Ini adalah fondasi - specs, design, dan tasks semuanya dibangun di atas ini.

Delta specs (spec.md)

Menetapkan perubahan perilaku apa saja, dengan satu delta spec per kapabilitas yang terdaftar di proposal.

Setiap delta spec adalah spec.md di dalam folder kapabilitas terkait. openspec validate dan openspec archive akan menolak bagian delta yang ditulis di file lain di bawah specs/, seperti specs/user-auth.md, karena archive tidak pernah menggabungkannya.

Struktur

Template yang diterima agen sebagai format output (templates/spec.md):

# Spec Delta

## Purpose
<!-- Hanya untuk kapabilitas baru: satu atau dua kalimat (50+ karakter) tentang kegunaan kapabilitas ini. Hapus bagian ini untuk kapabilitas yang sudah ada. -->

## ADDED Requirements

### Requirement: <!-- nama requirement -->
<!-- teks requirement -->

#### Scenario: <!-- nama scenario -->
- **WHEN** <!-- kondisi -->
- **THEN** <!-- hasil yang diharapkan -->

Instruksi

Instruksi yang dikirim ke agen saat ia menyusun artefak ini (dari schema.yaml):

Buat file spesifikasi yang menetapkan APA yang harus dilakukan sistem.

Spesifikasi adalah kontrak perilaku, bukan rencana implementasi.

Isi spesifikasi yang baik:
- Perilaku observabel yang diandalkan oleh pengguna atau sistem downstream
- Input, output, dan kondisi error
- Constraint eksternal (keamanan, privasi, keandalan, kompatibilitas)
- Scenario yang dapat diuji atau divalidasi secara eksplisit

Hindari dalam spesifikasi:
- Nama class/function internal
- Pilihan library atau framework
- Detail implementasi langkah demi langkah
- Rencana eksekusi detail (hal tersebut ada di design.md atau tasks.md)

Tes cepat: jika implementasi dapat berubah tanpa mengubah perilaku
yang terlihat dari luar, kemungkinan besar hal tersebut tidak termasuk dalam spesifikasi.

Buat satu file spec per kapabilitas yang terdaftar di bagian Capabilities proposal.
`<capability-path>` adalah direktori spec relatif terhadap `specs/` (misalnya,
`user-auth` atau `identity/user-auth`). Pertahankan path penuh:
- Kapabilitas baru: gunakan path persis dari proposal di `specs/<capability-path>/spec.md`. Setiap segmen path yang baru diperkenalkan di proposal harus dalam format kebab-case. Ikuti organisasi yang sudah ada di proyek; jangan menambahkan level domain baru jika proyek menggunakan layout datar.
- Kapabilitas termodifikasi: gunakan path yang sudah ada secara tepat dari `openspec/specs/<capability-path>/` saat membuat delta di `specs/<capability-path>/spec.md`. Jalankan `openspec list --specs` untuk memastikan path tersebut sebelum menulis delta, tambahkan `--store "<id>"` hanya untuk store standalone yang terdaftar - path yang salah ketik atau diarang akan menargetkan kapabilitas yang tidak ada alih-alih yang Anda maksud. Jangan memindahkan atau mengganti nama kapabilitas.

Tulis file spec satu per satu, sehingga pengguna melihat progres dan
eksekusi yang interupsi tetap mempertahankan file yang sudah ditulis:
- Sebelum menulis apa pun, bandingkan kapabilitas yang terdaftar di proposal
  dengan file `specs/<capability-path>/spec.md` yang sudah ada,
  dan mulai dengan kapabilitas pertama yang belum memiliki file. Jangan menulis ulang
  file yang sudah ada kecuali pengguna memintanya.
- Sebelum setiap file, sebutkan dalam satu baris kapabilitas apa yang sedang ditulis.
- Tulis setiap file segera setelah selesai disusun. Jangan merencanakan semua file
  sebelum menulis yang pertama.
- Berhenti ketika setiap kapabilitas yang terdaftar di proposal sudah memiliki filenya.

Harus ada minimal satu file spec kecuali `.openspec.yaml` perubahan
menyetel `skip_specs: true` (tidak ada perubahan perilaku di level spec) - `openspec validate`
akan menolak perubahan zero-delta tanpa penanda tersebut. Jika proposal tidak mendaftarkan
kapabilitas apa pun dan `skip_specs` tidak disetel, revisi proposal terlebih dahulu.

Operasi delta (gunakan header ##):
- **ADDED Requirements**: Kapabilitas baru
- **MODIFIED Requirements**: Perubahan perilaku - HARUS menyertakan konten lengkap yang diperbarui
- **REMOVED Requirements**: Fitur yang tidak digunakan lagi - HARUS menyertakan **Reason** dan **Migration**
- **RENAMED Requirements**: Perubahan nama saja - gunakan format FROM:/TO:

Persyaratan format:
- Setiap requirement: `### Requirement: <nama>` diikuti deskripsi
- Gunakan SHALL/MUST untuk requirement normatif (hindari should/may)
- Setiap scenario: `#### Scenario: <nama>` dengan format WHEN/THEN
- **KRITIS**: Scenario HARUS menggunakan tepat 4 hashtag (`####`). Menggunakan 3 hashtag atau bullet akan gagal secara diam-diam.
- Setiap requirement HARUS memiliki minimal satu scenario.
- Setiap scenario HARUS memiliki langkah WHEN/GIVEN (pemicunya) dan langkah THEN (hasilnya). Scenario yang hanya memiliki baris AND atau narasi biasa tetap dihitung sebagai scenario, tetapi `openspec validate` akan menandainya sebagai peringatan: validasi normal tetap lulus, tetapi `openspec validate --strict` akan gagal padanya.
- Jaga deskripsi setiap requirement (teks antara `### Requirement:` dan scenario pertamanya) agar tidak lebih dari 500 karakter. `openspec validate` akan menandai deskripsi yang lebih panjang di requirement ADDED dan di spec utama. Ini adalah peringatan: validasi normal tetap lulus, tetapi `openspec validate --strict` akan gagal padanya. Saat menulis requirement baru, nyatakan satu perilaku per requirement: pindahkan contoh dan kasus tepi ke scenarios, dan pecah requirement yang mencakup beberapa perilaku menjadi blok `### Requirement:` terpisah, masing-masing dengan scenariosnya sendiri. Di bawah MODIFIED, pertahankan blok requirement yang ada secara utuh; jangan memecah, memangkas, atau menulis ulang teks yang ada hanya untuk memenuhi panjang. Pecah requirement yang sudah ada dan panjang hanya jika pengguna memintanya, dalam perubahan yang dibuat untuk tujuan tersebut: di bawah MODIFIED, pertahankan header dan setiap scenario-nya serta pangkas deskripsinya menjadi satu perilaku tanpa mengubah artinya, kemudian tambahkan setiap perilaku yang Anda hapus sebagai requirement ADDED tersendiri dengan scenariosnya sendiri.

Hanya untuk kapabilitas baru: bagian pertama delta spec adalah `## Purpose` -
satu atau dua kalimat (50+ karakter, atau `openspec validate --strict`
melaporkannya terlalu singkat) yang menjelaskan kegunaan kapabilitas. Archive
menyalinnya ke spec utama yang dibuatnya; tanpa itu spec utama baru akan
dibiarkan dengan placeholder `TBD ... Update Purpose after archive` untuk diisi
secara manual. Jangan MENAMBAHKAN `## Purpose` ke delta untuk kapabilitas yang sudah ada -
spec tersebut sudah memilikinya dan bagian delta akan diabaikan. Untuk mengubah
Purpose kapabilitas yang sudah ada - termasuk placeholder `TBD` yang tersisa -
edit `<planningHome.root>/openspec/specs/<capability-path>/spec.md`
secara langsung. `planningHome.root` berasal dari respons `openspec instructions ...
--json`. Selalu gunakan alih-alih path relatif terhadap repo: hal ini
menyelesaikan ke store kapan pun perubahan berada di dalamnya - apakah
berasal dari `--store`, pointer `store:` proyek, atau store default global
- dan ke repositori saat ini jika tidak. Jangan coba tebak
kasus mana yang berlaku; field tersebut sudah memuat informasi.

Alur kerja requirement MODIFIED:
1. Temukan requirement yang sudah ada di `<planningHome.root>/openspec/specs/<capability-path>/spec.md` (root yang sadar store yang sama seperti di atas)
2. Salin blok requirement SELURUH (dari `### Requirement:` sampai semua scenarios)
3. Tempel di bawah `## MODIFIED Requirements` dan edit untuk mencerminkan perilaku baru
4. Pastikan teks header cocok secara persis (tidak peka whitespace)

Jebakan umum: Menggunakan MODIFIED dengan konten parsial akan kehilangan detail saat archive.
Jika menambahkan perhatian baru tanpa mengubah perilaku yang ada, gunakan ADDED.

Contoh (kapabilitas baru, jadi bagian pertamanya adalah `## Purpose`):
```
# Spec Delta
## Tujuan

Memungkinkan pengguna mengambil data mereka keluar dari produk dalam format portabel.

## Persyaratan Tambahan

### Persyaratan: Pengguna dapat mengekspor data
Sistem HARUS memungkinkan pengguna untuk mengekspor data mereka dalam format CSV.

#### Skenario: Ekspor berhasil
- **KETIKA** pengguna mengklik tombol "Export"
- **MAKA** sistem mengunduh file CSV dengan semua data pengguna## REMOVED Requirements

### Requirement: Ekspor legacy
**Reason**: Diganti oleh sistem ekspor baru
**Migration**: Gunakan endpoint ekspor baru di /api/v2/export
```

Spec harus dapat diuji - setiap skenario adalah potensi kasus uji.

design.md

Menjelaskan cara mengimplementasikan perubahan. Disusun hanya jika perubahan memerlukannya.

Struktur

Templat yang diterima agent sebagai format output (templates/design.md):

# Desain

## Konteks

<!-- Status saat ini dan batasan yang membentuk pendekatan. Lihat proposal.md untuk motivasi - jangan mengulanginya -->

## Tujuan / Non-Tujuan

**Tujuan:**
<!-- Apa yang ingin dicapai desain ini -->

**Non-Tujuan:**
<!-- Apa yang secara eksplisit berada di luar cakupan -->

## Keputusan

<!-- Keputusan desain utama dengan alasan dan alternatif yang dipertimbangkan -->

## Risiko / Trade-off

<!-- Risiko dan trade-off yang diketahui -->

Instruksi

Instruksi yang dikirim ke agent saat menyusun artefak ini (dari schema.yaml):

Buat dokumen desain yang menjelaskan CARA mengimplementasikan perubahan.

Kapan menyertakan design.md (buat hanya jika ada yang berlaku):
- Perubahan lintas layanan/modul atau pola arsitektur baru
- Dependensi eksternal baru atau perubahan model data yang signifikan
- Kompleksitas keamanan, performa, atau migrasi
- Ambiguitas yang lebih baik diselesaikan dengan keputusan teknis sebelum coding

Bagian:
- **Konteks**: Hanya status saat ini dan batasan yang diperlukan untuk menjelaskan pendekatan. Rujuk proposal untuk motivasi alih-alih mengulanginya (contoh: "Lihat proposal.md - Why").
- **Tujuan / Non-Tujuan**: Apa yang dicapai desain ini dan secara eksplisit dikecualikan. Jangan mengulang cakupan proposal - tambahkan hanya batasan tingkat desain.
- **Keputusan**: Pilihan teknis utama dengan alasan (mengapa X daripada Y?). Sertakan alternatif yang dipertimbangkan untuk setiap keputusan.
- **Risiko / Trade-off**: Keterbatasan yang diketahui, hal-hal yang bisa salah. Format: [Risiko] → Mitigasi
- **Rencana Migrasi**: Langkah-langkah untuk menerapkan, strategi rollback (jika berlaku)
- **Pertanyaan Terbuka**: Hal yang belum diketahui yang dapat dijawab dengan aman nanti tanpa mengubah spec, pendekatan, atau pemecahan tugas. Hilangkan jika tidak ada.

Pertanyaan terbuka adalah untuk hal yang benar-benar belum diketahui dan dapat ditunda, bukan keputusan yang Anda lewati. Jika sebuah pertanyaan akan mengubah spec, pendekatan yang dipilih, atau pemecahan tugas, selesaikan sekarang - tanyakan kepada pengguna alih-alih menebak.

Fokus pada arsitektur dan pendekatan, bukan implementasi baris demi baris.
Proposal mencakup mengapa dan apa; desain mencakup bagaimana. Rujuk proposal untuk motivasi dan, setelah ditulis, spec untuk persyaratan - jika suatu bagian hanya akan mengulanginya, tunjuk saja ke sana.

Dokumen desain yang baik menjelaskan "mengapa" di balik keputusan teknis.

tasks.md

Memecah implementasi menjadi tugas-tugas yang dapat diperiksa. apply melacak kemajuan di sini.

Struktur

Templat yang diterima agent sebagai format output (templates/tasks.md):

# Tugas

## 1. <!-- Nama Grup Tugas -->

- [ ] 1.1 <!-- Deskripsi tugas -->
- [ ] 1.2 <!-- Deskripsi tugas -->

## 2. <!-- Nama Grup Tugas -->

- [ ] 2.1 <!-- Deskripsi tugas -->
- [ ] 2.2 <!-- Deskripsi tugas -->

Instruksi

Instruksi yang dikirim ke agent saat menyusun artefak ini (dari schema.yaml):

Buat daftar tugas yang memecah pekerjaan implementasi.

Sebelum menulis tugas, periksa design.md untuk Pertanyaan Terbuka. Jika ada
yang akan mengubah apa yang dibangun, selesaikan dulu dengan pengguna - jangan
menanam asumsi yang tidak dinyatakan ke dalam daftar tugas.

**PENTING: Ikuti templat di bawah untuk tugas yang dilacak.** Fase apply mem-parsing
format kotak centang untuk melacak kemajuan. Kotak yang hanya berisi `x` dihitung selesai,
baik huruf besar maupun kecil dan dengan spasi apa pun, sehingga `- [ x]` juga selesai. Setiap
penanda lain, termasuk `- [~]`, `- [-]` dan `- []` yang kosong, dibaca sebagai
belum selesai. Baris tanpa kotak centang tidak dilacak sama sekali.

Pedoman:
- Kelompokkan tugas terkait yang dilacak di bawah judul bernomor ##
- Setiap tugas yang dilacak HARUS berupa kotak centang: `- [ ] X.Y Deskripsi tugas`
- Tugas harus cukup kecil untuk diselesaikan dalam satu sesi
- Urutkan tugas berdasarkan dependensi (apa yang harus dilakukan lebih dulu?)
- Lacak pekerjaan implementasi dan verifikasi yang dapat diselesaikan sebelum
  pengarsipan. Jika alur kerja yang diminta mencakup pengarsipan atau pekerjaan yang memerlukan
  perubahan ini untuk diarsipkan, pertahankan langkah-langkah tersebut sebagai bullet biasa di
  bagian opsional `## Tindak Lanjut Alur Kerja` di akhir tasks.md. Bullet ini
  adalah informasi referensi di luar kemajuan tugas yang dilacak.
- Setiap tugas HARUS menyatakan cara memverifikasi penyelesaian (tes, perintah,
  perilaku yang dapat diamati, atau artefak yang diserahkan). Letakkan verifikasi di
  deskripsi kotak centang tugas tersebut. Gunakan tugas verifikasi terpisah hanya
  ketika memeriksa integrasi atau perilaku sistem yang lebih luas yang mencakup
  beberapa tugas implementasi.
- Setiap grup tugas HARUS menyertakan tes dan dokumentasi yang diperlukan oleh
  pekerjaannya sendiri. JANGAN mengumpulkan pengujian atau dokumentasi ke dalam grup akhir -
  ketika grup yang lebih akhir pertama kali menjalankan pekerjaan dari grup awal, kegagalan
  merambat kembali melalui setiap grup di antaranya dan memaksa pengerjaan ulang. Grup
  yang pekerjaannya tidak memerlukan keduanya, seperti scaffolding atau penyiapan dependensi,
  juga tidak membawa keduanya. Grup akhir hanya untuk pemeriksaan integrasi, bukan untuk
  tes dan dokumentasi yang menjadi kewajiban grup sebelumnya.

Contoh:
```
# Tugas

## 1. Persiapan

- [ ] 1.1 Buat struktur modul baru dan verifikasi file yang diharapkan tersedia
- [ ] 1.2 Tambahkan dependensi ke package.json dan verifikasi instalasi paket berhasil

## 2. Implementasi Inti

- [ ] 2.1 Implementasikan fungsi ekspor data dan verifikasi tes ekspor lulus
- [ ] 2.2 Tambahkan utilitas pemformatan CSV dan verifikasi tes unit mencakup quoting dan delimiter
- [ ] 2.3 Dokumentasikan API ekspor di docs/export.md dan verifikasi perintah yang didokumentasikan berjalan sesuai tulisan
```

Jika berlaku, tambahkan tindak lanjut alur kerja sebagai bullet biasa, misalnya:
```
## Tindak Lanjut Alur Kerja

- Arsipkan perubahan setelah persyaratan peninjauan proyek terpenuhi.
- Verifikasi hasil yang diarsipkan.
```

Rujuk spec untuk apa yang perlu dibangun, desain untuk bagaimana membangunnya.

Apply

Serah terima dari perencanaan ke implementasi. Apply adalah fase yang mengerjakan tasks.md, bukan artefak.

• Dimulai: setelah tasks.md ada dan mencantumkan setidaknya satu tugas.
• Melacak: kotak centang di tasks.md. Mencentangnya adalah catatan kemajuan.
• Berakhir: semua kotak centang tercentang. OpenSpec kemudian menyarankan pengarsipan perubahan.

Pengaturan

Pengaturan apply (dari schema.yaml):

apply:
  requires: [tasks]
  tracks: tasks.md
  # instruction: ditampilkan di bawah

Instruksi

Instruksi yang dikirim ke agent saat implementasi dimulai (dari schema.yaml):

Baca file konteks, kerjakan tugas yang tertunda, tandai selesai seiring berjalannya waktu.
Jeda jika Anda menemui hambatan atau memerlukan klarifikasi.

schema.yaml

schema.yaml lengkap, dengan isi instruksi dihilangkan. Masing-masing ditampilkan secara lengkap di bagiannya di atas.

name: spec-driven
version: 1
description: Alur kerja OpenSpec bawaan - proposal → specs → design → tasks
artifacts:
  - id: proposal
    generates: proposal.md
    description: Dokumen proposal awal yang menguraikan perubahan
    template: proposal.md
    # instruction: ditampilkan secara lengkap di bagian proposal.md di atas
    requires: []

  - id: specs
    generates: "specs/**/*.md"
    description: Spesifikasi terperinci untuk perubahan
    template: spec.md
    # instruction: ditampilkan secara lengkap di bagian Delta specs di atas
    requires:
      - proposal

  - id: design
    generates: design.md
    description: Dokumen desain teknis dengan detail implementasi
    template: design.md
    # instruction: ditampilkan secara lengkap di bagian design.md di atas
    requires:
      - proposal

  - id: tasks
    generates: tasks.md
    description: Daftar periksa implementasi dengan tugas yang dapat dilacak
    template: tasks.md
    # instruction: ditampilkan secara lengkap di bagian tasks.md di atas
    requires:
      - specs
      - design

apply:
  requires: [tasks]
  tracks: tasks.md
  # instruction: ditampilkan secara lengkap di bagian Apply di atas