เวิร์กโฟลว์
คู่มือนี้ครอบคลุมแพทเทิร์นเวิร์กโฟลว์ทั่วไปสำหรับ OpenSpec และเวลาในการใช้งานแต่ละแบบ สำหรับการตั้งค่าพื้นฐาน โปรดดูที่ เริ่มต้นใช้งาน สำหรับอ้างอิงคำสั่ง โปรดดูที่ คำสั่ง
ปรัชญา: การดำเนินการ ไม่ใช่ขั้นตอน
เวิร์กโฟลว์แบบดั้งเดิมบังคับให้คุณต้องผ่านขั้นตอนต่างๆ ลำดับ: การวางแผน → การนำไปปฏิบัติ → เสร็จสิ้น อย่างไรก็ตาม งานจริงไม่ได้สามารถถูกจำกัดอยู่ในกรอบขั้นตอนอย่างแน่นอนได้
OPSX นำเสนอวิธีการที่แตกต่างออกไป:
text
แบบดั้งเดิม (ล็อกขั้นตอน):
PLANNING ────────► IMPLEMENTING ────────► DONE
│ │
│ "ไม่สามารถย้อนกลับได้" │
└────────────────────┘
OPSX (การดำเนินการแบบยืดหยุ่น):
proposal ──► specs ──► design ──► tasks ──► implementหลักการสำคัญ:
- การดำเนินการ ไม่ใช่ขั้นตอน - คำสั่งเป็นสิ่งที่คุณสามารถดำเนินการได้ ไม่ใช่ขั้นตอนที่คุณติดอยู่ในนั้น
- การพึ่งพา เป็นสิ่งอำนวยความสะดวก - การพึ่งพาแสดงถึงสิ่งที่สามารถทำได้ ไม่ใช่สิ่งที่จำเป็นต้องดำเนินการต่อไป
การปรับแต่ง: เวิร์กโฟลว์ของ OPSX ทำงานโดยใช้ สคีมา ที่กำหนดลำดับของ อาร์ติแฟกต์ โปรดดูที่ การปรับแต่ง สำหรับรายละเอียดเกี่ยวกับการสร้าง สคีมา ที่กำหนดเอง
สองโหมด
เส้นทางด่วนเริ่มต้น (โปรไฟล์ core)
การติดตั้งใหม่จะใช้ core เป็นค่าเริ่มต้น ซึ่งมีฟังก์ชันต่อไปนี้:
/opsx:explore/opsx:propose/opsx:apply/opsx:sync/opsx:archive
ลำดับการทำงานทั่วไป:
text
/opsx:explore ──► /opsx:propose ──► /opsx:apply ──► /opsx:sync ──► /opsx:archive
(optional)เริ่มต้นด้วยการสำรวจ (เป็นนิสัยที่ควรมี)
/opsx:explore เป็นส่วนหนึ่งของโปรไฟล์เริ่มต้น ไม่ใช่ฟีเจอร์เสริมขั้นสูง นี่คือขั้นตอนที่ควรใช้เมื่อคุณมีปัญหาแต่ยังไม่มีแผน ซึ่งเมื่อใช้กับผู้ช่วย AI นั้นเป็นเรื่องปกติที่เกิดขึ้นบ่อยครั้ง
text
คุณ: /opsx:explore
AI: คุณต้องการสำรวจเรื่องอะไร?
คุณ: ผลการค้นหาของเราดูล้าสมัย ไม่แน่ใจว่าปัญหาเกิดจาก การแคช, การสร้างดัชนี, หรือคำค้นหเอง
AI: ให้ฉันตรวจดู先... [อ่านบริการค้นหาและเลเยอร์แคช]
ปัญหาอยู่ที่ดัชนี: ดัชนีถูกสร้างใหม่เพียงครั้งเดียวต่อคืน ดังนั้นการแก้ไขจึงไม่แสดงจนถึงวันถัดไป มีสองตัวเลือก: รีบิลด์ดัชนีทันทีที่เขียนข้อมูล (เรียบง่าย, เพิ่มภาระงาน) หรือการล้างแคชด้วย TTL สั้น (มีส่วนประกอบมากขึ้น, ลดภาระงาน) เนื่องจากปริมาณการเขียนของคุณต่ำ การรีบิลด์ทันทีที่เขียนจึงเป็นวิธีแก้ที่สะอาดกว่า ต้องการกำหนดขอบเขตของมันไหม?
คุณ: ใช่
คุณ: /opsx:propose rebuild-search-index-on-writeขั้นตอนสำรวจไม่สร้างเอกสารของการเปลี่ยนแปลง และไม่เขียนโค้ดใดๆ นี่เป็นการสนทนาที่ไม่เสียค่าใช้จ่ายและไม่มีความเสี่ยง ที่จะเปลี่ยนความกังวลที่ไม่ชัดเจนให้เป็นการเปลี่ยนแปลงที่ชัดเจน ดังนั้นข้อเสนอที่จะตามมาจะมีความคมชัดมากขึ้น ถ้าคุณรู้อย่างแน่ใจว่าต้องการอะไรแล้ว? ข้ามขั้นตอนนี้ไปใช้ /opsx:propose โดยตรง คู่มือฉบับเต็ม: สำรวจก่อน.
โหมดการทำงานขยาย/เต็ม (เลือกเอง)
หากคุณต้องการคำสั่ง scaffold-and-build ที่ชัดเจน (/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/ เรียบร้อย
พร้อมสร้าง: โปรโปซอล
คุณ: /opsx:ff
AI: กำลังสร้างเอกสารของการวางแผนทั้งหมด...
✓ proposal.md
✓ specs/
✓ design.md
✓ tasks.md
พร้อมสำหรับการพัฒนา!
คุณ: /opsx:apply
AI: กำลังดำเนินการตาม tasks...
✓ เพิ่มปุ่มออกจากระบบในส่วนหัวหน้า
✓ ใช้งานการล้างเซสชัน
✓ เพิ่มกล่องยืนยันการทำงาน
ทำ tasks ทั้งหมดเรียบร้อย!
คุณ: /opsx:archive
AI: ✓ รวม specs เรียบร้อย
✓ เก็บการเปลี่ยนแปลงเข้าคลังเรียบร้อยเหมาะกับ: ฟีเจอร์ขนาดเล็กถึงกลาง, การแก้ไขบั๊ก, การเปลี่ยนแปลงที่ง่าย
การสำรวจเบื้องต้น
เมื่อข้อกำหนดไม่ชัดเจน หรือคุณต้องตรวจสอบก่อน:
text
/opsx:explore ──► /opsx:new ──► /opsx:continue ──► ... ──► /opsx:applyตัวอย่างสนทนา:
text
คุณ: /opsx:explore
AI: คุณต้องการสำรวจเรื่องอะไร?
คุณ: ฉันต้องการปรับปรุงประสิทธิภาพการโหลดหน้าเว็บ แต่ไม่แน่ใจว่าข้อจำกัดอยู่ที่ไหน
AI: ให้ฉันช่วยตรวจสอบ先...
[วิเคราะห์ขนาดบันเดิล, ระบุคำค้นหาที่ช้า, ทบทวน
รูปแบบการเรนเดอร์ของคอมโพเนนต์]
ฉันพบข้อจำกัดหลัก 3 รายการ:
1. รูปภาพขนาดใหญ่ที่ไม่ได้ปรับแต่ง
2. การดึงข้อมูลแบบซิงโครนัสใน ProductList
3. การเรนเดอร์ซ้ำจากการเปลี่ยนแปลงของ context
อยากแก้ไขรายการใดก่อน?
คุณ: มาทำเรื่องการดึงข้อมูลก่อนกัน
คุณ: /opsx:new optimize-product-list-fetching
AI: สร้างการเปลี่ยนแปลงเรียบร้อย พร้อมสร้าง: โปรโปซอล
คุณ: /opsx:continue
AI: กำลังสร้างโปรโปซอลจากการสำรวจของเรา...
[เขียนโปรโปซอลที่รวมข้อค้นพบจากการตรวจสอบ]
พร้อมสร้าง: specs, การออกแบบ
อยากทำรายการต่อไปใด?
คุณ: /opsx:continue
AI: กำลังสร้าง specs...เหมาะกับ: การปรับปรุงประสิทธิภาพ, การดีบั๊ก, การตัดสินใจด้านสถาปัตยกรรม, ข้อกำหนดที่ไม่ชัดเจน
การเปลี่ยนแปลงแบบขนาน
ทำงานกับการเปลี่ยนแปลงหลายรายการพร้อมกัน:
text
Change A: /opsx:new ──► /opsx:ff ──► /opsx:apply (in progress)
│
context switch
│
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...
[นำการแก้ไขไปใช้งาน]
ทำ tasks ทั้งหมดเรียบร้อย!
คุณ: /opsx:archive
AI: ✓ เก็บ fix-login-redirect เข้าคลังเรียบร้อย
คุณ: กลับไปทำงานโหมดมืดต่อกัน
คุณ: /opsx:apply add-dark-mode
AI: กำลังดำเนินการ add-dark-mode อีกครั้ง...
เริ่มทำงานที่ task 2.3: อัปเดตส่วนหัวหน้า...เหมาะกับ: การทำงานขนานหลายสตรีม, การขัดจังหวะด่วน, การทำงานร่วมกับทีม
เมื่อคุณมีการเปลี่ยนแปลงที่สมบูรณ์หลายรายการ ใช้ /opsx:bulk-archive:
text
คุณ: /opsx:bulk-archive
AI: พบการเปลี่ยนแปลงที่สมบูรณ์ 3 รายการ:
- add-dark-mode (ทำ tasks ทั้งหมดเรียบร้อย)
- fix-login-redirect (ทำ tasks ทั้งหมดเรียบร้อย)
- update-footer (ทำ tasks ทั้งหมดเรียบร้อย)
กำลังตรวจสอบข้อขัดแย้งของ specs...
⚠ add-dark-mode และ update-footer ทั้งคู่แก้ไขที่ specs/ui/
กำลังตรวจสอบโค้ดเบสเพื่อแก้ไข...
การเปลี่ยนแปลงทั้งสองถูกนำไปใช้งานแล้ว จะดำเนินการตามลำดับเวลา
เก็บการเปลี่ยนแปลงทั้ง 3 รายการเข้าคลังไหม?
คุณ: ใช่
AI: ✓ เก็บ add-dark-mode เข้าคลังเรียบร้อย
✓ เก็บ fix-login-redirect เข้าคลังเรียบร้อย
✓ เก็บ update-footer เข้าคลังเรียบร้อย
specs ถูกรวมตามลำดับ: add-dark-mode → update-footerฟังก์ชันเก็บเข้าคลังแบบกลุ่มจะตรวจพบว่ามีการเปลี่ยนแปลงหลายรายการแก้ไข specs ส่วนเดียวกัน และแก้ไขข้อขัดแย้งโดยตรวจสอบว่าสิ่งใดถูกนำไปใช้งานจริง
การสิ้นสุดการเปลี่ยนแปลง
ลำดับการสิ้นสุดที่แนะนำ:
text
/opsx:apply ──► /opsx:verify ──► /opsx:archive
│ │
validates prompts to sync
implementation if neededตรวจสอบ: ตรวจสอบงานของคุณ
/opsx:verify จะตรวจสอบความถูกต้องของการนำไปใช้งานเทียบกับเอกสารของการเปลี่ยนแปลงของคุณใน 3 ด้าน:
text
คุณ: /opsx:verify
AI: กำลังตรวจสอบ add-auth...
ความสมบูรณ์
✓ ทำ tasks ทั้งหมด 12 รายการใน tasks.md เรียบร้อย
✓ ข้อกำหนดทั้งหมดใน specs มีโค้ดที่ตรงกัน
⚠ สถานการณ์ "เซสชันหมดอายุหลังจากไม่ใช้งาน" ยังไม่ได้รับการทดสอบ
ความถูกต้อง
✓ การนำไปใช้งานตรงกับจุดประสงค์ของ specs
✓ กรณีขอบจากสถานการณ์ถูกจัดการ
✓ สถานะข้อผิดพลาดตรงกับคำนิยามของ specs
ความสอดคล้อง
✓ การตัดสินใจด้านการออกแบบสะท้อนในโครงสร้างโค้ด
✓ ข้อกำหนดในการตั้งชื่อสอดคล้องกับ design.md
⚠ การออกแบบระบุ "ขับเคลื่อนด้วยเหตุการณ์" แต่การนำไปใช้งานใช้ polling
สรุป
─────────────────────────────
ปัญหาสำคัญ: 0
คำเตือน: 2
พร้อมเก็บเข้าคลัง: ใช่ (พร้อมคำเตือน)
คำแนะนำ:
1. เพิ่มการทดสอบสำหรับสถานการณ์เซสชันหมดอายุ
2. พิจารณาปรับโครงสร้างโค้ดเป็นแบบขับเคลื่อนด้วยเหตุการณ์ตามการออกแบบ, หรืออัปเดต design.mdสิ่งที่ /opsx:verify ตรวจสอบ:
| มิติ | สิ่งที่ตรวจสอบ |
|---|---|
| ความสมบูรณ์ | ทำ tasks ทั้งหมด, ข้อกำหนดทั้งหมดถูกนำไปใช้งาน, สถานการณ์ทั้งหมดถูกครอบคลุม |
| ความถูกต้อง | การนำไปใช้งานตรงกับจุดประสงค์ของ specs, กรณีขอบถูกจัดการ |
| ความสอดคล้อง | การตัดสินใจด้านการออกแบบสะท้อนในโค้ด, รูปแบบสอดคล้องกัน |
การตรวจสอบจะไม่บล็อกการเก็บเข้าคลัง แต่จะแสดงปัญหาที่คุณอาจต้องการแก้ไขก่อน
เก็บเข้าคลัง: สิ้นสุดการเปลี่ยนแปลง
/opsx:archive จะสิ้นสุดการเปลี่ยนแปลงและย้ายไปยังคลังเก็บ:
text
คุณ: /opsx:archive
AI: กำลังเก็บ add-auth เข้าคลัง...
สถานะเอกสารของการเปลี่ยนแปลง:
✓ มีไฟล์ proposal.md
✓ มีโฟลเดอร์ specs/
✓ มีไฟล์ design.md
✓ มีไฟล์ tasks.md (ทำ tasks 12/12 รายการเรียบร้อย)
specs ที่เปลี่ยนแปลง: ยังไม่ได้ซิงค์กับ main
→ ต้องการซิงค์ทันทีไหม?
คุณ: ใช่
AI: ✓ ซิงค์ specs ไปยัง openspec/specs/auth/spec.md เรียบร้อย
✓ ย้ายไปยัง openspec/changes/archive/2025-01-24-add-auth/ เรียบร้อย
เก็บการเปลี่ยนแปลงเข้าคลังเรียบร้อยการเก็บเข้าคลังจะแจ้งเตือนหาก specs ยังไม่ได้ซิงค์ มันจะไม่บล็อกเมื่อ tasks ยังไม่สมบูรณ์ แต่จะเตือนคุณ
ควรใช้อะไรเมื่อใด
/opsx:ff กับ /opsx:continue
| สถานการณ์ | ใช้ |
|---|---|
| ข้อกำหนดชัดเจน, พร้อมพัฒนา | /opsx:ff |
| กำลังสำรวจ, ต้องการตรวจสอบแต่ละขั้นตอน | /opsx:continue |
| ต้องการปรับปรุงโปรโปซอลก่อนสร้าง specs | /opsx:continue |
| จำกัดเวลา, ต้องดำเนินการอย่างรวดเร็ว | /opsx:ff |
| การเปลี่ยนแปลงซับซ้อน, ต้องการควบคุมขั้นตอน | /opsx:continue |
หลักการง่ายๆ: หากคุณอธิบายขอบเขตทั้งหมดได้ล่วงหน้า ใช้ /opsx:ff หากคุณกำลังหาคำตอบระหว่างดำเนินการ ใช้ /opsx:continue
ควรอัปเดตหรือเริ่มใหม่
คำถามที่พบบ่อย: อัปเดตการเปลี่ยนแปลงที่มีอยู่ได้เมื่อใด และควรเริ่มการเปลี่ยนแปลงใหม่เมื่อใด?
อัปเดตการเปลี่ยนแปลงที่มีอยู่เมื่อ:
- จุดประสงค์เหมือนเดิม, การดำเนินการที่ปรับปรุงแล้ว
- ขอบเขตแคบลง (ส่ง MVP ก่อน, ส่วนที่เหลือทีหลัง)
- การแก้ไขที่เกิดจากการเรียนรู้ (โค้ดเบสไม่เหมือนที่คาดหวัง)
- การปรับแต่งการออกแบบตามข้อค้นพบจากการนำไปใช้งาน
เริ่มการเปลี่ยนแปลงใหม่เมื่อ:
- จุดประสงค์เปลี่ยนแปลงโดยพื้นฐาน
- ขอบเขตขยายไปเป็นงานที่ต่างกันทั้งหมด
- การเปลี่ยนแปลงเดิมสามารถทำเครื่องหมายว่า "เสร็จสิ้น" ได้โดยไม่ต้องพึ่งพาอื่น
- แพทช์จะทำให้สับสนมากกว่าที่จะทำให้ชัดเจน
text
┌─────────────────────────────────────┐
│ Is this the same work? │
└──────────────┬──────────────────────┘
│
┌──────────────────┼──────────────────┐
│ │ │
▼ ▼ ▼
Same intent? >50% overlap? Can original
Same problem? Same scope? be "done" without
│ │ these changes?
│ │ │
┌────────┴────────┐ ┌──────┴──────┐ ┌───────┴───────┐
│ │ │ │ │ │
YES NO YES NO NO YES
│ │ │ │ │ │
▼ ▼ ▼ ▼ ▼ ▼
UPDATE NEW UPDATE NEW UPDATE NEWตัวอย่าง: "เพิ่มโหมดมืด"
- "ต้องรองรับธีมที่กำหนดเองเพิ่มอีก" → การเปลี่ยนแปลงใหม่ (ขอบเขตขยาย)
- "การตรวจจับการตั้งค่าของระบบยากกว่าที่คาดหวัง" → อัปเดต (จุดประสงค์เหมือนเดิม)
- "ส่งสลับไปก่อน, เพิ่มการตั้งค่าทีหลัง" → อัปเดตแล้วเก็บเข้าคลัง, แล้วเริ่มการเปลี่ยนแปลงใหม่
วิธีปฏิบัติที่ดีที่สุด
ให้การเปลี่ยนแปลงมีจุดมุ่งหมายเดียว
หนึ่งหน่วยงานที่มีตรรกะต่อการเปลี่ยนแปลง หากคุณกำลังทำ "เพิ่มฟีเจอร์ X และปรับโครงสร้างโค้ด Y" พิจารณาแยกเป็นสองการเปลี่ยนแปลง
เหตุผลที่สำคัญ:
- ตรวจสอบและเข้าใจได้ง่ายขึ้น
- ประวัติการเก็บเข้าคลังที่สะอาดขึ้น
- ส่งออกได้อิสระจากกัน
- ย้อนกลับได้ง่ายขึ้นหากจำเป็น
ใช้ /opsx:explore เมื่อข้อกำหนดไม่ชัดเจน
ก่อนที่จะยืนยันที่จะทำการเปลี่ยนแปลง สำรวจพื้นที่ปัญหา:
text
คุณ: /opsx:explore
AI: คุณต้องการสำรวจเรื่องอะไร?
คุณ: เราควรจัดการกับการจำกัดอัตราการเรียกใช้ (rate limiting) สำหรับ API ของเราอย่างไร?
AI: ให้ฉันตรวจสอบการตั้งค่าปัจจุบันและตัวเลือกของคุณ...
[วิจัยโค้ดเบส, พิจารณารูปแบบ]
ฉันเห็นสามวิธีที่เราสามารถใช้ได้:
1. ใช้ Middleware (เรียบง่าย, ต่อ endpoint)
2. ใช้ Redis เป็นฐานข้อมูล (ปรับขนาดได้, แชร์สถานะ)
3. ใช้ Token bucket ต่อผู้ใช้ (ยุติธรรม, ซับซ้อน)
สแต็กปัจจุบันของคุณแนะนำให้ใช้วิธี 1 หรือ 2 ขนาดการใช้งานของคุณอยู่ที่ระดับใด?การสำรวจจะช่วยชัดเจนความคิดก่อนที่คุณจะสร้างเอกสารของการเปลี่ยนแปลง
ตรวจสอบก่อนเก็บเข้าคลัง
ใช้ /opsx:verify เพื่อตรวจสอบว่าการนำไปใช้งานตรงกับเอกสารของการเปลี่ยนแปลง:
text
คุณ: /opsx:verify
AI: กำลังตรวจสอบ add-dark-mode...
✓ ทำ tasks ทั้งหมดใน tasks.md เรียบร้อย
✓ ข้อกำหนดทั้งหมดใน specs มีโค้ดที่ตรงกัน
✓ การตัดสินใจด้านการออกแบบสะท้อนในการนำไปใช้งาน
พร้อมเก็บเข้าคลัง!ตรวจพบความไม่สอดคล้องก่อนที่คุณจะสิ้นสุดการเปลี่ยนแปลง
ตั้งชื่อการเปลี่ยนแปลงให้ชัดเจน
ชื่อที่ดีทำให้คำสั่ง openspec list มีประโยชน์:
| ดี: | หลีกเลี่ยง: |
|---|---|
| add-dark-mode | feature-1 |
| fix-login-redirect | update |
| optimize-product-query | changes |
| implement-2fa | wip |
คำสั่งอ้างอิงด่วน
สำหรับรายละเอียดและตัวเลือกทั้งหมดของคำสั่ง โปรดดูที่ คำสั่ง
| คำสั่ง | วัตถุประสงค์ | ใช้เมื่อ |
|---|---|---|
/opsx:propose | สร้างการเปลี่ยนแปลง + อาร์ติแฟกต์การวางแผน | เส้นทางเริ่มต้นที่เร็วที่สุด (โพรไฟล์ core) |
/opsx:explore | วิเคราะห์ความคิดเห็นร่วมกับ AI | เริ่มต้นที่นี่เมื่อไม่แน่ใจ: ข้อกำหนดไม่ชัดเจน การสืบค้นข้อมูล หรือการเปรียบเทียบตัวเลือกต่างๆ |
/opsx:new | เริ่มต้นโครงสร้างการเปลี่ยนแปลง | โหมดขยาย การควบคุมอาร์ติแฟกต์อย่างชัดเจน |
/opsx:continue | สร้างอาร์ติแฟกต์ถัดไป | โหมดขยาย การสร้างอาร์ติแฟกต์ทีละขั้นตอน |
/opsx:ff | สร้างอาร์ติแฟกต์การวางแผนทั้งหมด | โหมดขยาย ขอบเขตงานที่ชัดเจน |
/opsx:apply | ดำเนินการงานที่กำหนด | พร้อมเขียนโค้ด |
/opsx:verify | ตรวจสอบความถูกต้องของการดำเนินการ | โหมดขยาย ก่อนเก็บถาวร |
/opsx:sync | ผสานสเปคส่วนต่าง | โหมดขยาย ไม่บังคับ |
/opsx:archive | เก็บถาวรการเปลี่ยนแปลง | งานทั้งหมดเสร็จสิ้น |
/opsx:bulk-archive | เก็บถาวรการเปลี่ยนแปลงหลายรายการ | โหมดขยาย การทำงานแบบคู่ขนาน |
ขั้นตอนต่อไป
- การเขียนสเปคที่ดี - รูปลักษณ์ของข้อกำหนดและสถานการณ์ที่แข็งแกร่ง และวิธีการปรับขนาดการเปลี่ยนแปลงให้เหมาะสม
- การทบทวนการเปลี่ยนแปลง - การตรวจสอบเบื้องต้นใน 2 นาทีของแผนร่างก่อนเขียนโค้ดใดๆ
- OpenSpec ในทีม - วิธีที่การเปลี่ยนแปลงสอดคล้องกับกิ่งและ pull request
- คำสั่ง - อ้างอิงคำสั่งพร้อมตัวเลือกทั้งหมด
- แนวคิดพื้นฐาน - ศึกษาเชิงลึกเกี่ยวกับสเปค อาร์ติแฟกต์ และสคีมา
- การปรับแต่ง - สร้างเวิร์กโฟลว์ที่กำหนดเอง