Alur Kerja OPSX
Masukan sangat kami harapkan di Discord.
Apa Itu?
OPSX kini menjadi alur kerja standar untuk OpenSpec.
Ini adalah alur kerja yang cair dan iteratif untuk perubahan pada OpenSpec. Tidak ada lagi fase-fase yang kaku — hanya tindakan yang dapat Anda lakukan kapan saja.
Mengapa Ini Ada
Alur kerja OpenSpec lama berfungsi, namun terkunci:
- Instruksi terkode keras (hardcoded) — tersembunyi di dalam TypeScript, Anda tidak dapat mengubahnya
- Semua atau tidak sama sekali — satu perintah besar membuat semuanya, tidak bisa menguji bagian individu
- Struktur tetap — alur kerja yang sama untuk semua orang, tanpa kustomisasi
- Kotak hitam — ketika output AI buruk, Anda tidak dapat menyesuaikan prompt
OPSX membukanya. Sekarang siapa pun dapat:
- Bereksperimen dengan instruksi — edit templat, lihat apakah AI bekerja lebih baik
- Menguji secara granular — validasi instruksi setiap artefak secara independen
- Menyesuaikan alur kerja — definisikan artefak dan dependensi Anda sendiri
- Berekaborasi cepat — ubah templat, uji segera, tanpa perlu rebuild
Alur kerja lama: OPSX:
┌────────────────────────┐ ┌────────────────────────┐
│ Terkoding keras dalam │ │ schema.yaml │◄── Anda mengedit ini
│ paket │ │ templates/*.md │◄── Atau ini
│ (tidak bisa diubah) │ │ ↓ │
│ ↓ │ │ Efek instan │
│ Tunggu rilis baru │ │ ↓ │
│ ↓ │ │ Uji sendiri │
│ Berharap lebih baik │ │ │
└────────────────────────┘ └────────────────────────┘Ini untuk semua orang:
- Tim — buat alur kerja yang sesuai dengan cara kerja Anda sebenarnya
- Pengguna tingkat lanjut — sesuaikan prompt untuk mendapatkan output AI yang lebih baik untuk basis kode Anda
- Kontributor OpenSpec — bereksperimen dengan pendekatan baru tanpa perlu merilis versi baru
Kita semua masih belajar apa yang paling efektif. OPSX memungkinkan kita belajar bersama.
Pengalaman Pengguna
Masalah dengan alur kerja linear: Anda berada di "fase perencanaan", lalu "fase implementasi", lalu "selesai". Namun pekerjaan nyata tidak berjalan seperti itu. Anda mengimplementasikan sesuatu, menyadari desain Anda salah, perlu memperbarui spesifikasi, lalu melanjutkan implementasi. Fase-fase linear bertentangan dengan bagaimana pekerjaan sebenarnya terjadi.
Pendekatan OPSX:
- Aksi, bukan fase — buat, implementasikan, perbarui, arsipkan — lakukan kapan saja
- Dependensi adalah pemungkin — mereka menunjukkan apa yang mungkin dilakukan, bukan apa yang harus dilakukan selanjutnya
proposal ──→ specs ──→ design ──→ tasks ──→ implementPersiapan
# Pastikan Anda telah menginstal openspec — skill dihasilkan secara otomatis
openspec initIni akan membuat skill di .claude/skills/ (atau setara) yang akan dideteksi secara otomatis oleh asisten pengkodean AI.
Secara default, OpenSpec menggunakan profil alur kerja core (propose, explore, apply, update, sync, archive). Jika Anda ingin perintah alur kerja yang diperluas (new, continue, ff, verify, bulk-archive, onboard), konfigurasikan dengan openspec config profile dan terapkan dengan openspec update.
Selama persiapan, Anda akan diminta untuk membuat konfigurasi proyek (openspec/config.yaml). Ini opsional tetapi disarankan.
Konfigurasi Proyek
Konfigurasi proyek memungkinkan Anda mengatur nilai default dan menyuntikkan konteks spesifik proyek ke dalam semua artefak.
Membuat Konfigurasi
Konfigurasi dibuat selama openspec init, atau secara manual:
# 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 flowsBidang Konfigurasi
| Field | Type | Description |
|---|---|---|
schema | string | Schema default untuk perubahan baru (misalnya, spec-driven) |
context | string | Konteks proyek yang disuntikkan ke dalam instruksi semua artefak |
rules | object | Aturan per-artefak, dikunci berdasarkan ID artefak |
Cara Kerjanya
Prioritas Schema (tertinggi ke terendah):
- Flag CLI (
--schema <name>) - Metadata perubahan (
.openspec.yamldi direktori perubahan) - Konfigurasi proyek (
openspec/config.yaml) - Default (
spec-driven)
Penyuntikan Konteks:
- Konteks ditambahkan di awal instruksi setiap artefak
- Dibungkus dalam tag
<context>...</context> - Membantu AI memahami konvensi proyek Anda
Penyuntikan Aturan:
- Aturan hanya disuntikkan untuk artefak yang cocok
- Dibungkus dalam tag
<rules>...</rules> - Muncul setelah konteks, sebelum templat
ID Artefak Berdasarkan Schema
spec-driven (default):
proposal— Usulan Perubahanspecs— Spesifikasidesign— Desain Teknistasks— Tugas Implementasi
Validasi Konfigurasi
- ID artefak yang tidak dikenal dalam
rulesakan menghasilkan peringatan - Nama schema divalidasi terhadap schema yang tersedia
- Konteks memiliki batas ukuran 50KB
- YAML yang tidak valid akan dilaporkan beserta nomor barisnya
Pemecahan Masalah
"Unknown artifact ID in rules: X"
- Periksa apakah ID artefak sesuai dengan schema Anda (lihat daftar di atas)
- Jalankan
openspec schemas --jsonuntuk melihat ID artefak untuk setiap schema
Konfigurasi tidak diterapkan:
- Pastikan file berada di
openspec/config.yaml(bukan.yml) - Periksa sintaks YAML dengan validator
- Perubahan konfigurasi berlaku segera (tidak perlu restart)
Konteks terlalu besar:
- Konteks dibatasi hingga 50KB
- Ringkas atau tautkan ke dokumen eksternal sebagai gantinya
Perintah
| Command | What it does |
|---|---|
/opsx:propose | Buat perubahan dan hasilkan artefak perencanaan dalam satu langkah (jalur cepat default) |
/opsx:explore | Pikirkan ide, selidiki masalah, perjelas persyaratan |
/opsx:new | Mulai kerangka perubahan baru (alur kerja diperluas) |
/opsx:continue | Buat artefak berikutnya (alur kerja diperluas) |
/opsx:ff | Majukan artefak perencanaan dengan cepat (alur kerja diperluas) |
/opsx:apply | Implementasikan tugas, perbarui artefak jika diperlukan |
/opsx:update | Tinjau ulang artefak perencanaan perubahan dan jaga agar tetap koheren |
/opsx:verify | Validasi implementasi terhadap artefak (alur kerja diperluas) |
/opsx:sync | Gabungkan delta specs ke dalam specs utama (opsional) |
/opsx:archive | Arsipkan saat selesai |
/opsx:bulk-archive | Arsipkan beberapa perubahan yang selesai (alur kerja diperluas) |
/opsx:onboard | Panduan walkthrough perubahan end-to-end (alur kerja diperluas) |
Penggunaan
Jelajahi sebuah ide
/opsx:explorePikirkan ide, selidiki masalah, bandingkan opsi. Tidak ada struktur yang diperlukan - hanya mitra berpikir. Ketika wawasan menjadi jelas, beralihlah ke /opsx:propose (default) atau /opsx:new//opsx:ff (diperluas).
Mulai perubahan baru
/opsx:proposeMembuat perubahan dan menghasilkan artefak perencanaan yang diperlukan sebelum implementasi.
Jika Anda telah mengaktifkan alur kerja yang diperluas, Anda juga dapat menggunakan:
/opsx:new # hanya kerangka
/opsx:continue # buat satu artefak pada satu waktu
/opsx:ff # buat semua artefak perencanaan sekaligusBuat artefak
/opsx:continueMenampilkan apa yang siap dibuat berdasarkan dependensi, lalu membuat satu artefak. Gunakan berulang kali untuk membangun perubahan Anda secara inkremental.
/opsx:ff add-dark-modeMembuat semua artefak perencanaan sekaligus. Gunakan ketika Anda memiliki gambaran jelas tentang apa yang sedang Anda bangun.
Implementasi (bagian yang cair/fleksibel)
/opsx:applyBekerja melalui tugas-tugas, mencentangnya saat Anda melakukannya. Jika Anda menangani beberapa perubahan sekaligus, Anda dapat menjalankan /opsx:apply <name>; jika tidak, sistem seharusnya dapat menyimpulkan dari percakapan dan meminta Anda memilih jika tidak dapat menentukan.
Memperbarui perubahan
/opsx:update add-dark-mode - we're storing the theme in a cookie nowMerevisi artefak perencanaan yang sudah ada dari perubahan tersebut dan menjaga agar tetap koheren - ke arah mana pun (edit desain dapat berdampak balik ke proposal). Hanya artefak perencanaan: ini tidak pernah mengedit kode, dan tidak pernah membuat artefak yang hilang (itu adalah /opsx:continue). Setiap edit dikonfirmasi dengan Anda terlebih dahulu. Jika perubahan sudah diimplementasikan, sistem akan merekomendasikan /opsx:apply agar kode mengikuti rencana yang direvisi. Jika revisi Anda mengubah maksud perubahan, mulailah dari awal - lihat Kapan Memperbarui vs. Memulai Ulang.
Sinkronisasi delta specs
/opsx:syncMenggabungkan delta specs dari perubahan saat ini ke dalam openspec/specs/ utama Anda tanpa mengarsipkan — perubahan tetap aktif. Ini menerapkan seluruh delta: persyaratan di bawah ## REMOVED dihapus dari specs utama dan yang berganti nama diganti judulnya di tempat, sementara konten yang tidak disebutkan dalam delta dibiarkan tidak tersentuh. Sinkronisasi bersifat opsional — arsip akan meminta Anda untuk sinkronisasi terlebih dahulu jika belum dilakukan. Gunakan ini ketika Anda ingin specs utama diperbarui sebelum pengarsipan, ketika perubahan paralel perlu dibangun di atas specs yang baru saja ditambahkan oleh perubahan ini, atau ketika Anda ingin meninjau specs utama yang telah digabungkan sebelum pengarsipan.
Selesaikan
/opsx:archive # Pindahkan ke arsip saat selesai (meminta sinkronisasi specs jika diperlukan)Kapan Memperbarui vs. Memulai Ulang
Anda selalu dapat mengedit proposal atau specs Anda sebelum implementasi. Namun, kapan penyempurnaan berubah menjadi "ini adalah pekerjaan yang berbeda"?
Apa yang Ditangkap oleh Proposal
Proposal mendefinisikan tiga hal:
- Maksud — Masalah apa yang sedang Anda selesaikan?
- Lingkup — Apa yang masuk/keluar dari batasan?
- Pendekatan — Bagaimana Anda akan menyelesaikannya?
Pertanyaannya adalah: mana yang berubah, dan seberapa banyak?
Perbarui Perubahan yang Ada Ketika:
Maksud sama, eksekusi yang disempurnakan
- Anda menemukan kasus tepi yang tidak Anda pertimbangkan sebelumnya
- Pendekatan perlu disesuaikan tetapi tujuannya tidak berubah
- Implementasi mengungkapkan bahwa desainnya sedikit meleset
Lingkup menyempit
- Anda menyadari lingkup penuh terlalu besar, ingin meluncurkan MVP terlebih dahulu
- "Tambahkan mode gelap" → "Tambahkan tombol toggle mode gelap (preferensi sistem di v2)"
Koreksi berbasis pembelajaran
- Basis kode tidak terstruktur seperti yang Anda kira
- Sebuah dependensi tidak berfungsi seperti yang diharapkan
- "Gunakan variabel CSS" → "Gunakan prefix dark: Tailwind sebagai gantinya"
Mulai Perubahan Baru Ketika:
Maksud berubah secara fundamental
- Masalahnya sendiri sekarang berbeda
- "Tambahkan mode gelap" → "Tambahkan sistem tema komprehensif dengan warna, font, dan spasi kustom"
Lingkup meledak
- Perubahan tumbuh begitu besar sehingga pada dasarnya merupakan pekerjaan yang berbeda
- Proposal asli tidak akan dikenali lagi setelah pembaruan
- "Perbaiki bug login" → "Tulis ulang sistem autentikasi"
Yang asli dapat diselesaikan
- Perubahan asli dapat ditandai "selesai"
- Pekerjaan baru berdiri sendiri, bukan penyempurnaan
- Selesaikan "Tambahkan MVP mode gelap" → Arsipkan → Perubahan baru "Tingkatkan mode gelap"
Heuristik
┌─────────────────────────────────────┐
│ Apakah ini pekerjaan yang sama? │
└──────────────┬──────────────────────┘
│
┌──────────────────┼──────────────────┐
│ │ │
▼ ▼ ▼
Maksud sama? >50% tumpang tindih? Asli dapat
Masalah sama? Lingkup sama? diselesaikan "done" tanpa
│ │ perubahan ini?
│ │ │
┌────────┴────────┐ ┌──────┴──────┐ ┌───────┴───────┐
│ │ │ │ │ │
YA TIDAK YA TIDAK TIDAK YA
│ │ │ │ │ │
▼ ▼ ▼ ▼ ▼ ▼
PERBARUI BARU PERBARUI BARU PERBARUI BARU| Test | Perbarui | Perubahan Baru |
|---|---|---|
| Identitas | "Hal yang sama, disempurnakan" | "Pekerjaan berbeda" |
| Tumpang tindih lingkup | >50% tumpang tindih | <50% tumpang tindih |
| Penyelesaian | Tidak dapat "selesai" tanpa perubahan | Dapat menyelesaikan yang asli, pekerjaan baru berdiri sendiri |
| Cerita | Rantai pembaruan menceritakan kisah yang koheren | Tambalan akan membingungkan daripada memperjelas |
Prinsipnya
Memperbarui melestarikan konteks. Perubahan baru memberikan kejelasan.
Pilih perbarui ketika sejarah pemikiran Anda berharga. Pilih baru ketika memulai dari awal akan lebih jelas daripada melakukan tambalan.
Bayangkan seperti cabang git:
- Terus melakukan commit saat mengerjakan fitur yang sama
- Mulai cabang baru ketika itu benar-benar pekerjaan baru
- Terkadang gabungkan fitur parsial dan mulai dari awal untuk fase 2
Apa yang Berubah?
Legacy (/openspec:proposal) | OPSX (/opsx:*) | |
|---|---|---|
| Struktur | Satu dokumen proposal besar | Artefak diskrit dengan ketergantungan |
| Alur Kerja | Fase linier: rencana → implementasi → arsip | Aksi fleksibel — lakukan apa pun kapan saja |
| Iterasi | Sulit untuk kembali | Perbarui artefak seiring pembelajaran |
| Kustomisasi | Struktur tetap | Berbasis skema (tentukan artefak Anda sendiri) |
Wawasan utamanya: pekerjaan tidak bersifat linier. OPSX berhenti berpura-pura demikian.
Penjelasan Mendalam Arsitektur
Bagian ini menjelaskan bagaimana OPSX bekerja di balik layar dan bagaimana perbandingannya dengan alur kerja lama (legacy). Contoh dalam bagian ini menggunakan set perintah yang diperluas (new, continue, dll.); pengguna core default dapat memetakan alur yang sama ke propose → apply → sync → archive.
Filosofi: Fase vs Aksi
┌─────────────────────────────────────────────────────────────────────────────┐
│ LEGACY WORKFLOW │
│ (Phase-Locked, All-or-Nothing) │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
│ │ PLANNING │ ───► │ IMPLEMENTING │ ───► │ ARCHIVING │ │
│ │ PHASE │ │ PHASE │ │ PHASE │ │
│ └──────────────┘ └──────────────┘ └──────────────┘ │
│ │ │ │ │
│ ▼ ▼ ▼ │
│ /openspec:proposal /openspec:apply /openspec:archive │
│ │
│ • Membuat SEMUA artefak sekaligus │
│ • Tidak bisa kembali untuk memperbarui spesifikasi selama implementasi │
│ • Gerbang fase memaksa kemajuan linier │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────────────────────┐
│ OPSX WORKFLOW │
│ (Fluid Actions, Iterative) │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ ┌────────────────────────────────────────────┐ │
│ │ ACTIONS (not phases) │ │
│ │ │ │
│ │ new ◄──► continue ◄──► apply ◄──► archive │ │
│ │ │ │ │ │ │ │
│ │ └──────────┴───────────┴───────────┘ │ │
│ │ any order │ │
│ └────────────────────────────────────────────┘ │
│ │
│ • Buat artefak satu per satu ATAU percepat proses │
│ • Perbarui spesifikasi/design/tasks selama implementasi │
│ • Dependensi memungkinkan kemajuan, fase tidak ada │
│ │
└─────────────────────────────────────────────────────────────────────────────┘Arsitektur Komponen
Alur kerja lama (legacy) menggunakan template yang di-hardcode dalam TypeScript:
┌─────────────────────────────────────────────────────────────────────────────┐
│ LEGACY WORKFLOW COMPONENTS │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ Hardcoded Templates (TypeScript strings) │
│ │ │
│ ▼ │
│ Tool-specific configurators/adapters │
│ │ │
│ ▼ │
│ Generated Command Files (.claude/commands/openspec/*.md) │
│ │
│ • Struktur tetap, tanpa kesadaran artefak │
│ • Perubahan memerlukan modifikasi kode + rebuild │
│ │
└─────────────────────────────────────────────────────────────────────────────┘OPSX menggunakan skema eksternal dan mesin graf dependensi:
┌─────────────────────────────────────────────────────────────────────────────┐
│ 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) │
│ │
│ • Kompatibel lintas editor (Claude Code, Cursor, Devin) │
│ • Skills menanyakan CLI untuk data terstruktur │
│ • Sepenuhnya dapat dikustomisasi melalui file skema │
│ │
└─────────────────────────────────────────────────────────────────────────────┘Model Graf Dependensi
Artefak membentuk graf asiklik terarah (DAG). Dependensi adalah pemungkin, bukan gerbang:
proposal
(root node)
│
┌─────────────┴─────────────┐
│ │
▼ ▼
specs design
(requires: (requires:
proposal) proposal)
│ │
└─────────────┬─────────────┘
│
▼
tasks
(requires:
specs, design)
│
▼
┌──────────────┐
│ APPLY PHASE │
│ (requires: │
│ tasks) │
└──────────────┘Transisi keadaan:
BLOCKED ────────────────► READY ────────────────► DONE
│ │ │
Missing All deps File exists
dependencies are DONE on filesystemAlur Informasi
Alur kerja lama (legacy) — agen menerima instruksi statis:
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 goOPSX — agen menanyakan konteks yang kaya:
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 │
└──────────────────────────────────────────────────────────────────────────┘Model Iterasi
Alur kerja lama (legacy) — sulit untuk beriterasi:
┌─────────┐ ┌─────────┐ ┌─────────┐
│/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 onceOPSX — iterasi alami:
/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 directionSkema Kustom
Buat alur kerja kustom menggunakan perintah manajemen skema:
# Buat skema baru dari awal (interaktif)
openspec schema init my-workflow
# Atau fork skema yang sudah ada sebagai titik awal
openspec schema fork spec-driven my-workflow
# Validasi struktur skema Anda
openspec schema validate my-workflow
# Lihat dari mana skema di-resolve (berguna untuk debugging)
openspec schema which my-workflowSkema disimpan di openspec/schemas/ (lokal proyek, terkontrol versi) atau ~/.local/share/openspec/schemas/ (global pengguna).
Struktur skema:
openspec/schemas/research-first/
├── schema.yaml
└── templates/
├── research.md
├── proposal.md
└── tasks.mdContoh schema.yaml:
name: research-first
artifacts:
- id: research # Ditambahkan sebelum proposal
generates: research.md
requires: []
- id: proposal
generates: proposal.md
requires: [research] # Sekarang bergantung pada research
- id: tasks
generates: tasks.md
requires: [proposal]Graf Dependensi:
research ──► proposal ──► tasksRingkasan
| Aspek | Legacy | OPSX |
|---|---|---|
| Template | Hardcoded TypeScript | YAML eksternal + Markdown |
| Dependensi | Tidak ada (semua sekaligus) | DAG dengan topological sort |
| Keadaan | Model mental berbasis fase | Keberadaan di filesystem |
| Kustomisasi | Edit sumber, rebuild | Buat schema.yaml |
| Iterasi | Terkunci pada fase | Cair, edit apa pun |
| Dukungan Editor | Konfigurator/adaptor spesifik alat | Satu direktori skills |
Skema
Skema mendefinisikan artefak apa saja yang ada dan ketergantungannya. Saat ini tersedia:
- spec-driven (default): proposal → specs → design → tasks
# Daftar skema yang tersedia
openspec schemas
# Lihat semua skema beserta sumber resolusi mereka
openspec schema which --all
# Buat skema baru secara interaktif
openspec schema init my-workflow
# Fork skema yang sudah ada untuk disesuaikan
openspec schema fork spec-driven my-workflow
# Validasi struktur skema sebelum digunakan
openspec schema validate my-workflowTips
- Gunakan
/opsx:exploreuntuk memikirkan sebuah ide sebelum berkomitmen pada perubahan /opsx:ffketika Anda sudah tahu apa yang diinginkan,/opsx:continuesaat sedang mengeksplorasi- Selama
/opsx:apply, jika ada kesalahan — perbaiki artefaknya, lalu lanjutkan - Tugas melacak kemajuan melalui kotak centang di
tasks.md - Periksa status kapan saja:
openspec status --change "name"
Masukan
Ini masih kasar. Itu disengaja — kami sedang mempelajari apa yang berhasil.
Menemukan bug? Punya ide? Bergabunglah dengan kami di Discord atau buka masalah di GitHub.