เวิร์กโฟลว์ OPSX
ยินดีรับฟีดแบ็กบน Discord
มันคืออะไร?
OPSX ปัจจุบันเป็นเวิร์กโฟลว์มาตรฐานสำหรับ OpenSpec
มันคือ เวิร์กโฟลว์ที่ยืดหยุ่นและวนซ้ำ สำหรับการเปลี่ยนแปลง OpenSpec ไม่มีขั้นตอนที่เข้มงวดอีกต่อไป — มีเพียงการกระทำที่คุณสามารถทำได้ทุกเมื่อ
เหตุผลที่มีอยู่
ขั้นตอนการทำงาน OpenSpec แบบเดิมใช้งานได้ แต่มันถูก ล็อกตาย:
- คำสั่งถูกฝังไว้ — ฝังอยู่ใน TypeScript คุณไม่สามารถเปลี่ยนแปลงมันได้
- ทั้งหมดหรือไม่มีอะไร — คำสั่งใหญ่คำสั่งเดียวสร้างทุกอย่าง ไม่สามารถทดสอบแต่ละส่วนแยกกันได้
- โครงสร้างคงที่ — ขั้นตอนเดียวกันสำหรับทุกคน ไม่มีการปรับแต่ง
- กล่องดำ — เมื่อผลลัพธ์ AI ไม่ดี คุณไม่สามารถปรับแต่ง prompt ได้
OPSX เปิดมันขึ้นมา ตอนนี้ใครก็สามารถ:
- ทดลองกับคำสั่ง — แก้ไขเทมเพลต ดูว่า AI ทำงานได้ดีขึ้นหรือไม่
- ทดสอบอย่างละเอียด — ตรวจสอบคำสั่งของแต่ละ artifact แยกกัน
- ปรับแต่งขั้นตอนการทำงาน — กำหนด artifact และการพึ่งพาของคุณเอง
- วนซ้ำอย่างรวดเร็ว — เปลี่ยนเทมเพลต ทดสอบทันที ไม่ต้องสร้างใหม่
ขั้นตอนการทำงานแบบเดิม: OPSX:
┌────────────────────────┐ ┌────────────────────────┐
│ Hardcoded in package │ │ schema.yaml │◄── คุณแก้ไขตรงนี้
│ (can't change) │ │ templates/*.md │◄── หรือตรงนี้
│ ↓ │ │ ↓ │
│ Wait for new release │ │ Instant effect │
│ ↓ │ │ ↓ │
│ Hope it's better │ │ Test it yourself │
└────────────────────────┘ └────────────────────────┘นี่สำหรับทุกคน:
- ทีม — สร้างขั้นตอนการทำงานที่ตรงกับวิธีที่คุณทำงานจริง
- ผู้ใช้ขั้นสูง — ปรับแต่ง prompt เพื่อให้ได้ผลลัพธ์ AI ที่ดีกว่าสำหรับ codebase ของคุณ
- ผู้มีส่วนร่วม OpenSpec — ทดลองแนวทางใหม่โดยไม่ต้องรอรุ่นใหม่
เราทุกคนยังคงเรียนรู้ว่าอะไรทำงานได้ดีที่สุด OPSX ช่วยให้เราเรียนรู้ไปด้วยกัน
ประสบการณ์ของผู้ใช้
ปัญหาของขั้นตอนการทำงานเชิงเส้น: คุณอยู่ใน "ขั้นตอนวางแผน" จากนั้น "ขั้นตอนการนำไปใช้" แล้วก็ "เสร็จสิ้น" แต่งานจริงไม่ได้ทำงานแบบนั้น คุณนำบางอย่างไปใช้ ตระหนักว่าการออกแบบของคุณผิด ต้องอัปเดต spec แล้วดำเนินการต่อ ขั้นตอนเชิงเส้นขัดแย้งกับวิธีที่งานเกิดขึ้นจริง
แนวทาง OPSX:
- การกระทำ ไม่ใช่ขั้นตอน — สร้าง นำไปใช้ อัปเดต เก็บถาวร — ทำสิ่งเหล่านี้ได้ทุกเมื่อ
- การพึ่งพาเป็นตัวเปิดใช้งาน — มันแสดงให้เห็นว่าอะไรเป็นไปได้ ไม่ใช่สิ่งที่ต้องทำต่อไป
proposal ──→ specs ──→ design ──→ tasks ──→ implementการตั้งค่า
bash
# ตรวจสอบว่าคุณได้ติดตั้ง openspec แล้ว — skills จะถูกสร้างขึ้นโดยอัตโนมัติ
openspec initสิ่งนี้จะสร้าง skills ใน .claude/skills/ (หรือที่เทียบเท่า) ที่ AI coding assistants จะตรวจจับโดยอัตโนมัติ
โดยค่าเริ่มต้น OpenSpec ใช้โปรไฟล์ขั้นตอนการทำงาน core (propose, explore, apply, sync, archive) หากคุณต้องการคำสั่งขั้นตอนการทำงานแบบขยาย (new, continue, ff, verify, bulk-archive, onboard) ให้กำหนดค่าด้วย openspec config profile และใช้งานด้วย openspec update
ระหว่างการตั้งค่า คุณจะถูกถามให้สร้าง project config (openspec/config.yaml) นี่เป็นทางเลือกแต่แนะนำ
การกำหนดค่าโปรเจกต์
Project config ช่วยให้คุณตั้งค่าเริ่มต้นและฉีดบริบทเฉพาะโปรเจกต์เข้าไปในทุก artifact
การสร้าง Config
Config ถูกสร้างขึ้นระหว่าง 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ฟิลด์ Config
| ฟิลด์ | ประเภท | คำอธิบาย |
|---|---|---|
schema | string | Schema เริ่มต้นสำหรับการเปลี่ยนแปลงใหม่ (เช่น spec-driven) |
context | string | บริบทโปรเจกต์ที่ฉีดเข้าไปในคำสั่งของทุก artifact |
rules | object | กฎสำหรับแต่ละ artifact โดยระบุด้วย artifact ID |
วิธีการทำงาน
ลำดับความสำคัญของ Schema (สูงสุดไปต่ำสุด):
- แฟล็ก CLI (
--schema <name>) - เมตาดาต้าการเปลี่ยนแปลง (
.openspec.yamlในไดเรกทอรีการเปลี่ยนแปลง) - Project config (
openspec/config.yaml) - ค่าเริ่มต้น (
spec-driven)
การฉีดบริบท:
- บริบทจะถูกเติมหน้าคำสั่งของทุก artifact
- ถูกห่อด้วยแท็ก
<context>...</context> - ช่วยให้ AI เข้าใจธรรมเนียมของโปรเจกต์คุณ
การฉีดกฎ:
- กฎจะถูกฉีดเฉพาะสำหรับ artifact ที่ตรงกันเท่านั้น
- ถูกห่อด้วยแท็ก
<rules>...</rules> - ปรากฏหลังบริบท ก่อนเทมเพลต
Artifact IDs ตาม Schema
spec-driven (ค่าเริ่มต้น):
proposal— ข้อเสนอการเปลี่ยนแปลงspecs— ข้อกำหนดdesign— การออกแบบทางเทคนิคtasks— งานการนำไปใช้
การตรวจสอบ Config
- Artifact ID ที่ไม่รู้จักใน
rulesจะสร้างคำเตือน - ชื่อ Schema จะถูกตรวจสอบกับ schema ที่มีอยู่
- บริบทมีขีดจำกัดขนาด 50KB
- YAML ที่ไม่ถูกต้องจะถูกรายงานพร้อมหมายเลขบรรทัด
การแก้ไขปัญหา
"Unknown artifact ID in rules: X"
- ตรวจสอบว่า artifact ID ตรงกับ schema ของคุณ (ดูรายการด้านบน)
- รัน
openspec schemas --jsonเพื่อดู artifact ID สำหรับแต่ละ schema
Config ไม่ถูกนำไปใช้:
- ตรวจสอบว่าไฟล์อยู่ที่
openspec/config.yaml(ไม่ใช่.yml) - ตรวจสอบไวยากรณ์ YAML ด้วยตัวตรวจสอบ
- การเปลี่ยนแปลง Config มีผลทันที (ไม่ต้องรีสตาร์ท)
บริบทใหญ่เกินไป:
- บริบทถูกจำกัดไว้ที่ 50KB
- ให้สรุปหรือเชื่อมโยงไปยังเอกสารภายนอกแทน
คำสั่ง
| คำสั่ง | สิ่งที่ทำ |
|---|---|
/opsx:propose | สร้างการเปลี่ยนแปลงและสร้าง artifact การวางแผนในขั้นตอนเดียว (เส้นทางด่วนเริ่มต้น) |
/opsx:explore | คิดผ่านแนวคิด ตรวจสอบปัญหา ชี้แจงข้อกำหนด |
/opsx:new | เริ่ม scaffold การเปลี่ยนแปลงใหม่ (ขั้นตอนการทำงานแบบขยาย) |
/opsx:continue | สร้าง artifact ถัดไป (ขั้นตอนการทำงานแบบขยาย) |
/opsx:ff | Fast-forward 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 # scaffold เท่านั้น
/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. เริ่มใหม่
คุณสามารถแก้ไขข้อเสนอหรือ spec ของคุณได้เสมอก่อนการนำไปใช้ แต่เมื่อใดที่การปรับปรุงกลายเป็น "นี่คืองานที่แตกต่าง"?
สิ่งที่ข้อเสนอจับไว้
ข้อกำหนัดสามสิ่ง:
- เจตนา — คุณกำลังแก้ปัญหาอะไร?
- ขอบเขต — อะไรอยู่ใน/นอกขอบเขต?
- แนวทาง — คุณจะแก้ไขมันอย่างไร?
คำถามคือ: สิ่งใดเปลี่ยนไป และเปลี่ยนไปมากแค่ไหน?
อัปเดตการเปลี่ยนแปลงที่มีอยู่เมื่อ:
เจตนาเดียวกัน การดำเนินการที่ปรับปรุงแล้ว
- คุณค้นพบกรณีขอบเขตที่คุณไม่ได้พิจารณา
- แนวทางต้องปรับแต่งแต่เป้าหมายยังไม่เปลี่ยน
- การนำไปใช้เผยให้เห็นว่าการออกแบบผิดเล็กน้อย
ขอบเขตลดลง
- คุณตระหนักว่าขอบเขตเต็มใหญ่เกินไป ต้องการส่ง MVP ก่อน
- "เพิ่ม dark mode" → "เพิ่มปุ่มสลับ dark mode (ค่าระบบใน v2)"
การแก้ไขที่ขับเคลื่อนด้วยการเรียนรู้
- Codebase ไม่ได้จัดโครงสร้างอย่างที่คุณคิด
- การพึ่งพาไม่ทำงานตามที่คาดไว้
- "ใช้ CSS variables" → "ใช้ Tailwind's dark: prefix แทน"
เริ่มการเปลี่ยนแปลงใหม่เมื่อ:
เจตนาเปลี่ยนแปลงอย่างมีนัยสำคัญ
- ปัญหาเองตอนนี้แตกต่างออกไป
- "เพิ่ม dark mode" → "เพิ่มระบบธีมที่ครอบคลุมด้วยสี แบบอักษร ระยะห่างที่กำหนดเอง"
ขอบเขตขยายตัว
- การเปลี่ยนแปลงเติบโตมากจนเป็นงานที่แตกต่างโดยพื้นฐาน
- ข้อเสนอเดิมจะจดจำไม่ได้หลังจากอัปเดต
- "แก้ไขบั๊กเข้าสู่ระบบ" → "เขียนระบบ auth ใหม่"
ต้นฉบับสามารถทำให้เสร็จสมบูรณ์ได้
- การเปลี่ยนแปลงเดิมสามารถทำเครื่องหมายว่า "เสร็จสิ้น"
- งานใหม่ยืนอยู่คนเดียว ไม่ใช่การปรับปรุง
- เสร็จสิ้น "เพิ่ม MVP dark mode" → เก็บถาวร → การเปลี่ยนแปลงใหม่ "ปรับปรุง dark mode"
หลักเกณฑ์
┌─────────────────────────────────────┐
│ นี่คืองานเดียวกันหรือไม่? │
└──────────────┬──────────────────────┘
│
┌──────────────────┼──────────────────┐
│ │ │
▼ ▼ ▼
เจตนาเดียวกัน? ซ้อนทับ >50%? ต้นฉบับสามารถ
ปัญหาเดียวกัน? ขอบเขตเดียวกัน? "เสร็จสิ้น" โดยไม่มี
│ │ การเปลี่ยนแปลงเหล่านี้?
│ │ │
┌────────┴────────┐ ┌──────┴──────┐ ┌───────┴───────┐
│ │ │ │ │ │
ใช่ ไม่ ใช่ ไม่ ไม่ ใช่
│ │ │ │ │ │
▼ ▼ ▼ ▼ ▼ ▼
อัปเดต ใหม่ อัปเดต ใหม่ อัปเดต ใหม่| การทดสอบ | อัปเดต | การเปลี่ยนแปลงใหม่ |
|---|---|---|
| อัตลักษณ์ | "สิ่งเดียวกัน ที่ปรับปรุงแล้ว" | "งานที่แตกต่าง" |
| การซ้อนทับขอบเขต | ซ้อนทับ >50% | ซ้อนทับ <50% |
| ความสมบูรณ์ | ไม่สามารถ "เสร็จสิ้น" ได้หากไม่มีการเปลี่ยนแปลง | สามารถทำต้นฉบับให้เสร็จ งานใหม่ยืนอยู่คนเดียว |
| เรื่องราว | ห่วงโซ่อัปเดตบอกเล่าเรื่องราวที่สอดคล้องกัน | แพทช์จะทำให้สับสนมากกว่าชี้แจง |
หลักการ
การอัปเดตเก็บรักษาบริบท การเปลี่ยนแปลงใหม่ให้ความชัดเจน
เลือกอัปเดตเมื่อประวัติความคิดของคุณมีคุณค่า เลือกใหม่เมื่อการเริ่มต้นใหม่จะชัดเจนกว่าการปะติดปะต่อ
คิดเหมือน git branches:
- คอมมิตต่อไปในขณะที่ทำงานกับฟีเจอร์เดียวกัน
- เริ่ม branch ใหม่เมื่อมันเป็นงานใหม่โดยแท้จริง
- บางครั้งรวมฟีเจอร์บางส่วนและเริ่มใหม่สำหรับเฟส 2
มีอะไรแตกต่าง?
ระบบเดิม (/openspec:proposal) | OPSX (/opsx:*) | |
|---|---|---|
| โครงสร้าง | เอกสารข้อเสนอขนาดใหญ่เพียงฉบับเดียว | ผลลัพธ์แยกส่วนพร้อมการพึ่งพาอาศัยกัน |
| ขั้นตอนการทำงาน | ขั้นตอนเชิงเส้น: วางแผน → ดำเนินการ → เก็บถาวร | การดำเนินการที่ยืดหยุ่น — ทำอะไรก็ได้ทุกเมื่อ |
| การวนซ้ำ | ย้อนกลับได้ลำบาก | อัปเดตผลลัพธ์เมื่อคุณเรียนรู้ |
| การปรับแต่ง | โครงสร้างคงที่ | ขับเคลื่อนด้วย Schema (กำหนดผลลัพธ์ของคุณเอง) |
ข้อมูลเชิงลึกที่สำคัญ: งานไม่ได้เป็นแบบเส้นตรง OPSX หยุดแสร้งทำเป็นว่ามันเป็นเช่นนั้น
เจาะลึกสถาปัตยกรรม
ส่วนนี้อธิบายวิธีการทำงานเบื้องหลังของ OPSX และเปรียบเทียบกับเวิร์กโฟลว์แบบเดิม ตัวอย่างในส่วนนี้ใช้ชุดคำสั่งแบบขยาย (new, continue เป็นต้น); ผู้ใช้ core แบบดั้งเดิมสามารถแมปโฟลว์เดียวกันไปยัง propose → apply → sync → archive
ปรัชญา: เฟส vs การกระทำ
┌─────────────────────────────────────────────────────────────────────────────┐
│ เวิร์กโฟลว์แบบเดิม │
│ (ล็อกเฟส, ทั้งหมดหรือไม่มีเลย) │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
│ │ การวางแผน │ ───► │ การนำไปใช้ │ ───► │ การจัดเก็บ │ │
│ │ เฟส │ │ เฟส │ │ เฟส │ │
│ └──────────────┘ └──────────────┘ └──────────────┘ │
│ │ │ │ │
│ ▼ ▼ ▼ │
│ /openspec:proposal /openspec:apply /openspec:archive │
│ │
│ • สร้างสิ่งประดิษฐ์ทั้งหมดพร้อมกัน │
│ • ไม่สามารถย้อนกลับไปอัปเดตข้อกำหนดระหว่างการนำไปใช้ได้ │
│ • การล็อกเฟสบังคับให้ดำเนินการแบบเชิงเส้น │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────────────────────┐
│ เวิร์กโฟลว์ OPSX │
│ (การกระทำที่ลื่นไหล, วนซ้ำ) │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ ┌────────────────────────────────────────────┐ │
│ │ การกระทำ (ไม่ใช่เฟส) │ │
│ │ │ │
│ │ new ◄──► continue ◄──► apply ◄──► archive │ │
│ │ │ │ │ │ │ │
│ │ └──────────┴───────────┴───────────┘ │ │
│ │ ลำดับใดก็ได้ │ │
│ └────────────────────────────────────────────┘ │
│ │
│ • สร้างสิ่งประดิษฐ์ทีละชิ้น หรือ เร่งข้ามไปข้างหน้า │
│ • อัปเดตข้อกำหนด/การออกแบบ/งานระหว่างการนำไปใช้ │
│ • การพึ่งพาทำให้เกิดความคืบหน้า เฟสไม่มีอยู่จริง │
│ │
└─────────────────────────────────────────────────────────────────────────────┘สถาปัตยกรรมส่วนประกอบ
เวิร์กโฟลว์แบบเดิม ใช้เทมเพลตที่เขียนโค้ดตายตัวใน 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
(requires: (requires:
proposal) proposal)
│ │
└─────────────┬─────────────┘
│
▼
tasks
(requires:
specs, design)
│
▼
┌──────────────┐
│ เฟส APPLY │
│ (requires: │
│ tasks) │
└──────────────┘การเปลี่ยนสถานะ:
BLOCKED ────────────────► READY ────────────────► DONE
│ │ │
การพึ่งพา การพึ่งพาทั้งหมด ไฟล์มีอยู่
ที่ขาดหายไป อยู่ในสถานะ 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
# หรือแยกสคีมาที่มีอยู่เป็นจุดเริ่มต้น
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 |
| การวนซ้ำ | ล็อกเฟส | ลื่นไหล, แก้ไขอะไรก็ได้ |
| การรองรับเอดิเตอร์ | ตัวกำหนดค่า/อะแดปเตอร์เฉพาะเครื่องมือ | ไดเรกทอรีทักษะเดียว |
สคีมา
สคีมาจะกำหนดว่ามีสิ่งประดิษฐ์ (artifacts) อะไรบ้างและมีการพึ่งพาอาศัยกันอย่างไร ปัจจุบันมีให้ใช้งาน:
- spec-driven (ค่าเริ่มต้น): proposal → specs → design → tasks
bash
# 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เคล็ดลับ
- ใช้
/opsx:exploreเพื่อคิดทบทวนแนวคิดก่อนที่จะตัดสินใจเปลี่ยนแปลง - ใช้
/opsx:ffเมื่อคุณรู้ว่าต้องการอะไร, ใช้/opsx:continueเมื่ออยู่ในขั้นตอนการสำรวจ - ในระหว่าง
/opsx:applyหากมีสิ่งผิดปกติ — ให้แก้ไขสิ่งประดิษฐ์ (artifact) นั้น แล้วดำเนินการต่อ - งาน (Tasks) จะติดตามความคืบหน้าผ่านช่องทำเครื่องหมายใน
tasks.md - ตรวจสอบสถานะได้ทุกเมื่อ:
openspec status --change "name"
ข้อเสนอแนะ
นี่เป็นฉบับร่าง นั่นเป็นความตั้งใจ — เรากำลังเรียนรู้ว่าอะไรใช้ได้ผล
พบข้อบกพร่อง? มีแนวคิด? เข้าร่วมกับเราบน Discord หรือเปิด issue บน GitHub