การย้ายไปใช้ OPSX

คู่มือนี้ช่วยคุณเปลี่ยนจากเวิร์กโฟลว์ OpenSpec แบบเดิมไปสู่ OPSX การย้ายระบบได้รับการออกแบบมาให้ราบรื่น—งานที่มีอยู่ของคุณจะถูกเก็บรักษาไว้ และระบบใหม่ให้ความยืดหยุ่นมากขึ้น

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

OPSX แทนที่เวิร์กโฟลว์แบบล็อกเฟส (phase-locked) ด้วยแนวทางที่คล่องตัวและเน้นการดำเนินการ นี่คือจุดเปลี่ยนหลัก:

ด้าน	แบบเดิม (Legacy)	OPSX
คำสั่ง	/openspec:proposal, /openspec:apply, /openspec:archive	ค่าเริ่มต้น: /opsx:propose, /opsx:explore, /opsx:apply, /opsx:update, /opsx:schema, /opsx:archive (สามารถเพิ่มคำสั่งเวิร์กโฟลว์เพิ่มเติมได้)
เวิร์กโฟลว์	สร้างอาร์ติแฟกต์ทั้งหมดพร้อมกัน	สร้างแบบเพิ่มทีละส่วนหรือทั้งหมดพร้อมกัน—เลือกได้ตามต้องการ
การย้อนกลับ	ขั้นตอนการผ่านเฟสที่ทำได้ยาก	เป็นธรรมชาติ—อัปเดตอาร์ติแฟกต์ใดก็ได้ตลอดเวลา
การปรับแต่ง	โครงสร้างตายตัว	ขับเคลื่อนด้วย Schema ปรับแต่งได้อย่างเต็มที่
การกำหนดค่า	CLAUDE.md พร้อมมาร์คเกอร์ + project.md	การกำหนดค่าที่สะอาดตาใน openspec/config.yaml

การเปลี่ยนแปลงเชิงปรัชญา: งานไม่ได้เป็นเส้นตรง OPSX เลิก pretend ว่ามันเป็นเช่นนั้น

ก่อนเริ่ม

งานเดิมของคุณปลอดภัย

กระบวนการย้ายข้อมูลถูกออกแบบมาโดยคำนึงถึงการอนุรักษ์ข้อมูลเดิม:

• การเปลี่ยนแปลงที่กำลังดำเนินการใน openspec/changes/ — ถูกอนุรักษ์ไว้ทั้งหมด คุณสามารถดำเนินการต่อด้วยคำสั่ง OPSX ได้
• การเปลี่ยนแปลงที่เก็บถาวรแล้ว — ไม่ถูกแตะต้อง ประวัติของคุณยังคงสมบูรณ์
• สเปคหลักใน openspec/specs/ — ไม่ถูกแตะต้อง นี่คือแหล่งข้อมูลอ้างอิงของคุณ
• เนื้อหาของคุณใน CLAUDE.md, AGENTS.md ฯลฯ — ถูกอนุรักษ์ไว้ มีเพียงบล็อกเครื่องหมาย OpenSpec เท่านั้นที่ถูกนำออก ทุกสิ่งที่คุณเขียนไว้ยังคงอยู่

สิ่งที่ถูกนำออก

เฉพาะไฟล์ที่ OpenSpec จัดการและกำลังถูกแทนที่เท่านั้น:

สิ่งที่ถูกนำออก	เหตุผล
ディレクトリ/ไฟล์ของคำสั่ง slash แบบเดิม	ถูกแทนที่ด้วยระบบ skills ใหม่
openspec/AGENTS.md	ตัวกระตุ้น workflow ที่ล้าสมัย
เครื่องหมาย OpenSpec ใน CLAUDE.md, AGENTS.md ฯลฯ	ไม่จำเป็นอีกต่อไป

ตำแหน่งคำสั่งแบบเดิมตามเครื่องมือ (ตัวอย่าง—เครื่องมือของคุณอาจแตกต่างกัน):

