spec-driven

Varsayılan iş akışının çıktıları: sıralamaları, biçimleri ve ürettikleri değişiklik klasörü.

spec-driven, OpenSpec'in yerleşik varsayılan şemasıdır. schema.yaml, ayarladığı alanları tanımlar.

Çıktılar

İş akışı dört çıktı hazırlar:

Çıktı	Dosya	Amaç
proposal	proposal.md	Değişikliğin neden gerekli olduğu
specs	specs/<capability-path>/spec.md, her yetenek için bir tane	Hangi davranışın değiştiği
design	design.md	Nasıl oluşturulacağı
tasks	tasks.md	Uygulama kontrol listesi

Taslak sırası

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

Proposal (öneri) önce gelir. Specs (şartnameler) ve design (tasarım) herhangi bir sırada takip eder, tasks (görevler) ise her ikisine de ihtiyaç duyar. Uygulama (apply), tasks.md yerindeyken başlar.

İki atifact atlanabilir:

• design: koşulları hiçbiri uygulanmadığında, ajan bunu atlar ve yine de tasks taslağını hazırlar.
• specs: Değişikliğin .openspec.yaml dosyasında skip_specs: true ayarlayın.

Örnek değişiklik klasörü

add-user-auth adlı bir değişiklik, her artifact taslaklanmış halde:

openspec/changes/add-user-auth/
├── .openspec.yaml      değişiklik meta verisi, değişiklik oluşturulduğunda yazılır
├── proposal.md
├── specs/
│   └── user-auth/
│       └── spec.md     yetenek başına bir delta spec
├── design.md
└── tasks.md

proposal.md

Değişikliğin neden gerekli olduğunu belirler.

Yapı

Ajanın çıktı formatı olarak aldığı şablon (templates/proposal.md):

# Proposal (Öneri)

## Why (Neden)

<!-- Bu değişiklik için motivasyonu açıklayın. Hangi sorunu çözüyor? Neden şimdi? -->

## What Changes (Ne Değişiyor)

<!-- Ne değişeceğini tanımlayın. Yeni yetenekler, değişiklikler veya kaldırmalar hakkında spesifik olun. -->

## Capabilities (Yetenekler)

### New Capabilities (Yeni Yetenekler)
<!-- Tanıtılan yetenekler. Her yeteneği, ilgili gereksinimleri sistem evrildikçe sahiplenebilecek tutarlı bir sistem davranışı için adlandırın. Uygulama görevlerini veya öneri bölümlerini adlandırmayın. Geniş kapsamlı yakalama-tümü isimlerden kaçının. Proje'nin mevcut spec organizasyonunu takip eden kebab-case yol segmentleri kullanın (örneğin, user-auth veya identity/user-auth). Her biri specs/<capability-path>/spec.md oluşturur. -->
- `<capability-path>`: <bu yeteneğin neyi kapsadığına dair kısa açıklama>

### Modified Capabilities (Değiştirilen Yetenekler)
<!-- GEREKSİNİMLERİ değişen mevcut yetenekler (sadece uygulama değil). Sadece spec-seviyesi davranış değişiyorsa buraya ekleyin. Her biri bir delta spec dosyası gerektirir. openspec/specs/ altındaki tam mevcut yolu kullanın. Gereksinim değişikliği yoksa boş bırakın. Hiç yeteneği olmayan bir değişiklik (saf refactor, araçlama, dokümantasyon) .openspec.yaml dosyasında `skip_specs: true` ayarlamalıdır - openspec validate, bu işaretçi olmadan sıfır delta'lı bir değişikliği reddeder. Sadece doğrulama için bir gereksinim uydurmayın. -->
- `<existing-capability-path>`: <hangi gereksinim değişiyor>

## Impact (Etki)

<!-- Etkilenen kod, API'ler, bağımlılıklar, sistemler -->

Talimatlar

Bu artifact'i tasarlarken ajana gönderilen talimat (from schema.yaml):

Bu değişikliğin NEDEN gerekli olduğunu belirleyen öneri belgesini oluşturun.

