Quy trình OPSX
Phản hồi được chào đón trên Discord.
OPSX là gì?
OPSX hiện là quy trình chuẩn cho OpenSpec.
Đây là một quy trình linh hoạt, lặp lại cho các thay đổi của OpenSpec. Không còn các giai đoạn cứng nhắc — chỉ có các hành động bạn có thể thực hiện bất cứ lúc nào.
Tại Sao Công Cụ Này Tồn Tại
Quy trình OpenSpec cũ hoạt động được, nhưng nó bị khóa cứng:
- Hướng dẫn được hardcode — chôn trong TypeScript, bạn không thể thay đổi
- Tất cả hoặc không gì cả — một lệnh lớn tạo mọi thứ, không thể kiểm thử từng phần riêng lẻ
- Cấu trúc cố định — cùng một quy trình cho mọi người, không có tùy chỉnh
- Hộp đen — khi đầu ra của AI kém, bạn không thể tinh chỉnh prompt
OPSX mở khóa tất cả. Giờ bất kỳ ai cũng có thể:
- Thử nghiệm với hướng dẫn — chỉnh sửa một template, xem AI có làm tốt hơn không
- Kiểm thử chi tiết — xác thực hướng dẫn của từng artifact độc lập
- Tùy chỉnh quy trình — định nghĩa artifact và phụ thuộc của riêng bạn
- Lặp lại nhanh chóng — thay đổi template, kiểm thử ngay lập tức, không cần build lại
Legacy workflow: OPSX:
┌────────────────────────┐ ┌────────────────────────┐
│ Hardcoded in package │ │ schema.yaml │◄── Bạn chỉnh sửa cái này
│ (can't change) │ │ templates/*.md │◄── Hoặc cái này
│ ↓ │ │ ↓ │
│ Wait for new release │ │ Instant effect │
│ ↓ │ │ ↓ │
│ Hope it's better │ │ Test it yourself │
└────────────────────────┘ └────────────────────────┘Điều này dành cho tất cả mọi người:
- Đội ngũ — tạo quy trình phù hợp với cách bạn thực sự làm việc
- Người dùng nâng cao — tinh chỉnh prompt để có đầu ra AI tốt hơn cho codebase của bạn
- Người đóng góp OpenSpec — thử nghiệm cách tiếp cận mới mà không cần phát hành bản mới
Chúng ta đều vẫn đang học hỏi điều gì hoạt động tốt nhất. OPSX cho phép chúng ta cùng học.
Trải Nghiệm Người Dùng
Vấn đề với quy trình tuyến tính: Bạn "ở giai đoạn lập kế hoạch", rồi "ở giai đoạn triển khai", rồi "hoàn thành". Nhưng công việc thực tế không vận hành như vậy. Bạn triển khai một thứ gì đó, nhận ra thiết kế của mình sai, cần cập nhật spec, tiếp tục triển khai. Các giai đoạn tuyến tính đi ngược lại cách công việc thực sự diễn ra.
Cách tiếp cận của OPSX:
- Hành động, không phải giai đoạn — tạo, triển khai, cập nhật, lưu trữ — làm bất kỳ điều nào bất cứ lúc nào
- Phụ thuộc là yếu tố cho phép — chúng cho thấy điều gì là khả thi, không phải điều gì bắt buộc tiếp theo
proposal ──→ specs ──→ design ──→ tasks ──→ implementCài Đặt
# Đảm bảo bạn đã cài đặt openspec — skills được tạo tự động
openspec initĐiều này tạo skills trong .claude/skills/ (hoặc tương đương) mà các trợ lý AI lập trình tự động phát hiện.
Mặc định, OpenSpec sử dụng profile workflow core (propose, explore, apply, update, sync, archive). Nếu bạn muốn các lệnh workflow mở rộng (new, continue, ff, verify, bulk-archive, onboard), hãy cấu hình chúng bằng openspec config profile và áp dụng bằng openspec update.
Trong quá trình cài đặt, bạn sẽ được hỏi để tạo cấu hình dự án (openspec/config.yaml). Đây là tùy chọn nhưng được khuyến nghị.
Cấu Hình Dự Án
Cấu hình dự án cho phép bạn đặt giá trị mặc định và tiêm ngữ cảnh cụ thể của dự án vào tất cả các artifact.
Tạo Cấu Hình
Cấu hình được tạo trong openspec init, hoặc thủ công:
# 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 flowsCác Trường Cấu Hình
| Trường | Kiểu | Mô tả |
|---|---|---|
schema | string | Schema mặc định cho các thay đổi mới (ví dụ: spec-driven) |
context | string | Ngữ cảnh dự án được tiêm vào hướng dẫn của tất cả artifact |
rules | object | Quy tắc cho từng artifact, dùng ID artifact làm khóa |
Cách Hoạt Động
Ưu tiên schema (từ cao đến thấp):
- CLI flag (
--schema <name>) - Metadata của thay đổi (
.openspec.yamltrong thư mục thay đổi) - Cấu hình dự án (
openspec/config.yaml) - Mặc định (
spec-driven)
Tiêm ngữ cảnh:
- Ngữ cảnh được đặt trước hướng dẫn của mọi artifact
- Được bọc trong thẻ
<context>...</context> - Giúp AI hiểu các quy ước của dự án bạn
Tiêm quy tắc:
- Quy tắc chỉ được tiêm cho các artifact khớp
- Được bọc trong thẻ
<rules>...</rules> - Xuất hiện sau ngữ cảnh, trước template
Artifact ID Theo Schema
spec-driven (mặc định):
proposal— Đề xuất thay đổispecs— Đặc tảdesign— Thiết kế kỹ thuậttasks— Nhiệm vụ triển khai
Xác Thực Cấu Hình
- Artifact ID không xác định trong
rulessẽ tạo cảnh báo - Tên schema được xác thực đối chiếu với các schema khả dụng
- Ngữ cảnh có giới hạn kích thước 50KB
- YAML không hợp lệ được báo cáo kèm số dòng
Khắc Phục Sự Cố
"Unknown artifact ID in rules: X"
- Kiểm tra artifact ID khớp với schema của bạn (xem danh sách ở trên)
- Chạy
openspec schemas --jsonđể xem artifact ID cho từng schema
Cấu hình không được áp dụng:
- Đảm bảo tệp ở
openspec/config.yaml(không phải.yml) - Kiểm tra cú pháp YAML bằng trình xác thực
- Thay đổi cấu hình có hiệu lực ngay lập tức (không cần khởi động lại)
Ngữ cảnh quá lớn:
- Ngữ cảnh bị giới hạn ở 50KB
- Tóm tắt hoặc liên kết đến tài liệu bên ngoài thay thế
Các Lệnh
| Lệnh | Công dụng |
|---|---|
/opsx:propose | Tạo một thay đổi và sinh các artifact lập kế hoạch trong một bước (đường dẫn nhanh mặc định) |
/opsx:explore | Suy nghĩ về ý tưởng, điều tra vấn đề, làm rõ yêu cầu |
/opsx:new | Bắt đầu scaffold cho một thay đổi mới (workflow mở rộng) |
/opsx:continue | Tạo artifact tiếp theo (workflow mở rộng) |
/opsx:ff | Fast-forward các artifact lập kế hoạch (workflow mở rộng) |
/opsx:apply | Triển khai các nhiệm vụ, cập nhật artifact khi cần |
/opsx:update | Tu chỉnh các artifact lập kế hoạch của một thay đổi và giữ chúng nhất quán |
/opsx:verify | Xác thực triển khai đối chiếu với các artifact (workflow mở rộng) |
/opsx:sync | Hợp nhất delta specs vào main specs (tùy chọn) |
/opsx:archive | Lưu trữ khi hoàn thành |
/opsx:bulk-archive | Lưu trữ nhiều thay đổi đã hoàn thành (workflow mở rộng) |
/opsx:onboard | Hướng dẫn đi qua một thay đổi end-to-end (workflow mở rộng) |
Sử Dụng
Khám phá một ý tưởng
/opsx:exploreSuy nghĩ về ý tưởng, điều tra vấn đề, so sánh các phương án. Không yêu cầu cấu trúc - chỉ là một đối tác suy nghĩ. Khi các nhận thức kết tinh, chuyển sang /opsx:propose (mặc định) hoặc /opsx:new//opsx:ff (mở rộng).
Bắt đầu một thay đổi mới
/opsx:proposeTạo thay đổi và sinh các artifact lập kế hoạch cần thiết trước khi triển khai.
Nếu bạn đã bật workflow mở rộng, bạn có thể thay thế bằng:
/opsx:new # chỉ scaffold
/opsx:continue # tạo một artifact một lúc
/opsx:ff # tạo tất cả artifact lập kế hoạch cùng lúcTạo artifact
/opsx:continueHiển thị những gì sẵn sàng để tạo dựa trên phụ thuộc, sau đó tạo một artifact. Sử dụng lặp lại để xây dựng thay đổi của bạn dần dần.
/opsx:ff add-dark-modeTạo tất cả các artifact lập kế hoạch cùng lúc. Sử dụng khi bạn có hình ảnh rõ ràng về thứ mình đang xây dựng.
Triển khai (phần linh hoạt)
/opsx:applyXử lý các nhiệm vụ, đánh dấu hoàn thành khi bạn tiến hành. Nếu bạn đang xử lý nhiều thay đổi cùng lúc, bạn có thể chạy /opsx:apply <name>; nếu không, nó nên suy luận từ cuộc hội thoại và hỏi bạn chọn nếu không thể xác định.
Cập nhật một thay đổi
/opsx:update add-dark-mode - we're storing the theme in a cookie nowTu chỉnh các artifact lập kế hoạch hiện có của thay đổi và giữ chúng nhất quán - theo bất kỳ hướng nào (một chỉnh sửa thiết kế có thể lan ngược lại đề xuất). Chỉ artifact lập kế hoạch: nó không bao giờ sửa code, và không bao giờ tạo các artifact còn thiếu (đó là /opsx:continue). Mọi chỉnh sửa đều được xác nhận với bạn trước. Nếu thay đổi đã được triển khai, nó khuyến nghị /opsx:apply để code bắt kịp với kế hoạch đã tu chỉnh. Nếu bản tu chỉnh của bạn thay đổi ý định của thay đổi, hãy bắt đầu mới thay vì - xem Khi nào nên Cập nhật vs. Bắt đầu Mới.
Đồng bộ delta specs
/opsx:syncHợp nhất delta specs của thay đổi hiện tại vào openspec/specs/ chính của bạn mà không lưu trữ — thay đổi vẫn hoạt động. Nó áp dụng toàn bộ delta: một yêu cầu dưới ## REMOVED sẽ bị xóa khỏi spec chính và một cái được đổi tên sẽ được đặt lại tiêu đề tại chỗ, trong khi nội dung mà delta không đề cập sẽ được giữ nguyên. Đồng bộ là tùy chọn — lưu trữ sẽ hỏi bạn đồng bộ trước nếu bạn chưa làm. Sử dụng khi bạn muốn spec chính được cập nhật trước khi lưu trữ, khi một thay đổi song song cần xây dựng trên spec mà thay đổi này vừa thêm, hoặc khi bạn muốn xem xét spec chính đã hợp nhất trước khi lưu trữ.
Hoàn tất
/opsx:archive # Chuyển vào lưu trữ khi hoàn thành (hỏi đồng bộ specs nếu cần)Khi Nào Nên Cập Nhật vs. Bắt Đầu Mới
Bạn luôn có thể chỉnh sửa đề xuất hoặc specs trước khi triển khai. Nhưng khi nào việc tinh chỉnh trở thành "đây là công việc khác"?
Đề Xuất Bắt Giữ Điều Gì
Một đề xuất định nghĩa ba thứ:
- Ý định — Bạn đang giải quyết vấn đề gì?
- Phạm vi — Điều gì trong/ngoài phạm vi?
- Cách tiếp cận — Bạn sẽ giải quyết như thế nào?
Câu hỏi là: điều gì đã thay đổi, và thay đổi bao nhiêu?
Cập Nhật Thay Đổi Hiện Có Khi:
Cùng ý định, thực thi được tinh chỉnh
- Bạn phát hiện các trường hợp biên chưa cân nhắc
- Cách tiếp cận cần tinh chỉnh nhưng mục tiêu không thay đổi
- Triển khai tiết lộ thiết kế hơi lệch
Phạm vi thu hẹp
- Bạn nhận ra phạm vi đầy đủ quá lớn, muốn phát hành MVP trước
- "Thêm dark mode" → "Thêm công tắc dark mode (tùy chọn hệ thống ở v2)"
Sửa chữa dựa trên học hỏi
- Codebase không được cấu trúc như bạn nghĩ
- Một dependency không hoạt động như mong đợi
- "Dùng CSS variables" → "Dùng prefix dark: của Tailwind thay thế"
Bắt Đầu Thay Đổi Mới Khi:
Ý định thay đổi cơ bản
- Bản thân vấn đề giờ khác rồi
- "Thêm dark mode" → "Thêm hệ thống theme toàn diện với màu sắc tùy chỉnh, font, spacing"
Phạm vi bùng nổ
- Thay đổi phát triển đến mức nó thực chất là công việc khác
- Đề xuất gốc sẽ không nhận ra được sau các cập nhật
- "Sửa lỗi đăng nhập" → "Viết lại hệ thống xác thực"
Bản gốc có thể hoàn thành
- Thay đổi gốc có thể được đánh dấu "hoàn thành"
- Công việc mới đứng độc lập, không phải tinh chỉnh
- Hoàn thành "Thêm dark mode MVP" → Lưu trữ → Thay đổi mới "Nâng cấp dark mode"
Các Heuristic
┌─────────────────────────────────────┐
│ Đây có phải cùng công việc? │
└──────────────┬──────────────────────┘
│
┌──────────────────┼──────────────────┐
│ │ │
▼ ▼ ▼
Cùng ý định? >50% trùng lặp? Bản gốc có thể
Cùng vấn đề? Cùng phạm vi? "hoàn thành" mà
│ │ không cần các
│ │ thay đổi này?
│ │ │
┌────────┴────────┐ ┌──────┴──────┐ ┌───────┴───────┐
│ │ │ │ │ │
CÓ KHÔNG CÓ KHÔNG KHÔNG CÓ
│ │ │ │ │ │
▼ ▼ ▼ ▼ ▼ ▼
CẬP NHẬT MỚI CẬP NHẬT MỚI CẬP NHẬT MỚI| Tiêu chí | Cập nhật | Thay đổi mới |
|---|---|---|
| Bản sắc | "Cùng thứ, được tinh chỉnh" | "Công việc khác" |
| Trùng lặp phạm vi | >50% trùng lặp | <50% trùng lặp |
| Hoàn thành | Không thể "hoàn thành" mà không cần thay đổi | Có thể hoàn thành bản gốc, công việc mới đứng độc lập |
| Câu chuyện | Chuỗi cập nhật kể câu chuyện nhất quán | Các vá sẽ gây nhầm lẫn hơn là làm rõ |
Nguyên Tắc
Cập nhật bảo toàn ngữ cảnh. Thay đổi mới mang lại sự rõ ràng.
Chọn cập nhật khi lịch sử suy nghĩ của bạn có giá trị. Chọn mới khi bắt đầu lại sẽ rõ ràng hơn là vá.
Hãy nghĩ như các nhánh git:
- Tiếp tục commit khi làm việc trên cùng một tính năng
- Bắt đầu nhánh mới khi thực sự là công việc mới
- Đôi khi hợp nhất một tính năng một phần và bắt đầu mới cho giai đoạn 2
Có gì khác biệt?
Cũ (/openspec:proposal) | OPSX (/opsx:*) | |
|---|---|---|
| Cấu trúc | Một tài liệu đề xuất lớn duy nhất | Các thực thể rời rạc có phụ thuộc lẫn nhau |
| Quy trình | Các giai đoạn tuyến tính: lập kế hoạch → triển khai → lưu trữ | Các hành động linh hoạt — thực hiện bất cứ điều gì, bất cứ lúc nào |
| Lặp lại | Khó khăn khi quay lại | Cập nhật các thực thể khi bạn học hỏi thêm |
| Tùy chỉnh | Cấu trúc cố định | Dựa trên lược đồ (định nghĩa các thực thể của riêng bạn) |
Nhận thức then chốt: công việc không diễn ra theo tuyến tính. OPSX ngừng giả vờ rằng nó như vậy.
Phân tích sâu kiến trúc
Phần này giải thích cách OPSX hoạt động bên trong và cách nó so sánh với quy trình làm việc cũ (legacy). Các ví dụ trong phần này sử dụng bộ lệnh mở rộng (new, continue, v.v.); người dùng mặc định core có thể ánh xạ cùng một luồng sang propose → apply → sync → archive.
Triết lý: Giai đoạn vs Hành động
┌─────────────────────────────────────────────────────────────────────────────┐
│ QUY TRÌNH CŨ (LEGACY) │
│ (Khóa theo giai đoạn, tất cả hoặc không có gì) │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
│ │ PLANNING │ ───► │ IMPLEMENTING │ ───► │ ARCHIVING │ │
│ │ PHASE │ │ PHASE │ │ PHASE │ │
│ └──────────────┘ └──────────────┘ └──────────────┘ │
│ │ │ │ │
│ ▼ ▼ ▼ │
│ /openspec:proposal /openspec:apply /openspec:archive │
│ │
│ • Tạo TẤT CẢ các artifact cùng lúc │
│ • Không thể quay lại cập nhật spec trong quá trình triển khai │
│ • Cổng giai đoạn ép buộc tiến trình tuyến tính │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────────────────────┐
│ QUY TRÌNH OPSX │
│ (Hành động linh hoạt, lặp lại) │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ ┌────────────────────────────────────────────┐ │
│ │ HÀNH ĐỘNG (không phải giai đoạn) │ │
│ │ │ │
│ │ new ◄──► continue ◄──► apply ◄──► archive │ │
│ │ │ │ │ │ │ │
│ │ └──────────┴───────────┴───────────┘ │ │
│ │ bất kỳ thứ tự nào │ │
│ └────────────────────────────────────────────┘ │
│ │
│ • Tạo artifact từng cái một HOẶC nhảy nhanh │
│ • Cập nhật spec/design/tasks trong quá trình triển khai │
│ • Phụ thuộc cho phép tiến bộ, không tồn tại khái niệm giai đoạn │
│ │
└─────────────────────────────────────────────────────────────────────────────┘Kiến trúc thành phần
Quy trình cũ (legacy) sử dụng các mẫu được hardcode trong TypeScript:
┌─────────────────────────────────────────────────────────────────────────────┐
│ THÀNH PHẦN QUY TRÌNH CŨ (LEGACY) │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ Mẫu hardcode (chuỗi TypeScript) │
│ │ │
│ ▼ │
│ Bộ cấu hình/adapter riêng cho từng công cụ │
│ │ │
│ ▼ │
│ File lệnh được sinh ra (.claude/commands/openspec/*.md) │
│ │
│ • Cấu trúc cố định, không nhận thức về artifact │
│ • Thay đổi đòi hỏi sửa mã nguồn + build lại │
│ │
└─────────────────────────────────────────────────────────────────────────────┘OPSX sử dụng schema bên ngoài và một engine đồ thị phụ thuộc:
┌─────────────────────────────────────────────────────────────────────────────┐
│ THÀNH PHẦN OPSX │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ Định nghĩa Schema (YAML) │
│ ┌─────────────────────────────────────────────────────────────────────┐ │
│ │ name: spec-driven │ │
│ │ artifacts: │ │
│ │ - id: proposal │ │
│ │ generates: proposal.md │ │
│ │ requires: [] ◄── Phụ thuộc │ │
│ │ - id: specs │ │
│ │ generates: specs/**/*.md ◄── Glob patterns │ │
│ │ requires: [proposal] ◄── Kích hoạt sau proposal │ │
│ └─────────────────────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ Engine Đồ thị Artifact │
│ ┌─────────────────────────────────────────────────────────────────────┐ │
│ │ • Sắp xếp topo (thứ tự phụ thuộc) │ │
│ │ • Phát hiện trạng thái (sự tồn tại trên filesystem) │ │
│ │ • Sinh hướng dẫn phong phú (mẫu + ngữ cảnh) │ │
│ └─────────────────────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ File Skill (.claude/skills/openspec-*/SKILL.md) │
│ │
│ • Tương thích đa trình soạn thảo (Claude Code, Cursor, Devin) │
│ • Skill truy vấn CLI để lấy dữ liệu có cấu trúc │
│ • Hoàn toàn tùy chỉnh được thông qua file schema │
│ │
└─────────────────────────────────────────────────────────────────────────────┘Mô hình đồ thị phụ thuộc
Các artifact tạo thành một đồ thị có hướng không chu trình (DAG). Phụ thuộc là yếu tố kích hoạt, không phải cổng chặn:
proposal
(nút gốc)
│
┌─────────────┴─────────────┐
│ │
▼ ▼
specs design
(requires: (requires:
proposal) proposal)
│ │
└─────────────┬─────────────┘
│
▼
tasks
(requires:
specs, design)
│
▼
┌──────────────┐
│ APPLY PHASE │
│ (requires: │
│ tasks) │
└──────────────┘Chuyển trạng thái:
BLOCKED ────────────────► READY ────────────────► DONE
│ │ │
Thiếu Tất cả phụ File tồn tại
phụ thuộc thuộc đã DONE trên filesystemLuồng thông tin
Quy trình cũ (legacy) — agent nhận hướng dẫn tĩnh:
Người dùng: "/openspec:proposal"
│
▼
┌─────────────────────────────────────────┐
│ Hướng dẫn tĩnh: │
│ • Tạo proposal.md │
│ • Tạo tasks.md │
│ • Tạo design.md │
│ • Tạo các file delta spec │
│ │
│ Không nhận thức về những gì đã tồn tại │
│ hay phụ thuộc giữa các artifact │
└─────────────────────────────────────────┘
│
▼
Agent tạo TẤT CẢ các artifact cùng lúcOPSX — agent truy vấn để lấy ngữ cảnh phong phú:
Người dùng: "/opsx:continue"
│
▼
┌──────────────────────────────────────────────────────────────────────────┐
│ Bước 1: Truy vấn trạng thái hiện tại │
│ ┌────────────────────────────────────────────────────────────────────┐ │
│ │ $ openspec status --change "add-auth" --json │ │
│ │ │ │
│ │ { │ │
│ │ "artifacts": [ │ │
│ │ {"id": "proposal", "status": "done"}, │ │
│ │ {"id": "specs", "status": "ready"}, ◄── Sẵn sàng đầu tiên│ │
│ │ {"id": "design", "status": "ready"}, │ │
│ │ {"id": "tasks", "status": "blocked", │ │
│ │ "missingDeps": ["specs", "design"]} │ │
│ │ ] │ │
│ │ } │ │
│ └────────────────────────────────────────────────────────────────────┘ │
│ │
│ Bước 2: Lấy hướng dẫn phong phú cho artifact sẵn sàng │
│ ┌────────────────────────────────────────────────────────────────────┐ │
│ │ $ openspec instructions specs --change "add-auth" --json │ │
│ │ │ │
│ │ { │ │
│ │ "template": "# Specification\n\n## ADDED Requirements...", │ │
│ │ "dependencies": [{"id": "proposal", "path": "...", "done": true}│ │
│ │ "unlocks": ["tasks"] │ │
│ │ } │ │
│ └────────────────────────────────────────────────────────────────────┘ │
│ │
│ Bước 3: Đọc phụ thuộc → Tạo MỘT artifact → Hiển thị điều gì được mở khóa│
└──────────────────────────────────────────────────────────────────────────┘Mô hình lặp lại
Quy trình cũ (legacy) — khó khăn khi lặp lại:
┌─────────┐ ┌─────────┐ ┌─────────┐
│/proposal│ ──► │ /apply │ ──► │/archive │
└─────────┘ └─────────┘ └─────────┘
│ │
│ ├── "Khoan, thiết kế sai rồi"
│ │
│ ├── Các lựa chọn:
│ │ • Sửa file thủ công (làm hỏng ngữ cảnh)
│ │ • Bỏ và bắt đầu lại từ đầu
│ │ • Cố gắng tiếp tục và sửa sau
│ │
│ └── Không có cơ chế "quay lại" chính thức
│
└── Tạo TẤT CẢ các artifact cùng lúcOPSX — lặp lại tự nhiên:
/opsx:new ───► /opsx:continue ───► /opsx:apply ───► /opsx:archive
│ │ │
│ │ ├── "Thiết kế sai rồi"
│ │ │
│ │ ▼
│ │ Chỉ cần sửa design.md
│ │ và tiếp tục!
│ │ │
│ │ ▼
│ │ /opsx:apply tiếp tục
│ │ từ nơi bạn dừng lại
│ │
│ └── Tạo MỘT artifact, hiển thị điều gì được mở khóa
│
└── Khởi tạo thay đổi, chờ hướng dẫnSchema tùy chỉnh
Tạo quy trình làm việc tùy chỉnh bằng các lệnh quản lý schema:
# Tạo schema mới từ đầu (tương tác)
openspec schema init my-workflow
# Hoặc fork một schema hiện có làm điểm khởi đầu
openspec schema fork spec-driven my-workflow
# Xác thực cấu trúc schema của bạn
openspec schema validate my-workflow
# Xem schema được phân giải từ đâu (hữu ích để gỡ lỗi)
openspec schema which my-workflowSchema được lưu trong openspec/schemas/ (cấp dự án, kiểm soát phiên bản) hoặc ~/.local/share/openspec/schemas/ (toàn cục người dùng).
Cấu trúc schema:
openspec/schemas/research-first/
├── schema.yaml
└── templates/
├── research.md
├── proposal.md
└── tasks.mdVí dụ schema.yaml:
name: research-first
artifacts:
- id: research # Thêm trước proposal
generates: research.md
requires: []
- id: proposal
generates: proposal.md
requires: [research] # Bây giờ phụ thuộc vào research
- id: tasks
generates: tasks.md
requires: [proposal]Đồ thị phụ thuộc:
research ──► proposal ──► tasksTóm tắt
| Khía cạnh | Legacy | OPSX |
|---|---|---|
| Mẫu | Hardcode TypeScript | YAML bên ngoài + Markdown |
| Phụ thuộc | Không có (tất cả cùng lúc) | DAG với sắp xếp topo |
| Trạng thái | Mô hình nhận thức dựa trên giai đoạn | Sự tồn tại trên filesystem |
| Tùy chỉnh | Sửa mã nguồn, build lại | Tạo schema.yaml |
| Lặp lại | Khóa theo giai đoạn | Linh hoạt, sửa bất cứ thứ gì |
| Hỗ trợ trình soạn thảo | Bộ cấu hình/adapter riêng cho từng công cụ | Một thư mục skill duy nhất |
Schemas
Schemas định nghĩa các artifact tồn tại và các phụ thuộc của chúng. Hiện có sẵn:
- spec-driven (mặc định): proposal → specs → design → tasks
# Liệt kê các schemas có sẵn
openspec schemas
# Xem tất cả schemas cùng nguồn phân giải của chúng
openspec schema which --all
# Tạo một schema mới tương tác
openspec schema init my-workflow
# Fork một schema hiện có để tùy chỉnh
openspec schema fork spec-driven my-workflow
# Xác thực cấu trúc schema trước khi sử dụng
openspec schema validate my-workflowMẹo
- Sử dụng
/opsx:exploređể suy nghĩ về một ý tưởng trước khi cam kết thay đổi /opsx:ffkhi bạn biết mình muốn gì,/opsx:continuekhi đang khám phá- Trong quá trình
/opsx:apply, nếu có gì sai — sửa artifact, sau đó tiếp tục - Tasks theo dõi tiến độ thông qua các checkbox trong
tasks.md - Kiểm tra trạng thái bất cứ lúc nào:
openspec status --change "name"
Phản hồi
Đây là bản nháp. Điều này là có chủ đích — chúng tôi đang học hỏi những gì hiệu quả.
Tìm thấy lỗi? Có ý tưởng? Tham gia cùng chúng tôi trên Discord hoặc mở một issue trên GitHub.