• Claude Code: .claude/commands/openspec/
• Cursor: .cursor/commands/openspec-*.md
• Devin Desktop (เดิมชื่อ Windsurf): .windsurf/workflows/openspec-*.md
• Cline: .clinerules/workflows/openspec-*.md
• Roo: .roo/commands/openspec-*.md
• GitHub Copilot: .github/prompts/openspec-*.prompt.md (เฉพาะส่วนขยาย IDE; ไม่รองรับใน Copilot CLI)
• Codex: OpenSpec ปัจจุบันใช้เส้นทางมาตรฐาน .agents/skills/openspec-* ไฟล์ SKILL.md ที่ OpenSpec จัดการภายใต้เส้นทางเดิม .codex/skills จะถูกปรับให้สอดคล้องกันเฉพาะเมื่อมีไฟล์แทนที่อยู่แล้ว ไฟล์ที่กำหนดเองและสำเนาที่แตกต่างกันจะยังคงอยู่ที่เดิม หากต้นไม้ .agents ที่ไม่มีเครื่องหมายอยู่แล้วมี OpenSpec skills อยู่ OpenSpec จะอนุรักษ์การเรนเดอร์แบบเดิมของ Codex ($openspec-*) หรือแบบทั่วไป (/openspec-*) แทนที่จะเดาจากไดเรกทอรีแบบเดิม เลือก codex โดยเฉพาะด้วย openspec init เพื่อสลับความเป็นเจ้าของ การทำความสะอาด prompt แบบเดิมยังคงมุ่งเป้าไปที่เฉพาะชื่อไฟล์ที่ OpenSpec อนุญาตใน $CODEX_HOME/prompts หรือ ~/.codex/prompts เท่านั้น
• และอื่น ๆ (Augment, Continue, Amazon Q ฯลฯ)

การย้ายข้อมูลจะตรวจจับเครื่องมือที่คุณตั้งค่าไว้และทำความสะอาดไฟล์แบบเดิมของเครื่องมือเหล่านั้น

รายการสิ่งที่ถูกนำออกอาจดูยาว แต่ทั้งหมดนี้เป็นไฟล์ที่ OpenSpec สร้างขึ้นในครั้งแรก เนื้อหาของคุณเองจะไม่ถูกลบออกเลย

สิ่งที่ต้องได้รับความสนใจจากคุณ

มีไฟล์หนึ่งที่ต้องการการย้ายข้อมูลด้วยตนเอง:

openspec/project.md — ไฟล์นี้ไม่ถูกลบอัตโนมัติเพราะอาจมีบริบทโปรเจกต์ที่คุณเขียนไว้ คุณต้อง:

1. ทบทวนเนื้อหาภายใน
2. ย้ายบริบทที่มีประโยชน์ไปยัง openspec/config.yaml (ดูคำแนะนำด้านล่าง)
3. ลบไฟล์เมื่อพร้อม

เหตุผลที่เราทำ التغييرนี้:

ไฟล์ project.md เดิมเป็นแบบ passive—agents อาจอ่าน อาจไม่อ่าน อาจลืมสิ่งที่อ่าน เราพบว่าความน่าเชื่อถือไม่สม่ำเสมอ

บริบทใน config.yaml ใหม่ถูก ฉีดเข้าไปในทุกคำขอการวางแผนของ OpenSpec ซึ่งหมายความว่ากฎระเบียบ โปรเจกต์ สแต็กเทคโนโลยี และกฎของคุณจะอยู่ตลอดเมื่อ AI สร้าง artifacts ความน่าเชื่อถือสูงขึ้น

ข้อแลกเปลี่ยน:

เนื่องจากบริบทถูกฉีดเข้าไปในทุกคำขอ คุณควรเขียนให้กระชับ มุ่งเน้นสิ่งที่สำคัญจริง ๆ:

• สแต็กเทคโนโลยีและกฎระเบียบหลัก
• ข้อจำกัดที่ไม่ชัดเจนที่ AI ต้องรู้
• กฎที่เคยถูกละเลยบ่อยครั้ง

ไม่ต้องกังวลว่าจะทำให้สมบูรณ์แบบ เราเองก็กำลังเรียนรู้ว่าอะไรทำงานได้ดีที่สุด และเราจะปรับปรุงวิธีการฉีดบริบทอย่างต่อเนื่องจากการทดลอง

