เวิร์กโฟลว์
คู่มือนี้ครอบคลุมรูปแบบเวิร์กโฟลว์ทั่วไปสำหรับ OpenSpec และเมื่อใดควรใช้แต่ละแบบ สำหรับการตั้งค่าเบื้องต้น ดูที่ เริ่มต้นใช้งาน สำหรับคำสั่งอ้างอิง ดูที่ คำสั่ง
ปรัชญา: การกระทำ ไม่ใช่ขั้นตอน
เวิร์กโฟลว์แบบดั้งเดิมบังคับให้คุณผ่านขั้นตอน: การวางแผน จากนั้นการนำไปใช้ จากนั้นเสร็จสิ้น แต่งานจริงไม่ได้พอดีกับกรอบเหล่านั้นอย่างเรียบร้อย
OPSX ใช้วิธีการที่แตกต่าง:
text
Traditional (phase-locked):
PLANNING ────────► IMPLEMENTING ────────► DONE
│ │
│ "Can't go back" │
└────────────────────┘
OPSX (fluid actions):
proposal ──► specs ──► design ──► tasks ──► implementหลักการสำคัญ:
- การกระทำ ไม่ใช่ขั้นตอน - คำสั่งคือสิ่งที่คุณสามารถทำได้ ไม่ใช่ขั้นตอนที่คุณติดอยู่
- การพึ่งพาเป็นตัวเปิดใช้งาน - พวกเขาแสดงสิ่งที่เป็นไปได้ ไม่ใช่สิ่งที่จำเป็นต้องทำต่อไป
การปรับแต่ง: เวิร์กโฟลว์ OPSX ขับเคลื่อนโดยสคีมาที่กำหนดลำดับสิ่งประดิษฐ์ ดูรายละเอียดเกี่ยวกับการสร้างสคีมาที่กำหนดเองได้ที่ การปรับแต่ง
โหมดการทำงานสองแบบ
โหมดเริ่มต้นแบบเร็ว (โปรไฟล์ core)
การติดตั้งใหม่จะใช้ค่าเริ่มต้นเป็น core ซึ่งมีคำสั่งดังนี้:
/opsx:propose/opsx:explore/opsx:apply/opsx:sync/opsx:archive
ขั้นตอนการทำงานทั่วไป:
text
/opsx:propose ──► /opsx:apply ──► /opsx:sync ──► /opsx:archiveขั้นตอนการทำงานแบบขยาย/เต็มรูปแบบ (เลือกเอง)
หากคุณต้องการคำสั่งสำหรับสร้างโครงสร้างและพัฒนาอย่างชัดเจน (/opsx:new, /opsx:continue, /opsx:ff, /opsx:verify, /opsx:bulk-archive, /opsx:onboard) ให้เปิดใช้งานด้วย:
bash
openspec config profile
openspec updateรูปแบบขั้นตอนการทำงาน (โหมดขยาย)
ฟีเจอร์แบบเร็ว
เมื่อคุณรู้ว่าต้องการสร้างอะไรและต้องการแค่ดำเนินการ:
text
/opsx:new ──► /opsx:ff ──► /opsx:apply ──► /opsx:verify ──► /opsx:archiveตัวอย่างการสนทนา:
text
คุณ: /opsx:new add-logout-button
AI: สร้างโฟลเดอร์ openspec/changes/add-logout-button/ แล้ว
พร้อมสร้าง: proposal
คุณ: /opsx:ff
AI: กำลังสร้างเอกสารวางแผนทั้งหมด...
✓ proposal.md
✓ specs/
✓ design.md
✓ tasks.md
พร้อมสำหรับการพัฒนาแล้ว!
คุณ: /opsx:apply
AI: กำลังดำเนินงานตามรายการงาน...
✓ เพิ่มปุ่มออกจากระบบในส่วนหัวแล้ว
✓ ดำเนินการล้างข้อมูลเซสชันแล้ว
✓ เพิ่มกล่องโต้ตอบยืนยันแล้ว
งานทั้งหมดเสร็จสิ้น!
คุณ: /opsx:archive
AI: ✓ รวมข้อกำหนดแล้ว
✓ เก็บถาวรการเปลี่ยนแปลงแล้วเหมาะสำหรับ: ฟีเจอร์ขนาดเล็กถึงกลาง, การแก้ไขบั๊ก, การเปลี่ยนแปลงที่ไม่ซับซ้อน
แบบสำรวจ
เมื่อข้อกำหนดไม่ชัดเจนหรือคุณต้องการตรวจสอบก่อน:
text
/opsx:explore ──► /opsx:new ──► /opsx:continue ──► ... ──► /opsx:applyตัวอย่างการสนทนา:
text
คุณ: /opsx:explore
AI: คุณต้องการสำรวจเรื่องอะไร?
คุณ: ฉันต้องการปรับปรุงประสิทธิภาพการโหลดหน้าเว็บ แต่ไม่แน่ใจว่าคอขวดอยู่ตรงไหน
AI: ให้ฉันช่วยตรวจสอบ...
[วิเคราะห์ขนาดบันเดิล, ระบุคำสั่งคิวรีที่ช้า, ตรวจสอบรูปแบบการเรนเดอร์คอมโพเนนต์]
ฉันพบคอขวดหลักสามจุด:
1. รูปภาพขนาดใหญ่ที่ยังไม่ได้ปรับให้เหมาะสม
2. การดึงข้อมูลแบบซิงโครนัสใน ProductList
3. การเรนเดอร์ซ้ำจากการเปลี่ยนแปลงของ context
คุณต้องการจัดการกับจุดไหนก่อน?
คุณ: มาจัดการกับปัญหาการดึงข้อมูลกันเถอะ
คุณ: /opsx:new optimize-product-list-fetching
AI: สร้างการเปลี่ยนแปลงแล้ว พร้อมสร้าง: proposal
คุณ: /opsx:continue
AI: กำลังสร้าง proposal จากผลการสำรวจของเรา...
[เขียน proposal โดยรวมข้อมูลเชิงลึกจากการตรวจสอบ]
พร้อมสร้าง: specs, design
คุณต้องการสร้างอะไรต่อ?
คุณ: /opsx:continue
AI: กำลังสร้าง specs...เหมาะสำหรับ: การเพิ่มประสิทธิภาพ, การดีบัก, การตัดสินใจด้านสถาปัตยกรรม, ข้อกำหนดที่ไม่ชัดเจน
การเปลี่ยนแปลงแบบคู่ขนาน
ทำงานกับหลายการเปลี่ยนแปลงพร้อมกัน:
text
Change A: /opsx:new ──► /opsx:ff ──► /opsx:apply (อยู่ระหว่างดำเนินการ)
│
เปลี่ยนบริบท
│
Change B: /opsx:new ──► /opsx:ff ──────► /opsx:applyตัวอย่างการสนทนา:
text
คุณ: ฉันกำลังทำงานกับ add-dark-mode แต่ถูกดึงไปแก้บั๊ก
คุณ: /opsx:new fix-login-redirect
AI: สร้างโฟลเดอร์ openspec/changes/fix-login-redirect/ แล้ว
คุณ: /opsx:ff
AI: ✓ สร้างเอกสารวางแผนแล้ว
คุณ: /opsx:apply
AI: กำลังทำงานกับ fix-login-redirect...
[ดำเนินการแก้ไข]
งานทั้งหมดเสร็จสิ้น!
คุณ: /opsx:archive
AI: ✓ เก็บถาวร fix-login-redirect แล้ว
คุณ: กลับไปทำ dark mode ต่อเถอะ
คุณ: /opsx:apply add-dark-mode
AI: กลับมาทำงานกับ add-dark-mode ต่อ...
เริ่มต้นที่งาน 2.3: อัปเดต Header...เหมาะสำหรับ: กระแสงานแบบคู่ขนาน, การขัดจังหวะเร่งด่วน, การทำงานร่วมกันเป็นทีม
เมื่อคุณมีการเปลี่ยนแปลงที่เสร็จสมบูรณ์หลายรายการ ให้ใช้ /opsx:bulk-archive:
text
คุณ: /opsx:bulk-archive
AI: พบ 3 การเปลี่ยนแปลงที่เสร็จสมบูรณ์:
- add-dark-mode (งานทั้งหมดเสร็จแล้ว)
- fix-login-redirect (งานทั้งหมดเสร็จแล้ว)
- update-footer (งานทั้งหมดเสร็จแล้ว)
กำลังตรวจสอบข้อขัดแย้งของข้อกำหนด...
⚠ add-dark-mode และ update-footer ทั้งคู่เกี่ยวข้องกับ specs/ui/
กำลังตรวจสอบฐานรหัสเพื่อแก้ไข...
การเปลี่ยนแปลงทั้งสองถูกนำไปใช้แล้ว จะดำเนินการตามลำดับเวลา
เก็บถาวรทั้ง 3 การเปลี่ยนแปลงหรือไม่?
คุณ: ใช่
AI: ✓ เก็บถาวร add-dark-mode แล้ว
✓ เก็บถาวร fix-login-redirect แล้ว
✓ เก็บถาวร update-footer แล้ว
รวมข้อกำหนดตามลำดับ: add-dark-mode → update-footerการเก็บถาวรแบบกลุ่มจะตรวจจับเมื่อมีการเปลี่ยนแปลงหลายรายการที่เกี่ยวข้องกับข้อกำหนดเดียวกัน และแก้ไขข้อขัดแย้งโดยตรวจสอบสิ่งที่ถูกนำไปใช้จริง
การสิ้นสุดการเปลี่ยนแปลง
ขั้นตอนการสิ้นสุดที่แนะนำ:
text
/opsx:apply ──► /opsx:verify ──► /opsx:archive
│ │
ตรวจสอบ แจ้งเตือนให้ซิงค์
การนำไปใช้ หากจำเป็นตรวจสอบ: ตรวจสอบงานของคุณ
/opsx:verify ตรวจสอบการนำไปใช้กับเอกสารของคุณในสามมิติ:
text
คุณ: /opsx:verify
AI: กำลังตรวจสอบ add-auth...
ความสมบูรณ์
✓ งานทั้ง 12 รายการใน tasks.md ถูกเลือกแล้ว
✓ ข้อกำหนดทั้งหมดใน specs มีโค้ดที่สอดคล้องกัน
⚠ สถานการณ์ "หมดเวลาเซสชันหลังไม่มีการใช้งาน" ยังไม่ได้ทดสอบ
ความถูกต้อง
✓ การนำไปใช้ตรงกับเจตนาของข้อกำหนด
✓ จัดการกรณีขอบเขตจากสถานการณ์แล้ว
✓ สถานะข้อผิดพลาดตรงกับคำจำกัดความในข้อกำหนด
ความสอดคล้อง
✓ การตัดสินใจด้านการออกแบบสะท้อนในโครงสร้างโค้ด
✓ อนุสัญญาการตั้งชื่อสอดคล้องกับ design.md
⚠ การออกแบบกล่าวถึง "event-driven" แต่การนำไปใช้ใช้ polling
สรุป
─────────────────────────────
ปัญหาวิกฤต: 0
คำเตือน: 2
พร้อมเก็บถาวร: ใช่ (พร้อมคำเตือน)
คำแนะนำ:
1. เพิ่มการทดสอบสำหรับสถานการณ์หมดเวลาเซสชัน
2. พิจารณาปรับโครงสร้างเป็น event-driven ตามที่ออกแบบ หรืออัปเดต design.mdสิ่งที่ verify ตรวจสอบ:
| มิติ | สิ่งที่ตรวจสอบ |
|---|---|
| ความสมบูรณ์ | งานทั้งหมดเสร็จสิ้น, ข้อกำหนดทั้งหมดถูกนำไปใช้, ครอบคลุมสถานการณ์ |
| ความถูกต้อง | การนำไปใช้ตรงกับเจตนาของข้อกำหนด, จัดการกรณีขอบเขต |
| ความสอดคล้อง | การตัดสินใจด้านการออกแบบสะท้อนในโค้ด, รูปแบบสอดคล้องกัน |
Verify จะไม่บล็อกการเก็บถาวร แต่จะแสดงปัญหาที่คุณอาจต้องการจัดการก่อน
เก็บถาวร: สิ้นสุดการเปลี่ยนแปลง
/opsx:archive เสร็จสิ้นการเปลี่ยนแปลงและย้ายไปยังที่เก็บถาวร:
text
คุณ: /opsx:archive
AI: กำลังเก็บถาวร add-auth...
สถานะเอกสาร:
✓ proposal.md มีอยู่
✓ specs/ มีอยู่
✓ design.md มีอยู่
✓ tasks.md มีอยู่ (งานเสร็จ 12/12 รายการ)
ข้อกำหนดเดลต้ายังไม่ได้ซิงค์ไปยังสาขาหลัก
→ คุณต้องการซิงค์ตอนนี้หรือไม่?
คุณ: ใช่
AI: ✓ ซิงค์ข้อกำหนดไปยัง openspec/specs/auth/spec.md แล้ว
✓ ย้ายไปยัง openspec/changes/archive/2025-01-24-add-auth/ แล้ว
เก็บถาวรการเปลี่ยนแปลงสำเร็จArchive จะแจ้งเตือนหากข้อกำหนดยังไม่ได้ซิงค์ จะไม่บล็อกงานที่ยังไม่เสร็จ แต่จะแจ้งเตือนคุณ
เมื่อใช้อะไร
/opsx:ff เทียบกับ /opsx:continue
| สถานการณ์ | ใช้ |
|---|---|
| ข้อกำหนดชัดเจน พร้อมสร้าง | /opsx:ff |
| กำลังสำรวจ ต้องการตรวจสอบแต่ละขั้นตอน | /opsx:continue |
| ต้องการปรับปรุง proposal ก่อนสร้าง specs | /opsx:continue |
| มีแรงกดดันด้านเวลา ต้องการความเร็ว | /opsx:ff |
| การเปลี่ยนแปลงซับซ้อน ต้องการควบคุม | /opsx:continue |
หลักทั่วไป: หากคุณสามารถอธิบายขอบเขตทั้งหมดได้ล่วงหน้า ให้ใช้ /opsx:ff หากคุณกำลังค้นหาไปเรื่อยๆ ให้ใช้ /opsx:continue
เมื่ออัปเดตเทียบกับเริ่มต้นใหม่
คำถามที่พบบ่อย: เมื่อใดควรอัปเดตการเปลี่ยนแปลงที่มีอยู่ และเมื่อใดควรเริ่มต้นใหม่?
อัปเดตการเปลี่ยนแปลงที่มีอยู่เมื่อ:
- เจตนาเดียวกัน การดำเนินการที่ละเอียดขึ้น
- ขอบเขตแคบลง (MVP ก่อน ส่วนที่เหลือทีหลัง)
- การแก้ไขที่ขับเคลื่อนด้วยการเรียนรู้ (ฐานรหัสไม่เป็นอย่างที่คาดไว้)
- การปรับแต่งการออกแบบจากการค้นพบระหว่างการพัฒนา
เริ่มต้นการเปลี่ยนแปลงใหม่เมื่อ:
- เจตนาเปลี่ยนแปลงอย่างมีนัยสำคัญ
- ขอบเขตขยายไปเป็นงานที่แตกต่างโดยสิ้นเชิง
- การเปลี่ยนแปลงเดิมสามารถทำเครื่องหมายว่า "เสร็จสิ้น" ได้โดยอิสระ
- การแก้ไขจะสร้างความสับสนมากกว่าความชัดเจน
text
┌─────────────────────────────────────┐
│ นี่เป็นงานเดียวกันหรือไม่? │
└──────────────┬──────────────────────┘
│
┌──────────────────┼──────────────────┐
│ │ │
▼ ▼ ▼
เจตนาเดียวกัน? ทับซ้อน >50%? การเปลี่ยนแปลงเดิม
ปัญหาเดียวกัน? ขอบเขตเดียวกัน? สามารถ "เสร็จสิ้น" ได้
│ │ โดยไม่มีการเปลี่ยนแปลงเหล่านี้?
│ │ │
┌────────┴────────┐ ┌──────┴──────┐ ┌───────┴───────┐
│ │ │ │ │ │
ใช่ ไม่ ใช่ ไม่ ไม่ ใช่
│ │ │ │ │ │
▼ ▼ ▼ ▼ ▼ ▼
อัปเดต ใหม่ อัปเดต ใหม่ อัปเดต ใหม่ตัวอย่าง: "เพิ่มโหมดมืด"
- "ต้องรองรับธีมที่กำหนดเองด้วย" → การเปลี่ยนแปลงใหม่ (ขอบเขตขยาย)
- "การตรวจจับค่าที่ต้องการของระบบยากกว่าที่คาด" → อัปเดต (เจตนาเดียวกัน)
- "มาส่งปุ่มสลับก่อน เพิ่มการตั้งค่าทีหลัง" → อัปเดตแล้วเก็บถาวร จากนั้นเริ่มการเปลี่ยนแปลงใหม่
แนวปฏิบัติที่ดีที่สุด
รักษาการเปลี่ยนแปลงให้เน้นจุดประสงค์
หนึ่งหน่วยตรรกะของงานต่อการเปลี่ยนแปลง หากคุณกำลังทำ "เพิ่มฟีเจอร์ X และปรับปรุง Y" ให้พิจารณาแยกเป็นสองการเปลี่ยนแปลง
เหตุผลสำคัญ:
- ตรวจสอบและเข้าใจง่ายกว่า
- ประวัติที่เก็บถาวรสะอาดกว่า
- สามารถส่งมอบได้อย่างอิสระ
- ย้อนกลับง่ายกว่าหากจำเป็น
ใช้ /opsx:explore สำหรับข้อกำหนดที่ไม่ชัดเจน
ก่อนที่จะมุ่งมั่นกับการเปลี่ยนแปลง ให้สำรวจพื้นที่ปัญหา:
text
คุณ: /opsx:explore
AI: คุณต้องการสำรวจเรื่องอะไร?
คุณ: เราควรจัดการกับ rate limiting สำหรับ API ของเราอย่างไร?
AI: ให้ฉันตรวจสอบการตั้งค่าปัจจุบันและตัวเลือกของคุณ...
[ค้นคว้าฐานรหัส พิจารณารูปแบบ]
ฉันเห็นสามแนวทางที่เราสามารถใช้:
1. แบบมิดเดิลแวร์ (ง่าย, ต่อ endpoint)
2. แบบ Redis (ปรับขนาดได้, สถานะร่วม)
3. โทเค็นบัคเก็ตต่อผู้ใช้ (ยุติธรรม, ซับซ้อน)
สแต็คปัจจุบันของคุณแนะนำ #1 หรือ #2 ขนาดของคุณเป็นเท่าไหร่?การสำรวจช่วยให้ความคิดชัดเจนก่อนที่คุณจะสร้างเอกสาร
ตรวจสอบก่อนเก็บถาวร
ใช้ /opsx:verify เพื่อตรวจสอบว่าการนำไปใช้ตรงกับเอกสาร:
text
คุณ: /opsx:verify
AI: กำลังตรวจสอบ add-dark-mode...
✓ งานทั้งหมดใน tasks.md ถูกเลือกแล้ว
✓ ข้อกำหนดใน specs มีโค้ดที่สอดคล้องกัน
✓ การตัดสินใจด้านการออกแบบสะท้อนในการนำไปใช้
พร้อมเก็บถาวรแล้ว!จับความไม่ตรงกันก่อนที่คุณจะปิดการเปลี่ยนแปลง
ตั้งชื่อการเปลี่ยนแปลงให้ชัดเจน
ชื่อที่ดีทำให้ openspec list มีประโยชน์:
text
ดี: หลีกเลี่ยง:
add-dark-mode feature-1
fix-login-redirect update
optimize-product-query changes
implement-2fa wipคำสั่งอ้างอิงด่วน
สำหรับรายละเอียดและตัวเลือกคำสั่งทั้งหมด ดูที่ Commands
| คำสั่ง | วัตถุประสงค์ | เมื่อใช้งาน |
|---|---|---|
/opsx:propose | สร้างการเปลี่ยนแปลง + เอกสารวางแผน | เส้นทางเริ่มต้นเร็ว (core โปรไฟล์) |
/opsx:explore | คิดทบทวนแนวคิด | ข้อกำหนดไม่ชัดเจน, การตรวจสอบ |
/opsx:new | เริ่มโครงสร้างการเปลี่ยนแปลง | โหมดขยาย, การควบคุมเอกสารชัดเจน |
/opsx:continue | สร้างเอกสารถัดไป | โหมดขยาย, การสร้างเอกสารทีละขั้น |
/opsx:ff | สร้างเอกสารวางแผนทั้งหมด | โหมดขยาย, ขอบเขตชัดเจน |
/opsx:apply | ดำเนินงาน | พร้อมเขียนโค้ด |
/opsx:verify | ตรวจสอบการดำเนินงาน | โหมดขยาย, ก่อนเก็บถาวร |
/opsx:sync | รวมข้อกำหนดเดลต้า | โหมดขยาย, ทางเลือก |
/opsx:archive | เสร็จสิ้นการเปลี่ยนแปลง | งานทั้งหมดเสร็จสิ้น |
/opsx:bulk-archive | เก็บถาวรหลายการเปลี่ยนแปลง | โหมดขยาย, งานขนาน |
ขั้นตอนถัดไป
- Commands - อ้างอิงคำสั่งเต็มรูปแบบพร้อมตัวเลือก
- Concepts - รายละเอียดเชิงลึกเกี่ยวกับข้อกำหนด, เอกสาร และสคีมา
- Customization - สร้างเวิร์กโฟลว์ที่กำหนดเอง