Skip to content

ขั้นตอน OPSX

ยินดีรับความคิดเห็นบน Discord

มันคืออะไร?

OPSX คือขั้นตอนมาตรฐานสำหรับ OpenSpec ในปัจจุบัน

นี่คือ ขั้นตอนที่ยืดหยุ่นและเป็นวัฏจักร สำหรับการเปลี่ยนแปลง OpenSpec ไม่มีขั้นตอนที่ตายตัวอีกต่อไป — มีเพียงการกระทำที่คุณสามารถทำได้ทุกเมื่อ

เหตุผลที่สร้างเครื่องมือนี้

เวิร์กโฟลว์ OpenSpec แบบเดิมใช้งานได้ แต่มี ข้อจำกัดหลายประการ:

  • คำสั่งถูกฝังไว้ — อยู่ในโค้ด TypeScript คุณไม่สามารถแก้ไขได้
  • ทั้งหมดหรือไม่มีเลย — คำสั่งเดียวสร้างทุกอย่าง ไม่สามารถทดสอบชิ้นส่วนแยกได้
  • โครงสร้างตายตัว — เวิร์กโฟลว์เดียวกันสำหรับทุกคน ไม่สามารถปรับแต่งได้
  • กล่องดำ — เมื่อผลลัพธ์จาก AI ไม่ดี คุณไม่สามารถปรับแต่ง prompt ได้

OPSX เปิดให้ใช้งานได้อย่างอิสระ ตอนนี้ใครก็สามารถ:

  1. ทดลองกับคำสั่ง — แก้ไขเทมเพลต ดูว่า AI ทำได้ดีขึ้นหรือไม่
  2. ทดสอบอย่างละเอียด — ตรวจสอบคำสั่งของแต่ละ artifact อย่างอิสระ
  3. ปรับแต่งเวิร์กโฟลว์ — กำหนด artifact และความเชื่อมโยงของคุณเอง
  4. พัฒนาอย่างรวดเร็ว — เปลี่ยนเทมเพลต ทดสอบทันที ไม่ต้องสร้างใหม่
