เวิร์กโฟลว์ OPSX
ยินดีรับฟีดแบ็กบน Discord.
คืออะไร?
OPSX ได้กลายเป็นเวิร์กโฟลว์มาตรฐานสำหรับ OpenSpec ในขณะนี้
มันคือเวิร์กโฟลว์ที่ยืดหยุ่นและเป็นวงรอบสำหรับการเปลี่ยนแปลงของ OpenSpec ไม่มีขั้นตอนที่เข้มงวดอีกต่อไป — เพียงแค่การดำเนินการที่คุณสามารถทำได้ทุกเมื่อ
เหตุผลที่สิ่งนี้ถูกสร้างขึ้นมา
เวิร์กโฟลว์ OpenSpec รุ่นเก่าใช้งานได้ แต่ถูก ล็อคไว้อย่างเข้มงวด:
- คำสั่งถูกฮาร์ดโค้ด — ซ่อนอยู่ในโค้ด TypeScript ไม่สามารถแก้ไขได้
- แบบทั้งหมดหรือไม่ก็ไม่มีเลย — คำสั่งเดียวสร้างทุกอย่าง ไม่สามารถทดสอบแต่ละส่วนได้แยกกัน
- โครงสร้างตายตัว — เวิร์กโฟลว์เหมือนกันสำหรับทุกคน ไม่สามารถปรับแต่งได้
- กล่องดำ — เมื่อผลลัพธ์จาก AI ไม่ดี ไม่สามารถปรับแต่ง prompt ได้
OPSX ปลดล็อกสิ่งนี้ให้ใช้งานได้อย่างอิสระ ตอนนี้ใครก็สามารถ:
- ทดลองกับคำสั่ง — แก้ไขเทมเพลต ดูว่า AI จะทำงานได้ดีขึ้นหรือไม่
- ทดสอบแบบละเอียดยิบ — ตรวจสอบคำสั่งของแต่ละอาร์ติแฟกต์แยกกันอิสระจากกัน
- ปรับแต่งเวิร์กโฟลว์ตามต้องการ — กำหนดอาร์ติแฟกต์และ dependencies ของคุณเอง
- วนซ้ำอย่างรวดเร็ว — เปลี่ยนเทมเพลต ทดสอบทันที ไม่ต้อง Build ใหม่
Legacy workflow: OPSX:
┌────────────────────────┐ ┌────────────────────────┐
│ ฮาร์ดโค้ดอยู่ในแพคเกจ │ │ schema.yaml │◄── คุณแก้ไขส่วนนี้
│ (ไม่สามารถแก้ไขได้) │ │ templates/*.md │◄── หรือส่วนนี้
│ ↓ │ │ ↓ │
│ รอการอัปเดตเวอร์ชันใหม่ │ │ เกิดผลทันที │
│ ↓ │ │ ↓ │
│ หวังว่าจะดีขึ้น │ │ ทดสอบด้วยตัวเอง │
└────────────────────────┘ └────────────────────────┘สิ่งนี้สร้างขึ้นสำหรับทุกคน:
- ทีม — สร้างเวิร์กโฟลว์ที่ตรงกับวิธีการทำงานจริงของคุณ
- ผู้ใช้ขั้นสูง — ปรับแต่ง prompt เพื่อรับผลลัพธ์จาก AI ที่ดีขึ้นสำหรับโค้ดเบสของคุณ
- ผู้มีส่วนร่วมใน OpenSpec — ทดลองใช้วิธีการใหม่โดยไม่ต้องรอการอัปเดตเวอร์ชันใหม่
เราทุกคนยังคงเรียนรู้ว่าสิ่งใดทำงานได้ดีที่สุด OPSX ช่วยให้เราสามารถเรียนรู้ร่วมกันได้
ประสบการณ์ของผู้ใช้
ปัญหาของเวิร์กโฟลว์แบบเส้นตรง: คุณจะ "อยู่ในขั้นตอนวางแผน" จากนั้น "อยู่ในขั้นตอนการพัฒนา" และ "เสร็จสิ้น" แต่งานจริงไม่ได้ทำงานในลักษณะนี้ คุณพัฒนาบางสิ่งแล้วรู้ว่าออกแบบผิด ต้องอัปเดตสเปค แล้วดำเนินการพัฒนาต่อ ขั้นตอนแบบเส้นตรงขัดขืนกับวิธีการทำงานจริงของงาน
แนวทางของ OPSX:
- เป็นการกระทำ ไม่ใช่ขั้นตอน — สร้าง, พัฒนา, อัปเดต, เก็บถาวร — ทำสิ่งใดๆ เหล่านี้ได้ทุกเมื่อ
- Dependencies เป็นตัวช่วยเปิดโอกาส — แสดงว่าสิ่งใดเป็นไปได้ ไม่ใช่สิ่งที่จำเป็นต้องทำต่อไป
proposal ──→ specs ──→ design ──→ tasks ──→ implementการติดตั้ง
bash
# ตรวจสอบให้แน่ใจว่าคุณได้ติดตั้ง openspec แล้ว — สกิลจะถูกสร้างขึ้นโดยอัตโนมัติ
openspec initสิ่งนี้จะสร้างสกิลใน .claude/skills/ (หรือตำแหน่งที่เทียบเท่า) ที่ผู้ช่วยเขียนโค้ด AI สามารถตรวจพบโดยอัตโนมัติ
โดยค่าเริ่มต้น OpenSpec จะใช้โปรไฟล์เวิร์กโฟลว์ core (propose, explore, apply, sync, archive) หากคุณต้องการคำสั่งเวิร์กโฟลว์แบบขยาย (new, continue, ff, verify, bulk-archive, onboard) ให้กำหนดค่าด้วย openspec config profile และนำไปใช้ด้วย openspec update
ระหว่างการติดตั้ง ระบบจะแจ้งให้คุณสร้าง คอนฟิกโปรเจกต์ (openspec/config.yaml) สิ่งนี้เป็นตัวเลือกแต่แนะนำให้ใช้
การตั้งค่าโปรเจกต์
คอนฟิกโปรเจกต์ช่วยให้คุณตั้งค่าเริ่มต้นและใส่บริบทเฉพาะของโปรเจกต์ลงในอาร์ติแฟกต์ทั้งหมดได้
การสร้างคอนฟิก
คอนฟิกจะถูกสร้างขึ้นระหว่าง openspec init หรือสร้างด้วยตนเอง:
yaml
# openspec/config.yaml
schema: spec-driven
context: |
สแต็กเทคโนโลยี: TypeScript, React, Node.js
สมมติฐาน API: RESTful, การตอบกลับ JSON
การทดสอบ: Vitest สำหรับ unit tests, Playwright สำหรับ e2e
สไตล์โค้ด: ESLint ร่วมกับ Prettier, TypeScript แบบเคร่งครัด
rules:
proposal:
- รวมแผน rollback
- ระบุทีมที่ได้รับผลกระทบ
specs:
- ใช้รูปแบบ Given/When/Then สำหรับสถานการณ์
design:
- รวม sequence diagrams สำหรับฟลว์ที่ซับซ้อนฟิลด์ของคอนฟิก
| ฟิลด์ | ชนิดข้อมูล | คำอธิบาย |
|---|---|---|
schema | string | สคีมาเริ่มต้นสำหรับการเปลี่ยนแปลงใหม่ (เช่น spec-driven) |
context | string | บริบทของโปรเจกต์ที่ใส่เข้าไปในคำสั่งของอาร์ติแฟกต์ทั้งหมด |
rules | object | กฎสำหรับแต่ละอาร์ติแฟกต์ ใช้ ID ของอาร์ติแฟกต์เป็นคีย์ |
วิธีการทำงาน
ลำดับความสำคัญของสคีมา (จากสูงไปต่ำ):
- ธง CLI (
--schema <name>) - เมตาดาต้าของการเปลี่ยนแปลง (
.openspec.yamlในไดเร็กทอรีของการเปลี่ยนแปลง) - คอนฟิกโปรเจกต์ (
openspec/config.yaml) - ค่าเริ่มต้น (
spec-driven)
การใส่บริบทเข้าไป:
- บริบทจะถูกนำมาวางไว้หน้าคำสั่งของอาร์ติแฟกต์ทุกอัน
- ห่อหุ้มด้วยแท็ก
<context>...</context> - ช่วยให้ AI เข้าใจกฎเกณฑ์ของโปรเจกต์ของคุณ
การใส่กฎเข้าไป:
- กฎจะถูกใส่เข้าไปเฉพาะสำหรับอาร์ติแฟกต์ที่ตรงกันเท่านั้น
- ห่อหุ้มด้วยแท็ก
<rules>...</rules> - ปรากฏอยู่หลังบริบท และก่อนเทมเพลต
ID ของอาร์ติแฟกต์ตามสคีมา
spec-driven (ค่าเริ่มต้น):
proposal— ข้อเสนอการเปลี่ยนแปลงspecs— สเปคdesign— ออกแบบเทคนิคtasks— งานที่ต้องพัฒนา
การตรวจสอบความถูกต้องของคอนฟิก
- ID ของอาร์ติแฟกต์ที่ไม่รู้จักใน
rulesจะสร้างคำเตือน - ชื่อสคีมาจะถูกตรวจสอบกับสคีมาที่มีอยู่
- บริบทมีขีดจำกัดขนาด 50KB
- YAML ที่ไม่ถูกต้องจะถูกรายงานพร้อมกับเลขบรรทัด
การแก้ไขปัญหา
"ID ของอาร์ติแฟกต์ที่ไม่รู้จักใน rules: X"
- ตรวจสอบว่า ID ของอาร์ติแฟกต์ตรงกับสคีมาของคุณ (ดูรายการด้านบน)
- รัน
openspec schemas --jsonเพื่อดู ID ของอาร์ติแฟกต์สำหรับแต่ละสคีมา
คอนฟิกไม่ถูกนำไปใช้:
- ตรวจสอบให้แน่ใจว่าไฟล์อยู่ที่
openspec/config.yaml(ไม่ใช่.yml) - ตรวจสอบไวยากรณ์ YAML ด้วยเครื่องมือตรวจสอบ
- การเปลี่ยนแปลงคอนฟิกจะมีผลทันที (ไม่ต้องรีสตาร์ทโปรแกรม)
บริบทมีขนาดใหญ่เกินไป:
- บริบทมีขีดจำกัดขนาด 50KB
- สรุปหรือลิงก์ไปยังเอกสารภายนอกแทน
คำสั่ง
| คำสั่ง | หน้าที่ |
|---|---|
/opsx:propose | สร้างการเปลี่ยนแปลงและสร้างอาร์ติแฟกต์วางแผนในขั้นตอนเดียว (เส้นทางด่วนเริ่มต้น) |
/opsx:explore | คิดไอเดีย ตรวจสอบปัญหา ชี้แจงข้อกำหนด |
/opsx:new | เริ่มสร้างโครงสร้างการเปลี่ยนแปลงใหม่ (เวิร์กโฟลว์แบบขยาย) |
/opsx:continue | สร้างอาร์ติแฟกต์ถัดไป (เวิร์กโฟลว์แบบขยาย) |
/opsx:ff | กระโดดไปสร้างอาร์ติแฟกต์วางแผนทั้งหมดทันที (เวิร์กโฟลว์แบบขยาย) |
/opsx:apply | พัฒนางานที่กำหนด อัปเดตอาร์ติแฟกต์ตามความจำเป็น |
/opsx:update | แก้ไขอาร์ติแฟกต์วางแผนของการเปลี่ยนแปลงและรักษาความสอดคล้องกัน |
/opsx:verify | ตรวจสอบความถูกต้องของการพัฒนาต่อกับอาร์ติแฟกต์ (เวิร์กโฟลว์แบบขยาย) |
/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สร้างการเปลี่ยนแปลงและสร้างอาร์ติแฟกต์วางแผนที่จำเป็นก่อนการพัฒนา
หากคุณเปิดใช้งานเวิร์กโฟลว์แบบขยายแล้ว คุณสามารถใช้คำสั่งต่อไปนี้แทน:
text
/opsx:new # สร้างโครงสร้างเท่านั้น
/opsx:continue # สร้างอาร์ติแฟกต์ทีละอัน
/opsx:ff # สร้างอาร์ติแฟกต์วางแผนทั้งหมดทันทีสร้างอาร์ติแฟกต์
/opsx:continueแสดงสิ่งที่พร้อมสร้างตาม dependencies แล้วสร้างอาร์ติแฟกต์หนึ่งอัน ใช้ซ้ำเพื่อสร้างการเปลี่ยนแปลงของคุณเพิ่มขึ้นทีละน้อย
/opsx:ff add-dark-modeสร้างอาร์ติแฟกต์วางแผนทั้งหมดทันที ใช้เมื่อคุณมีความเข้าใจชัดเจนว่าคุณกำลังสร้างอะไร
พัฒนา (ส่วนที่ยืดหยุ่นได้)
/opsx:applyดำเนินการผ่านงานที่กำหนด ทำเครื่องหมายว่าเสร็จสิ้นเมื่อทำไปถึง หากคุณกำลังจัดการกับการเปลี่ยนแปลงหลายรายการ คุณสามารถรัน /opsx:apply <name> ได้ มิฉะนั้นระบบจะคาดเดาจากบทสนทนาและถามให้คุณเลือกหากไม่สามารถทราบได้
การอัปเดตการเปลี่ยนแปลง
/opsx:update add-dark-mode - ตอนนี้เราจะเก็บธีมในคุกกี้แก้ไขอาร์ติแฟกต์วางแผนที่มีอยู่ของการเปลี่ยนแปลงและรักษาความสอดคล้องกัน - ในทิศทางใดๆ (การแก้ไขออกแบบอาจส่งผลกระทบกลับไปยังข้อเสนอ) เฉพาะอาร์ติแฟกต์วางแผนเท่านั้น: มันไม่เคยแก้ไขโค้ด และไม่เคยสร้างอาร์ติแฟกต์ที่หายไป (นั้นคือหน้าที่ของ /opsx:continue) การแก้ไขทุกครั้งจะได้รับการยืนยันจากคุณก่อน หากการเปลี่ยนแปลงนั้นได้รับการพัฒนาแล้ว ระบบจะแนะนำให้ใช้ /opsx:apply เพื่อให้โค้ดตามแผนที่แก้ไขใหม่ได้ หากการแก้ไขของคุณเปลี่ยน จุดประสงค์ ของการเปลี่ยนแปลง ให้เริ่มใหม่แทน - ดู เมื่อใดควรอัปเดตและเมื่อใดควรเริ่มใหม่
สิ้นสุดการทำงาน
/opsx:archive # ย้ายไปเก็บถาวรเมื่อเสร็จสิ้น (จะแจ้งให้ซิงค์สเปคหากจำเป็น)เมื่อใดควรอัปเดตและเมื่อใดควรเริ่มใหม่
คุณสามารถแก้ไขข้อเสนอหรือสเปคของคุณได้ตลอดก่อนการพัฒนา แต่เมื่อไหร่ที่การปรับแต่งกลายเป็น "นี่เป็นงานที่แตกต่างกัน"?
ข้อเสนอจะบันทึกสิ่งใดไว้
ข้อเสนอกำหนดสิ่งสามอย่าง:
- จุดประสงค์ — ปัญหาอะไรที่คุณกำลังแก้ไข?
- ขอบเขต — สิ่งใดอยู่ในขอบเขต/นอกขอบเขต?
- แนวทาง — คุณจะแก้ไขปัญหาด้วยวิธีใด?
คำถามคือ: สิ่งใดเปลี่ยนแปลง และเปลี่ยนแปลงมากน้อยเพียงใด?
อัปเดตการเปลี่ยนแปลงที่มีอยู่เมื่อ:
จุดประสงค์เหมือนเดิม การดำเนินการที่ปรับปรุงแล้ว
- คุณพบกับกรณีพิเศษที่คุณไม่เคยคิดไว้
- แนวทางต้องการปรับแต่งเล็กน้อย แต่เป้าหมายไม่เปลี่ยนแปลง
- การพัฒนาชี้ให้เห็นว่าออกแบบผิดเล็กน้อย
ขอบเขตแคบลง
- คุณรู้ว่าขอบเขตเต็มใหญ่เกินไป ต้องการส่ง MVP ก่อน
- "Add dark mode" → "Add dark mode toggle (system preference in v2)"
- การเรียนรู้จากประสบการณ์ทำให้ต้องแก้ไข
- โครงสร้างโค้ดเบสไม่เหมือนกับที่คุณคิดไว้
- dependency ทำงานไม่เหมือนที่คาดหวัง
- "Use CSS variables" → "Use Tailwind's dark: prefix instead"
เริ่มสร้างการเปลี่ยนแปลงใหม่เมื่อ:
จุดประสงค์เปลี่ยนแปลงพื้นฐานแล้ว
- ปัญหาตัวเองก็เปลี่ยนแปลงไปแล้ว
- "Add dark mode" → "Add comprehensive theme system with custom colors, fonts, spacing"
ขอบเขตเพิ่มขึ้นอย่างมาก
- การเปลี่ยนแปลงเพิ่มขึ้นมากจนเป็นงานที่แตกต่างกันแท้จริง
- ข้อเสนอเดิมจะไม่สามารถรู้จักได้หลังจากการอัปเดต
- "Fix login bug" → "Rewrite auth system"
รายการเดิมสามารถเสร็จสิ้นได้
- การเปลี่ยนแปลงเดิมสามารถทำเครื่องหมายว่า "เสร็จสิ้น" ได้
- งานใหม่เป็นรายการ standalone ไม่ใช่การปรับแต่งเพิ่มเติม
- เสร็จสิ้น "Add dark mode MVP" → เก็บถาวร → สร้างการเปลี่ยนแปลงใหม่ "ปรับปรุงโหมดมืด"
หลักการประมาณการ
┌─────────────────────────────────────┐
│ นี่เป็นงานเดียวกันหรือไม่? │
└──────────────┬──────────────────────┘
│
┌──────────────────┼──────────────────┐
│ │ │
▼ ▼ ▼
จุดประสงค์เหมือนกัน? ซ้อนทับกัน >50%? การเปลี่ยนแปลงเดิม
ปัญหาเหมือนกัน? ขอบเขตเหมือนกัน? สามารถ "เสร็จสิ้น" ได้
│ │ โดยไม่มีการเปลี่ยนแปลงเหล่านี้?
│ │ │
┌────────┴────────┐ ┌──────┴──────┐ ┌───────┴───────┐
│ │ │ │ │ │
ใช่ ไม่ ใช่ ไม่ ไม่ ใช่
│ │ │ │ │ │
▼ ▼ ▼ ▼ ▼ ▼
อัปเดต ใหม่ อัปเดต ใหม่ อัปเดต ใหม่| การทดสอบ | อัปเดต | การเปลี่ยนแปลงใหม่ |
|---|---|---|
| เอกลักษณ์ | "สิ่งเดียวกัน แก้ไขปรับปรุง" | "งานที่แตกต่างกัน" |
| การซ้อนทับของขอบเขต | ซ้อนทับกัน >50% | ซ้อนทับกัน <50% |
| ความสมบูรณ์ | ไม่สามารถ "เสร็จสิ้น" ได้โดยไม่มีการเปลี่ยนแปลง | สามารถเสร็จสิ้นรายการเดิม งานใหม่เป็นรายการ standalone |
| เรื่องราว | เชนการอัปเดตเล่าเรื่องราวที่สอดคล้องกัน | การแก้ไขแบบกระตุกจะทำให้สับสนมากกว่าความเข้าใจ |
หลักการ
การอัปเดตจะรักษาบริบทไว้ การเปลี่ยนแปลงใหม่จะให้ความชัดเจน
เลือกการอัปเดตเมื่อประวัติความคิดของคุณมีค่า เลือกการสร้างใหม่เมื่อเริ่มใหม่จะชัดเจนกว่าการแก้ไขแบบกระตุก
คิดเหมือนกับ git branches:
- ทำการ commit ต่อเนื่องขณะที่กำลังทำงานกับฟีเจอร์เดียวกัน
- สร้าง branch ใหม่เมื่อเป็นงานที่แตกต่างจริง
- บางครั้งรวมฟีเจอร์ที่ยังไม่เสร็จและเริ่มใหม่สำหรับเฟส 2
สิ่งที่แตกต่างกัน?
เวิร์กโฟลว์รุ่นเก่า (/openspec:proposal) | OPSX (/opsx:*) | |
|---|---|---|
| โครงสร้าง | เอกสารข้อเสนอขนาดใหญ่เดียว | อาร์ติแฟกต์แยกกันพร้อม dependencies |
| เวิร์กโฟลว์ | ขั้นตอนแบบเส้นตรง: วางแผน → พัฒนา → เก็บถาวร | การกระทำแบบยืดหยุ่น — ทำสิ่งใดๆ ได้ทุกเมื่อ |
| การวนซ้ำ | ยากที่จะกลับไปแก้ไขก่อนหน้า | อัปเดตอาร์ติแฟกต์เมื่อคุณเรียนรู้เพิ่มเติม |
| การปรับแต่ง | โครงสร้างตายตัว | กำหนดโดยสคีมา (กำหนดอาร์ติแฟกต์ของคุณเองได้) |
ข้อความสำคัญ: งานไม่ได้เป็นแบบเส้นตรง OPSX หยุดทำเหมือนว่าเป็นแบบเส้นตรง
การเจาะลึกสถาปัตยกรรม
ส่วนนี้อธิบายว่า OPSX ทำงานอย่างไรภายในระบบและเปรียบเทียบกับเวิร์กโฟลว์เดิมอย่างไร ตัวอย่างในส่วนนี้ใช้ชุดคำสั่งเพิ่มเติม (new, continue, ฯลฯ); ผู้ใช้ core เริ่มต้นสามารถแมปโฟลว์เดียวกันไปยัง propose → apply → sync → archive ได้
ปรัชญา: ขั้นตอน (Phases) กับการดำเนินการ (Actions)
┌─────────────────────────────────────────────────────────────────────────────┐
│ เวิร์กโฟลว์เดิม (LEGACY) │
│ (ล็อกตามเฟส, ทั้งหมดหรือไม่มีอะไรเลย) │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
│ │ เฟสการวางแผน │ ───► │ เฟสการพัฒนา │ ───► │ เฟสการจัดเก็บ │ │
│ │ (PHASE) │ │ (PHASE) │ │ (PHASE) │ │
│ └──────────────┘ └──────────────┘ └──────────────┘ │
│ │ │ │ │
│ ▼ ▼ ▼ │
│ /openspec:proposal /openspec:apply /openspec:archive │
│ │
│ • สร้างอาร์ติแฟกต์ทั้งหมดในครั้งเดียว │
│ • ไม่สามารถย้อนกลับไปอัปเดตสเปคระหว่างการพัฒนาได้ │
│ • ประตูเฟสบังคับให้มีการดำเนินการเชิงเส้น │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────────────────────┐
│ เวิร์กโฟลว์ OPSX │
│ (การดำเนินการที่ยืดหยุ่น, การทำซ้ำ) │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ ┌────────────────────────────────────────────┐ │
│ │ การดำเนินการ (ไม่ใช่เฟส) │ │
│ │ │ │
│ │ new ◄──► continue ◄──► apply ◄──► archive │ │
│ │ │ │ │ │ │ │
│ │ └──────────┴───────────┴───────────┘ │ │
│ │ ลำดับใดก็ได้ │ │
│ └────────────────────────────────────────────┘ │
│ │
│ • สร้างอาร์ติแฟกต์ทีละรายการ หรือ ก้าวหน้าอย่างรวดเร็ว │
│ • อัปเดตสเปค/การออกแบบ/งานระหว่างการพัฒนา │
│ • การพึ่งพาช่วยให้ดำเนินการไปได้ ไม่มีเฟสที่ต้องมีอยู่จริง │
│ │
└─────────────────────────────────────────────────────────────────────────────┘สถาปัตยกรรมของคอมโพเนนต์
เวิร์กโฟลว์เดิม (Legacy) ใช้เทมเพลตที่ฮาร์ดโค้ดไว้ใน TypeScript:
┌─────────────────────────────────────────────────────────────────────────────┐
│ คอมโพเนนต์ของเวิร์กโฟลว์เดิม │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ เทมเพลตฮาร์ดโค้ด (สตริง 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)
│
▼
┌──────────────┐
│ เฟสการประยุกต์ใช้│
│ (ต้องพึ่งพา: │
│ tasks) │
└──────────────┘การเปลี่ยนผ่านสถานะ:
ถูกบล็อก (BLOCKED) ──────────────► พร้อม (READY) ──────────────► เสร็จสิ้น (DONE)
│ │ │
การพึ่งพาหายไป การพึ่งพาทั้งหมด ไฟล์มีอยู่บน
เป็น DONE ระบบไฟล์การไหลของข้อมูล
เวิร์กโฟลว์เดิม (Legacy) — เอเจนต์รับคำแนะนำแบบคงที่:
ผู้ใช้: "/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: อ่านการพึ่งพา → สร้างอาร์ติแฟกต์หนึ่งรายการ → แสดงสิ่งที่ปลดล็อก │
└──────────────────────────────────────────────────────────────────────────┘โมเดลการทำซ้ำ
เวิร์กโฟลว์เดิม (Legacy) — การทำซ้ำค่อนข้างยุ่งยาก:
┌─────────┐ ┌─────────┐ ┌─────────┐
│/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 ฮาร์ดโค้ด | YAML + Markdown ภายนอก |
| ความ 의 의존 | ไม่มี (สร้างทั้งหมดพร้อมกัน) | DAG พร้อมการเรียงลำดับตามท็อปอล็อจี |
| สถานะ | โมเดลจิตใจแบบใช้เฟสเป็นฐาน | การอยู่ของไฟล์ในระบบไฟล์ |
| การปรับแต่ง | แก้ไขซอร์สโค้ด, สรสร้างใหม่ | สร้าง schema.yaml |
| การวนซ้ำ | ล็อกตามเฟส | ยืดหยุ่น, แก้ไขอะไรก็ได้ |
| การสนับสนุนโปรแกรมแก้ไข | คอนฟิกเกอร์/อะแดปเตอร์เฉพาะเครื่องมือ | ไดเร็กทอรีสกิลเดียว |
สคีม
สคีมกำหนดว่าอาร์ติแฟกต์ใดบ้างที่มีอยู่และมีความ 의 의존อย่างไร ปัจจุบันมีให้ใช้ดังนี้:
- spec-driven (ค่าเริ่มต้น): proposal → specs → design → tasks
bash
# แสดงสคีมที่มีอยู่ทั้งหมด
openspec schemas
# ดูสคีมทั้งหมดพร้อมแหล่งที่มาของการโหลด
openspec schema which --all
# สร้างสคีมใหม่แบบโต้ตอบ
openspec schema init my-workflow
# fork สคีมที่มีอยู่เพื่อปรับแต่ง
openspec schema fork spec-driven my-workflow
# ตรวจสอบโครงสร้างสคีมก่อนใช้งาน
openspec schema validate my-workflowเคล็ดลับ
- ใช้
/opsx:exploreเพื่อคิดไอเดียให้ชัดก่อนที่จะ commit การเปลี่ยนแปลง - ใช้
/opsx:ffเมื่อคุณรู้ว่าต้องการอะไร, ใช้/opsx:continueเมื่อกำลังสำรวจ - ระหว่างใช้
/opsx:apply, หากมีสิ่งผิดปกติ — แก้ไขอาร์ติแฟกต์นั้น จากนั้นดำเนินการต่อ - Tasks ติดตามความคืบหน้าโดยใช้เช็คบ็อกซ์ใน
tasks.md - ตรวจสอบสถานะได้ตลอดเวลา:
openspec status --change "name"
ข้อเสนอแนะ
นี่ยังเป็นเวอร์ชันเบื้องต้น ซึ่งเป็นเรื่องเจตนา — เราเรียนรู้ว่าสิ่งใดที่ทำงานได้ดี
พบข้อผิดพลาด? มีไอเดีย? เข้าร่วมกับเราบน Discord หรือเปิด issue บน GitHub.