Bölümler:
- **Why (Neden)**: Sorun veya fırsat hakkında 1-2 cümle. Hangi sorunu çözüyor? Neden şimdi?
- **What Changes (Ne Değişiyor)**: Değişikliklerin madde listesi. Yeni yetenekler, değişiklikler veya kaldırmalar hakkında spesifik olun. Kırıcı değişiklikleri **BREAKING** ile işaretleyin.
- **Capabilities (Yetenekler)**: Hangi spec'lerin oluşturulacağını veya değiştirileceğini belirleyin:
  - **New Capabilities (Yeni Yetenekler)**: Tanıtılan yetenekleri listeleyin. Her biri yeni bir `specs/<capability-path>/spec.md` olur. Her yeteneği, bu değişiklikteki iş için değil (örneğin, `add-login-endpoint`), dayanıklı bir sistem davranışı için adlandırın (örneğin, `user-auth`). İlgili gereksinimleri sistem evrildikçe sahiplenebilecek tutarlı bir sınır seçin; geniş kapsamlı yeteneklerden kaçının. Kebab-case yol segmentleri kullanın (örneğin, `user-auth` veya `identity/user-auth`) ve projenin mevcut spec organizasyonunu takip edin.
  - **Modified Capabilities (Değiştirilen Yetenekler)**: GEREKSİNİMLERİ değişen mevcut yetenekleri listeleyin. Sadece spec-seviyesi davranış değişiyorsa dahil edin (sadece uygulama detayları değil). Her biri bir delta spec dosyası gerektirir. `openspec/specs/` altındaki tam mevcut yolu kullanın. Gereksinim değişikliği yoksa boş bırakın.
- **Impact (Etki)**: Etkilenen kod, API'ler, bağımlılıklar veya sistemler.

ÖNEMLİ: Capabilities bölümü kritik. Proposal ve specs aşamaları arasındaki sözleşmeyi oluşturur. Bu bölümü doldurmadan önce mevcut spec'leri araştırın:
`openspec list --specs` komutunu çalıştırarak projenin yetenek envanterini alın, ardından ilgili görünenler için `openspec show "<spec-id>" --type spec --json --no-scenarios` komutunu çalıştırın - bu, bir yeteneğin amacını ve gereksinim metinlerini, tam spec dosyalarını context'e çekmeden döndürür. Yalnızca kayıtlı bağımsız bir store için her iki komuta da `--store "<id>"` ekleyin ve `--type spec` tutun: aynı isimde bir change ve spec aksi takdirde ambiguous-item hatasına yol açar. `--specs` olmadan `openspec list`, uçuşta olan değişiklikleri listeler, spec'leri değil - projenin zaten neyi kapsadığını asla göstermez. Yakın benzetme bir isim uydurmak yerine mevcut bir yeteneğin tam yolunu yeniden kullanın. Filtreli okuma sadece bir genel bakıştır. Ne zaten kapsandığına veya neyin değişmesi gerektiğine karar vermeden önce, `openspec show "<spec-id>" --type spec` ile (aynı `--store` kuralı) senaryolar da dahil her ilgili spec'i tamamen okuyun. Burada listelenen her yetenek karşılık gelen bir spec dosyasına ihtiyaç duyacak.

Her değişiklik en az bir yeteneği (yeni veya değiştirilmiş) bildirmeli veya specs'ten açıkça vazgeçmelidir: `openspec validate`, `.openspec.yaml` dosyasında `skip_specs: true` ayarlanmamışsa sıfır delta'lı bir değişikliği reddeder. `skip_specs: true` sadece spec-seviyesi davranış değişikliği olmadığında kullanın (saf refactor, araçlama, dokümantasyon) - spec'ler davranışı tanımlar, bu yüzden davranış değişmiyorsa hiçbir spec de değişmemelidir. Sadece doğrulamayı karşılamak için bir gereksinim uydurmayın.

Kısa tutun (1-2 sayfa). "Neden"e odaklanın "nasıl"a değil - uygulama detayları design.md'ye aittir.

Bu temel - specs, design ve tasks hepsi buna dayanır.

Delta spec'ler (spec.md)

Ne davranışın değiştiğini tanımlar, proposal'in listelediği her yetenek için bir delta spec ile.

Her delta spec, yetenek klasörü içindeki spec.md dosyasıdır. openspec validate ve openspec archive, specs/ altındaki başka herhangi bir dosyada yazılan delta bölümlerini (örneğin specs/user-auth.md) reddeder, çünkü archive onları asla birleştirmez.

Yapı

Ajanın çıktı formatı olarak aldığı şablon (templates/spec.md):

# Spec Delta

## Purpose (Amaç)
<!-- Sadece yeni yetenekler için: bu yeteneğin ne için olduğu hakkında bir veya iki cümle (50+ karakter). Mevcut bir yetenek için bu bölümü silin. -->

