OPSX İş Akışı

Geri bildirimler Discord üzerinden memnuniyetle karşılanır.

Bu Nedir?

OPSX artık OpenSpec için standart iş akışıdır.

OpenSpec değişiklikleri için akıcı, yinelemeli bir iş akışıdır. Artık katı aşamalar yok — sadece istediğiniz zaman gerçekleştirebileceğiniz eylemler var.

Neden Var

Eski OpenSpec iş akışı çalışıyor ancak kilitlenmiş durumda:

• Talimatlar sabit kodlanmış — TypeScript'in içine gömülü, değiştiremezsiniz
• Ya hep ya hiç — tek bir büyük komut her şeyi oluşturur, tek tek parçaları test edemezsiniz
• Sabit yapı — herkes için aynı iş akışı, özelleştirme yok
• Kara kutu — AI çıktısı kötü olduğunda, istemlere müdahale edemezsiniz

OPSX bunu açar. Artık herkes:

1. Talimatlarla deney yapın — bir şablonu düzenleyin, AI'nın daha iyi iş çıkarıp çıkarmadığını görün
2. Ayrıntılı test edin — her bir yapıtın talimatlarını bağımsız olarak doğrulayın
3. İş akışlarını özelleştirin — kendi yapıtlarınızı ve bağımlılıklarınızı tanımlayın
4. Hızla yineleyin — şablonu değiştirin, hemen test edin, yeniden derlemeye gerek yok