---

การรันการย้ายข้อมูล

ทั้ง openspec init และ openspec update จะตรวจจับไฟล์แบบเดิมและแนะนำคุณผ่านกระบวนการทำความสะอาดเดียวกัน ใช้ whichever ที่เหมาะกับสถานการณ์ของคุณ:

• การติดตั้งใหม่จะตั้งค่าเริ่มต้นที่ profile core (propose, explore, apply, update, sync, archive)
• การติดตั้งที่ย้ายข้อมูลแล้วจะอนุรักษ์ workflow ที่ติดตั้งไว้ก่อนหน้านี้โดยเขียน profile custom เมื่อจำเป็น

การใช้ openspec init

รันคำสั่งนี้หากคุณต้องการเพิ่มเครื่องมือใหม่หรือตั้งค่าเครื่องมือใหม่:

openspec init

คำสั่ง init จะตรวจจับไฟล์แบบเดิมและแนะนำคุณผ่านกระบวนการทำความสะอาด:

Upgrading to the new OpenSpec

OpenSpec now uses agent skills, the emerging standard across coding
agents. This simplifies your setup while keeping everything working
as before.

Files to remove
No user content to preserve:
  • .claude/commands/openspec/
  • openspec/AGENTS.md

Files to update
OpenSpec markers will be removed, your content preserved:
  • CLAUDE.md
  • AGENTS.md

Needs your attention
  • openspec/project.md
    We won't delete this file. It may contain useful project context.

    The new openspec/config.yaml has a "context:" section for planning
    context. This is included in every OpenSpec request and works more
    reliably than the old project.md approach.

    Review project.md, move any useful content to config.yaml's context
    section, then delete the file when ready.

? Upgrade and clean up legacy files? (Y/n)

สิ่งที่เกิดขึ้นเมื่อคุณตอบ yes:

1. ไดเรกทอรีคำสั่ง slash แบบเดิมถูกลบออก
2. เครื่องหมาย OpenSpec ถูกลบออกจาก CLAUDE.md, AGENTS.md ฯลฯ (เนื้อหาของคุณยังคงอยู่)
3. openspec/AGENTS.md ถูกลบ
4. Skills ใหม่ถูกติดตั้งใน .claude/skills/
5. openspec/config.yaml ถูกสร้างพร้อม schema เริ่มต้น

การใช้ openspec update

รันคำสั่งนี้หากคุณต้องการเพียงย้ายข้อมูลและรีเฟรชเครื่องมือที่มีอยู่ให้เป็นเวอร์ชันล่าสุด:

openspec update

คำสั่ง update จะตรวจจับและทำความสะอาด artifacts แบบเดิมเช่นกัน จากนั้นรีเฟรช skills/commands ที่สร้างให้ตรงกับ profile และค่าการส่งมอบปัจจุบันของคุณ

สิ่งแวดล้อมแบบ Non-Interactive / CI

สำหรับการย้ายข้อมูลด้วยสคริปต์:

openspec init --force --tools claude

แฟลก --force จะข้ามการถามและยอมรับการทำความสะอาดอัตโนมัติ

รวมถึงการทำความสะอาดไฟล์ prompt ของ Codex ที่ OpenSpec จัดการในไดเรกทอรี prompt ระดับ global ของ Codex การทำความสะอาดมุ่งเป้าไปที่เฉพาะชื่อไฟล์ prompt แบบเดิมของ Codex ที่ OpenSpec อนุญาตเท่านั้น ลบออกเฉพาะเมื่อมี skills แทนที่ .agents/skills/openspec-* อยู่แล้ว และอนุรักษ์ไฟล์อื่นทั้งหมด

---

การย้าย project.md ไปยัง config.yaml

ไฟล์ openspec/project.md เดิมเป็นไฟล์ markdown แบบอิสระสำหรับบริบทโปรเจกต์ ไฟล์ openspec/config.yaml ใหม่มีโครงสร้างและ—สำคัญที่สุด—ถูกฉีดเข้าไปในทุกคำขอการวางแผน เพื่อให้กฎระเบียบของคุณอยู่ตลอดเมื่อ AI ทำงาน