## ADDED Requirements (EKLENEN Gereksinimler)

### Requirement: <!-- gereksinim adı -->
<!-- gereksinim metni -->

#### Scenario: <!-- senaryo adı -->
- **WHEN** <!-- koşul -->
- **THEN** <!-- beklenen sonuç -->

Talimatlar

Bu artifact'i tasarlarken ajana gönderilen talimat (from schema.yaml):

Sistemin NE yapması gerektiğini tanımlayan spec dosyaları oluşturun.

Spec bir davranış sözleşmesidir, bir uygulama planı değil.

İyi spec içeriği:
- Kullanıcıların veya alt sistemlerin güvenebileceği gözlemlenebilir davranış
- Girdiler, çıktılar ve hata koşulları
- Harici kısıtlamalar (güvenlik, gizlilik, güvenilirlik, uyumluluk)
- Test edilebilecek veya açıkça doğrulanabilecek senaryolar

Spec'lerde KAÇINILMASI GEREKENLER:
- İç sınıf/fonksiyon isimleri
- Kütüphane veya framework seçimleri
- Adım adım uygulama detayları
- Detaylı yürütme planları (bunlar design.md veya tasks.md'ye aittir)

Hızlı test: uygulama, dışarıdan görünen davranışı değiştirmeden değişebiliyorsa, bu muhtemelen spec'e ait değildir.

Proposal'in Capabilities bölümünde listelenen her yetenek için bir spec dosyası oluşturun.
`<capability-path>`, `specs/`'e göreli spec dizinidir (örneğin, `user-auth` veya `identity/user-auth`). Tam yolu koruyun:
- Yeni yetenekler: proposal'deki tam yolu `specs/<capability-path>/spec.md` adresinde kullanın. Proposal'de yeni tanıtılan her yol segmenti kebab-case olmalıdır. Projenin mevcut organizasyonunu takip edin; proje düz bir düzen kullanıyorsa yeni bir domain seviyesi eklemeyin.
- Değiştirilen yetenekler: `openspec/specs/<capability-path>/` altındaki tam mevcut yolu, delta'yı `specs/<capability-path>/spec.md` adresinde oluştururken kullanın. `openspec list --specs` çalıştırarak o yolu onaylayın, yalnızca kayıtlı bağımsız bir store için `--store "<id>"` ekleyin - yanlış yazılmış veya uydurulmuş bir yol, kastettiğiniz yetenek yerine var olmayan bir yeteneği hedefler. Yetenekleri taşımayın veya yeniden adlandırmayın.

Spec dosyalarını tek tek yazın, böylece kullanıcı ilerlemeyi görür ve kesintili bir çalışma zaten yazılan dosyaları korur:
- Herhangi bir şey yazmadan önce, proposal'in listelediği yetenekleri zaten var olan `specs/<capability-path>/spec.md` dosyalarıyla karşılaştırın ve dosyası olmayan ilk yetenekle başlayın. Kullanıcı sizden istemediği sürece var olan bir dosyayı yeniden yazmayın.
- Her dosyadan önce, hangi yeteneği yazdığınızı tek satırda belirtin.
- Taslağınız hazır olunca her dosyayı hemen yazın. İlk dosyayı yazmadan önce her dosyayı planlamayın.
- Proposal'in listelediği her yeteneğinin dosyası olduğunda durun.

Değişikliğin `.openspec.yaml` dosyası `skip_specs: true` ayarlamadığı sürece (spec-seviyesi davranış değişikliği yok) en az bir spec dosyası olmalıdır - `openspec validate` bu işaretçi olmadan sıfır delta'lı bir değişikliği reddeder. Proposal hiç yetenek listelemiyorsa ve `skip_specs` ayarlı değilse, önce proposal'i gözden geçirin.

Delta işlemleri (## başlıkları kullanın):
- **ADDED Requirements (EKLENEN Gereksinimler)**: Yeni yetenekler
- **MODIFIED Requirements (DEĞİŞTİRİLEN Gereksinimler)**: Değişen davranış - TAM güncellenmiş içeriği MUTLAKA içermeli
- **REMOVED Requirements (KALDIRILAN Gereksinimler)**: Kullanımdan kaldırılan özellikler - **Reason (Neden)** ve **Migration (Göç)** MUTLAKA içermeli
- **RENAMED Requirements (YENİDEN ADLANDIRILAN Gereksinimler)**: Sadece isim değişiklikleri - FROM:/TO: formatını kullanın

Gereksinim formatı:
- Her gereksinim: `### Requirement: <name>` ardından açıklama
- Normatif gereksinimler için SHALL/MUST kullanın (should/may'den kaçının)
- Her senaryo: `#### Scenario: <name>` WHEN/THEN formatıyla
- **KRİTİK**: Senaryolar TAM OLARAK 4 hashtag (`####`) kullanmalıdır. 3 hashtag veya madde işareti kullanımı sessizce başarısız olur.
- Her gereksinim EN AZ bir senaryoya sahip olmalıdır.
- Her senaryo bir WHEN/GIVEN adımına (tetikleyicisi) ve bir THEN adımına (sonucu) sahip olmalıdır. Sadece AND satırları veya düz metin içeren bir senaryo yine de bir senaryo sayılır, ancak `openspec validate` bunu uyarı olarak işaretler: normal doğrulama yine de geçer, ama `openspec validate --strict` bunda başarısız olur.
- Her gereksinimin açıklamasını (`### Requirement:` ile ilk senaryosu arasındaki metin) 500 karakter veya daha az tutun. `openspec validate` ADDED gereksinimlerde ve ana spec'te daha uzun açıklamaları uyarı olarak işaretler. Bu bir uyarıdır: normal doğrulama yine de geçer, ama `openspec validate --strict` bunda başarısız olur. Yeni bir gereksinim yazarken, gereksinim başına bir davranış belirtin: örnekleri ve kenar durumlarını senaryolara taşıyın, birkaç davranışı kapsayan bir gereksinimi, her biri kendi senaryolarına sahip ayrı `### Requirement:` bloklarına bölün. MODIFIED altında, mevcut gereksinim bloğunu bütünlüğünde tutun; uzunluğu karşılamak için asla bölmeyin, kırpmayın veya mevcut metni yeniden yazmayın. Mevcut uzun bir gereksinimi sadece kullanıcı istediğinde, o amaçla yapılan bir değişiklikte bölün: MODIFIED altında, başlığını ve her senaryosunu koruyun ama açıklamasını anlamı değiştirmeden tek bir davranışa indirin, ardından çıkardığınız her davranışı kendi senaryolarıyla kendi ADDED gereksinimi olarak ekleyin.

Sadece yeni yetenekler için: delta spec'in ilk bölümü `## Purpose` -
bir veya iki cümle (50+ karakter, aksi takdirde `openspec validate --strict` bunu çok kısa olarak raporlar) yeteneğin ne için olduğunu açıklayan. Archive bunu oluşturduğu ana spec'e kopyalar; olmadan yeni ana spec `TBD ... Update Purpose after archive` yer tutucusu ile bırakılır, elle doldurulmak üzere. Mevcut bir yetenek için delta'ya `## Purpose` EKLEMEYİN - o spec zaten birine sahip ve delta'nkı yok sayılır. Mevcut bir yeteneğin Purpose'unu değiştirmek için - kalan `TBD` yer tutucusu dahil - `<planningHome.root>/openspec/specs/<capability-path>/spec.md` dosyasını doğrudan düzenleyin. `planningHome.root`, `openspec instructions ... --json` yanıtından gelir. Her zaman bunu kullanın, repo-göreli bir yol yerine: bu, değişiklik bir store'da yaşadığında store'a çözümlenir - bu `--store`'dan, bir proje `store:` işaretçisinden veya global bir varsayılan store'dan gelmiş olsun - ve aksi takdirde mevcut depoya. Hangi durumun geçerli olduğunu hesaplamaya çalışmayın; alan zaten bunu halletmiştir.

MODIFIED gereksinimleri iş akışı:
1. Mevcut gereksinimi `<planningHome.root>/openspec/specs/<capability-path>/spec.md` adresinde bulun (yukarıdaki aynı store-farkında root)
2. TÜM gereksinim bloğunu kopyalayın (`### Requirement:`'dan tüm senaryolar aracılığıyla)
3. `## MODIFIED Requirements` altına yapıştırın ve yeni davranışı yansıtacak şekilde düzenleyin
4. Başlık metninin tam olarak eşleştiğinden emin olun (boşluk duyarsız)

 yaygın tuzak: Kısmi içerikle MODIFIED kullanmak, archive zamanında detay kaybına yol açar. Mevcut davranışı değiştirmeden yeni endişeler ekliyorsanız, bunun yerine ADDED kullanın.

Örnek (yeni bir yetenek, bu yüzden ilk bölümü `## Purpose`):
```
# Spec Delta
```

## Amaç

Kullanıcıların verilerini ürününden taşınabilir formatta çıkarmasına izin verir.

## Eklenen Gereksinimler

### Gereksinim: Kullanıcı verilerini ihraç edebilir
Sistem, kullanıcıların verilerini CSV formatında ihraç etmesine izin vermelidir.

#### Başarılı ihraç
- **WHEN** kullanıcı "Export" düğmesine tıkladığında
- **THEN** sistem tüm kullanıcı verilerini içeren bir CSV dosyası indirir

## Kaldırılan Gereksinimler

### Gereksinim: Eski ihraç
**Reason**: Yeni ihraç sistemiyle değiştirildi
**Migration**: Yeni ihraç endpoint'ini /api/v2/export kullanın

```
Specs should be testable - each scenario is a potential test case.
```

## design.md

Değişikliği nasıl uygulayacağı açıklar. Sadece değişiklik için gerekli olduğunda taslak olarak alınır.

### Yapı

Aracın alabileceği çıkış formatı şablonu ([templates/design.md](https://github.com/Fission-AI/OpenSpec/blob/main/schemas/spec-driven/templates/design.md)):

```md
# Design

## Context

<!-- Current state and constraints that shape the approach. See proposal.md for motivation - don't restate it -->

## Goals / Non-Goals

**Goals:**
<!-- What this design aims to achieve -->

**Non-Goals:**
<!-- What is explicitly out of scope -->

## Decisions

<!-- Key design decisions with rationale and alternatives considered -->

## Risks / Trade-offs

<!-- Known risks and trade-offs -->
```

### Talimatlar

Aracın bu artefaktı taslaklaması sırasında gönderilen talimatlar ([schema.yaml](https://github.com/Fission-AI/OpenSpec/blob/main/schemas/spec-driven/schema.yaml)):

```md
Create the design document that explains HOW to implement the change.

When to include design.md (create only if any apply):
- Cross-cutting change (multiple services/modules) or new architectural pattern
- New external dependency or significant data model changes
- Security, performance, or migration complexity
- Ambiguity that benefits from technical decisions before coding

Sections:
- **Context**: Only the current state and constraints needed to explain the approach. Reference the proposal for motivation instead of restating it (e.g., "See proposal.md - Why").
- **Goals / Non-Goals**: What this design achieves and explicitly excludes. Don't restate the proposal's scope - add only design-level boundaries.
- **Decisions**: Key technical choices with rationale (why X over Y?). Include alternatives considered for each decision.
- **Risks / Trade-offs**: Known limitations, things that could go wrong. Format: [Risk] → Mitigation
- **Migration Plan**: Steps to deploy, rollback strategy (if applicable)
- **Open Questions**: Unknowns that can safely be answered later without
  changing the specs, the approach, or the task breakdown. Omit if none.

Open questions are for genuinely deferrable unknowns, not decisions you
skipped. If a question would change the specs, the chosen approach, or the
task breakdown, resolve it now - ask the user instead of guessing.

Focus on architecture and approach, not line-by-line implementation.
The proposal covers why and what; design covers how. Reference the
proposal for motivation and, once written, the specs for requirements -
if a section would only restate them, point to them instead.

Good design docs explain the "why" behind technical decisions.
```

## tasks.md

Uygulamayı denetlenebilir görevlere ayırır. [apply](#apply) burada ilerlemeyi takip eder.

### Yapı

Aracın alabileceği çıkış formatı şablonu ([templates/tasks.md](https://github.com/Fission-AI/OpenSpec/blob/main/schemas/spec-driven/templates/tasks.md)):

```md
# Tasks

## 1. <!-- Task Group Name -->

- [ ] 1.1 <!-- Task description -->
- [ ] 1.2 <!-- Task description -->

## 2. <!-- Task Group Name -->

- [ ] 2.1 <!-- Task description -->
- [ ] 2.2 <!-- Task description -->
```

### Talimatlar

Aracın bu artefaktı taslaklaması sırasında gönderilen talimatlar ([schema.yaml](https://github.com/Fission-AI/OpenSpec/blob/main/schemas/spec-driven/schema.yaml)):

```md
Create the task list that breaks down the implementation work.

Before writing tasks, check design.md for Open Questions. If any of them
would change what gets built, resolve them with the user first - do not
bake an unstated assumption into the task list.

**IMPORTANT: Follow the template below for tracked tasks.** The apply phase parses
checkbox format to track progress. A box holding only `x` counts as done,
upper or lower case and with any spacing, so `- [ x]` is done too. Every
other marker, including `- [~]`, `- [-]` and an empty `- []`, reads as
unfinished. A line with no checkbox is not tracked at all.

Guidelines:
- Group related tracked tasks under ## numbered headings
- Each tracked task MUST be a checkbox: `- [ ] X.Y Task description`
- Tasks should be small enough to complete in one session
- Order tasks by dependency (what must be done first?)
- Track implementation and verification work that can be completed before
  archive. If the requested workflow includes archive or work that requires
  this change to be archived, preserve those steps as plain bullets in an
  optional `## Workflow follow-up` section at the end of tasks.md. These
  bullets are reference information outside tracked task progress.
- Each task MUST state how to verify completion (a test, command,
  observable behavior, or delivered artifact). Put the verification in
  that task's checkbox description. Use a separate verification task only
  when it checks broader integration or system behavior that spans
  multiple implementation tasks.
- Each task group MUST land the tests and documentation its own work
  calls for. Do NOT collect testing or documentation into a final group -
  when a late group first exercises work from an early one, the failures
  cascade back through every group in between and force rework. A group
  whose work calls for neither, such as scaffolding or dependency setup,
  carries neither. A final group is for integration checks only, not for
  the tests and docs an earlier group owed.

Example:
```
# Tasks

## 1. Setup

- [ ] 1.1 Create new module structure and verify expected files are present
- [ ] 1.2 Add dependencies to package.json and verify package installation succeeds

## 2. Core Implementation

- [ ] 2.1 Implement data export function and verify the export test passes
- [ ] 2.2 Add CSV formatting utilities and verify unit tests cover quoting and delimiters
- [ ] 2.3 Document the export API in docs/export.md and verify the documented command runs as written
```

When applicable, append workflow follow-up as plain bullets, for example:
```
## Workflow follow-up

- Archive the change after the project's review requirements are satisfied.
- Verify the archived result.
```

Reference specs for what needs to be built, design for how to build it.
```

## Apply

Planlamadan uygulamaya devir. Apply, `tasks.md` üzerinde çalışan bir fazadır, bir artefakt değil.

- **Başlar**: `tasks.md` dosyası var olduğunda ve en az bir görev içerdiği zaman.
- **Takip eder**: `tasks.md` içindeki kutucukları. Bunları işaretleme, ilerleme kayıttır.
- **Biter**: tüm kutucuklar işaretlendiğinde. OpenSpec daha sonra değişikliği arşivlemeyi önerir.

### Ayarlar

Uygulama ayarları ([schema.yaml](https://github.com/Fission-AI/OpenSpec/blob/main/schemas/spec-driven/schema.yaml)):

```yaml
apply:
  requires: [tasks]
  tracks: tasks.md
  # instruction: shown below
```

### Talimatlar

Uygulama başladığında aracą gönderilen talimatlar ([schema.yaml](https://github.com/Fission-AI/OpenSpec/blob/main/schemas/spec-driven/schema.yaml)):

```md
Read context files, work through pending tasks, mark complete as you go.
Pause if you hit blockers or need clarification.
```

## schema.yaml

Tam [schema.yaml](https://github.com/Fission-AI/OpenSpec/blob/main/schemas/spec-driven/schema.yaml), talimat metinleri çıkarılmıştır. Her biri bölümlerde tam olarak gösterilmiştir:

```yaml
name: spec-driven
version: 1
description: Default OpenSpec workflow - proposal → specs → design → tasks
artifacts:
  - id: proposal
    generates: proposal.md
    description: Initial proposal document outlining the change
    template: proposal.md
    # instruction: shown in full under proposal.md above
    requires: []

  - id: specs
    generates: "specs/**/*.md"
    description: Detailed specifications for the change
    template: spec.md
    # instruction: shown in full under Delta specs above
    requires:
      - proposal

  - id: design
    generates: design.md
    description: Technical design document with implementation details
    template: design.md
    # instruction: shown in full under design.md above
    requires:
      - proposal

  - id: tasks
    generates: tasks.md
    description: Implementation checklist with trackable tasks
    template: tasks.md
    # instruction: shown in full under tasks.md above
    requires:
      - specs
      - design

apply:
  requires: [tasks]
  tracks: tasks.md
  # instruction: shown below
```