ขั้นตอนการทำงานของ OPSX
ยินดีรับข้อเสนอแนะผ่าน Discord
คืออะไร?
OPSX ได้กลายเป็นขั้นตอนการทำงานมาตรฐานสำหรับ OpenSpec แล้ว
นี่คือ ขั้นตอนการทำงานแบบยืดหยุ่นและทำซ้ำได้ สำหรับการเปลี่ยนแปลงใน OpenSpec ไม่ต้องมีขั้นตอนที่ตายตัวอีกต่อไป — มีเพียงการดำเนินการที่คุณสามารถทำได้ตลอดเวลา
เหตุผลที่สิ่งนี้มีอยู่
กระบวนการทำงาน OpenSpec แบบเดิมใช้งานได้ แต่ถูก ล็อกไว้:
- คำสั่งถูก hardcode ไว้ — ซ่อนอยู่ใน TypeScript คุณไม่สามารถแก้ไขได้
- ทำทั้งหมดหรือไม่ทำเลย — คำสั่งเดียวสร้างทุกอย่าง ไม่สามารถทดสอบแต่ละส่วนได้
- โครงสร้างตายตัว — ใช้ workflow เดียวกันสำหรับทุกคน ไม่มี customization
- กล่องดำ — เมื่อผลลัพธ์จาก AI ไม่ดี คุณไม่สามารถปรับ prompt ได้
OPSX เปิดให้แก้ไขได้ ตอนนี้ทุกคนสามารถ:
- ทดลองกับคำสั่ง — แก้ไข template ดูว่า AI ทำได้ดีขึ้นหรือไม่
- ทดสอบแบบละเอียด — ตรวจสอบคำสั่งของแต่ละ artifact แยกกัน
- ปรับ workflow ให้เหมาะกับตัวเอง — กำหนด artifact และ dependencies ของคุณเอง
- พัฒนาอย่างรวดเร็ว — เปลี่ยน template ทดสอบทันที ไม่ต้อง rebuild
Legacy workflow: OPSX:
┌────────────────────────┐ ┌────────────────────────┐
│ Hardcoded in package │ │ schema.yaml │◄── คุณแก้ไขตรงนี้
│ (can't change) │ │ templates/*.md │◄── หรือตรงนี้
│ ↓ │ │ ↓ │
│ Wait for new release │ │ Instant effect │
│ ↓ │ │ ↓ │
│ Hope it's better │ │ Test it yourself │
└────────────────────────┘ └────────────────────────┘สิ่งนี้สำหรับทุกคน:
- ทีม — สร้าง workflow ที่ตรงกับวิธีการทำงานจริงของคุณ
- ผู้ใช้ระดับสูง — ปรับ prompt เพื่อให้ได้ผลลัพธ์จาก AI ที่ดีขึ้นสำหรับ codebase ของคุณ
- ผู้มีส่วนร่วมใน OpenSpec — ทดลองแนวทางใหม่โดยไม่ต้องรอ release
เราทุกคนยังเรียนรู้ว่าอะไรดีที่สุด OPSX ช่วยให้เราร่วมเรียนรู้ไปด้วยกัน
ประสบการณ์ของผู้ใช้
ปัญหาของ workflow แบบเส้นตรง: คุณ "อยู่ในขั้นตอนการวางแผน" แล้ว "อยู่ในขั้นตอนการ implement" แล้ว "เสร็จ" แต่การทำงานจริงไม่ได้เป็นแบบนั้น คุณ implement บางอย่าง แล้วพบว่า design ผิด ต้องอัปเดต specs แล้ว continue implement ขั้นตอนแบบเส้นตรงขัดกับวิธีการทำงานจริง
แนวทางของ OPSX:
- Actions ไม่ใช่ phases — create, implement, update, archive — ทำอะไรก็ได้ตลอดเวลา
- Dependencies คือตัวช่วย — แสดงว่าอะไรเป็นไปได้ ไม่ใช่สิ่งที่ต้องทำถัดไป
proposal ──→ specs ──→ design ──→ tasks ──→ implementการตั้งค่า
# Make sure you have openspec installed — skills are automatically generated
openspec initสิ่งนี้จะสร้าง skills ใน .claude/skills/ (หรือเทียบเท่า) ที่ AI coding assistants จะตรวจจับอัตโนมัติ
โดยค่าเริ่มต้น OpenSpec ใช้ workflow profile core (propose, explore, apply, update, sync, archive) หากคุณต้องการ workflow commands ที่ขยาย (new, continue, ff, verify, bulk-archive, onboard) ให้ตั้งค่าด้วย openspec config profile แล้ว apply ด้วย openspec update
ระหว่างตั้งค่า คุณจะถูกถามให้สร้าง project config (openspec/config.yaml) สิ่งนี้เป็น optional แต่แนะนำ
การตั้งค่าโปรเจกต์
Project config ช่วยให้คุณตั้งค่าเริ่มต้นและ inject context เฉพาะโปรเจกต์เข้าไปใน artifact ทุกตัว
การสร้าง Config
Config ถูกสร้างระหว่าง openspec init หรือทำด้วยตนเอง:
# 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 | Context ของโปรเจกต์ที่ inject เข้าไปในคำสั่งของ artifact ทุกตัว |
rules | object | กฎเฉพาะ artifact ใช้ artifact ID เป็น key |
วิธีทำงาน
ลำดับความสำคัญของ Schema (สูงสุดไปต่ำสุด):
- CLI flag (
--schema <name>) - Change metadata (
.openspec.yamlใน change directory) - Project config (
openspec/config.yaml) - ค่าเริ่มต้น (
spec-driven)
การ inject Context:
- Context ถูก prepend เข้าไปในคำสั่งของ artifact ทุกตัว
- ห่อด้วยแท็ก
<context>...</context> - ช่วยให้ AI เข้าใจ conventions ของโปรเจกต์คุณ
การ inject Rules:
- Rules ถูก inject เฉพาะ artifact ที่ตรงกัน
- ห่อด้วยแท็ก
<rules>...</rules> - ปรากฏหลัง context ก่อน template
Artifact IDs ตาม Schema
spec-driven (ค่าเริ่มต้น):
proposal— ข้อเสนอการเปลี่ยนแปลงspecs— สเปคdesign— ออกแบบทางเทคนิคtasks— งาน implement
การตรวจสอบ Config
- Artifact IDs ที่ไม่รู้จักใน
rulesจะสร้าง warning - ชื่อ Schema ถูกตรวจสอบเทียบกับ schema ที่มีอยู่
- Context มีขีดจำกัดขนาด 50KB
- YAML ที่ไม่ถูกต้องจะถูกรายงานพร้อมหมายเลขบรรทัด
การแก้ไขปัญหา
"Unknown artifact ID in rules: X"
- ตรวจสอบว่า artifact IDs ตรงกับ schema ของคุณ (ดูรายการด้านบน)
- รัน
openspec schemas --jsonเพื่อดู artifact IDs ของแต่ละ schema
Config ไม่ถูก apply:
- ตรวจสอบว่าไฟล์อยู่ที่
openspec/config.yaml(ไม่ใช่.yml) - ตรวจสอบ syntax ของ YAML ด้วย validator
- การเปลี่ยนแปลง config มีผลทันที (ไม่ต้อง restart)
Context ใหญ่เกินไป:
- Context จำกัดที่ 50KB
- สรุปหรือ link ไปยังเอกสารภายนอกแทน
คำสั่ง
| คำสั่ง | ทำอะไร |
|---|---|
/opsx:propose | สร้างการเปลี่ยนแปลงและสร้าง planning artifacts ในขั้นตอนเดียว (เส้นทางด่วนค่าเริ่มต้น) |
/opsx:explore | คิดผ่านไอเดีย สำรวจปัญหา ทำความชัดเจนกับ requirements |
/opsx:new | เริ่มต้น scaffold การเปลี่ยนแปลงใหม่ (workflow ที่ขยาย) |
/opsx:continue | สร้าง artifact ถัดไป (workflow ที่ขยาย) |
/opsx:ff | Fast-forward planning artifacts (workflow ที่ขยาย) |
/opsx:apply | Implement tasks อัปเดต artifacts ตามความจำเป็น |
/opsx:update | แก้ไข planning artifacts ของการเปลี่ยนแปลงและรักษาความสอดคล้อง |
/opsx:verify | ตรวจสอบ implementation เทียบกับ artifacts (workflow ที่ขยาย) |
/opsx:sync | รวม delta specs เข้ากับ main specs (optional) |
/opsx:archive | Archive เมื่อเสร็จ |
/opsx:bulk-archive | Archive การเปลี่ยนแปลงที่เสร็จหลายรายการ (workflow ที่ขยาย) |
/opsx:onboard | นำทาง walkthrough การเปลี่ยนแปลง end-to-end (workflow ที่ขยาย) |
การใช้งาน
สำรวจไอเดีย
/opsx:exploreคิดผ่านไอเดีย สำรวจปัญหา เปรียบเทียบตัวเลือก ไม่ต้องมีโครงสร้าง — แค่ thinking partner เมื่อ insight ชัดเจน ให้เปลี่ยนไป /opsx:propose (ค่าเริ่มต้น) หรือ /opsx:new//opsx:ff (ขยาย)
เริ่มต้นการเปลี่ยนแปลงใหม่
/opsx:proposeสร้างการเปลี่ยนแปลงและสร้าง planning artifacts ที่จำเป็นก่อน implement
หากคุณเปิดใช้งาน workflow ที่ขยาย คุณสามารถใช้แทนได้:
/opsx:new # scaffold only
/opsx:continue # create one artifact at a time
/opsx:ff # create all planning artifacts at onceสร้าง artifacts
/opsx:continueแสดงว่าอะไรพร้อมสร้างตาม dependencies แล้วสร้าง artifact หนึ่งตัว ใช้ซ้ำเพื่อสร้างการเปลี่ยนแปลงของคุณแบบค่อยเป็นค่อยไป
/opsx:ff add-dark-modeสร้าง planning artifacts ทั้งหมดในครั้งเดียว ใช้เมื่อคุณมีภาพชัดเจนว่ากำลังสร้างอะไร
Implement (ส่วนที่ไหลลื่น)
/opsx:applyทำงานผ่าน tasks ติ๊กถูกเมื่อทำเสร็จ หากคุณกำลังจัดการการเปลี่ยนแปลงหลายรายการ คุณสามารถรัน /opsx:apply <name>; มิฉะนั้นมันควร infer จากบทสนทนาและถามให้คุณเลือกหากไม่สามารถระบุได้
อัปเดตการเปลี่ยนแปลง
/opsx:update add-dark-mode - we're storing the theme in a cookie nowแก้ไข planning artifacts ที่มีอยู่ของการเปลี่ยนแปลงและรักษาความสอดคล้อง — ในทิศทางใดก็ได้ (การแก้ไข design อาจย้อนกลับไปถึง proposal) เฉพาะ planning artifacts เท่านั้น: มันไม่แก้ไข code และมันไม่สร้าง artifacts ที่ขาดหาย (นั่นคือ /opsx:continue) ทุกการแก้ไขได้รับการยืนยันกับคุณก่อน หากการเปลี่ยนแปลงถูก implement แล้ว มันแนะนำ /opsx:apply เพื่อให้ code ตามทันแผนที่ถูกแก้ไข หากการแก้ไขของคุณเปลี่ยน intent ของการเปลี่ยนแปลง ให้เริ่มต้นใหม่แทน — ดู เมื่อไหร่ควร Update vs. เริ่มต้นใหม่
Sync delta specs
/opsx:syncรวม delta specs ของการเปลี่ยนแปลงปัจจุบันเข้ากับ openspec/specs/ หลักของคุณโดยไม่ archive — การเปลี่ยนแปลงยังคง active มัน apply delta ทั้งหมด: requirement ภายใต้ ## REMOVED จะถูกลบออกจาก main spec และที่เปลี่ยนชื่อจะถูกเปลี่ยนชื่อในตำแหน่งเดิม ส่วนเนื้อหาที่ delta ไม่ได้กล่าวถึงจะคงอยู่ตามเดิม Sync เป็น optional — archive จะถามให้คุณ sync ก่อนหากคุณยังไม่ได้ทำ ใช้เมื่อคุณต้องการให้ main specs อัปเดตก่อน archive เมื่อการเปลี่ยนแปลงแบบขนานต้องการสร้างบน specs ที่เพิ่งเพิ่ม หรือเมื่อคุณต้องการ review main spec ที่รวมแล้วก่อน archive
เสร็จสิ้น
/opsx:archive # Move to archive when done (prompts to sync specs if needed)เมื่อไหร่ควร Update vs. เริ่มต้นใหม่
คุณสามารถแก้ไข proposal หรือ specs ก่อน implement เสมอ แต่เมื่อไหร่ที่การปรับให้ดีขึ้นกลายเป็น "นี่คืองานที่ต่างออกไป"?
สิ่งที่ Proposal จับต้องได้
Proposal กำหนดสามสิ่ง:
- Intent — คุณกำลังแก้ปัญหาอะไร?
- Scope — อะไรอยู่ใน/อยู่นอกขอบเขต?
- Approach — คุณจะแก้ปัญหานี้อย่างไร?
คำถามคือ: อะไรเปลี่ยน และเปลี่ยนมากแค่ไหน?
อัปเดตการเปลี่ยนแปลงที่มีอยู่เมื่อ:
Intent เดิม การ execute ที่ปรับให้ดีขึ้น
- คุณพบ edge cases ที่ไม่ได้คิดไว้
- Approach ต้องปรับเล็กน้อยแต่เป้าหมายไม่เปลี่ยน
- Implementation เผยว่า design ผิดเล็กน้อย
Scope แคบลง
- คุณตระหนักว่า scope เต็มใหญ่เกินไป อยาก ship MVP ก่อน
- "Add dark mode" → "Add dark mode toggle (system preference in v2)"
การแก้ไขจากการเรียนรู้
- Codebase ไม่ได้จัดโครงสร้างอย่างที่คุณคิด
- Dependency ไม่ได้ทำงานตามที่คาดหวัง
- "Use CSS variables" → "Use Tailwind's dark: prefix instead"
เริ่มต้นการเปลี่ยนแปลงใหม่เมื่อ:
Intent เปลี่ยนแปลงอย่างพื้นฐาน
- ปัญหาเองต่างออกไปแล้ว
- "Add dark mode" → "Add comprehensive theme system with custom colors, fonts, spacing"
Scope ระเบิด
- การเปลี่ยนแปลงโตมากจนแทบจะเป็นงานที่ต่างออกไป
- Proposal เดิมจะจำไม่ได้หลังอัปเดต
- "Fix login bug" → "Rewrite auth system"
เดิมเสร็จได้
- การเปลี่ยนแปลงเดิมสามารถทำเครื่องหมายว่า "เสร็จ" ได้
- งานใหม่ยืนได้ด้วยตัวเอง ไม่ใช่การปรับให้ดีขึ้น
- เสร็จ "Add dark mode MVP" → Archive → การเปลี่ยนแปลงใหม่ "Enhance dark mode"
หลักเกณฑ์
┌─────────────────────────────────────┐
│ 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| การทดสอบ | Update | การเปลี่ยนแปลงใหม่ |
|---|---|---|
| ตัวตน | "สิ่งเดียวกัน ปรับให้ดีขึ้น" | "งานที่ต่างออกไป" |
| Scope overlap | >50% overlap | <50% overlap |
| การเสร็จสิ้น | ไม่สามารถ "เสร็จ" ได้โดยไม่มีการเปลี่ยนแปลง | เสร็จเดิมได้ งานใหม่ยืนได้ด้วยตัวเอง |
| เรื่องราว | Update chain บอกเรื่องราวที่สอดคล้อง | Patch จะทำให้สับสนมากกว่าชัดเจน |
หลักการ
Update รักษา context. การเปลี่ยนแปลงใหม่ให้ clarity.
เลือก update เมื่อประวัติการคิดของคุณมีคุณค่า เลือกใหม่เมื่อเริ่มต้นใหม่จะชัดเจนกว่าการ patch
คิดเหมือน git branches:
- Continue commit ขณะที่ทำงานบน feature เดิม
- เริ่มต้น branch ใหม่เมื่อเป็นงานใหม่จริงๆ
- บางครั้ง merge feature บางส่วนแล้วเริ่มต้นใหม่สำหรับ phase 2
มีความแตกต่างกันอย่างไร?
แบบเดิม (/openspec:proposal) | OPSX (/opsx:*) | |
|---|---|---|
| โครงสร้าง | เอกสารข้อเสนอขนาดใหญ่ฉบับเดียว | อาร์ติแฟกต์ที่แยกจากกันและมีความสัมพันธ์เชิงพึ่งพา |
| ขั้นตอนการทำงาน | ขั้นตอนแบบเส้นตรง: วางแผน → ดำเนินการ → บันทึกรหัส | การดำเนินการที่ยืดหยุ่น — ทำสิ่งใดก็ได้ในเวลาที่สะดวก |
| การปรับปรุงซ้ำ | ยากต่อการย้อนกลับไปแก้ไข | อัปเดตอาร์ติแฟกต์เมื่อเรียนรู้เพิ่มเติม |
| การปรับแต่ง | โครงสร้างตายตัว | ใช้สคีมาเป็นตัวกำหนด (สามารถกำหนดอาร์ติแฟกต์ของคุณเองได้) |
ข้อสรุปสำคัญ: งานไม่ได้เป็นไปตามเส้นตรงเสมอไป OPSX เลิกสมมติว่างานจะเป็นเช่นนั้น
การเจาะลึกสถาปัตยกรรม
ส่วนนี้อธิบายว่า OPSX ทำงานอย่างไรภายใน และเปรียบเทียบกับกระบวนการทำงานแบบเดิมอย่างไร ตัวอย่างในส่วนนี้ใช้ชุดคำสั่งที่ขยาย (new, continue ฯลฯ); ผู้ใช้ core เริ่มต้นสามารถแมปโฟลว์เดียวกันไปยัง propose → apply → sync → archive
ปรัชญา: เฟส vs การกระทำ
┌─────────────────────────────────────────────────────────────────────────────┐
│ LEGACY WORKFLOW │
│ (Phase-Locked, All-or-Nothing) │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
│ │ PLANNING │ ───► │ IMPLEMENTING │ ───► │ ARCHIVING │ │
│ │ PHASE │ │ PHASE │ │ PHASE │ │
│ └──────────────┘ └──────────────┘ └──────────────┘ │
│ │ │ │ │
│ ▼ ▼ ▼ │
│ /openspec:proposal /openspec:apply /openspec:archive │
│ │
│ • Creates ALL artifacts at once │
│ • Can't go back to update specs during implementation │
│ • Phase gates enforce linear progression │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────────────────────┐
│ OPSX WORKFLOW │
│ (Fluid Actions, Iterative) │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ ┌────────────────────────────────────────────┐ │
│ │ ACTIONS (not phases) │ │
│ │ │ │
│ │ new ◄──► continue ◄──► apply ◄──► archive │ │
│ │ │ │ │ │ │ │
│ │ └──────────┴───────────┴───────────┘ │ │
│ │ any order │ │
│ └────────────────────────────────────────────┘ │
│ │
│ • Create artifacts one at a time OR fast-forward │
│ • Update specs/design/tasks during implementation │
│ • Dependencies enable progress, phases don't exist │
│ │
└─────────────────────────────────────────────────────────────────────────────┘สถาปัตยกรรมคอมโพเนนต์
กระบวนการทำงานแบบเดิม ใช้เทมเพลตที่เขียนตายตัวใน TypeScript:
┌─────────────────────────────────────────────────────────────────────────────┐
│ LEGACY WORKFLOW COMPONENTS │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ Hardcoded Templates (TypeScript strings) │
│ │ │
│ ▼ │
│ Tool-specific configurators/adapters │
│ │ │
│ ▼ │
│ Generated Command Files (.claude/commands/openspec/*.md) │
│ │
│ • Fixed structure, no artifact awareness │
│ • Change requires code modification + rebuild │
│ │
└─────────────────────────────────────────────────────────────────────────────┘OPSX ใช้สคีมาภายนอกและเอนจินกราฟความสัมพันธ์:
┌─────────────────────────────────────────────────────────────────────────────┐
│ OPSX COMPONENTS │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ Schema Definitions (YAML) │
│ ┌─────────────────────────────────────────────────────────────────────┐ │
│ │ name: spec-driven │ │
│ │ artifacts: │ │
│ │ - id: proposal │ │
│ │ generates: proposal.md │ │
│ │ requires: [] ◄── Dependencies │ │
│ │ - id: specs │ │
│ │ generates: specs/**/*.md ◄── Glob patterns │ │
│ │ requires: [proposal] ◄── Enables after proposal │ │
│ └─────────────────────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ Artifact Graph Engine │
│ ┌─────────────────────────────────────────────────────────────────────┐ │
│ │ • Topological sort (dependency ordering) │ │
│ │ • State detection (filesystem existence) │ │
│ │ • Rich instruction generation (templates + context) │ │
│ └─────────────────────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ Skill Files (.claude/skills/openspec-*/SKILL.md) │
│ │
│ • Cross-editor compatible (Claude Code, Cursor, Devin) │
│ • Skills query CLI for structured data │
│ • Fully customizable via schema files │
│ │
└─────────────────────────────────────────────────────────────────────────────┘โมเดลกราฟความสัมพันธ์
ชิ้นงานสร้างเป็นกราฟมีทิศทางแบบไม่วน (DAG) ความสัมพันธ์เป็น ตัวเปิดใช้งาน ไม่ใช่ ตัวกั้น:
proposal
(root node)
│
┌─────────────┴─────────────┐
│ │
▼ ▼
specs design
(requires: (requires:
proposal) proposal)
│ │
└─────────────┬─────────────┘
│
▼
tasks
(requires:
specs, design)
│
▼
┌──────────────┐
│ APPLY PHASE │
│ (requires: │
│ tasks) │
└──────────────┘การเปลี่ยนสถานะ:
BLOCKED ────────────────► READY ────────────────► DONE
│ │ │
Missing All deps File exists
dependencies are DONE on filesystemการไหลของข้อมูล
กระบวนการทำงานแบบเดิม — เอเจนต์ได้รับคำสั่งแบบคงที่:
User: "/openspec:proposal"
│
▼
┌─────────────────────────────────────────┐
│ Static instructions: │
│ • Create proposal.md │
│ • Create tasks.md │
│ • Create design.md │
│ • Create delta spec files │
│ │
│ No awareness of what exists or │
│ dependencies between artifacts │
└─────────────────────────────────────────┘
│
▼
Agent creates ALL artifacts in one goOPSX — เอเจนต์สอบถามบริบทที่สมบูรณ์:
User: "/opsx:continue"
│
▼
┌──────────────────────────────────────────────────────────────────────────┐
│ Step 1: Query current state │
│ ┌────────────────────────────────────────────────────────────────────┐ │
│ │ $ openspec status --change "add-auth" --json │ │
│ │ │ │
│ │ { │ │
│ │ "artifacts": [ │ │
│ │ {"id": "proposal", "status": "done"}, │ │
│ │ {"id": "specs", "status": "ready"}, ◄── First ready │ │
│ │ {"id": "design", "status": "ready"}, │ │
│ │ {"id": "tasks", "status": "blocked", │ │
│ │ "missingDeps": ["specs", "design"]} │ │
│ │ ] │ │
│ │ } │ │
│ └────────────────────────────────────────────────────────────────────┘ │
│ │
│ Step 2: Get rich instructions for ready artifact │
│ ┌────────────────────────────────────────────────────────────────────┐ │
│ │ $ openspec instructions specs --change "add-auth" --json │ │
│ │ │ │
│ │ { │ │
│ │ "template": "# Specification\n\n## ADDED Requirements...", │ │
│ │ "dependencies": [{"id": "proposal", "path": "...", "done": true}│ │
│ │ "unlocks": ["tasks"] │ │
│ │ } │ │
│ └────────────────────────────────────────────────────────────────────┘ │
│ │
│ Step 3: Read dependencies → Create ONE artifact → Show what's unlocked │
└──────────────────────────────────────────────────────────────────────────┘โมเดลการวนซ้ำ
กระบวนการทำงานแบบเดิม — การวนซ้ำทำได้ยาก:
┌─────────┐ ┌─────────┐ ┌─────────┐
│/proposal│ ──► │ /apply │ ──► │/archive │
└─────────┘ └─────────┘ └─────────┘
│ │
│ ├── "Wait, the design is wrong"
│ │
│ ├── Options:
│ │ • Edit files manually (breaks context)
│ │ • Abandon and start over
│ │ • Push through and fix later
│ │
│ └── No official "go back" mechanism
│
└── Creates ALL artifacts at onceOPSX — การวนซ้ำอย่างเป็นธรรมชาติ:
/opsx:new ───► /opsx:continue ───► /opsx:apply ───► /opsx:archive
│ │ │
│ │ ├── "The design is wrong"
│ │ │
│ │ ▼
│ │ Just edit design.md
│ │ and continue!
│ │ │
│ │ ▼
│ │ /opsx:apply picks up
│ │ where you left off
│ │
│ └── Creates ONE artifact, shows what's unlocked
│
└── Scaffolds change, waits for directionสคีมาแบบกำหนดเอง
สร้างกระบวนการทำงานแบบกำหนดเองโดยใช้คำสั่งจัดการสคีมา:
# สร้างสคีมาใหม่ตั้งแต่ต้น (แบบโต้ตอบ)
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:
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 |
| การวนซ้ำ | ล็อกตามเฟส | ยืดหยุ่น แก้ไขอะไรก็ได้ |
| การรองรับโปรแกรมแก้ไข | คอนฟิกูเรเตอร์/อะแดปเตอร์เฉพาะเครื่องมือ | โฟลเดอร์ skills เดียว |
Schemas
Schemas กำหนดว่า artifacts มีอะไรบ้าง และความสัมพันธ์ระหว่างกัน ปัจจุบันมีดังนี้:
- spec-driven (ค่าเริ่มต้น): proposal → specs → design → tasks
# แสดงรายการ schemas ที่พร้อมใช้งาน
openspec schemas
# ดู schemas ทั้งหมดพร้อมแหล่งที่มาของการ resolve
openspec schema which --all
# สร้าง schema ใหม่แบบ interactive
openspec schema init my-workflow
# Fork schema ที่มีอยู่เพื่อปรับแต่ง
openspec schema fork spec-driven my-workflow
# ตรวจสอบโครงสร้าง schema ก่อนใช้งาน
openspec schema validate my-workflowเคล็ดลับ
- ใช้
/opsx:exploreเพื่อคิดทบทวนไอเดียก่อนตัดสินใจเปลี่ยนแปลง - ใช้
/opsx:ffเมื่อคุณรู้แล้วว่าต้องการอะไร และใช้/opsx:continueเมื่ออยู่ในโหมดสำรวจ - ระหว่าง
/opsx:applyหากมีอะไรผิดพลาด — แก้ไข artifact แล้วจึงดำเนินการต่อ - Tasks ติดตามความคืบหน้าผ่าน checkboxes ใน
tasks.md - ตรวจสอบสถานะได้ทุกเมื่อ:
openspec status --change "name"
ข้อเสนอแนะ
สิ่งนี้ยังหยาบอยู่ นั่นคือเจตนา — เราอยู่ระหว่างเรียนรู้ว่าอะไรได้ผล
พบ bug? มีไอเดีย? เข้าร่วมกับเราบน Discord หรือเปิด issue บน GitHub