เวิร์กโฟลว์แบบเดิม:                     OPSX:
┌────────────────────────┐           ┌────────────────────────┐
│  ฝังอยู่ในแพ็กเกจ      │           │  schema.yaml           │◄── คุณแก้ไขไฟล์นี้
│  (ไม่สามารถแก้ไขได้)    │           │  templates/*.md        │◄── หรือไฟล์นี้
│        ↓               │           │        ↓               │
│  รอเวอร์ชันใหม่        │           │  มีผลทันที             │
│        ↓               │           │        ↓               │
│  หวังว่าจะดีขึ้น       │           │  ทดสอบด้วยตัวเอง       │
└────────────────────────┘           └────────────────────────┘

เครื่องมือนี้สำหรับทุกคน:

  • ทีม — สร้างเวิร์กโฟลว์ที่ตรงกับวิธีการทำงานจริงของคุณ
  • ผู้ใช้ขั้นสูง — ปรับแต่ง prompt เพื่อให้ได้ผลลัพธ์ AI ที่ดีขึ้นสำหรับโค้ดเบสของคุณ
  • ผู้มีส่วนร่วมใน OpenSpec — ทดลองวิธีการใหม่ๆ โดยไม่ต้องรอเวอร์ชันใหม่

เราทุกคนยังคงเรียนรู้ว่าอะไรดีที่สุด OPSX ช่วยให้เราเรียนรู้ร่วมกัน

ประสบการณ์ผู้ใช้

ปัญหาของเวิร์กโฟลว์แบบเส้นตรง: คุณอยู่ใน "ขั้นตอนการวางแผน" จากนั้น "ขั้นตอนการพัฒนา" แล้วก็ "เสร็จสิ้น" แต่การทำงานจริงไม่ได้เป็นแบบนั้น คุณพัฒนาบางอย่าง ตระหนักว่าการออกแบบผิด ต้องอัปเดตสเปก แล้วพัฒนาต่อ ขั้นตอนแบบเส้นตรงขัดแย้งกับวิธีการทำงานจริง

วิธีการของ OPSX:

  • การกระทำ ไม่ใช่ขั้นตอน — สร้าง พัฒนา อัปเดต เก็บถาวร — ทำได้ทุกอย่างทุกเมื่อ
  • ความเชื่อมโยงเป็นตัวอำนวยความสะดวก — แสดงสิ่งที่เป็นไปได้ ไม่ใช่สิ่งที่ต้องทำต่อไป
  proposal ──→ specs ──→ design ──→ tasks ──→ implement

การตั้งค่า

bash
# ตรวจสอบว่าคุณได้ติดตั้ง openspec แล้ว — skills จะถูกสร้างโดยอัตโนมัติ
openspec init

คำสั่งนี้จะสร้าง skills ใน .claude/skills/ (หรือตำแหน่งที่เทียบเท่า) ซึ่ง AI coding assistant จะตรวจจับโดยอัตโนมัติ

ตามค่าเริ่มต้น OpenSpec ใช้โปรไฟล์เวิร์กโฟลว์ core (propose, explore, apply, archive) หากคุณต้องการคำสั่งเวิร์กโฟลว์ที่ขยายเพิ่ม (new, continue, ff, verify, sync, bulk-archive, onboard) ให้กำหนดค่าด้วย openspec config profile และนำไปใช้ด้วย openspec update

ระหว่างการตั้งค่า คุณจะได้รับแจ้งให้สร้าง การกำหนดค่าโปรเจกต์ (openspec/config.yaml) ซึ่งเป็นทางเลือกแต่แนะนำให้ทำ

การกำหนดค่าโปรเจกต์

การกำหนดค่าโปรเจกต์ช่วยให้คุณตั้งค่าเริ่มต้นและใส่บริบทเฉพาะโปรเจกต์ลงในทุก artifact

การสร้างการกำหนดค่า

การกำหนดค่าจะถูกสร้างระหว่าง 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

ฟิลด์การกำหนดค่า

ฟิลด์ประเภทคำอธิบาย
schemastringSchema เริ่มต้นสำหรับการเปลี่ยนแปลงใหม่ (เช่น spec-driven)
contextstringบริบทโปรเจกต์ที่ใส่ลงในคำสั่งของทุก artifact
rulesobjectกฎสำหรับแต่ละ artifact โดยใช้ artifact ID เป็นคีย์

วิธีการทำงาน

ลำดับความสำคัญของ Schema (จากสูงไปต่ำ):

  1. แฟล็ก CLI (--schema <name>)
  2. เมตาดาต้าการเปลี่ยนแปลง (.openspec.yaml ในไดเรกทอรีการเปลี่ยนแปลง)
  3. การกำหนดค่าโปรเจกต์ (openspec/config.yaml)
  4. ค่าเริ่มต้น (spec-driven)

การใส่บริบท:

  • บริบทจะถูกเพิ่มไว้ด้านหน้าคำสั่งของทุก artifact
  • ห่อไว้ในแท็ก <context>...</context>
  • ช่วยให้ AI เข้าใจข้อตกลงของโปรเจกต์คุณ

การใส่กฎ:

  • กฎจะถูกใส่เฉพาะ artifact ที่ตรงกันเท่านั้น
  • ห่อไว้ในแท็ก <rules>...</rules>
  • ปรากฏหลังบริบท ก่อนเทมเพลต

Artifact IDs ตาม Schema

spec-driven (ค่าเริ่มต้น):

  • proposal — ข้อเสนอการเปลี่ยนแปลง
  • specs — ข้อกำหนด
  • design — การออกแบบทางเทคนิค
  • tasks — งานพัฒนา

การตรวจสอบการกำหนดค่า

  • Artifact IDs ที่ไม่รู้จักใน rules จะสร้างคำเตือน
  • ชื่อ schema จะถูกตรวจสอบกับ schema ที่มีอยู่
  • บริบทมีขนาดจำกัด 50KB
  • YAML ที่ไม่ถูกต้องจะรายงานพร้อมหมายเลขบรรทัด

การแก้ไขปัญหา

"Unknown artifact ID in rules: X"

  • ตรวจสอบว่า artifact IDs ตรงกับ schema ของคุณ (ดูรายการด้านบน)
  • รัน openspec schemas --json เพื่อดู artifact IDs สำหรับแต่ละ schema

การกำหนดค่าไม่ถูกนำไปใช้:

  • ตรวจสอบว่าไฟล์อยู่ที่ openspec/config.yaml (ไม่ใช่ .yml)
  • ตรวจสอบไวยากรณ์ YAML ด้วยตัวตรวจสอบ
  • การเปลี่ยนแปลงการกำหนดค่าจะมีผลทันที (ไม่ต้องรีสตาร์ท)

บริบทมีขนาดใหญ่เกินไป:

  • บริบทจำกัดที่ 50KB
  • สรุปหรือลิงก์ไปยังเอกสารภายนอกแทน

คำสั่ง

คำสั่งหน้าที่
/opsx:proposeสร้างการเปลี่ยนแปลงและสร้าง artifact สำหรับการวางแผนในขั้นตอนเดียว (เส้นทางด่วนเริ่มต้น)
/opsx:exploreคิดทบทวนไอเดีย ตรวจสอบปัญหา ชี้แจงข้อกำหนด
/opsx:newเริ่มโครงสร้างการเปลี่ยนแปลงใหม่ (เวิร์กโฟลว์ที่ขยาย)
/opsx:continueสร้าง artifact ถัดไป (เวิร์กโฟลว์ที่ขยาย)
/opsx:ffข้ามขั้นตอน 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        # สร้างโครงสร้างเท่านั้น
/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. เริ่มใหม่

คุณสามารถแก้ไขข้อเสนอหรือ specs ได้เสมอ trướcการพัฒนา แต่เมื่อใดการปรับปรุงจะกลายเป็น "งานที่แตกต่าง"?

สิ่งที่ Proposal บันทึก

Proposal กำหนดสามสิ่ง:

  1. เจตนา — คุณกำลังแก้ปัญหาอะไร?
  2. ขอบเขต — อะไรอยู่ใน/นอกขอบเขต?
  3. วิธีการ — คุณจะแก้ไขอย่างไร?

คำถามคือ: สิ่งใดเปลี่ยนไป และเปลี่ยนมากน้อยเพียงใด?

อัปเดตการเปลี่ยนแปลงที่มีอยู่เมื่อ:

เจตนาเดียวกัน การดำเนินการปรับปรุง

  • คุณพบกรณีขอบที่ไม่ได้พิจารณา
  • วิธีการต้องปรับแต่งเล็กน้อยแต่เป้าหมายไม่เปลี่ยน
  • การพัฒนาเปิดเผยว่าการออกแบบผิดพลาดเล็กน้อย

ขอบเขตแคบลง

  • คุณตระหนักว่าขอบเขตเต็มมีขนาดใหญ่เกินไป ต้องการส่ง MVP ก่อน
  • "เพิ่มโหมดมืด" → "เพิ่มสวิตช์โหมดมืด (ความต้องการระบบใน v2)"

การแก้ไขจากการเรียนรู้

  • โครงสร้างโค้ดเบสไม่เป็นไปตามที่คุณคิด
  • ความเชื่อมโยงไม่ทำงานตามที่คาดไว้
  • "ใช้ CSS variables" → "ใช้ dark: prefix ของ Tailwind แทน"

เริ่มการเปลี่ยนแปลงใหม่เมื่อ:

เจตนาเปลี่ยนแปลงอย่างมีนัยสำคัญ

  • ปัญหาเองตอนนี้แตกต่างกัน
  • "เพิ่มโหมดมืด" → "เพิ่มระบบธีมที่ครอบคลุมพร้อมสี ฟอนต์ และระยะห่างที่กำหนดเอง"

ขอบเขตขยายใหญ่

  • การเปลี่ยนแปลงเติบโตมากจนเป็นงานที่แตกต่างโดยพื้นฐาน
  • ข้อเสนอเดิมจะไม่สามารถจำแนกได้หลังการอัปเดต
  • "แก้ไขบั๊กล็อกอิน" → "เขียนระบบ auth ใหม่"

ต้นฉบับสามารถเสร็จสิ้นได้

  • การเปลี่ยนแปลงเดิมสามารถทำเครื่องหมาย "เสร็จสิ้น"
  • งานใหม่เป็นอิสระ ไม่ใช่การปรับปรุง
  • เสร็จสิ้น "เพิ่ม MVP โหมดมืด" → เก็บถาวร → การเปลี่ยนแปลงใหม่ "ปรับปรุงโหมดมืด"

หลักเกณฑ์

                        ┌─────────────────────────────────────┐
                        │     นี่เป็นงานเดียวกันหรือไม่?      │
                        └──────────────┬──────────────────────┘

                    ┌──────────────────┼──────────────────┐
                    │                  │                  │
                    ▼                  ▼                  ▼
             เจตนาเดียวกัน?      >50% ทับซ้อน?      ต้นฉบับสามารถ
             ปัญหาเดียวกัน?     ขอบเขตเดียวกัน?    "เสร็จสิ้น" ได้โดย
                    │                  │          ไม่มีการเปลี่ยนแปลง
                    │                  │          เหล่านี้?
          ┌────────┴────────┐  ┌──────┴──────┐   ┌───────┴───────┐
          │                 │  │             │   │               │
         ใช่               ไม่ ใช่           ไม่  ไม่              ใช่
          │                 │  │             │   │               │
          ▼                 ▼  ▼             ▼   ▼               ▼
       อัปเดต            ใหม่ อัปเดต       ใหม่  อัปเดต          ใหม่
การทดสอบอัปเดตการเปลี่ยนแปลงใหม่
ตัวตน"สิ่งเดียวกัน ปรับปรุง""งานที่แตกต่าง"
ขอบเขตทับซ้อน>50% ทับซ้อน<50% ทับซ้อน
การเสร็จสิ้นไม่สามารถ "เสร็จสิ้น" ได้โดยไม่มีการเปลี่ยนแปลงสามารถเสร็จสิ้นต้นฉบับ งานใหม่เป็นอิสระ
เรื่องราวสายการอัปเดตเล่าเรื่องราวที่สอดคล้องกันการแก้ไขจะทำให้สับสนมากกว่าชี้แจง

หลักการ

การอัปเดตสงวนบริบท การเปลี่ยนแปลงใหม่ให้ความชัดเจน

เลือกอัปเดตเมื่อประวัติความคิดของคุณมีคุณค่า เลือกใหม่เมื่อการเริ่มต้นใหม่จะชัดเจนกว่าการแก้ไข

คิดว่ามันเหมือนกับ git branches:

  • คอมมิตต่อไปเรื่อยๆ ขณะทำงานในฟีเจอร์เดียวกัน
  • เริ่ม branch ใหม่เมื่อเป็นงานใหม่จริงๆ
  • บางครั้ง merge ฟีเจอร์บางส่วนและเริ่มใหม่สำหรับเฟสที่ 2

มีอะไรเปลี่ยนไปบ้าง?

แบบเดิม (/openspec:proposal)OPSX (/opsx:*)
โครงสร้างเอกสารข้อเสนอฉบับเดียวชิ้นงานที่แยกจากกันพร้อมการเชื่อมโยง
ขั้นตอนการทำงานขั้นตอนเชิงเส้น: วางแผน → ดำเนินการ → จัดเก็บการกระทำที่ยืดหยุ่น — ทำได้ทุกอย่างทุกเมื่อ
การวนซ้ำย้อนกลับได้ยากอัปเดตชิ้นงานตามที่คุณเรียนรู้
การปรับแต่งโครงสร้างที่ตายตัวขับเคลื่อนด้วย Schema (กำหนดชิ้นงานของคุณเอง)

ข้อสังเกตสำคัญ: งานไม่ได้เป็นเส้นตรง OPSX หยุดแกล้งทำเป็นว่ามันเป็นเช่นนั้น

การวิเคราะห์สถาปัตยกรรมเชิงลึก

ส่วนนี้อธิบายวิธีการทำงานของ OPSX ภายใต้ hood และเปรียบเทียบกับเวิร์กโฟลว์แบบเดิม ตัวอย่างในส่วนนี้ใช้ชุดคำสั่งที่ขยาย (new, continue, ฯลฯ) ผู้ใช้ core แบบเริ่มต้นสามารถแมปขั้นตอนเดียวกันไปยัง propose → apply → archive

ปรัชญา: ขั้นตอน vs การกระทำ

┌─────────────────────────────────────────────────────────────────────────────┐
│                         เวิร์กโฟลว์แบบเดิม                                   │
│                    (ล็อกขั้นตอน, ทั้งหมดหรือไม่มีเลย)                        │
├─────────────────────────────────────────────────────────────────────────────┤
│                                                                             │
│   ┌──────────────┐      ┌──────────────┐      ┌──────────────┐             │
│   │   ขั้นตอน    │ ───► │   ขั้นตอน    │ ───► │   ขั้นตอน    │             │
│   │   การวางแผน  │      │   การดำเนินการ│      │   การจัดเก็บ  │             │
│   └──────────────┘      └──────────────┘      └──────────────┘             │
│         │                     │                     │                       │
│         ▼                     ▼                     ▼                       │
│   /openspec:proposal   /openspec:apply      /openspec:archive              │
│                                                                             │
│   • สร้างเอกสารทั้งหมดพร้อมกันในครั้งเดียว                                  │
│   • ไม่สามารถย้อนกลับไปอัปเดตข้อกำหนดระหว่างการดำเนินการ                     │
│   • ประตูขั้นตอนบังคับให้ดำเนินไปแบบเส้นตรง                                 │
│                                                                             │
└─────────────────────────────────────────────────────────────────────────────┘


┌─────────────────────────────────────────────────────────────────────────────┐
│                         เวิร์กโฟลว์ OPSX                                     │
│                      (การกระทำที่ลื่นไหล, แบบวนซ้ำ)                         │
├─────────────────────────────────────────────────────────────────────────────┤
│                                                                             │
│              ┌────────────────────────────────────────────┐                 │
│              │           การกระทำ (ไม่ใช่ขั้นตอน)         │                 │
│              │                                            │                 │
│              │   new ◄──► continue ◄──► apply ◄──► archive │                 │
│              │    │          │           │           │    │                 │
│              │    └──────────┴───────────┴───────────┘    │                 │
│              │              ลำดับใดก็ได้                   │                 │
│              └────────────────────────────────────────────┘                 │
│                                                                             │
│   • สร้างเอกสารทีละรายการ หรือ ข้ามไปข้างหน้า                               │
│   • อัปเดตข้อกำหนด/การออกแบบ/งานระหว่างการดำเนินการ                        │
│   • ความขึ้นอยู่กับทำให้เกิดความคืบหน้า ไม่มีขั้นตอน                         │
│                                                                             │
└─────────────────────────────────────────────────────────────────────────────┘

สถาปัตยกรรมส่วนประกอบ

เวิร์กโฟลว์แบบเดิม ใช้เทมเพลตที่ hardcode ไว้ใน TypeScript:

┌─────────────────────────────────────────────────────────────────────────────┐
│                      ส่วนประกอบเวิร์กโฟลว์แบบเดิม                            │
├─────────────────────────────────────────────────────────────────────────────┤
│                                                                             │
│   เทมเพลตที่ hardcode ไว้ (สตริง 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)


                          ┌──────────────┐
                          │ ขั้นตอน APPLY │
                          │ (ต้องการ:    │
                          │  tasks)      │
                          └──────────────┘

การเปลี่ยนสถานะ:

   BLOCKED ────────────────► READY ────────────────► 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

# หรือ 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 ที่ hardcode ไว้YAML + Markdown ภายนอก
ความขึ้นอยู่กับไม่มี (ทั้งหมดพร้อมกัน)DAG พร้อมการเรียงลำดับเชิงอรรถ
สถานะแบบจำลองจิตใจที่อิงขั้นตอนการมีอยู่ในระบบไฟล์
การปรับแต่งแก้ไขซอร์ส, สร้างใหม่สร้าง schema.yaml
การวนซ้ำล็อกขั้นตอนลื่นไหล, แก้ไขอะไรก็ได้
การรองรับตัวแก้ไขตัวกำหนดค่า/อะแดปเตอร์เฉพาะเครื่องมือไดเรกทอรีทักษะเดียว

สคีมา

สคีมาจะกำหนดว่ามีชิ้นงานใดบ้างและความเชื่อมโยงระหว่างกัน ปัจจุบันมีสคีมาที่พร้อมใช้งานดังนี้:

  • spec-driven (ค่าเริ่มต้น): proposal → specs → design → tasks
bash
# แสดงรายการสคีมาที่มีอยู่
openspec schemas

# แสดงสคีมาทั้งหมดพร้อมแหล่งที่มาของการตัดสินใจ
openspec schema which --all

# สร้างสคีมาใหม่แบบโต้ตอบ
openspec schema init my-workflow

# คัดลอกสคีมาที่มีอยู่เพื่อปรับแต่ง
openspec schema fork spec-driven my-workflow

# ตรวจสอบโครงสร้างสคีมาก่อนใช้งาน
openspec schema validate my-workflow

เคล็ดลับ

  • ใช้ /opsx:explore เพื่อพิจารณาแนวคิดก่อนตัดสินใจเปลี่ยนแปลง
  • ใช้ /opsx:ff เมื่อคุณรู้แล้วว่าต้องการอะไร หรือ /opsx:continue เมื่อยังกำลังสำรวจ
  • ระหว่าง /opsx:apply หากมีบางอย่างไม่ถูกต้อง — แก้ไขชิ้นงานก่อน แล้วจึงดำเนินการต่อ
  • งานจะติดตามความคืบหน้าผ่านช่องทำเครื่องหมายใน tasks.md
  • ตรวจสอบสถานะได้ตลอดเวลา: openspec status --change "name"

ข้อเสนอแนะ

ส่วนนี้ยังอยู่ในขั้นต้น ซึ่งเป็นเจตนา — เรากำลังเรียนรู้ว่าสิ่งใดใช้ได้ผล

พบข้อผิดพลาด? มีความคิดเห็น? เข้าร่วมกับเราบน Discord หรือเปิด issue บน GitHub