Legacy workflow:                      OPSX:
┌────────────────────────┐           ┌────────────────────────┐
│  Hardcoded in package  │           │  schema.yaml           │◄── You edit this
│  (can't change)        │           │  templates/*.md        │◄── Or this
│        ↓               │           │        ↓               │
│  Wait for new release  │           │  Instant effect        │
│        ↓               │           │        ↓               │
│  Hope it's better      │           │  Test it yourself      │
└────────────────────────┘           └────────────────────────┘

Bu herkes içindir:

• Ekipler — gerçekte nasıl çalıştığınıza uyan iş akışları oluşturun
• İleri düzey kullanıcılar — kod tabanınız için daha iyi AI çıktıları almak üzere istemleri ince ayarlayın
• OpenSpec katkıda bulunanlar — sürüm yayınlamadan yeni yaklaşımlarla deney yapın

Hepimiz hâlâ en iyi neyin işe yaradığını öğreniyoruz. OPSX birlikte öğrenmemizi sağlar.

Kullanıcı Deneyimi

Doğrusal iş akışlarıyla ilgili sorun: 'Planlama aşaması'ndasınız, ardından 'uygulama aşaması'ndasınız, sonra 'tamamlandı'. Ancak gerçek işler böyle işlemez. Bir şeyi uygularsınız, tasarımınızın yanlış olduğunu fark edersiniz, özellikleri güncellemeniz gerekir, uygulamaya devam edersiniz. Doğrusal aşamalar, işin gerçekte nasıl gerçekleştiğine karşı mücadele eder.

OPSX yaklaşımı:

• Aşamalar değil, eylemler — oluştur, uygula, güncelle, arşivle — istediğiniz zaman herhangi birini yapın
• Bağımlılıklar kolaylaştırıcıdır — neyin mümkün olduğunu gösterir, bir sonraki adımda neyin gerekli olduğunu değil

  proposal ──→ specs ──→ design ──→ tasks ──→ implement

Kurulum

# openspec'in kurulu olduğundan emin olun — yetenekler otomatik olarak oluşturulur
openspec init

Bu, AI kodlama asistanlarının otomatik olarak algıladığı .claude/skills/ (veya eşdeğeri) içinde yetenekler oluşturur.

Varsayılan olarak OpenSpec, core iş akışı profilini (propose, explore, apply, update, sync, archive) kullanır. Genişletilmiş iş akışı komutlarını (new, continue, ff, verify, bulk-archive, onboard) istiyorsanız, bunları openspec config profile ile yapılandırın ve openspec update ile uygulayın.

Kurulum sırasında bir proje yapılandırması (openspec/config.yaml) oluşturmanız istenecek. Bu isteğe bağlıdır ancak önerilir.

Proje Yapılandırması

Proje yapılandırması, varsayılanları ayarlamanıza ve projeye özgü bağlamı tüm yapıtlara enjekte etmenize olanak tanır.

Yapılandırma Oluşturma

Yapılandırma, openspec init sırasında oluşturulur veya manuel olarak oluşturulur:

# openspec/config.yaml
schema: spec-driven

context: |
  Tech stack: TypeScript, React, Node.js
  API conventions: RESTful, JSON responses
  Testing: Vitest for unit tests, Playwright for e2e
  Style: ESLint with Prettier, strict TypeScript

rules:
  proposal:
    - Include rollback plan
    - Identify affected teams
  specs:
    - Use Given/When/Then format for scenarios
  design:
    - Include sequence diagrams for complex flows

Yapılandırma Alanları

Alan	Tür	Açıklama
schema	string	Yeni değişiklikler için varsayılan şema (örn. spec-driven)
context	string	Tüm yapıt talimatlarına enjekte edilen proje bağlamı
rules	object	Yapıt kimliğine göre anahtarlanmış, yapıt başına kurallar

Nasıl Çalışır

Şema önceliği (en yüksekten en düşüğe):

1. CLI bayrağı (--schema <name>)
2. Değişiklik üstverisi (değişiklik dizinindeki .openspec.yaml)
3. Proje yapılandırması (openspec/config.yaml)
4. Varsayılan (spec-driven)

Bağlam enjeksiyonu:

• Bağlam, her yapıtın talimatlarına başa eklenir
• <context>...</context> etiketleri ile sarılır
• AI'nın projenizin kurallarını anlamasına yardımcı olur

Kural enjeksiyonu:

• Kurallar yalnızca eşleşen yapıtlar için enjekte edilir
• <rules>...</rules> etiketleri ile sarılır
• Bağlamdan sonra, şablondan önce görünür

Şemaya Göre Yapıt Kimlikleri

spec-driven (varsayılan):

• proposal — Değişiklik teklifi
• specs — Belirtimler
• design — Teknik tasarım
• tasks — Uygulama görevleri

Yapılandırma Doğrulaması

• rules içindeki bilinmeyen yapıt kimlikleri uyarı üretir
• Şema adları, kullanılabilir şemalara göre doğrulanır
• Bağlamın 50 KB boyut sınırı vardır
• Geçersiz YAML, satır numaraları ile bildirilir

Sorun Giderme

"Bilinmeyen yapıt kimliği (rules): X"

• Yapıt kimliklerinin şemanızla eşleştiğini kontrol edin (yukarıdaki listeye bakın)
• Her şemanın yapıt kimliklerini görmek için openspec schemas --json çalıştırın

Yapılandırma uygulanmıyorsa:

• Dosyanın openspec/config.yaml konumunda olduğundan emin olun (.yml değil)
• Bir doğrulayıcı ile YAML sözdizimini kontrol edin
• Yapılandırma değişiklikleri hemen etkili olur (yeniden başlatma gerekmez)

Bağlam çok büyükse:

• Bağlam 50 KB ile sınırlıdır
• Özetleyin veya bunun yerine harici belgelere bağlantı verin

Komutlar

Komut	Ne yapar
/opsx:propose	Tek adımda bir değişiklik oluştur ve planlama yapıtlarını üret (varsayılan hızlı yol)
/opsx:explore	Fikirler üzerinde düşün, sorunları araştır, gereksinimleri netleştir
/opsx:new	Yeni bir değişiklik iskeleti başlat (genişletilmiş iş akışı)
/opsx:continue	Bir sonraki yapıtı oluştur (genişletilmiş iş akışı)
/opsx:ff	Planlama yapıtlarını hızlı ilerlet (genişletilmiş iş akışı)
/opsx:apply	Görevleri uygula, gerektiğinde yapıtları güncelle
/opsx:update	Bir değişikliğin planlama yapıtlarını gözden geçir ve tutarlı kalmalarını sağla
/opsx:verify	Uygulamayı yapıtlarla doğrula (genişletilmiş iş akışı)
/opsx:sync	Delta belirtimleri ana belirtimlerle birleştir (isteğe bağlı)
/opsx:archive	Tamamlandığında arşivle
/opsx:bulk-archive	Tamamlanmış birden çok değişikliği arşivle (genişletilmiş iş akışı)
/opsx:onboard	Uçtan uca bir değişikliğin rehberli turu (genişletilmiş iş akışı)

Kullanım

Bir Fikri Keşfedin

/opsx:explore

Fikirler üzerinde düşünün, sorunları araştırın, seçenekleri karşılaştırın. Yapı gerekmez – sadece bir düşünme ortağı. İçgörüler netleştiğinde, /opsx:propose (varsayılan) veya /opsx:new//opsx:ff (genişletilmiş) ile geçiş yapın.

Yeni Bir Değişiklik Başlatın

/opsx:propose

Değişikliği oluşturur ve uygulamadan önce gerekli planlama yapıtlarını üretir.

Eğer genişletilmiş iş akışlarını etkinleştirdiyseniz, bunun yerine şunları kullanabilirsiniz:

/opsx:new        # yalnızca iskelet
/opsx:continue   # her seferinde bir yapıt oluştur
/opsx:ff         # tüm planlama yapıtlarını tek seferde oluştur

Yapıtları Oluşturun

/opsx:continue

Bağımlılıklara göre hangilerinin oluşturulmaya hazır olduğunu gösterir, ardından bir yapıt oluşturur. Değişikliğinizi adım adım oluşturmak için tekrar tekrar kullanın.

/opsx:ff add-dark-mode

Tüm planlama yapıtlarını tek seferde oluşturur. Ne inşa ettiğinize dair net bir resminiz olduğunda kullanın.

Uygulama (akışkan kısım)

/opsx:apply

Görevler üzerinde çalışır, ilerledikçe onları işaretler. Birden fazla değişiklikle uğraşıyorsanız /opsx:apply <name> çalıştırabilirsiniz; aksi takdirde konuşmadan çıkarım yapar ve anlayamazsa seçmenizi ister.

Bir Değişikliği Güncelleme

/opsx:update add-dark-mode - temayı artık bir çerezde saklıyoruz

Değişikliğin mevcut planlama yapıtlarını gözden geçirir ve tutarlı kalmalarını sağlar – her yönde (bir tasarım düzenlemesi teklife geri yansıyabilir). Yalnızca planlama yapıtları: kodu asla düzenlemez ve hiçbir eksik yapıt oluşturmaz (bu /opsx:continue'nun işidir). Her düzenleme önce sizinle onaylanır. Değişiklik zaten uygulandıysa, kodun gözden geçirilmiş plana yetişmesi için /opsx:apply önerir. Düzeltmeniz değişikliğin amacını değiştiriyorsa, bunun yerine yeni bir değişiklik başlatın – bkz. Ne Zaman Güncellenir, Ne Zaman Yeni Başlanır.

Delta Belirtimleri Senkronize Et

/opsx:sync

Mevcut değişikliğin delta belirtimlerini, arşivlemeden ana openspec/specs/ dizininize birleştirir — değişiklik aktif kalır. Tüm deltayı uygular: ## REMOVED altındaki bir gereksinim ana belirtimden silinir ve yeniden adlandırılan biri yerinde yeniden başlıklandırılır, deltanın bahsetmediği içerik dokunulmaz. Senkronizasyon isteğe bağlıdır — arşivleme, önceden senkronize etmediyseniz sizi uyarır. Arşivlemeden önce ana belirtimlerin güncellenmesini istediğinizde, paralel bir değişiklik bu yeni eklenen belirtimlere dayanması gerektiğinde veya arşivlemeden önce birleştirilmiş ana belirtimi gözden geçirmek istediğinizde kullanın.

Tamamlama

/opsx:archive   # Tamamlandığında arşive taşı (gerekirse belirtimleri senkronize etmeni ister)

Ne Zaman Güncellenir, Ne Zaman Yeni Başlanır

Uygulamadan önce teklifinizi veya belirtimlerinizi her zaman düzenleyebilirsiniz. Peki, iyileştirme ne zaman 'bu farklı bir iş' hâline gelir?

Bir Teklifin Kapsadıkları

Bir teklif üç şeyi tanımlar:

1. Amaç — Hangi sorunu çözüyorsunuz?
2. Kapsam — Sınırlar neler? Neler dahil, neler hariç?
3. Yaklaşım — Nasıl çözeceksiniz?

Soru şu: hangisi değişti ve ne kadar değişti?

Aşağıdaki Durumlarda Mevcut Değişikliği Güncelleyin:

Amaç aynı, uygulama iyileştirilmiş

• Daha önce düşünmediğiniz uç durumları keşfettiniz
• Yaklaşımın ince ayara ihtiyacı var ancak hedef aynı
• Uygulama, tasarımın biraz hatalı olduğunu gösterdi

Kapsam daralır

• Tam kapsamın çok büyük olduğunu fark ettiniz, önce MVP'yi yayınlamak istiyorsunuz
• "Karanlık mod ekle" → "Karanlık mod geçişi ekle (sistem tercihi v2'de)"

Öğrenmeye dayalı düzeltmeler

• Kod tabanı düşündüğünüz gibi yapılandırılmamış
• Bir bağımlılık beklendiği gibi çalışmıyor
• "CSS değişkenlerini kullan" → "Bunun yerine Tailwind'in dark: ön ekini kullan"

Aşağıdaki Durumlarda Yeni Bir Değişiklik Başlatın:

Amaç temelden değişti

• Sorunun kendisi artık farklı
• "Karanlık mod ekle" → "Özel renkler, yazı tipleri, boşluklarla kapsamlı tema sistemi ekle"

Kapsam patladı

• Değişiklik o kadar büyüdü ki esasen farklı bir iş
• Güncellemelerden sonra orijinal teklif tanınmaz hâle gelir
• "Giriş hatasını düzelt" → "Kimlik doğrulama sistemini yeniden yaz"

Orijinal tamamlanabilir

• Orijinal değişiklik 'tamamlandı' olarak işaretlenebilir
• Yeni iş, bir iyileştirme değil, başlı başına durur
• "Karanlık mod MVP ekle"yi tamamla → Arşivle → Yeni değişiklik "Karanlık modu geliştir"

Sezgisel Kurallar

                        ┌─────────────────────────────────────┐
                        │     Bu aynı iş mi?                  │
                        └──────────────┬──────────────────────┘
                                       │
                    ┌──────────────────┼──────────────────┐
                    │                  │                  │
                    ▼                  ▼                  ▼
             Amaç aynı mı?      >%50 örtüşme var mı?  Orijinal bu
             Sorun aynı mı?      Kapsam aynı mı?      değişiklikler
                    │                  │              olmadan "biter" mi?
                    │                  │                  │
          ┌────────┴────────┐  ┌──────┴──────┐   ┌───────┴───────┐
          │                 │  │             │   │               │
         EVET             HAYIR EVET        HAYIR HAYIR         EVET
          │                 │  │             │   │               │
          ▼                 ▼  ▼             ▼   ▼               ▼
       GÜNCELLE           YENİ GÜNCELLE    YENİ GÜNCELLE       YENİ

Test	Güncelle	Yeni Değişiklik
Kimlik	"Aynı şey, iyileştirilmiş"	"Farklı bir iş"
Kapsam örtüşmesi	>%50 örtüşüyor	<%50 örtüşüyor
Tamamlanma	Değişiklikler olmadan "tamamlandı" sayılmaz	Orijinal bitirilebilir, yeni iş kendi başına yeterli
Hikâye	Güncelleme zinciri tutarlı bir hikâye anlatır	Yama yapmak netleştirmekten çok kafa karıştırır

İlke

Güncelleme bağlamı korur. Yeni değişiklik netlik sağlar.

Düşünce geçmişinizin değerli olduğu durumlarda güncellemeyi seçin. Yama yapmaktansa sıfırdan başlamanın daha net olacağı durumlarda yenisini seçin.

Bunu git dalları gibi düşünün:

• Aynı özellik üzerinde çalışırken commit etmeye devam edin
• Gerçekten yeni bir iş olduğunda yeni bir dal başlatın
• Bazen kısmi bir özelliği birleştirin ve 2. aşama için taze başlayın

Ne Farklı?

	Eski Sürüm (/openspec:proposal)	OPSX (/opsx:*)
Yapı	Tek büyük öneri belgesi	Bağımlılıkları olan ayrık artefaktlar
İş Akışı	Doğrusal aşamalar: planla → uygula → arşivle	Akışkan eylemler — istediğiniz zaman her şeyi yapın
İterasyon	Geri dönmek zor	Öğendikçe artefaktları güncelleyin
Özelleştirme	Sabit yapı	Şema odaklı (kendi artefaktlarınızı tanımlayın)

Temel içgörü: iş doğrusal değildir. OPSX bunu iddia etmeyi bırakır.

Mimari Derinlemesine İnceleme

Bu bölüm, OPSX'in perde arkasında nasıl çalıştığını ve eski iş akışıyla nasıl karşılaştırıldığını açıklar. Bu bölümdeki örnekler genişletilmiş komut setini (new, continue, vb.) kullanır; varsayılan core kullanıcıları aynı akışı propose → apply → sync → archive olarak eşleyebilir.

Felsefe: Aşamalar vs Eylemler

┌─────────────────────────────────────────────────────────────────────────────┐
│                         LEGACY WORKFLOW                                      │
│                    (Phase-Locked, All-or-Nothing)                           │
├─────────────────────────────────────────────────────────────────────────────┤
│                                                                             │
│   ┌──────────────┐      ┌──────────────┐      ┌──────────────┐             │
│   │   PLANNING   │ ───► │ IMPLEMENTING │ ───► │   ARCHIVING  │             │
│   │    PHASE     │      │    PHASE     │      │    PHASE     │             │
│   └──────────────┘      └──────────────┘      └──────────────┘             │
│         │                     │                     │                       │
│         ▼                     ▼                     ▼                       │
│   /openspec:proposal   /openspec:apply      /openspec:archive              │
│                                                                             │
│   • Creates ALL artifacts at once                                          │
│   • Can't go back to update specs during implementation                    │
│   • Phase gates enforce linear progression                                  │
│                                                                             │
└─────────────────────────────────────────────────────────────────────────────┘


┌─────────────────────────────────────────────────────────────────────────────┐
│                            OPSX WORKFLOW                                     │
│                      (Fluid Actions, Iterative)                             │
├─────────────────────────────────────────────────────────────────────────────┤
│                                                                             │
│              ┌────────────────────────────────────────────┐                 │
│              │           ACTIONS (not phases)             │                 │
│              │                                            │                 │
│              │   new ◄──► continue ◄──► apply ◄──► archive │                 │
│              │    │          │           │           │    │                 │
│              │    └──────────┴───────────┴───────────┘    │                 │
│              │              any order                     │                 │
│              └────────────────────────────────────────────┘                 │
│                                                                             │
│   • Create artifacts one at a time OR fast-forward                         │
│   • Update specs/design/tasks during implementation                        │
│   • Dependencies enable progress, phases don't exist                       │
│                                                                             │
└─────────────────────────────────────────────────────────────────────────────┘

Bileşen Mimarisi

Eski iş akışı TypeScript'te sabit kodlanmış şablonlar kullanır:

┌─────────────────────────────────────────────────────────────────────────────┐
│                      LEGACY WORKFLOW COMPONENTS                              │
├─────────────────────────────────────────────────────────────────────────────┤
│                                                                             │
│   Hardcoded Templates (TypeScript strings)                                  │
│                    │                                                        │
│                    ▼                                                        │
│   Tool-specific configurators/adapters                                      │
│                    │                                                        │
│                    ▼                                                        │
│   Generated Command Files (.claude/commands/openspec/*.md)                  │
│                                                                             │
│   • Fixed structure, no artifact awareness                                  │
│   • Change requires code modification + rebuild                             │
│                                                                             │
└─────────────────────────────────────────────────────────────────────────────┘

OPSX harici şemalar ve bağımlılık grafiği motoru kullanır:

┌─────────────────────────────────────────────────────────────────────────────┐
│                         OPSX COMPONENTS                                      │
├─────────────────────────────────────────────────────────────────────────────┤
│                                                                             │
│   Schema Definitions (YAML)                                                 │
│   ┌─────────────────────────────────────────────────────────────────────┐   │
│   │  name: spec-driven                                                  │   │
│   │  artifacts:                                                         │   │
│   │    - id: proposal                                                   │   │
│   │      generates: proposal.md                                         │   │
│   │      requires: []              ◄── Dependencies                     │   │
│   │    - id: specs                                                      │   │
│   │      generates: specs/**/*.md  ◄── Glob patterns                    │   │
│   │      requires: [proposal]      ◄── Enables after proposal           │   │
│   └─────────────────────────────────────────────────────────────────────┘   │
│                    │                                                        │
│                    ▼                                                        │
│   Artifact Graph Engine                                                     │
│   ┌─────────────────────────────────────────────────────────────────────┐   │
│   │  • Topological sort (dependency ordering)                           │   │
│   │  • State detection (filesystem existence)                           │   │
│   │  • Rich instruction generation (templates + context)                │   │
│   └─────────────────────────────────────────────────────────────────────┘   │
│                    │                                                        │
│                    ▼                                                        │
│   Skill Files (.claude/skills/openspec-*/SKILL.md)                          │
│                                                                             │
│   • Cross-editor compatible (Claude Code, Cursor, Devin)                    │
│   • Skills query CLI for structured data                                    │
│   • Fully customizable via schema files                                     │
│                                                                             │
└─────────────────────────────────────────────────────────────────────────────┘

Bağımlılık Grafiği Modeli

Artifaktlar yönlendirilmiş asiklik bir grafik (DAG) oluşturur. Bağımlılıklar kolaylaştırıcılardır, kapılar değil:

                              proposal
                             (root node)
                                  │
                    ┌─────────────┴─────────────┐
                    │                           │
                    ▼                           ▼
                 specs                       design
              (requires:                  (requires:
               proposal)                   proposal)
                    │                           │
                    └─────────────┬─────────────┘
                                  │
                                  ▼
                               tasks
                           (requires:
                           specs, design)
                                  │
                                  ▼
                          ┌──────────────┐
                          │ APPLY PHASE  │
                          │ (requires:   │
                          │  tasks)      │
                          └──────────────┘

Durum geçişleri:

   BLOCKED ────────────────► READY ────────────────► DONE
      │                        │                       │
   Missing                  All deps               File exists
   dependencies             are DONE               on filesystem

Bilgi Akışı

Eski iş akışı — agent statik talimatlar alır:

  User: "/openspec:proposal"
           │
           ▼
  ┌─────────────────────────────────────────┐
  │  Static instructions:                   │
  │  • Create proposal.md                   │
  │  • Create tasks.md                      │
  │  • Create design.md                     │
  │  • Create delta spec files              │
  │                                         │
  │  No awareness of what exists or         │
  │  dependencies between artifacts         │
  └─────────────────────────────────────────┘
           │
           ▼
  Agent creates ALL artifacts in one go

OPSX — agent zengin bağlam için sorgular yapar:

  User: "/opsx:continue"
           │
           ▼
  ┌──────────────────────────────────────────────────────────────────────────┐
  │  Step 1: Query current state                                             │
  │  ┌────────────────────────────────────────────────────────────────────┐  │
  │  │  $ openspec status --change "add-auth" --json                      │  │
  │  │                                                                    │  │
  │  │  {                                                                 │  │
  │  │    "artifacts": [                                                  │  │
  │  │      {"id": "proposal", "status": "done"},                         │  │
  │  │      {"id": "specs", "status": "ready"},      ◄── First ready      │  │
  │  │      {"id": "design", "status": "ready"},                          │  │
  │  │      {"id": "tasks", "status": "blocked",                          │  │
  │  │       "missingDeps": ["specs", "design"]}                          │  │
  │  │    ]                                                               │  │
  │  │  }                                                                 │  │
  │  └────────────────────────────────────────────────────────────────────┘  │
  │                                                                          │
  │  Step 2: Get rich instructions for ready artifact                        │
  │  ┌────────────────────────────────────────────────────────────────────┐  │
  │  │  $ openspec instructions specs --change "add-auth" --json          │  │
  │  │                                                                    │  │
  │  │  {                                                                 │  │
  │  │    "template": "# Specification\n\n## ADDED Requirements...",      │  │
  │  │    "dependencies": [{"id": "proposal", "path": "...", "done": true}│  │
  │  │    "unlocks": ["tasks"]                                            │  │
  │  │  }                                                                 │  │
  │  └────────────────────────────────────────────────────────────────────┘  │
  │                                                                          │
  │  Step 3: Read dependencies → Create ONE artifact → Show what's unlocked  │
  └──────────────────────────────────────────────────────────────────────────┘

Yineleme Modeli

Eski iş akışı — yinelemek zor:

  ┌─────────┐     ┌─────────┐     ┌─────────┐
  │/proposal│ ──► │ /apply  │ ──► │/archive │
  └─────────┘     └─────────┘     └─────────┘
       │               │
       │               ├── "Wait, the design is wrong"
       │               │
       │               ├── Options:
       │               │   • Edit files manually (breaks context)
       │               │   • Abandon and start over
       │               │   • Push through and fix later
       │               │
       │               └── No official "go back" mechanism
       │
       └── Creates ALL artifacts at once

OPSX — doğal yineleme:

  /opsx:new ───► /opsx:continue ───► /opsx:apply ───► /opsx:archive
      │                │                  │
      │                │                  ├── "The design is wrong"
      │                │                  │
      │                │                  ▼
      │                │            Just edit design.md
      │                │            and continue!
      │                │                  │
      │                │                  ▼
      │                │         /opsx:apply picks up
      │                │         where you left off
      │                │
      │                └── Creates ONE artifact, shows what's unlocked
      │
      └── Scaffolds change, waits for direction

Özel Şemalar

Şema yönetim komutlarını kullanarak özel iş akışları oluşturun:

# Sıfırdan yeni bir şema oluştur (etkileşimli)
openspec schema init my-workflow

# Ya da başlangıç noktası olarak mevcut bir şemayı çatalla
openspec schema fork spec-driven my-workflow

# Şema yapınızı doğrulayın
openspec schema validate my-workflow

# Bir şemanın nereden çözüldüğünü görün (hata ayıklama için yararlı)
openspec schema which my-workflow

Şemalar openspec/schemas/ (proje-yerel, sürüm kontrolü altında) veya ~/.local/share/openspec/schemas/ (kullanıcı global) konumlarında saklanır.

Şema yapısı:

openspec/schemas/research-first/
├── schema.yaml
└── templates/
    ├── research.md
    ├── proposal.md
    └── tasks.md

Örnek schema.yaml:

name: research-first
artifacts:
  - id: research        # Added before proposal
    generates: research.md
    requires: []

  - id: proposal
    generates: proposal.md
    requires: [research]  # Now depends on research

  - id: tasks
    generates: tasks.md
    requires: [proposal]

Bağımlılık Grafiği:

   research ──► proposal ──► tasks

Özet

Özellik	Eski	OPSX
Şablonlar	Sabit kodlanmış TypeScript	Harici YAML + Markdown
Bağımlılıklar	Yok (hepsi bir anda)	Topolojik sıralamalı DAG
Durum	Faz temelli zihinsel model	Dosya sistemi varlığı
Özelleştirme	Kaynağı düzenle, yeniden derle	schema.yaml oluştur
Yineleme	Faz kilitli	Akışkan, her şeyi düzenle
Editör Desteği	Araca özel yapılandırıcı/adaptörler	Tek beceri dizini

Şemalar

Şemalar, hangi artefaktların var olduğunu ve bağımlılıklarını tanımlar. Şu anda mevcut:

• spec-driven (varsayılan): proposal → specs → design → tasks

# List available schemas
openspec schemas

# See all schemas with their resolution sources
openspec schema which --all

# Create a new schema interactively
openspec schema init my-workflow

# Fork an existing schema for customization
openspec schema fork spec-driven my-workflow

# Validate schema structure before use
openspec schema validate my-workflow

İpuçları

• Bir değişikliğe karar vermeden önce bir fikri değerlendirmek için /opsx:explore komutunu kullanın
• Ne istediğinizi bildiğinizde /opsx:ff, keşif yaparken /opsx:continue kullanın
• /opsx:apply sırasında bir şeyler yanlışsa — artefaktı düzeltin, sonra devam edin
• Görevler, tasks.md içindeki onay kutuları aracılığıyla ilerlemeyi takip eder
• Durumu istediğiniz zaman kontrol edin: openspec status --change "name"

Geri Bildirim

Bu kaba. Bu kasıtlı — neyin işe yaradığını öğreniyoruz.

Bir hata mı buldunuz? Fikirleriniz mi var? Discord üzerinden bize katılın veya GitHub üzerinde bir konu açın.