ก่อน (project.md)

# Project Context

This is a TypeScript monorepo using React and Node.js.
We use Jest for testing and follow strict ESLint rules.
Our API is RESTful and documented in docs/api.md.

## Conventions

- All public APIs must maintain backwards compatibility
- New features should include tests
- Use Given/When/Then format for specifications

หลัง (config.yaml)

schema: spec-driven

context: |
  Tech stack: TypeScript, React, Node.js
  Testing: Jest with React Testing Library
  API: RESTful, documented in docs/api.md
  We maintain backwards compatibility for all public APIs

rules:
  proposal:
    - Include rollback plan for risky changes
  specs:
    - Use Given/When/Then format for scenarios
    - Reference existing patterns before inventing new ones
  design:
    - Include sequence diagrams for complex flows

ความแตกต่างหลัก

project.md	config.yaml
Markdown แบบอิสระ	YAML ที่มีโครงสร้าง
ข้อความก้อนเดียว	บริบทและกฎแยกตาม artifact
ไม่ชัดเจนว่าถูกใช้เมื่อไหร่	บริบทปรากฏในทุก artifacts; กฎปรากฏเฉพาะใน artifacts ที่ตรงกันเท่านั้น
ไม่มีตัวเลือก schema	ฟิลด์ schema: ที่ชัดเจนกำหนด workflow เริ่มต้น

สิ่งที่ต้องเก็บ สิ่งที่ต้องทิ้ง

เมื่อย้ายข้อมูล ให้เลือกอย่างมีสติ ถามตัวเองว่า: "AI ต้องการสิ่งนี้สำหรับ ทุก คำขอการวางแผนหรือไม่?"

ผู้สมัครที่ดีสำหรับ context:

• สแต็กเทคโนโลยี (ภาษา เฟรมเวิร์ก ฐานข้อมูล)
• รูปแบบสถาปัตยกรรมหลัก (monorepo, microservices ฯลฯ)
• ข้อจำกัดที่ไม่ชัดเจน ("เราไม่สามารถใช้ไลบรารี X ได้เพราะ...")
• กฎระเบียบสำคัญที่เคยถูกละเลยบ่อยครั้ง

ย้ายไปยัง rules: แทน

• รูปแบบการจัดรูปแบบเฉพาะ artifact ("ใช้ Given/When/Then ใน specs")
• เกณฑ์การทบทวน ("proposal ต้องมีแผน rollback")
• สิ่งเหล่านี้ปรากฏเฉพาะใน artifact ที่ตรงกัน ทำให้คำขออื่นเบาขึ้น

ตัดออกทั้งหมด

• แนวปฏิบัติทั่วไปที่ AI รู้แล้ว
• คำอธิบายยาวที่สรุปได้
• บริบททางประวัติศาสตร์ที่ไม่ส่งผลต่องานปัจจุบัน

ขั้นตอนการย้ายข้อมูล

1. สร้าง config.yaml (หากยังไม่ได้สร้างโดย init):

   schema: spec-driven

2. เพิ่มบริบทของคุณ (ให้กระชับ—สิ่งนี้ถูกใส่ในทุกคำขอ):

   context: |
     Your project background goes here.
     Focus on what the AI genuinely needs to know.

3. เพิ่มกฎเฉพาะ artifact (ไม่บังคับ):

   rules:
     proposal:
       - Your proposal-specific guidance
     specs:
       - Your spec-writing rules

4. ลบ project.md เมื่อคุณย้ายทุกอย่างที่มีประโยชน์แล้ว

อย่าคิดมากไป เริ่มจากสิ่งจำเป็นและปรับปรุงไปเรื่อย ๆ หากคุณสังเกตเห็นว่า AI ขาดอะไรที่สำคัญ ให้เพิ่มเข้าไป หากบริบทดูอ้วนเกินไป ให้ตัดออก นี่คือเอกสารที่มีชีวิต

ต้องการความช่วยเหลือ? ใช้ Prompt นี้

หากคุณไม่แน่ใจว่าจะสรุป project.md ของคุณอย่างไร ให้ถาม AI assistant ของคุณ:

I'm migrating from OpenSpec's old project.md to the new config.yaml format.

Here's my current project.md:
[paste your project.md content]

Please help me create a config.yaml with:
1. A concise `context:` section (this gets injected into every planning request, so keep it tight—focus on tech stack, key constraints, and conventions that often get ignored)
2. `rules:` for specific artifacts if any content is artifact-specific (e.g., "use Given/When/Then" belongs in specs rules, not global context)

Leave out anything generic that AI models already know. Be ruthless about brevity.

AI จะช่วยคุณระบุสิ่งจำเป็น vs สิ่งที่สามารถตัดออกได้

---

คำสั่งใหม่

ความพร้อมใช้งานของคำสั่งขึ้นอยู่กับ profile:

เริ่มต้น (core profile):

คำสั่ง	วัตถุประสงค์
/opsx:propose	สร้างการเปลี่ยนแปลงและสร้าง artifacts การวางแผนในขั้นตอนเดียว
/opsx:explore	คิดผ่านไอเดียโดยไม่มีโครงสร้าง
/opsx:apply	ดำเนินการตามงานใน tasks.md
/opsx:update	แก้ไข artifacts การวางแผนของการเปลี่ยนแปลงและรักษาความสอดคล้อง
/opsx:sync	รวม delta specs เข้ากับ specs หลัก
/opsx:archive	สรุปและเก็บถาวรการเปลี่ยนแปลง

Workflow ขยาย (เลือกเอง):

คำสั่ง	วัตถุประสงค์
/opsx:new	เริ่มต้น scaffold การเปลี่ยนแปลงใหม่
/opsx:continue	สร้าง artifact ถัดไป (ทีละหนึ่ง)
/opsx:ff	Fast-forward—สร้าง artifacts การวางแผนพร้อมกัน
/opsx:verify	ตรวจสอบว่า implementation ตรงกับ specs
/opsx:bulk-archive	เก็บถาวรหลายการเปลี่ยนแปลงพร้อมกัน
/opsx:onboard	Workflow onboarding แบบนำทางจากต้นจนจบ

เปิดใช้งานคำสั่งขยายด้วย openspec config profile จากนั้นรัน openspec update

การแมปคำสั่งจากแบบเดิม

แบบเดิม	OPSX เทียบเท่า
/openspec:proposal	/opsx:propose (เริ่มต้น) หรือ /opsx:new แล้ว /opsx:ff (ขยาย)
/openspec:apply	/opsx:apply
/openspec:archive	/opsx:archive

ความสามารถใหม่

ความสามารถเหล่านี้เป็นส่วนหนึ่งของชุดคำสั่ง workflow ขยาย

การสร้าง artifact แบบละเอียด:

/opsx:continue

สร้าง artifact ทีละหนึ่งตาม dependencies ใช้เมื่อคุณต้องการทบทวนแต่ละขั้นตอน

โหมดสำรวจ:

/opsx:explore

คิดผ่านไอเดียกับพาร์ทเนอร์ก่อนตัดสินใจเปลี่ยนแปลง

ทำความเข้าใจสถาปัตยกรรมใหม่

จากแบบ Phase-Locked สู่ Fluid (ยืดหยุ่น)

เวิร์กโฟลว์เดิมบังคับให้ทำงานเป็นเส้นตรง:

┌──────────────┐      ┌──────────────┐      ┌──────────────┐
│   PLANNING   │ ───► │ IMPLEMENTING │ ───► │   ARCHIVING  │
│    PHASE     │      │    PHASE     │      │    PHASE     │
└──────────────┘      └──────────────┘      └──────────────┘

หากคุณกำลังอยู่ในขั้นตอน Implementation แล้วพบว่า Design ผิด?
ก็โชคร้ายล่ะ เพราะ Phase gates ไม่อนุญาตให้คุณย้อนกลับได้ง่ายๆ

OPSX ใช้ Actions แทน Phases:

         ┌───────────────────────────────────────────────┐
         │           ACTIONS (not phases)                │
         │                                               │
         │     new ◄──► continue ◄──► apply ◄──► archive │
         │      │          │           │             │   │
         │      └──────────┴───────────┴─────────────┘   │
         │                    any order                  │
         └───────────────────────────────────────────────┘

