ขั้นตอน OPSX
ยินดีรับความคิดเห็นบน Discord
มันคืออะไร?
OPSX คือขั้นตอนมาตรฐานสำหรับ OpenSpec ในปัจจุบัน
นี่คือ ขั้นตอนที่ยืดหยุ่นและเป็นวัฏจักร สำหรับการเปลี่ยนแปลง OpenSpec ไม่มีขั้นตอนที่ตายตัวอีกต่อไป — มีเพียงการกระทำที่คุณสามารถทำได้ทุกเมื่อ
เหตุผลที่สร้างเครื่องมือนี้
เวิร์กโฟลว์ OpenSpec แบบเดิมใช้งานได้ แต่มี ข้อจำกัดหลายประการ:
- คำสั่งถูกฝังไว้ — อยู่ในโค้ด TypeScript คุณไม่สามารถแก้ไขได้
- ทั้งหมดหรือไม่มีเลย — คำสั่งเดียวสร้างทุกอย่าง ไม่สามารถทดสอบชิ้นส่วนแยกได้
- โครงสร้างตายตัว — เวิร์กโฟลว์เดียวกันสำหรับทุกคน ไม่สามารถปรับแต่งได้
- กล่องดำ — เมื่อผลลัพธ์จาก AI ไม่ดี คุณไม่สามารถปรับแต่ง prompt ได้
OPSX เปิดให้ใช้งานได้อย่างอิสระ ตอนนี้ใครก็สามารถ:
- ทดลองกับคำสั่ง — แก้ไขเทมเพลต ดูว่า AI ทำได้ดีขึ้นหรือไม่
- ทดสอบอย่างละเอียด — ตรวจสอบคำสั่งของแต่ละ artifact อย่างอิสระ
- ปรับแต่งเวิร์กโฟลว์ — กำหนด artifact และความเชื่อมโยงของคุณเอง
- พัฒนาอย่างรวดเร็ว — เปลี่ยนเทมเพลต ทดสอบทันที ไม่ต้องสร้างใหม่
เวิร์กโฟลว์แบบเดิม: OPSX:
┌────────────────────────┐ ┌────────────────────────┐
│ ฝังอยู่ในแพ็กเกจ │ │ schema.yaml │◄── คุณแก้ไขไฟล์นี้
│ (ไม่สามารถแก้ไขได้) │ │ templates/*.md │◄── หรือไฟล์นี้
│ ↓ │ │ ↓ │
│ รอเวอร์ชันใหม่ │ │ มีผลทันที │
│ ↓ │ │ ↓ │
│ หวังว่าจะดีขึ้น │ │ ทดสอบด้วยตัวเอง │
└────────────────────────┘ └────────────────────────┘เครื่องมือนี้สำหรับทุกคน:
- ทีม — สร้างเวิร์กโฟลว์ที่ตรงกับวิธีการทำงานจริงของคุณ
- ผู้ใช้ขั้นสูง — ปรับแต่ง prompt เพื่อให้ได้ผลลัพธ์ AI ที่ดีขึ้นสำหรับโค้ดเบสของคุณ
- ผู้มีส่วนร่วมใน OpenSpec — ทดลองวิธีการใหม่ๆ โดยไม่ต้องรอเวอร์ชันใหม่
เราทุกคนยังคงเรียนรู้ว่าอะไรดีที่สุด OPSX ช่วยให้เราเรียนรู้ร่วมกัน
ประสบการณ์ผู้ใช้
ปัญหาของเวิร์กโฟลว์แบบเส้นตรง: คุณอยู่ใน "ขั้นตอนการวางแผน" จากนั้น "ขั้นตอนการพัฒนา" แล้วก็ "เสร็จสิ้น" แต่การทำงานจริงไม่ได้เป็นแบบนั้น คุณพัฒนาบางอย่าง ตระหนักว่าการออกแบบผิด ต้องอัปเดตสเปก แล้วพัฒนาต่อ ขั้นตอนแบบเส้นตรงขัดแย้งกับวิธีการทำงานจริง
วิธีการของ OPSX:
- การกระทำ ไม่ใช่ขั้นตอน — สร้าง พัฒนา อัปเดต เก็บถาวร — ทำได้ทุกอย่างทุกเมื่อ
- ความเชื่อมโยงเป็นตัวอำนวยความสะดวก — แสดงสิ่งที่เป็นไปได้ ไม่ใช่สิ่งที่ต้องทำต่อไป
proposal ──→ specs ──→ design ──→ tasks ──→ implementการตั้งค่า
bash
# ตรวจสอบว่าคุณได้ติดตั้ง openspec แล้ว — skills จะถูกสร้างโดยอัตโนมัติ
openspec initคำสั่งนี้จะสร้าง skills ใน .claude/skills/ (หรือตำแหน่งที่เทียบเท่า) ซึ่ง AI coding assistant จะตรวจจับโดยอัตโนมัติ
ตามค่าเริ่มต้น OpenSpec ใช้โปรไฟล์เวิร์กโฟลว์ core (propose, explore, apply, archive) หากคุณต้องการคำสั่งเวิร์กโฟลว์ที่ขยายเพิ่ม (new, continue, ff, verify, sync, bulk-archive, onboard) ให้กำหนดค่าด้วย openspec config profile และนำไปใช้ด้วย openspec update
ระหว่างการตั้งค่า คุณจะได้รับแจ้งให้สร้าง การกำหนดค่าโปรเจกต์ (openspec/config.yaml) ซึ่งเป็นทางเลือกแต่แนะนำให้ทำ
การกำหนดค่าโปรเจกต์
การกำหนดค่าโปรเจกต์ช่วยให้คุณตั้งค่าเริ่มต้นและใส่บริบทเฉพาะโปรเจกต์ลงในทุก artifact
การสร้างการกำหนดค่า
การกำหนดค่าจะถูกสร้างระหว่าง openspec init หรือสร้างด้วยตนเอง:
yaml
# 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ฟิลด์การกำหนดค่า
| ฟิลด์ | ประเภท | คำอธิบาย |
|---|---|---|
schema | string | Schema เริ่มต้นสำหรับการเปลี่ยนแปลงใหม่ (เช่น spec-driven) |
context | string | บริบทโปรเจกต์ที่ใส่ลงในคำสั่งของทุก artifact |
rules | object | กฎสำหรับแต่ละ artifact โดยใช้ artifact ID เป็นคีย์ |
วิธีการทำงาน
ลำดับความสำคัญของ Schema (จากสูงไปต่ำ):
- แฟล็ก CLI (
--schema <name>) - เมตาดาต้าการเปลี่ยนแปลง (
.openspec.yamlในไดเรกทอรีการเปลี่ยนแปลง) - การกำหนดค่าโปรเจกต์ (
openspec/config.yaml) - ค่าเริ่มต้น (
spec-driven)
การใส่บริบท:
- บริบทจะถูกเพิ่มไว้ด้านหน้าคำสั่งของทุก artifact
- ห่อไว้ในแท็ก
<context>...</context> - ช่วยให้ AI เข้าใจข้อตกลงของโปรเจกต์คุณ
การใส่กฎ:
- กฎจะถูกใส่เฉพาะ artifact ที่ตรงกันเท่านั้น
- ห่อไว้ในแท็ก
<rules>...</rules> - ปรากฏหลังบริบท ก่อนเทมเพลต
Artifact IDs ตาม Schema
spec-driven (ค่าเริ่มต้น):
proposal— ข้อเสนอการเปลี่ยนแปลงspecs— ข้อกำหนดdesign— การออกแบบทางเทคนิคtasks— งานพัฒนา
การตรวจสอบการกำหนดค่า
- Artifact IDs ที่ไม่รู้จักใน
rulesจะสร้างคำเตือน - ชื่อ schema จะถูกตรวจสอบกับ schema ที่มีอยู่
- บริบทมีขนาดจำกัด 50KB
- YAML ที่ไม่ถูกต้องจะรายงานพร้อมหมายเลขบรรทัด
การแก้ไขปัญหา
"Unknown artifact ID in rules: X"
- ตรวจสอบว่า artifact IDs ตรงกับ schema ของคุณ (ดูรายการด้านบน)
- รัน
openspec schemas --jsonเพื่อดู artifact IDs สำหรับแต่ละ schema
การกำหนดค่าไม่ถูกนำไปใช้:
- ตรวจสอบว่าไฟล์อยู่ที่
openspec/config.yaml(ไม่ใช่.yml) - ตรวจสอบไวยากรณ์ YAML ด้วยตัวตรวจสอบ
- การเปลี่ยนแปลงการกำหนดค่าจะมีผลทันที (ไม่ต้องรีสตาร์ท)
บริบทมีขนาดใหญ่เกินไป:
- บริบทจำกัดที่ 50KB
- สรุปหรือลิงก์ไปยังเอกสารภายนอกแทน
คำสั่ง
| คำสั่ง | หน้าที่ |
|---|---|
/opsx:propose | สร้างการเปลี่ยนแปลงและสร้าง artifact สำหรับการวางแผนในขั้นตอนเดียว (เส้นทางด่วนเริ่มต้น) |
/opsx:explore | คิดทบทวนไอเดีย ตรวจสอบปัญหา ชี้แจงข้อกำหนด |
/opsx:new | เริ่มโครงสร้างการเปลี่ยนแปลงใหม่ (เวิร์กโฟลว์ที่ขยาย) |
/opsx:continue | สร้าง artifact ถัดไป (เวิร์กโฟลว์ที่ขยาย) |
/opsx:ff | ข้ามขั้นตอน artifact สำหรับการวางแผน (เวิร์กโฟลว์ที่ขยาย) |
/opsx:apply | พัฒนางาน ปรับปรุง artifact ตามความจำเป็น |
/opsx:verify | ตรวจสอบการพัฒนาเทียบกับ artifact (เวิร์กโฟลว์ที่ขยาย) |
/opsx:sync | ซิงค์ delta specs ไปยัง main (เวิร์กโฟลว์ที่ขยาย, ทางเลือก) |
/opsx:archive | เก็บถาวรเมื่อเสร็จสิ้น |
/opsx:bulk-archive | เก็บถาวรการเปลี่ยนแปลงที่เสร็จสิ้นหลายรายการ (เวิร์กโฟลว์ที่ขยาย) |
/opsx:onboard | แนะนำขั้นตอนการเปลี่ยนแปลงแบบ end-to-end (เวิร์กโฟลว์ที่ขยาย) |
การใช้งาน
สำรวจไอเดีย
/opsx:exploreคิดทบทวนไอเดีย ตรวจสอบปัญหา เปรียบเทียบทางเลือก ไม่ต้องมีโครงสร้าง — แค่เป็นผู้ช่วยคิด เมื่อความคิดเห็นชัดเจนแล้ว ให้เปลี่ยนไปใช้ /opsx:propose (เริ่มต้น) หรือ /opsx:new//opsx:ff (ที่ขยาย)
เริ่มการเปลี่ยนแปลงใหม่
/opsx:proposeสร้างการเปลี่ยนแปลงและสร้าง artifact สำหรับการวางแผนที่จำเป็นก่อนการพัฒนา
หากคุณเปิดใช้งานเวิร์กโฟลว์ที่ขยายแล้ว คุณสามารถใช้:
text
/opsx:new # สร้างโครงสร้างเท่านั้น
/opsx:continue # สร้าง artifact ทีละรายการ
/opsx:ff # สร้าง artifact สำหรับการวางแผนทั้งหมดในครั้งเดียวสร้าง artifact
/opsx:continueแสดงสิ่งที่พร้อมจะสร้างตามความเชื่อมโยง จากนั้นสร้าง artifact หนึ่งรายการ ใช้ซ้ำเพื่อสร้างการเปลี่ยนแปลงของคุณทีละส่วน
/opsx:ff add-dark-modeสร้าง artifact สำหรับการวางแผนทั้งหมดในครั้งเดียว ใช้เมื่อคุณมีภาพชัดเจนว่าจะสร้างอะไร
พัฒนา (ส่วนที่ยืดหยุ่น)
/opsx:applyทำงานผ่านงานต่างๆ ตรวจสอบออกเมื่อทำเสร็จ หากคุณกำลังจัดการการเปลี่ยนแปลงหลายรายการ คุณสามารถรัน /opsx:apply <name>; มิฉะนั้นระบบจะอนุมานจากบทสนทนาและแจ้งให้คุณเลือกหากไม่สามารถระบุได้
เสร็จสิ้น
/opsx:archive # ย้ายไปเก็บถาวรเมื่อเสร็จสิ้น (จะแจ้งให้ซิงค์ specs หากจำเป็น)เมื่อใดควรอัปเดต vs. เริ่มใหม่
คุณสามารถแก้ไขข้อเสนอหรือ specs ได้เสมอ trướcการพัฒนา แต่เมื่อใดการปรับปรุงจะกลายเป็น "งานที่แตกต่าง"?
สิ่งที่ Proposal บันทึก
Proposal กำหนดสามสิ่ง:
- เจตนา — คุณกำลังแก้ปัญหาอะไร?
- ขอบเขต — อะไรอยู่ใน/นอกขอบเขต?
- วิธีการ — คุณจะแก้ไขอย่างไร?
คำถามคือ: สิ่งใดเปลี่ยนไป และเปลี่ยนมากน้อยเพียงใด?
อัปเดตการเปลี่ยนแปลงที่มีอยู่เมื่อ:
เจตนาเดียวกัน การดำเนินการปรับปรุง
- คุณพบกรณีขอบที่ไม่ได้พิจารณา
- วิธีการต้องปรับแต่งเล็กน้อยแต่เป้าหมายไม่เปลี่ยน
- การพัฒนาเปิดเผยว่าการออกแบบผิดพลาดเล็กน้อย
ขอบเขตแคบลง
- คุณตระหนักว่าขอบเขตเต็มมีขนาดใหญ่เกินไป ต้องการส่ง MVP ก่อน
- "เพิ่มโหมดมืด" → "เพิ่มสวิตช์โหมดมืด (ความต้องการระบบใน v2)"
การแก้ไขจากการเรียนรู้
- โครงสร้างโค้ดเบสไม่เป็นไปตามที่คุณคิด
- ความเชื่อมโยงไม่ทำงานตามที่คาดไว้
- "ใช้ CSS variables" → "ใช้ dark: prefix ของ Tailwind แทน"
เริ่มการเปลี่ยนแปลงใหม่เมื่อ:
เจตนาเปลี่ยนแปลงอย่างมีนัยสำคัญ
- ปัญหาเองตอนนี้แตกต่างกัน
- "เพิ่มโหมดมืด" → "เพิ่มระบบธีมที่ครอบคลุมพร้อมสี ฟอนต์ และระยะห่างที่กำหนดเอง"
ขอบเขตขยายใหญ่
- การเปลี่ยนแปลงเติบโตมากจนเป็นงานที่แตกต่างโดยพื้นฐาน
- ข้อเสนอเดิมจะไม่สามารถจำแนกได้หลังการอัปเดต
- "แก้ไขบั๊กล็อกอิน" → "เขียนระบบ auth ใหม่"
ต้นฉบับสามารถเสร็จสิ้นได้
- การเปลี่ยนแปลงเดิมสามารถทำเครื่องหมาย "เสร็จสิ้น"
- งานใหม่เป็นอิสระ ไม่ใช่การปรับปรุง
- เสร็จสิ้น "เพิ่ม MVP โหมดมืด" → เก็บถาวร → การเปลี่ยนแปลงใหม่ "ปรับปรุงโหมดมืด"
หลักเกณฑ์
┌─────────────────────────────────────┐
│ นี่เป็นงานเดียวกันหรือไม่? │
└──────────────┬──────────────────────┘
│
┌──────────────────┼──────────────────┐
│ │ │
▼ ▼ ▼
เจตนาเดียวกัน? >50% ทับซ้อน? ต้นฉบับสามารถ
ปัญหาเดียวกัน? ขอบเขตเดียวกัน? "เสร็จสิ้น" ได้โดย
│ │ ไม่มีการเปลี่ยนแปลง
│ │ เหล่านี้?
┌────────┴────────┐ ┌──────┴──────┐ ┌───────┴───────┐
│ │ │ │ │ │
ใช่ ไม่ ใช่ ไม่ ไม่ ใช่
│ │ │ │ │ │
▼ ▼ ▼ ▼ ▼ ▼
อัปเดต ใหม่ อัปเดต ใหม่ อัปเดต ใหม่| การทดสอบ | อัปเดต | การเปลี่ยนแปลงใหม่ |
|---|---|---|
| ตัวตน | "สิ่งเดียวกัน ปรับปรุง" | "งานที่แตกต่าง" |
| ขอบเขตทับซ้อน | >50% ทับซ้อน | <50% ทับซ้อน |
| การเสร็จสิ้น | ไม่สามารถ "เสร็จสิ้น" ได้โดยไม่มีการเปลี่ยนแปลง | สามารถเสร็จสิ้นต้นฉบับ งานใหม่เป็นอิสระ |
| เรื่องราว | สายการอัปเดตเล่าเรื่องราวที่สอดคล้องกัน | การแก้ไขจะทำให้สับสนมากกว่าชี้แจง |
หลักการ
การอัปเดตสงวนบริบท การเปลี่ยนแปลงใหม่ให้ความชัดเจน
เลือกอัปเดตเมื่อประวัติความคิดของคุณมีคุณค่า เลือกใหม่เมื่อการเริ่มต้นใหม่จะชัดเจนกว่าการแก้ไข
คิดว่ามันเหมือนกับ git branches:
- คอมมิตต่อไปเรื่อยๆ ขณะทำงานในฟีเจอร์เดียวกัน
- เริ่ม branch ใหม่เมื่อเป็นงานใหม่จริงๆ
- บางครั้ง merge ฟีเจอร์บางส่วนและเริ่มใหม่สำหรับเฟสที่ 2
มีอะไรเปลี่ยนไปบ้าง?
แบบเดิม (/openspec:proposal) | OPSX (/opsx:*) | |
|---|---|---|
| โครงสร้าง | เอกสารข้อเสนอฉบับเดียว | ชิ้นงานที่แยกจากกันพร้อมการเชื่อมโยง |
| ขั้นตอนการทำงาน | ขั้นตอนเชิงเส้น: วางแผน → ดำเนินการ → จัดเก็บ | การกระทำที่ยืดหยุ่น — ทำได้ทุกอย่างทุกเมื่อ |
| การวนซ้ำ | ย้อนกลับได้ยาก | อัปเดตชิ้นงานตามที่คุณเรียนรู้ |
| การปรับแต่ง | โครงสร้างที่ตายตัว | ขับเคลื่อนด้วย Schema (กำหนดชิ้นงานของคุณเอง) |
ข้อสังเกตสำคัญ: งานไม่ได้เป็นเส้นตรง OPSX หยุดแกล้งทำเป็นว่ามันเป็นเช่นนั้น
การวิเคราะห์สถาปัตยกรรมเชิงลึก
ส่วนนี้อธิบายวิธีการทำงานของ OPSX ภายใต้ hood และเปรียบเทียบกับเวิร์กโฟลว์แบบเดิม ตัวอย่างในส่วนนี้ใช้ชุดคำสั่งที่ขยาย (new, continue, ฯลฯ) ผู้ใช้ core แบบเริ่มต้นสามารถแมปขั้นตอนเดียวกันไปยัง propose → apply → archive
ปรัชญา: ขั้นตอน vs การกระทำ
┌─────────────────────────────────────────────────────────────────────────────┐
│ เวิร์กโฟลว์แบบเดิม │
│ (ล็อกขั้นตอน, ทั้งหมดหรือไม่มีเลย) │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
│ │ ขั้นตอน │ ───► │ ขั้นตอน │ ───► │ ขั้นตอน │ │
│ │ การวางแผน │ │ การดำเนินการ│ │ การจัดเก็บ │ │
│ └──────────────┘ └──────────────┘ └──────────────┘ │
│ │ │ │ │
│ ▼ ▼ ▼ │
│ /openspec:proposal /openspec:apply /openspec:archive │
│ │
│ • สร้างเอกสารทั้งหมดพร้อมกันในครั้งเดียว │
│ • ไม่สามารถย้อนกลับไปอัปเดตข้อกำหนดระหว่างการดำเนินการ │
│ • ประตูขั้นตอนบังคับให้ดำเนินไปแบบเส้นตรง │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────────────────────┐
│ เวิร์กโฟลว์ OPSX │
│ (การกระทำที่ลื่นไหล, แบบวนซ้ำ) │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ ┌────────────────────────────────────────────┐ │
│ │ การกระทำ (ไม่ใช่ขั้นตอน) │ │
│ │ │ │
│ │ new ◄──► continue ◄──► apply ◄──► archive │ │
│ │ │ │ │ │ │ │
│ │ └──────────┴───────────┴───────────┘ │ │
│ │ ลำดับใดก็ได้ │ │
│ └────────────────────────────────────────────┘ │
│ │
│ • สร้างเอกสารทีละรายการ หรือ ข้ามไปข้างหน้า │
│ • อัปเดตข้อกำหนด/การออกแบบ/งานระหว่างการดำเนินการ │
│ • ความขึ้นอยู่กับทำให้เกิดความคืบหน้า ไม่มีขั้นตอน │
│ │
└─────────────────────────────────────────────────────────────────────────────┘สถาปัตยกรรมส่วนประกอบ
เวิร์กโฟลว์แบบเดิม ใช้เทมเพลตที่ hardcode ไว้ใน TypeScript:
┌─────────────────────────────────────────────────────────────────────────────┐
│ ส่วนประกอบเวิร์กโฟลว์แบบเดิม │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ เทมเพลตที่ hardcode ไว้ (สตริง TypeScript) │
│ │ │
│ ▼ │
│ ตัวกำหนดค่า/อะแดปเตอร์เฉพาะเครื่องมือ │
│ │ │
│ ▼ │
│ ไฟล์คำสั่งที่สร้างขึ้น (.claude/commands/openspec/*.md) │
│ │
│ • โครงสร้างคงที่ ไม่รู้จักเอกสาร │
│ • การเปลี่ยนแปลงต้องแก้ไขโค้ด + สร้างใหม่ │
│ │
└─────────────────────────────────────────────────────────────────────────────┘OPSX ใช้สคีมาภายนอกและเครื่องยนต์กราฟความขึ้นอยู่กับ:
┌─────────────────────────────────────────────────────────────────────────────┐
│ ส่วนประกอบ OPSX │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ คำจำกัดความสคีมา (YAML) │
│ ┌─────────────────────────────────────────────────────────────────────┐ │
│ │ name: spec-driven │ │
│ │ artifacts: │ │
│ │ - id: proposal │ │
│ │ generates: proposal.md │ │
│ │ requires: [] ◄── ความขึ้นอยู่กับ │ │
│ │ - id: specs │ │
│ │ generates: specs/**/*.md ◄── รูปแบบ glob │ │
│ │ requires: [proposal] ◄── เปิดใช้งานหลังจาก proposal │ │
│ └─────────────────────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ เครื่องยนต์กราฟเอกสาร │
│ ┌─────────────────────────────────────────────────────────────────────┐ │
│ │ • การเรียงลำดับแบบเชิงอรรถ (การจัดเรียงตามความขึ้นอยู่กับ) │ │
│ │ • การตรวจจับสถานะ (การมีอยู่ในระบบไฟล์) │ │
│ │ • การสร้างคำแนะนำที่สมบูรณ์ (เทมเพลต + บริบท) │ │
│ └─────────────────────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ ไฟล์ทักษะ (.claude/skills/openspec-*/SKILL.md) │
│ │
│ • ใช้งานร่วมกับตัวแก้ไขหลายตัว (Claude Code, Cursor, Windsurf) │
│ • ทักษะสอบถาม CLI สำหรับข้อมูลแบบมีโครงสร้าง │
│ • ปรับแต่งได้เต็มที่ผ่านไฟล์สคีมา │
│ │
└─────────────────────────────────────────────────────────────────────────────┘แบบจำลองกราฟความขึ้นอยู่กับ
เอกสารก่อตัวเป็นกราฟไม่มีทิศทาง (DAG) ความขึ้นอยู่กับเป็น ตัวเปิดใช้งาน ไม่ใช่ประตู:
proposal
(โหนดราก)
│
┌─────────────┴─────────────┐
│ │
▼ ▼
specs design
(ต้องการ: (ต้องการ:
proposal) proposal)
│ │
└─────────────┬─────────────┘
│
▼
tasks
(ต้องการ:
specs, design)
│
▼
┌──────────────┐
│ ขั้นตอน APPLY │
│ (ต้องการ: │
│ tasks) │
└──────────────┘การเปลี่ยนสถานะ:
BLOCKED ────────────────► READY ────────────────► DONE
│ │ │
ไม่มี ความขึ้นอยู่กับทั้งหมด ไฟล์มีอยู่
ความขึ้นอยู่กับ เสร็จสิ้นแล้ว ในระบบไฟล์กระแสข้อมูล
เวิร์กโฟลว์แบบเดิม — เอเจนต์รับคำแนะนำแบบคงที่:
ผู้ใช้: "/openspec:proposal"
│
▼
┌─────────────────────────────────────────┐
│ คำแนะนำแบบคงที่: │
│ • สร้าง proposal.md │
│ • สร้าง tasks.md │
│ • สร้าง design.md │
│ • สร้าง specs/<capability>/spec.md │
│ │
│ ไม่รู้ว่ามีอะไรอยู่แล้วหรือ │
│ ความขึ้นอยู่กับระหว่างเอกสาร │
└─────────────────────────────────────────┘
│
▼
เอเจนต์สร้างเอกสารทั้งหมดในครั้งเดียวOPSX — เอเจนต์สอบถามเพื่อรับบริบทที่สมบูรณ์:
ผู้ใช้: "/opsx:continue"
│
▼
┌──────────────────────────────────────────────────────────────────────────┐
│ ขั้นตอน 1: สอบถามสถานะปัจจุบัน │
│ ┌────────────────────────────────────────────────────────────────────┐ │
│ │ $ openspec status --change "add-auth" --json │ │
│ │ │ │
│ │ { │ │
│ │ "artifacts": [ │ │
│ │ {"id": "proposal", "status": "done"}, │ │
│ │ {"id": "specs", "status": "ready"}, ◄── ตัวแรกที่พร้อม │ │
│ │ {"id": "design", "status": "ready"}, │ │
│ │ {"id": "tasks", "status": "blocked", "missingDeps": ["specs"]}│ │
│ │ ] │ │
│ │ } │ │
│ └────────────────────────────────────────────────────────────────────┘ │
│ │
│ ขั้นตอน 2: รับคำแนะนำที่สมบูรณ์สำหรับเอกสารที่พร้อม │
│ ┌────────────────────────────────────────────────────────────────────┐ │
│ │ $ openspec instructions specs --change "add-auth" --json │ │
│ │ │ │
│ │ { │ │
│ │ "template": "# Specification\n\n## ADDED Requirements...", │ │
│ │ "dependencies": [{"id": "proposal", "path": "...", "done": true}│ │
│ │ "unlocks": ["tasks"] │ │
│ │ } │ │
│ └────────────────────────────────────────────────────────────────────┘ │
│ │
│ ขั้นตอน 3: อ่านความขึ้นอยู่กับ → สร้างเอกสารหนึ่งรายการ → แสดงสิ่งที่ถูกปลดล็อก │
└──────────────────────────────────────────────────────────────────────────┘แบบจำลองการวนซ้ำ
เวิร์กโฟลว์แบบเดิม — การวนซ้ำทำได้ยาก:
┌─────────┐ ┌─────────┐ ┌─────────┐
│/proposal│ ──► │ /apply │ ──► │/archive │
└─────────┘ └─────────┘ └─────────┘
│ │
│ ├── "เดี๋ยว การออกแบบผิด"
│ │
│ ├── ตัวเลือก:
│ │ • แก้ไขไฟล์ด้วยตนเอง (ทำลายบริบท)
│ │ • ละทิ้งและเริ่มใหม่
│ │ • ดำเนินการต่อและแก้ไขภายหลัง
│ │
│ └── ไม่มีกลไก "ย้อนกลับ" อย่างเป็นทางการ
│
└── สร้างเอกสารทั้งหมดพร้อมกันOPSX — การวนซ้ำเป็นธรรมชาติ:
/opsx:new ───► /opsx:continue ───► /opsx:apply ───► /opsx:archive
│ │ │
│ │ ├── "การออกแบบผิด"
│ │ │
│ │ ▼
│ │ แค่แก้ไข design.md
│ │ แล้วดำเนินการต่อ!
│ │ │
│ │ ▼
│ │ /opsx:apply รับช่วงต่อ
│ │ จากจุดที่คุณหยุดไว้
│ │
│ └── สร้างเอกสารหนึ่งรายการ แสดงสิ่งที่ถูกปลดล็อก
│
└── สร้างโครงร่างการเปลี่ยนแปลง รอคำแนะนำสคีมาที่กำหนดเอง
สร้างเวิร์กโฟลว์ที่กำหนดเองโดยใช้คำสั่งการจัดการสคีมา:
bash
# สร้างสคีมาใหม่ตั้งแต่ต้น (แบบโต้ตอบ)
openspec schema init my-workflow
# หรือ fork สคีมาที่มีอยู่เป็นจุดเริ่มต้น
openspec schema fork spec-driven my-workflow
# ตรวจสอบโครงสร้างสคีมาของคุณ
openspec schema validate my-workflow
# ดูว่าสคีมาถูกแก้ไขจากที่ไหน (มีประโยชน์สำหรับการแก้ไขปัญหา)
openspec schema which my-workflowสคีมาถูกเก็บไว้ใน openspec/schemas/ (เฉพาะโปรเจกต์, ควบคุมเวอร์ชัน) หรือ ~/.local/share/openspec/schemas/ (ทั่วโลกสำหรับผู้ใช้)
โครงสร้างสคีมา:
openspec/schemas/research-first/
├── schema.yaml
└── templates/
├── research.md
├── proposal.md
└── tasks.mdตัวอย่าง schema.yaml:
yaml
name: research-first
artifacts:
- id: research # เพิ่มก่อน proposal
generates: research.md
requires: []
- id: proposal
generates: proposal.md
requires: [research] # ตอนนี้ขึ้นอยู่กับ research
- id: tasks
generates: tasks.md
requires: [proposal]กราฟความขึ้นอยู่กับ:
research ──► proposal ──► tasksสรุป
| แง่มุม | แบบเดิม | OPSX |
|---|---|---|
| เทมเพลต | TypeScript ที่ hardcode ไว้ | YAML + Markdown ภายนอก |
| ความขึ้นอยู่กับ | ไม่มี (ทั้งหมดพร้อมกัน) | DAG พร้อมการเรียงลำดับเชิงอรรถ |
| สถานะ | แบบจำลองจิตใจที่อิงขั้นตอน | การมีอยู่ในระบบไฟล์ |
| การปรับแต่ง | แก้ไขซอร์ส, สร้างใหม่ | สร้าง schema.yaml |
| การวนซ้ำ | ล็อกขั้นตอน | ลื่นไหล, แก้ไขอะไรก็ได้ |
| การรองรับตัวแก้ไข | ตัวกำหนดค่า/อะแดปเตอร์เฉพาะเครื่องมือ | ไดเรกทอรีทักษะเดียว |
สคีมา
สคีมาจะกำหนดว่ามีชิ้นงานใดบ้างและความเชื่อมโยงระหว่างกัน ปัจจุบันมีสคีมาที่พร้อมใช้งานดังนี้:
- spec-driven (ค่าเริ่มต้น): proposal → specs → design → tasks
bash
# แสดงรายการสคีมาที่มีอยู่
openspec schemas
# แสดงสคีมาทั้งหมดพร้อมแหล่งที่มาของการตัดสินใจ
openspec schema which --all
# สร้างสคีมาใหม่แบบโต้ตอบ
openspec schema init my-workflow
# คัดลอกสคีมาที่มีอยู่เพื่อปรับแต่ง
openspec schema fork spec-driven my-workflow
# ตรวจสอบโครงสร้างสคีมาก่อนใช้งาน
openspec schema validate my-workflowเคล็ดลับ
- ใช้
/opsx:exploreเพื่อพิจารณาแนวคิดก่อนตัดสินใจเปลี่ยนแปลง - ใช้
/opsx:ffเมื่อคุณรู้แล้วว่าต้องการอะไร หรือ/opsx:continueเมื่อยังกำลังสำรวจ - ระหว่าง
/opsx:applyหากมีบางอย่างไม่ถูกต้อง — แก้ไขชิ้นงานก่อน แล้วจึงดำเนินการต่อ - งานจะติดตามความคืบหน้าผ่านช่องทำเครื่องหมายใน
tasks.md - ตรวจสอบสถานะได้ตลอดเวลา:
openspec status --change "name"
ข้อเสนอแนะ
ส่วนนี้ยังอยู่ในขั้นต้น ซึ่งเป็นเจตนา — เรากำลังเรียนรู้ว่าสิ่งใดใช้ได้ผล
พบข้อผิดพลาด? มีความคิดเห็น? เข้าร่วมกับเราบน Discord หรือเปิด issue บน GitHub