Dependency Graph

Artifacts จะสร้างเป็น directed graph โดย Dependencies เป็นตัวเปิดทาง (enablers) ไม่ใช่ประตูตรวจสอบ (gates):

                        proposal
                       (root node)
                            │
              ┌─────────────┴─────────────┐
              │                           │
              ▼                           ▼
           specs                       design
        (requires:                  (requires:
         proposal)                   proposal)
              │                           │
              └─────────────┬─────────────┘
                            │
                            ▼
                         tasks
                     (requires:
                     specs, design)

เมื่อคุณรัน /opsx:continue ระบบจะตรวจสอบว่าอะไรพร้อมใช้งาน และเสนอ Artifact ถัดไปให้คุณ นอกจากนี้ คุณยังสามารถสร้าง Artifacts ที่พร้อมใช้งานหลายรายการได้ตามลำดับใดก็ได้

Skills vs Commands

ระบบเดิมใช้ไฟล์คำสั่งที่เฉพาะเจาะจงกับเครื่องมือ:

.claude/commands/openspec/
├── proposal.md
├── apply.md
└── archive.md

OPSX ใช้มาตรฐาน skills ที่กำลังได้รับความนิยม:

.claude/skills/
├── openspec-explore/SKILL.md
├── openspec-new-change/SKILL.md
├── openspec-continue-change/SKILL.md
├── openspec-apply-change/SKILL.md
└── ...

Skills สามารถใช้งานได้ข้ามเครื่องมือเขียนโค้ดด้วย AI หลายตัว และให้ metadata ที่ richer กว่า

ใน OPSX, Codex รองรับเฉพาะ skills เท่านั้น OpenSpec不再生成 Codex custom prompt files; ให้ใช้ไดเรกทอรี .agents/skills/openspec-* ที่ถูกสร้างขึ้นแทน

---

การดำเนินการต่อจาก Changes ที่มีอยู่

Changes ที่กำลังดำเนินการของคุณจะทำงานร่วมกับคำสั่งของ OPSX ได้อย่างราบรื่น

มี Active change จากเวิร์กโฟลว์เดิม?

/opsx:apply add-my-feature

OPSX จะอ่าน Artifacts ที่มีอยู่แล้วและดำเนินการต่อจากจุดที่คุณหยุดไว้

ต้องการเพิ่ม Artifacts อื่นๆ เข้าไปใน Change ที่มีอยู่?

/opsx:continue add-my-feature

แสดงสิ่งที่พร้อมสร้างโดยอิงจากสิ่งที่มีอยู่แล้ว

ต้องการดูสถานะ?

openspec status --change add-my-feature

---

ระบบ Config ใหม่

โครงสร้าง config.yaml

# Required: Default schema สำหรับ changes ใหม่
schema: spec-driven

# Optional: Project context (สูงสุด 50KB)
# ถูก Inject เข้าไปใน Instructions ของทุก Artifact
context: |
  ข้อมูลพื้นหลังของโปรเจกต์, tech stack,
  conventions และ constraints ของคุณ

# Optional: กฎสำหรับแต่ละ Artifact
# จะถูก Inject เข้าไปใน Artifacts ที่ตรงกันเท่านั้น
rules:
  proposal:
    - Include rollback plan
  specs:
    - Use Given/When/Then format
  design:
    - Document fallback strategies
  tasks:
    - Break into 2-hour maximum chunks

การ Resolution Schema

เมื่อตัดสินใจว่าจะใช้ Schema ใด OPSX จะตรวจสอบตามลำดับดังนี้:

1. CLI flag: --schema <name> (มีความสำคัญสูงสุด)
2. Change metadata: .openspec.yaml ในไดเรกทอรีของ change
3. Project config: openspec/config.yaml
4. Default: spec-driven

Schemas ที่พร้อมใช้งาน

Schema	Artifacts	เหมาะสำหรับ
spec-driven	proposal → specs → design → tasks	โปรเจกต์ส่วนใหญ่

แสดง Schemas ทั้งหมดที่พร้อมใช้งาน:

openspec schemas

Custom Schemas

สร้าง workflow ของคุณเอง:

openspec schema init my-workflow

หรือ Fork จากอันที่มีอยู่แล้ว:

openspec schema fork spec-driven my-workflow

ดูรายละเอียดเพิ่มเติมได้ที่ Customization

---

การแก้ปัญหา (Troubleshooting)

"Legacy files detected in non-interactive mode"

คุณกำลังรันในสภาพแวดล้อม CI หรือแบบ Non-interactive ให้ใช้:

openspec init --force

คำสั่งไม่ปรากฏหลังจากการ Migration

รีสตาร์ท IDE ของคุณ Skills จะถูกตรวจจับเมื่อเริ่มต้นการทำงาน

"Unknown artifact ID in rules"

ตรวจสอบว่าคีย์ใน rules: ของคุณตรงกับ Artifact IDs ของ Schema ที่คุณใช้:

• spec-driven: proposal, specs, design, tasks

รันคำสั่งนี้เพื่อดู Artifact IDs ที่ถูกต้อง:

openspec schemas --json

Config ไม่ถูกนำไปใช้

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

project.md ไม่ได้รับการ Migration

ระบบตั้งใจเก็บ project.md ไว้เนื่องจากอาจมีเนื้อหาที่กำหนดเองของคุณ โปรดตรวจสอบด้วยตนเอง ย้ายส่วนที่มีประโยชน์ไปยัง config.yaml จากนั้นลบไฟล์ออก

ต้องการดูว่าจะมีการทำความสะอาดอะไรบ้าง?

รันคำสั่ง init แล้วปฏิเสธคำขอทำความสะอาด (cleanup prompt)—คุณจะเห็นสรุปการตรวจจับทั้งหมดโดยไม่มีการเปลี่ยนแปลงใดๆ เกิดขึ้น

---

สรุปอย่างรวดเร็ว (Quick Reference)

ไฟล์หลังการ Migration

project/
├── openspec/
│   ├── specs/                    # ไม่เปลี่ยนแปลง
│   ├── changes/                  # ไม่เปลี่ยนแปลง
│   │   └── archive/              # ไม่เปลี่ยนแปลง
│   └── config.yaml               # ใหม่: การกำหนดค่าโปรเจกต์
├── .claude/
│   └── skills/                   # ใหม่: OPSX skills
│       ├── openspec-propose/     # default core profile
│       ├── openspec-explore/
│       ├── openspec-apply-change/
│       ├── openspec-update-change/
│       ├── openspec-sync-specs/
│       ├── openspec-archive-change/
│       └── ...                   # expanded profile เพิ่ม new/continue/ff ฯลฯ
├── CLAUDE.md                     # ลบ OpenSpec markers ออกแล้ว เก็บเนื้อหาของคุณไว้
└── AGENTS.md                     # ลบ OpenSpec markers ออกแล้ว เก็บเนื้อหาของคุณไว้

สิ่งที่ถูกลบออกไป

• .claude/commands/openspec/ — แทนที่ด้วย .claude/skills/
• openspec/AGENTS.md — ล้าสมัย
• openspec/project.md — ย้ายไปยัง config.yaml แล้วลบออก
• บล็อก Marker ของ OpenSpec ใน CLAUDE.md, AGENTS.md เป็นต้น

ตารางสรุปคำสั่ง (Command Cheatsheet)

/opsx:propose      เริ่มอย่างรวดเร็ว (default core profile)
/opsx:apply        ดำเนินการตาม Tasks
/opsx:archive      เสร็จสิ้นและจัดเก็บถาวร

# Workflow แบบขยาย (หากเปิดใช้งาน):
/opsx:new          สร้างโครงสร้างพื้นฐานของ Change
/opsx:continue     สร้าง Artifact ถัดไป
/opsx:ff           สร้าง Planning artifacts

---

การขอความช่วยเหลือ

• Discord: discord.gg/YctCnvvshC
• GitHub Issues: github.com/Fission-AI/OpenSpec/issues
• Documentation: docs/opsx.md สำหรับข้อมูลอ้างอิงเต็มรูปแบบของ OPSX