อ้างอิง CLI

OpenSpec CLI (openspec) ให้คำสั่งเทอร์มินัลสำหรับการตั้งค่าโปรเจกต์ การตรวจสอบความถูกต้อง การตรวจสอบสถานะ และการจัดการ คำสั่งเหล่านี้เป็นส่วนเสริมของคำสั่ง Slash ของ AI (เช่น /opsx:propose) ที่อธิบายไว้ใน คำสั่ง

Summary

หมวดหมู่	คำสั่ง	วัตถุประสงค์
การตั้งค่า	`init`, `update`	เริ่มต้นและอัปเดต OpenSpec ในโปรเจกต์ของคุณ
สโตร์ (repo OpenSpec แยกต่างหาก)	`store setup`, `store register`, `store unregister`, `store remove`, `store list`, `store doctor`	จัดการสโตร์ — repo OpenSpec แยกต่างหากที่คุณได้ลงทะเบียนไว้
สุขภาพระบบ	`doctor`	รายงานสุขภาพความสัมพันธ์ของรากที่ได้รับการระบุ
บริบทการทำงาน	`context`	รวบรวมชุดการทำงาน (ราก + สโตร์ที่อ้างอิง)
เวิร์กเซตส่วนตัว	`workset create`, `workset list`, `workset open`, `workset remove`	เก็บและเปิดมุมมองการทำงานส่วนตัวในเครื่องของคุณผ่านเครื่องมือของคุณ
การเรียกดู	`list`, `view`, `show`	สำรวจการเปลี่ยนแปลงและสเปค
การตรวจสอบความถูกต้อง	`validate`	ตรวจสอบการเปลี่ยนแปลงและสเปคเพื่อหาปัญหา
วงจรชีวิต	`archive`	สรุปการเปลี่ยนแปลงที่เสร็จสมบูรณ์
เวิร์กโฟลว์	`new change`, `status`, `instructions`, `templates`, `schemas`	สนับสนุนเวิร์กโฟลว์ที่ขับเคลื่อนด้วยอาร์ติแฟกต์
สคีมา	`schema init`, `schema fork`, `schema validate`, `schema which`	สร้างและจัดการเวิร์กโฟลว์ที่กำหนดเอง
การกำหนดค่า	`config`	ดูและแก้ไขการตั้งค่า
เครื่องมือช่วย	`feedback`, `completion`	ฟีดแบ็กและการบูรณาการกับเชลล์

คำสั่งสำหรับมนุษย์ vs เอเจนต์

ส่วนใหญ่ของคำสั่ง CLI ออกแบบมาเพื่อ ใช้งานโดยมนุษย์ ในเทอร์มินัล บางคำสั่งยังรองรับ ใช้งานโดยเอเจนต์/สคริปต์ ผ่านเอาต์พุต JSON

คำสั่งสำหรับมนุษย์เท่านั้น

คำสั่งเหล่านี้มีปฏิสัมพันธ์และออกแบบมาเพื่อใช้งานในเทอร์มินัล:

คำสั่ง	วัตถุประสงค์
`openspec init`	เริ่มต้นโปรเจกต์ (พร้อมแจ้งเตือนแบบปฏิสัมพันธ์)
`openspec view`	แดชบอร์ดแบบปฏิสัมพันธ์
`openspec workset open <name>`	เปิด workset ที่บันทึกไว้ (หน้าต่างแก้ไขหรือเซสชันเอเจนต์ในเทอร์มินัล)
`openspec config edit`	เปิดไฟล์คอนฟิกในโปรแกรมแก้ไข
`openspec feedback`	ส่งความคิดเห็นผ่าน GitHub
`openspec completion install`	ติดตั้งคำเติมเต็มสำหรับเชลล์

คำสั่งที่รองรับเอเจนต์

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

คำสั่ง	ใช้งานโดยมนุษย์	ใช้งานโดยเอเจนต์
`openspec list`	เบราต์การเปลี่ยนแปลง/สเปค	ใช้ `--json` เพื่อรับข้อมูลที่มีโครงสร้าง
`openspec show <item>`	อ่านเนื้อหา	ใช้ `--json` เพื่อแยกวิเคราะห์
`openspec validate`	ตรวจสอบปัญหา	ใช้ `--all --json` เพื่อตรวจสอบจำนวนมาก
`openspec status`	ดูความคืบหน้าของอาร์ติแฟกต์	ใช้ `--json` เพื่อรับสถานะที่มีโครงสร้าง
`openspec instructions`	รับขั้นตอนต่อไป	ใช้ `--json` เพื่อรับคำแนะนำสำหรับเอเจนต์
`openspec templates`	ค้นหาพาธของเทมเพลต	ใช้ `--json` เพื่อแก้ไขพาธ
`openspec schemas`	รายการสคีมาที่มีอยู่	ใช้ `--json` เพื่อค้นหาสคีมา
`openspec store setup <id>`	สร้างและลงทะเบียนสโตร์ท้องถิ่น	ใช้ `--json` พร้อมอินพุตที่ชัดเจนเพื่อรับเอาต์พุตการตั้งค่าที่มีโครงสร้าง
`openspec store register <path>`	ลงทะเบียนสโตร์ที่มีอยู่	ใช้ `--json` เพื่อรับเอาต์พุตการลงทะเบียนที่มีโครงสร้าง
`openspec store unregister <id>`	ลบการลงทะเบียนสโตร์ท้องถิ่น	ใช้ `--json` เพื่อรับเอาต์พุตการทำความสะอาดที่มีโครงสร้าง
`openspec store remove <id>`	ลบโฟลเดอร์สโตร์ท้องถิ่นที่ลงทะเบียนไว้	ใช้ `--yes --json` เพื่อลบแบบไม่ต้องปฏิสัมพันธ์
`openspec store list`	เบราต์สโตร์ที่ลงทะเบียนไว้	ใช้ `--json` เพื่อรับรายการลงทะเบียนที่มีโครงสร้าง
`openspec store doctor`	ตรวจสอบการตั้งค่าสโตร์ท้องถิ่น	ใช้ `--json` เพื่อรับการวินิจฉัยที่มีโครงสร้าง
`openspec new change <id>`	สร้าง scaffolding การเปลี่ยนแปลงในรีโปท้องถิ่น	ใช้ `--json` และเพิ่ม `--store <id>` เพื่อใช้สโตร์ที่ลงทะเบียนเป็นรากของ OpenSpec
`openspec workset create [name]`	สร้างมุมมองการทำงานส่วนตัว	ใช้ `--member <path> --json` เพื่อสร้างแบบไม่ต้องปฏิสัมพันธ์
`openspec workset list`	เบราต์ workset ที่บันทึกไว้	ใช้ `--json` เพื่อรับมุมมองที่มีโครงสร้าง
`openspec workset remove <name>`	ลบมุมมองที่บันทึกไว้	ใช้ `--yes --json` เพื่อลบแบบไม่ต้องปฏิสัมพันธ์

ตัวเลือกทั่วโลก

ตัวเลือกเหล่านี้ทำงานกับคำสั่งทั้งหมด:

ตัวเลือก	คำอธิบาย
`--version`, `-V`	แสดงหมายเลขเวอร์ชัน
`--no-color`	ปิดการแสดงผลสี
`--help`, `-h`	แสดงความช่วยเหลือสำหรับคำสั่ง

คำสั่งการตั้งค่า

`openspec init`

เริ่มต้น OpenSpec ในโปรเจกต์ของคุณ สร้างโครงสร้างโฟลเดอร์และกำหนดค่าเครื่องมือ AI ที่เชื่อมต่อ

พฤติกรรมเริ่มต้นใช้ค่าพื้นฐานของคอนฟิกทั่วโลก: โพรไฟล์ core, การส่งมอบ both, เวิร์กโฟลว์ propose, explore, apply, sync, archive

openspec init [path] [options]

อาร์กิวเมนต์:

อาร์กิวเมนต์	จำเป็น	คำอธิบาย
`path`	ไม่	ไดเร็กทอรีเป้าหมาย (ค่าเริ่มต้น: ไดเร็กทอรีปัจจุบัน)

ตัวเลือก:

ตัวเลือก	คำอธิบาย
`--tools <list>`	กำหนดค่าเครื่องมือ AI แบบไม่ต้องปฏิสัมพันธ์ ใช้ `all`, `none`, หรือรายการที่คั่นด้วยจุลภาค
`--force`	ล้างไฟล์เลเกซี่อัตโนมัติโดยไม่ต้องถาม
`--profile <profile>`	กำหนดค่าโพรไฟล์ทั่วโลกสำหรับการเริ่มต้นนี้ (`core` หรือ `custom`)

--profile custom จะใช้เวิร์กโฟลว์ที่เลือกไว้ปัจจุบันในคอนฟิกทั่วโลก (openspec config profile)

รหัสเครื่องมือที่รองรับ (--tools): amazon-q, antigravity, auggie, bob, claude, cline, codeartsagent, codex, forgecode, codebuddy, continue, costrict, crush, cursor, factory, gemini, github-copilot, hermes, iflow, junie, kilocode, kimi, kiro, lingma, vibe, oh-my-pi, opencode, pi, qoder, qwen, roocode, trae, windsurf, zcode

รายการนี้สอดคล้องกับ AI_TOOLS ใน src/core/config.ts. ดู เครื่องมือที่รองรับ เพื่อดูสกิลและพาธคำสั่งของแต่ละเครื่องมือ

ตัวอย่าง:

bash

# Interactive initialization
openspec init

# Initialize in a specific directory
openspec init ./my-project

# Non-interactive: configure for Claude and Cursor
openspec init --tools claude,cursor

# Configure for all supported tools
openspec init --tools all

# Override profile for this run
openspec init --profile core

# Skip prompts and auto-cleanup legacy files
openspec init --force

สิ่งที่ถูกสร้าง:

openspec/
├── specs/              # สเปคของคุณ (เป็นแหล่งข้อมูลที่เชื่อถือได้)
├── changes/            # การเปลี่ยนแปลงที่เสนอ
└── config.yaml         # คอนฟิกโปรเจกต์

.claude/skills/         # สกิล Claude Code (หากเลือก claude)
.cursor/skills/         # สกิล Cursor (หากเลือก cursor)
.cursor/commands/       # คำสั่ง Cursor OPSX (หากการส่งมอบรวมคำสั่ง)
... (คอนฟิกเครื่องมืออื่นๆ)

`openspec update`

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

openspec update [path] [options]

อาร์กิวเมนต์:

อาร์กิวเมนต์	จำเป็น	คำอธิบาย
`path`	ไม่	ไดเร็กทอรีเป้าหมาย (ค่าเริ่มต้น: ไดเร็กทอรีปัจจุบัน)

ตัวเลือก:

ตัวเลือก	คำอธิบาย
`--force`	บังคับให้อัปเดตแม้ไฟล์จะเป็นเวอร์ชันล่าสุดแล้ว

ตัวอย่าง:

bash

# อัปเดตไฟล์คำแนะนำหลังจากอัปเกรด npm
npm update @fission-ai/openspec
openspec update

สโตร์ (รีโป OpenSpec แยกต่างหาก)

เบต้า. สโตร์และฟีเจอร์ที่สร้างขึ้นบนพื้นฐานของมัน (การอ้างอิง, บริบทการทำงาน, workset) เป็นรายการใหม่ ชื่อคำสั่ง แฟล็ก รูปแบบไฟล์ และเอาต์พุต JSON อาจมีการเปลี่ยนแปลงระหว่างเวอร์ชันต่างๆ สำหรับคำแนะนำที่เน้นปัญหาก่อน, ดู คู่มือสโตร์

สโตร์คือรีโป OpenSpec แยกต่างหากที่คุณลงทะเบียนบนเครื่องนี้ ตัวอย่างเช่น รีโปการวางแผนหรือรีโปสัญญา การลงทะเบียนสโตร์ทำให้คำสั่งทั่วไป (list, show, status, validate, new change, archive, ...) สามารถทำงานในนั้นได้จากทุกที่โดยส่ง --store <id>

`openspec store setup`

สร้างและลงทะเบียนสโตร์ท้องถิ่น เมื่อไม่มีการส่งอาร์กิวเมนต์ในเทอร์มินัล OpenSpec จะแนะนำผู้ใช้ผ่านขั้นตอนการตั้งค่า เอเจนต์และสคริปต์ควรส่งอินพุตที่ชัดเจนและใช้ --json

bash

openspec store setup [id] [options]

ตัวเลือก:

ตัวเลือก	คำอธิบาย
`--path <path>`	โฟลเดอร์ที่สโตร์ควรอยู่ (ตัวอย่างเช่น `~/openspec/<id>`)
`--remote <url>`	บันทึกรีโมตหลักใน `store.yaml` ของสโตรีใหม่
`--init-git`	เริ่มต้นรีโป Git พร้อมคอมมิตเริ่มต้น (ค่าเริ่มต้น)
`--no-init-git`	ข้ามทุกการดำเนินการ Git: ไม่มีการเริ่มต้น ไม่มีคอมมิตเริ่มต้น
`--json`	ออกเอาต์พุต JSON

การรันแบบไม่ต้องปฏิสัมพันธ์ (--json, สคริปต์, เอเจนต์) ต้องส่งทั้งรหัสสโตร์และ --path ในเทอร์มินัลแบบปฏิสัมพันธ์ การตั้งค่าจะถามตำแหน่งพร้อมคำแนะนำที่สามารถแก้ไขได้ในตำแหน่งที่มองเห็นได้และเป็นของผู้ใช้ (ตัวอย่างเช่น ~/openspec/<id>); มันไม่เคยใช้ค่าเริ่มต้นเป็นไดเร็กทอรีข้อมูลที่จัดการโดย OpenSpec

ตัวอย่าง:

bash

openspec store setup
openspec store setup team-context
openspec store setup team-context --path ~/openspec/team-context --no-init-git
openspec store setup team-context --path ~/openspec/team-context --no-init-git --json

`openspec store register`

ลงทะเบียนโฟลเดอร์สโตร์ท้องถิ่นที่มีอยู่ ระหว่างช่วงเบต้าของสโตร์ รากอาจถูกลงทะเบียนก่อนที่มีการเปลี่ยนแปลง สเปคถูกนำไปใช้ หรือการเปลี่ยนแปลงถูกเก็บถาวร; ในกรณีนั้น openspec/changes/, openspec/specs/, และ openspec/changes/archive/ อาจขาดอยู่จนกว่าคำสั่งทั่วไปจะสร้างไฟล์เหล่านั้น รีโปที่มีเพียงคอนฟิกที่ประกาศ store: <id> จะยังคงเป็นตัวชี้ไปยังสโตร์อื่นและไม่ถูกลงทะเบียนเป็นรากสโตร์เว้นแต่ว่าตัวชี้นั้นจะถูกลบออก

bash

openspec store register [path] [options]

ตัวเลือก:

ตัวเลือก	คำอธิบาย
`--id <id>`	รหัสสโตร์; ค่าเริ่มต้นเป็นข้อมูลเมตาของสโตร์หรือชื่อโฟลเดอร์
`--yes`	ยืนยันการสร้างข้อมูลเมตประจำตัวสโตร์สำหรับราก OpenSpec ที่ปกติ
`--json`	ออกเอาต์พุต JSON

`openspec store unregister`

ลบการลงทะเบียนสโตร์ท้องถิ่นออกโดยไม่ลบไฟล์

bash

openspec store unregister <id> [--json]

ใช้เมื่อสโตร์ถูกย้าย, คลอนไปที่อื่น, หรือไม่ควรแสดงโดย OpenSpec บนเครื่องนี้อีกต่อไป

`openspec store remove`

ลบการลงทะเบียนสโตร์ท้องถิ่นออกและลบโฟลเดอร์ท้องถิ่นของมัน

bash

openspec store remove <id> [--yes] [--json]

remove จะแสดงโฟลเดอร์ที่แน่นอนก่อนลบในเทอร์มินัลแบบปฏิสัมพันธ์ เอเจนต์ สคริปต์ และผู้เรียก JSON ต้องส่ง --yes เพื่อยืนยันการลบ OpenSpec ปฏิเสธการลบโฟลเดอร์ที่ไม่มีการเก็บข้อมูลเมตของสโตร์ที่ตรงกัน

`openspec store list`

รายการสโตร์ที่ลงทะเบียนในเครื่อง

bash

openspec store list [--json]
openspec store ls [--json]

`openspec store doctor`

ตรวจสอบการลงทะเบียนสโตร์ท้องถิ่น ข้อมูลเมต และการมีอยู่ของ Git

bash

openspec store doctor [id] [--json]

Doctor ทำหน้าที่วินิจฉัยเท่านั้น; มันรายงานรากที่ขาด ข้อมูลเมตที่ไม่ตรงกัน และสถานะรีจิสทรีท้องถิ่นที่ไม่ถูกต้องโดยไม่แก้ไขสโตร์

การอ้างอิงสโตร์จากโปรเจกต์

รีโปโปรเจกต์สามารถประกาศว่าสโตร์ใดบ้างที่งานของมันใช้ข้อมูลจากใน openspec/config.yaml:

yaml

schema: spec-driven
references:
  - team-context

ตั้งแต่นั้นเป็นต้นไป เอาต์พุตของ openspec instructions ในรีโปนั้น (ทั้งพื้นผิวต่ออาร์ติแฟกต์และ apply โหมด JSON และโหมดสำหรับมนุษย์) จะพร้อมดัชนีของสเปคของแต่ละสโตร์ที่อ้างอิง — รหัสสเปค สรุปหนึ่งบรรทัดจากส่วน Purpose ของแต่ละสเปค และคำสั่งดึงข้อมูล (openspec show <spec-id> --type spec --store <id>) ดัชนีนี้สร้างแบบสดจากเช็คเอาต์ที่ลงทะเบียนในแต่ละครั้งที่รัน; เนื้อหาสเปคไม่เคยถูกคัดลอกลงในเอาต์พุต

การอ้างอิงเป็นบริบทแบบอ่านเท่านั้น พวกมันไม่เคยเปลี่ยนตำแหน่งที่คำสั่งทำงาน: งานยังคงอยู่ในรากของรีโปเอง และการเขียนไปยังสโตร์ที่อ้างอิงยังคงเป็นการกระทำ --store ที่ชัดเจน การอ้างอิงที่ไม่สามารถแก้ไขได้ (ตัวอย่างเช่น สโตร์ที่ไม่ได้ลงทะเบียนบนเครื่องนี้) จะลดระดับเป็นคำเตือนในดัชนีพร้อมวิธีแก้ไขที่แน่นอน และคำแนะนำยังคงถูกสร้าง openspec doctor รายงานสุขภาพของการอ้างอิงในที่เดียว

การบันทึกตำแหน่งที่สโตร์ถูกคลอนมาจาก

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

bash

openspec store setup team-context --path ~/openspec/team-context \
  --remote git@github.com:acme/team-context.git

รีโมตจะถูกบันทึกใน .openspec-store/store.yaml ภายในคอมมิตเริ่มต้น เพื่อให้การคลอนทุกครั้งรู้จักรีโมตนี้โดยเกิดมาแล้ว สำหรับสโตร์ที่มีอยู่ แก้ไข store.yaml ด้วยตนเองและคอมมิต store doctor จะแสดงรีโมตที่บันทึกไว้ (และต้นกำเนิด Git ของเช็คเอาต์ที่สังเกตเห็น); คำแนะนำในการแบ่งปันระหว่าง setup และ register จะระบุชื่อมัน; และ register จะบันทึกต้นกำเนิดของเช็คเอาต์ในรีจิสทรีเฉพาะเครื่อง

การประกาศการอ้างอิงสามารถพกพาต้นทางการคลอนด้วยเช่นกัน เพื่อให้เพื่อนร่วมทีมที่ยังไม่มีสโตร์ได้รับวิธีแก้ไขที่สมบูรณ์และสามารถวางได้ (git clone <remote> <path> && openspec store register <path> --id <id>):

yaml

references:
  - { id: team-context, remote: "git@github.com:acme/team-context.git" }

การบันทึกรีโมตไม่ใช่การซิงค์: OpenSpec ไม่เคยคลอน ดึง หรือพุชด้วยตัวเอง

การประกาศสโตร์เริ่มต้น

รีโปที่มีการวางแผนภายนอกทั้งหมด — ไม่มี openspec/specs/ หรือ openspec/changes/ ในเครื่อง — สามารถประกาศสโตร์ของมันเพียงครั้งเดียวแทนที่จะส่ง --store ในทุกคำสั่ง:

yaml

# openspec/config.yaml (ไฟล์เดียวภายใต้ openspec/)
store: team-context

คำสั่งทั่วไปจะแก้ไขไปยังสโตร์ที่ประกาศโดยอัตโนมัติ; แบนเนอร์รากและบล็อก JSON root รายงาน source: "declared" พร้อมรหัสสโตร์ และคำใบ้ที่พิมพ์ออกยังคงมี --store <id> การประกาศนี้เป็นตัวสำรอง ไม่ใช่ตัวแทนที่เขียนทับ: --store ที่ชัดเจนจะชนะเสมอ และไดเร็กทอรีที่มีโฟลเดอร์วางแผนจริงจะเพิกเฉยต่อตัวชี้ (พร้อมคำเตือน) เพื่อแปลงรีโปตัวชี้เป็นราก OpenSpec ในเครื่อง ลบบรรทัด store: และรัน openspec init — init ปฏิเสธการสร้าง scaffolding ในขณะที่การประกาศยังคงอยู่

ตัวแปรระดับเครื่องครอบคลุมทุกรีโปทันที: openspec config set defaultStore <id> (ดู การกำหนดค่า) มันถูก consults เท่านั้นหลังจากที่ --store, รากท้องถิ่น และตัวชี้โปรเจกต์ล้มเหลวในการแก้ไขทั้งหมด; แบนเนอร์รากและบล็อก JSON root จากนั้นจะรายงาน source: "global_default".

Doctor (สุขภาพความสัมพันธ์)

คำถามแบบอ่านอย่างเดียวเพียงหนึ่งคำในหนึ่งตำแหน่ง: รากของ OpenSpec มีสุขภาพดีหรือไม่ และ store ที่อ้างอิงไปถึงพร้อมใช้งานบนเครื่องนี้หรือไม่?

bash

openspec doctor [--store <id>] [--json]

รายงานนี้แบ่งเป็นสุขภาพของราก, สุขภาพของ metadata ของ store (รวมถึงบันทึกเมื่อ recorded remote กับ origin ของ checkout แตกต่างกัน และบันทึกเมื่อ checkout ของ store ล้าหลังจาก upstream tracking ref ที่ดึงล่าสุด) และสุขภาพของ reference (แสดงคำแนะนำการวินิจฉัยแบบเดียวกัน พร้อมวิธีแก้ไขด้วยการ clone สำหรับ reference ที่ยังไม่สามารถแก้ไขได้) ผลการตรวจสอบสุขภาพไม่ว่าจะมีระดับความรุนแรงใด ๆ จะส่งค่ากลับ 0 — เอเจนต์จะอ่านอาร์เรย์ status; เฉพาะเมื่อคำสั่งล้มเหลว (ไม่มีราก, store ที่ไม่รู้จัก) เท่านั้นที่จะส่งค่ากลับ 1 Doctor ไม่เคยทำการ clone, sync หรือแก้ไขใด ๆ หากต้องการรับชุดข้อมูลที่ประกอบรวมกันเองแทนการตรวจสอบสุขภาพของชุดนั้น ให้ใช้ openspec context

Working context (ชุดที่ประกอบรวมกัน)

ทุกสิ่งที่งานนี้เกี่ยวข้องผ่านการประกาศของ OpenSpec ในหนึ่งชุดทำงาน: รากของ OpenSpec และ store ที่อ้างอิงไปถึง

bash

openspec context [--store <id>] [--json] [--code-workspace <path> [--force]]

สรุป JSON สามารถใช้งานได้โดยเอเจนต์ (แต่ละ store ที่อ้างอิงพร้อมใช้งานจะมี fetch recipe ของตัวเอง; สมาชิกที่ยังไม่สามารถแก้ไขได้จะมีคำแนะนำการแก้ไขแบบเดียวกับที่ doctor แสดง) พารามิเตอร์ --code-workspace จะเขียนไฟล์ workspace ของ VS Code เพิ่มเติมซึ่งประกอบด้วยรากและ store ที่อ้างอิงพร้อมใช้งาน (โฟลเดอร์ ref:<id>) — นี่คือการเขียนไฟล์เพียงอย่างเดียวที่คำสั่งนี้ทำ หากไฟล์นั้นมีอยู่แล้วจะถูกปฏิเสธเว้นแต่ใช้ --force สมาชิกที่ไม่พร้อมใช้งานจะถูกรายงานเท่านั้น ไม่เคยถูกเดาคาดเดา

"Working context" คือชุดที่ประกอบรวมกัน; ฟิลด์ context: ใน openspec/config.yaml คือข้อมูลพื้นหลังของโปรเจกต์ที่ถูกแทรกเข้าไปในคำแนะนำ — สิ่งที่แตกต่างกันสองอย่าง openspec doctor ตอบว่าชุดนั้นมีสุขภาพดีหรือไม่; openspec context ตอบว่าชุดนั้นคืออะไร

Worksets ส่วนบุคคล

เบต้า. Worksets เป็นส่วนหนึ่งของพื้นผิวเบต้าใหม่; คำสั่ง แฟล็ก และรูปแบบไฟล์อาจมีการเปลี่ยนแปลงระหว่างการอัปเดตแต่ละครั้ง สำหรับคำแนะนำการใช้งานแบบทีละขั้น ให้ดูที่ คู่มือร้านค้า

Workset คือมุมมองส่วนบุคคลที่มีชื่อของโฟลเดอร์ที่คุณทำงานร่วมกัน — โฟลเดอร์รากสำหรับการวางแผน พร้อมโฟลเดอร์อื่นๆ ที่คุณเลือกเพิ่ม — ถูกเก็บไว้บนเครื่องของคุณและเปิดใหม่ด้วยชื่อในเครื่องมือของคุณ เป็นข้อมูลเฉพาะในเครื่องเท่านั้น: ไม่เคยถูกคอมมิต ไม่เคยถูกแชร์ ไม่เคยถูกสร้างจากคำประกาศ และการลบ workset จะไม่ส่งผลกระทบต่อโฟลเดอร์สมาชิกใดๆ เลย

bash

openspec workset create [name] [--member <path> | --member <name>=<path>]... [--tool <id>] [--json]
openspec workset list [--json]
openspec workset open <name> [--tool <id>]
openspec workset remove <name> [--yes] [--json]

คำสั่ง create จะเรียกใช้ขั้นตอนการสร้างแบบมีคำแนะนำสั้น (หรือรับค่าแฟล็ก --member โดยไม่ต้องโต้ตอบ; สมาชิกแรกเป็นสมาชิกหลัก — เซสชันจะเริ่มต้นที่นั่น) คำสั่ง open จะเปิดเครื่องมือที่เลือก: เอดิเตอร์ (VS Code, Cursor) จะเปิดหน้าต่างพร้อมสมาชิกทั้งหมดแล้วคืนค่ากลับ; เอเจนต์ CLI (Claude Code, codex) จะนำ control เทอร์มินัลนี้เป็นเซสชันพร้อมสมาชิกทั้งหมดเชื่อมต่ออยู่ และไม่มีคำถามที่กรอกไว้ล่วงหน้า เซสชันจะสิ้นสุดเมื่อคุณออกจากโปรแกรม หากโฟลเดอร์สมาชิกหายไปในขณะเปิด ระบบจะข้ามไปพร้อมแสดงบันทึก; ส่วนที่เหลือจะถูกเปิด การตั้งค่าเครื่องมือที่บันทึกไว้สามารถแทนที่ได้ทุกครั้งที่เปิดด้วยแฟล็ก --tool

การรองรับเครื่องมือใหม่เป็นการกำหนดค่าเท่านั้น ไม่ใช่การเขียนโค้ด เครื่องมือแต่ละเครื่องจะมีหนึ่งในสองรูปแบบการเปิดใช้งาน — workspace-file (เปิดด้วยไฟล์ .code-workspace ที่สร้างอัตโนมัติ) หรือ attach-dirs (ใช้หนึ่งแฟล็กเชื่อมต่อต่อสมาชิกหนึ่งรายการ) — และคีย์ openers ในไฟล์ config.json ทั่วไป (เปิดไฟล์นี้ด้วยคำสั่ง openspec config edit) ใช้เพื่อเพิ่มเครื่องมือหรือปรับแต่งเครื่องมือในตัวตามแต่ละฟิลด์:

json

{
  "openers": {
    "zed": { "style": "workspace-file" },
    "claude": { "attach_flag": "--dir" }
  }
}

สถานะทั้งหมดของ workset จะอยู่ในโฟลเดอร์ worksets/ ภายใต้โฟลเดอร์ข้อมูล全局ของระบบ (ซึ่งประกอบด้วยมุมมองที่บันทึกไว้ และไฟล์ <name>.code-workspace ที่สร้างอัตโนมัติ ซึ่งจะถูกสร้างใหม่ทุกครั้งที่เปิด); การลบโฟลเดอร์นี้จะลบร่องรอยทั้งหมดของ workset ทิ้งไป

คำสั่งสำหรับการเรียกดู

`openspec list`

แสดงรายการการเปลี่ยนแปลงหรือสเปคในโปรเจกต์ของคุณ

openspec list [options]

ตัวเลือก:

ตัวเลือก	คำอธิบาย
`--specs`	แสดงรายการสเปคแทนการเปลี่ยนแปลง
`--changes`	แสดงรายการการเปลี่ยนแปลง (ค่าเริ่มต้น)
`--sort <order>`	เรียงลำดับตาม `recent` (ค่าเริ่มต้น) หรือ `name`
`--json`	ส่งออกในรูปแบบ JSON

ตัวอย่าง:

bash

# แสดงรายการการเปลี่ยนแปลงที่ใช้งานอยู่ทั้งหมด
openspec list

# แสดงรายการสเปคทั้งหมด
openspec list --specs

# เอาต์พุต JSON สำหรับสคริปต์
openspec list --json

เอาต์พุต (ข้อความ):

การเปลี่ยนแปลง:
  add-dark-mode     ไม่มีงาน      เมื่อสักครู่

`openspec view`

แสดงแดชบอร์ดแบบโต้ตอบสำหรับเรียกดูสเปคและการเปลี่ยนแปลง

openspec view

เปิดอินเทอร์เฟซบนเทอร์มินัลสำหรับนำทางไปยังสเปคและการเปลี่ยนแปลงในโปรเจกต์ของคุณ

`openspec show`

แสดงรายละเอียดของการเปลี่ยนแปลงหรือสเปค

openspec show [item-name] [options]

อาร์กิวเมนต์:

อาร์กิวเมนต์	จำเป็น	คำอธิบาย
`item-name`	ไม่	ชื่อของการเปลี่ยนแปลงหรือสเปค (จะแจ้งให้ป้อนหากไม่ระบุ)

ตัวเลือก:

ตัวเลือก	คำอธิบาย
`--type <type>`	ระบุประเภท: `change` หรือ `spec` (จะตรวจจับอัตโนมัติหากไม่สับสน)
`--json`	ส่งออกในรูปแบบ JSON
`--no-interactive`	ปิดการแจ้งให้ป้อนข้อมูล

ตัวเลือกเฉพาะสำหรับการเปลี่ยนแปลง:

ตัวเลือก	คำอธิบาย
`--deltas-only`	แสดงเฉพาะสเปค delta (ในโหมด JSON)

ตัวเลือกเฉพาะสำหรับสเปค:

ตัวเลือก	คำอธิบาย
`--requirements`	แสดงเฉพาะข้อกำหนด ไม่รวมสถานการณ์ (ในโหมด JSON)
`--no-scenarios`	ไม่รวมเนื้อหาสถานการณ์ (ในโหมด JSON)
`-r, --requirement <id>`	แสดงข้อกำหนดเฉพาะตามดัชนีเริ่มต้นที่ 1 (ในโหมด JSON)

ตัวอย่าง:

bash

# การเลือกแบบโต้ตอบ
openspec show

# แสดงการเปลี่ยนแปลงเฉพาะ
openspec show add-dark-mode

# แสดงสเปคเฉพาะ
openspec show auth --type spec

# เอาต์พุต JSON สำหรับการแยกวิเคราะห์
openspec show add-dark-mode --json

คำสั่งสำหรับการตรวจสอบความถูกต้อง

`openspec validate`

ตรวจสอบการเปลี่ยนแปลงและสเปคเพื่อหาปัญหาเกี่ยวกับโครงสร้าง

openspec validate [item-name] [options]

การเปลี่ยนแปลงที่ไม่มีการเปลี่ยนแปลงสเปค (delta) ใดๆ จะล้มเหลวในการตรวจสอบเว้นแต่ไฟล์ .openspec.yaml ของมันระบุ skip_specs: true (สำหรับงานรีแฟกเตอร์ที่ไม่ได้มีการเปลี่ยนแปลงพฤติกรรม การปรับปรุงเครื่องมือ หรืองานเอกสาร — ดู สูตรที่ 5)

อาร์กิวเมนต์:

อาร์กิวเมนต์	จำเป็น	คำอธิบาย
`item-name`	ไม่	รายการที่ต้องการตรวจสอบเฉพาะ (จะแจ้งให้ป้อนหากไม่ระบุ)

ตัวเลือก:

ตัวเลือก	คำอธิบาย
`--all`	ตรวจสอบการเปลี่ยนแปลงและสเปคทั้งหมด
`--changes`	ตรวจสอบการเปลี่ยนแปลงทั้งหมด
`--specs`	ตรวจสอบสเปคทั้งหมด
`--type <type>`	ระบุประเภทเมื่อชื่อไม่ชัดเจน: `change` หรือ `spec`
`--strict`	เปิดใช้งานโหมดตรวจสอบแบบเข้มงวด
`--json`	ส่งออกในรูปแบบ JSON
`--concurrency <n>`	จำนวนการตรวจสอบแบบขนานสูงสุด (ค่าเริ่มต้น: 6 หรือใช้ค่าจากตัวแปรสภาพแวดล้อม `OPENSPEC_CONCURRENCY`)
`--no-interactive`	ปิดการแจ้งให้ป้อนข้อมูล

ตัวอย่าง:

bash

# การตรวจสอบแบบโต้ตอบ
openspec validate

# ตรวจสอบการเปลี่ยนแปลงเฉพาะ
openspec validate add-dark-mode

# ตรวจสอบการเปลี่ยนแปลงทั้งหมด
openspec validate --changes

# ตรวจสอบทั้งหมดพร้อมเอาต์พุต JSON (สำหรับ CI/สคริปต์)
openspec validate --all --json

# การตรวจสอบแบบเข้มงวดพร้อมเพิ่มจำนวนการตรวจสอบแบบขนาน
openspec validate --all --strict --concurrency 12

เอาต์พุต (ข้อความ):

กำลังตรวจสอบ add-dark-mode...
  ✓ ไฟล์ proposal.md ถูกต้อง
  ✓ ไฟล์ specs/ui/spec.md ถูกต้อง
  ⚠ ไฟล์ design.md: ขาดส่วน "แนวทางทางเทคนิค"

พบ 1 คำเตือน

เอาต์พุต (JSON):

json

{
  "version": "1.0.0",
  "results": {
    "changes": [
      {
        "name": "add-dark-mode",
        "valid": true,
        "warnings": ["design.md: ขาดส่วน 'แนวทางทางเทคนิค'"]
      }
    ]
  },
  "summary": {
    "total": 1,
    "valid": 1,
    "invalid": 0
  }
}

คำสั่งสำหรับวงจรชีวิตของงาน

`openspec archive`

เก็บการเปลี่ยนแปลงที่เสร็จสมบูรณ์ไว้ในคลัง และรวมสเปค delta เข้าไปในสเปคหลัก

openspec archive [change-name] [options]

อาร์กิวเมนต์:

อาร์กิวเมนต์	จำเป็น	คำอธิบาย
`change-name`	ไม่	การเปลี่ยนแปลงที่ต้องการเก็บในคลัง (จะแจ้งให้ป้อนหากไม่ระบุ)

ตัวเลือก:

ตัวเลือก	คำอธิบาย
`-y, --yes`	ข้ามการแจ้งให้ยืนยัน
`--skip-specs`	ข้ามการอัปเดตสเปคสำหรับการเก็บในคลังครั้งนี้ การเปลี่ยนแปลงที่ไม่มีการเปลี่ยนแปลงสเปค (delta) ตลอดไปควรระบุ `skip_specs: true` ในไฟล์ `.openspec.yaml` แทน — การเก็บในคลังจะทำงานโดยไม่ต้องใช้แฟล็กนี้
`--no-validate`	ข้ามการตรวจสอบความถูกต้อง (ต้องการการยืนยัน)

ตัวอย่าง:

bash

# การเก็บในคลังแบบโต้ตอบ
openspec archive

# เก็บการเปลี่ยนแปลงเฉพาะในคลัง
openspec archive add-dark-mode

# เก็บในคลังโดยไม่ต้องแจ้งให้ป้อนข้อมูล (สำหรับ CI/สคริปต์)
openspec archive add-dark-mode --yes

# เก็บการเปลี่ยนแปลงเกี่ยวกับเครื่องมือที่ไม่มีผลต่อสเปคในคลัง
openspec archive update-ci-config --skip-specs

ขั้นตอนการทำงาน:

ตรวจสอบความถูกต้องของการเปลี่ยนแปลง (เว้นแต่ใช้แฟล็ก --no-validate)
แจ้งให้ยืนยัน (เว้นแต่ใช้แฟล็ก --yes)
รวมสเปค delta เข้าไปใน openspec/specs/
ย้ายโฟลเดอร์การเปลี่ยนแปลงไปยัง openspec/changes/archive/YYYY-MM-DD-<name>/

คำสั่งสำหรับเวิร์กโฟลว์

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

`openspec new change`

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

bash

openspec new change <name> [options]

ชื่อของการเปลี่ยนแปลงต้องใช้ kebab-case ตัวพิมพ์เล็กเท่านั้น ต้องเริ่มด้วยตัวพิมพ์เล็ก ต่อมาคือตัวพิมพ์เล็ก ตัวเลข และเครื่องหมายยัติภังค์เพียงหนึ่งตัว ห้ามเริ่มด้วยตัวเลข ห้ามมีช่องว่าง ขีดเส้นใต้ ตัวพิมพ์ใหญ่ เครื่องหมายยัติภังค์ติดกัน หรือเครื่องหมายยัติภังค์อยู่หน้า/ท้ายชื่อ หากต้องการรวม ID ของตั๋วจากระบบภายนอก ควรนำคำนำหน้าตามด้วย เช่น ticket-123-add-notifications แทนที่จะเป็น 123-add-notifications

ตัวเลือก:

ตัวเลือก	คำอธิบาย
`--description <text>`	คำอธิบายที่จะเพิ่มเข้าไปใน `index.md`
`--goal <text>`	ข้อมูลเมตาดาต้าของเป้าหมายแบบเลือกได้ที่จะเก็บพร้อมกับการเปลี่ยนแปลง
`--schema <name>`	สคีมาเวิร์กโฟลว์ที่จะใช้
`--store <id>`	ID ของสโตร์ที่จะใช้เป็นรากของ OpenSpec (สโตร์คือ repo OpenSpec แยกที่คุณได้ลงทะเบียนไว้)
`--json`	ส่งออกในรูปแบบ JSON

ตัวอย่าง:

bash

openspec new change add-billing-api
openspec new change add-billing-api --store team-context --json

`openspec status`

แสดงสถานะความสมบูรณ์ของอาร์ติแฟคตสำหรับการเปลี่ยนแปลง

openspec status [options]

ตัวเลือก:

ตัวเลือก	คำอธิบาย
`--change <id>`	ชื่อของการเปลี่ยนแปลง (จะแจ้งให้ป้อนหากไม่ระบุ)
`--schema <name>`	แทนที่สคีมา (ตรวจจับอัตโนมัติจากคอนฟิกของการเปลี่ยนแปลง)
`--json`	ส่งออกในรูปแบบ JSON

ตัวอย่าง:

bash

# การตรวจสอบสถานะแบบโต้ตอบ
openspec status

# สถานะสำหรับการเปลี่ยนแปลงเฉพาะ
openspec status --change add-dark-mode

# JSON สำหรับใช้งานกับเอเจนต์
openspec status --change add-dark-mode --json

เอาต์พุต (ข้อความ):

การเปลี่ยนแปลง: add-dark-mode
สคีมา: spec-driven
ความคืบหน้า: เสร็จสมบูรณ์ 2/4 อาร์ติแฟคต

[x] proposal
[ ] design
[x] specs
[-] tasks (ถูกบล็อกโดย: design)

การเปลี่ยนแปลงที่ระบุ skip_specs: true จะแสดงขั้นตอนสเปคของมันเป็น [~] specs (ข้าม: การเปลี่ยนแปลงประกาศ skip_specs) และไม่นับขั้นตอนนี้เข้าสู่จำนวนความคืบหน้า

เอาต์พุต (JSON):

json

{
  "changeName": "add-dark-mode",
  "schemaName": "spec-driven",
  "isComplete": false,
  "applyRequires": ["tasks"],
  "artifacts": [
    {"id": "proposal", "outputPath": "proposal.md", "status": "done", "requires": []},
    {"id": "design", "outputPath": "design.md", "status": "ready", "requires": ["proposal"]},
    {"id": "specs", "outputPath": "specs/**/*.md", "status": "done", "requires": ["proposal"]},
    {"id": "tasks", "outputPath": "tasks.md", "status": "blocked", "requires": ["specs", "design"], "missingDeps": ["design"]}
  ]
}

`openspec instructions`

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

openspec instructions [artifact] [options]

อาร์กิวเมนต์:

อาร์กิวเมนต์	จำเป็น	คำอธิบาย
`artifact`	ไม่	ID ของอาร์ติแฟคต: `proposal`, `specs`, `design`, `tasks` หรือ `apply`

ตัวเลือก:

ตัวเลือก	คำอธิบาย
`--change <id>`	ชื่อของการเปลี่ยนแปลง (จำเป็นต้องระบุในโหมดไม่โต้ตอบ)
`--schema <name>`	แทนที่สคีมา
`--json`	ส่งออกในรูปแบบ JSON

กรณีพิเศษ: ใช้ apply เป็นอาร์ติแฟคตเพื่อรับคำแนะนำในการใช้งานงาน

ตัวอย่าง:

bash

# รับคำแนะนำสำหรับอาร์ติแฟคตต่อไป
openspec instructions --change add-dark-mode

# รับคำแนะนำสำหรับอาร์ติแฟคตเฉพาะ
openspec instructions design --change add-dark-mode

# รับคำแนะนำสำหรับใช้งาน/การนำไปปฏิบัติใช้
openspec instructions apply --change add-dark-mode

# JSON สำหรับใช้งานกับเอเจนต์
openspec instructions design --change add-dark-mode --json

เอาต์พุตประกอบด้วย:

เนื้อหาต้นแบบของอาร์ติแฟคต
บริบทของโปรเจกต์จากไฟล์คอนฟิก
เนื้อหาจากอาร์ติแฟคตที่เกี่ยวข้อง
กฎเฉพาะอาร์ติแฟคตจากไฟล์คอนฟิก

สำหรับอาร์ติแฟคตที่ถูกข้ามผ่าน skip_specs: true เอาต์พุตจะเป็นคำเตือนเท่านั้น (ในโหมด JSON จะเพิ่มฟิลด์ skipped/warning) — ห้ามสร้างอาร์ติแฟคตนี้

`openspec templates`

แสดงพาธของต้นแบบที่แก้ไขแล้วสำหรับอาร์ติแฟคตทั้งหมดในสคีมา

openspec templates [options]

ตัวเลือก:

ตัวเลือก	คำอธิบาย
`--schema <name>`	สคีมาที่ต้องการตรวจสอบ (ค่าเริ่มต้น: `spec-driven`)
`--json`	ส่งออกในรูปแบบ JSON

ตัวอย่าง:

bash

# แสดงพาธของต้นแบบสำหรับสคีมาเริ่มต้น
openspec templates

# แสดงต้นแบบสำหรับสคีมาที่กำหนดเอง
openspec templates --schema my-workflow

# JSON สำหรับใช้งานทางโปรแกรม
openspec templates --json

เอาต์พุต (ข้อความ):

สคีมา: spec-driven

ต้นแบบ:
  proposal  → ~/.openspec/schemas/spec-driven/templates/proposal.md
  specs     → ~/.openspec/schemas/spec-driven/templates/specs.md
  design    → ~/.openspec/schemas/spec-driven/templates/design.md
  tasks     → ~/.openspec/schemas/spec-driven/templates/tasks.md

`openspec schemas`

แสดงรายการสคีมาเวิร์กโฟลว์ที่มีพร้อมกับคำอธิบายและลำดับขั้นของอาร์ติแฟคต

openspec schemas [options]

ตัวเลือก:

ตัวเลือก	คำอธิบาย
`--json`	ส่งออกในรูปแบบ JSON

ตัวอย่าง:

bash

openspec schemas

เอาต์พุต:

สคีมาที่มีอยู่:

  spec-driven (แพคเกจ)
    เวิร์กโฟลว์การพัฒนาที่ขับเคลื่อนด้วยสเปคเริ่มต้น
    ลำดับขั้น: proposal → specs → design → tasks

  my-custom (โปรเจกต์)
    เวิร์กโฟลว์ที่กำหนดเองสำหรับโปรเจกต์นี้
    ลำดับขั้น: research → proposal → tasks

คำสั่งสคีม่า

คำสั่งสำหรับสร้างและจัดการสคีม่าของเวิร์กโฟลว์ที่กำหนดเอง

`openspec schema init`

สร้างสคีม่าใหม่เฉพาะของโปรเจกต์

openspec schema init <name> [options]

อาร์กิวเมนต์:

อาร์กิวเมนต์	จำเป็น	คำอธิบาย
`name`	ใช่	ชื่อสคีม่า (รูปแบบ kebab-case)

ตัวเลือก:

ตัวเลือก	คำอธิบาย
`--description <text>`	คำอธิบายสคีม่า
`--artifacts <list>`	รายการ ID อาร์ติแฟกต์คั่นด้วยจุลภาค (ค่าเริ่มต้น: `proposal,specs,design,tasks`)
`--default`	ตั้งเป็นสคีม่าเริ่มต้นของโปรเจกต์
`--no-default`	ไม่แจ้งเตือนให้ตั้งเป็นค่าเริ่มต้น
`--force`	เขียนทับสคีม่าที่มีอยู่แล้ว
`--json`	ผลลัพธ์ในรูปแบบ JSON

ตัวอย่าง:

bash

# สร้างสคีม่าผ่านแบบโต้ตอบ
openspec schema init research-first

# สร้างแบบไม่โต้ตอบพร้อมระบุอาร์ติแฟกต์ที่ต้องการ
openspec schema init rapid \
  --description "Rapid iteration workflow" \
  --artifacts "proposal,tasks" \
  --default

สิ่งที่ถูกสร้างขึ้น:

openspec/schemas/<name>/
├── schema.yaml           # คำนิยามสคีม่า
└── templates/
    ├── proposal.md       # เทมเพลตสำหรับแต่ละอาร์ติแฟกต์
    ├── specs.md
    ├── design.md
    └── tasks.md

`openspec schema fork`

คัดลอกสคีม่าที่มีอยู่แล้วเข้าสู่โปรเจกต์ของคุณเพื่อปรับแต่งเอง

openspec schema fork <source> [name] [options]

อาร์กิวเมนต์:

อาร์กิวเมนต์	จำเป็น	คำอธิบาย
`source`	ใช่	สคีม่าที่ต้องการคัดลอก
`name`	ไม่	ชื่อสคีม่าใหม่ (ค่าเริ่มต้น: `<source>-custom`)

ตัวเลือก:

ตัวเลือก	คำอธิบาย
`--force`	เขียนทับปลายทางที่มีอยู่แล้ว
`--json`	ผลลัพธ์ในรูปแบบ JSON

ตัวอย่าง:

bash

# สร้างสคีม่าสืบทอดจากสคีม่า spec-driven ที่มีอยู่ภายใน
openspec schema fork spec-driven my-workflow

`openspec schema validate`

ตรวจสอบความถูกต้องของโครงสร้างและเทมเพลตของสคีม่า

openspec schema validate [name] [options]

อาร์กิวเมนต์:

อาร์กิวเมนต์	จำเป็น	คำอธิบาย
`name`	ไม่	สคีม่าที่ต้องการตรวจสอบ (หากไม่ระบุจะตรวจสอบทั้งหมด)

ตัวเลือก:

ตัวเลือก	คำอธิบาย
`--verbose`	แสดงขั้นตอนการตรวจสอบอย่างละเอียด
`--json`	ผลลัพธ์ในรูปแบบ JSON

ตัวอย่าง:

bash

# ตรวจสอบสคีม่าเฉพาะ
openspec schema validate my-workflow

# ตรวจสอบสคีม่าทั้งหมด
openspec schema validate

`openspec schema which`

แสดงตำแหน่งต้นทางที่สคีม่าถูกโหลดจาก (มีประโยชน์สำหรับการแก้ไขลำดับความสำคัญของสคีม่า)

openspec schema which [name] [options]

อาร์กิวเมนต์:

อาร์กิวเมนต์	จำเป็น	คำอธิบาย
`name`	ไม่	ชื่อสคีม่า

ตัวเลือก:

ตัวเลือก	คำอธิบาย
`--all`	แสดงรายการสคีม่าทั้งหมดพร้อมตำแหน่งต้นทาง
`--json`	ผลลัพธ์ในรูปแบบ JSON

ตัวอย่าง:

bash

# ตรวจสอบตำแหน่งต้นทางของสคีม่า
openspec schema which spec-driven

ผลลัพธ์:

สคีม่า spec-driven โหลดจาก: แพ็กเกจ
  ตำแหน่งต้นทาง: /usr/local/lib/node_modules/@fission-ai/openspec/schemas/spec-driven

ลำดับความสำคัญของสคีม่า:

โปรเจกต์: openspec/schemas/<name>/
ผู้ใช้: ~/.local/share/openspec/schemas/<name>/
แพ็กเกจ: สคีม่าที่มีอยู่ภายใน

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

`openspec config`

ดูและแก้ไขการกำหนดค่าทั่วไปของ OpenSpec

openspec config <subcommand> [options]

คำสั่งย่อย:

คำสั่งย่อย	คำอธิบาย
`path`	แสดงตำแหน่งไฟล์การกำหนดค่า
`list`	แสดงการตั้งค่าทั้งหมดปัจจุบัน
`get <key>`	ดึงค่าที่กำหนดโดยเฉพาะ
`set <key> <value>`	ตั้งค่าที่กำหนด
`unset <key>`	ลบคีย์ที่กำหนด
`reset`	รีเซ็ตเป็นค่าเริ่มต้น
`edit`	เปิดใน `$EDITOR`
`profile [preset]`	กำหนดค่าโปรไฟล์เวิร์กโฟลว์ผ่านแบบโต้ตอบหรือโดยใช้พรีเซ็ต

ตัวอย่าง:

bash

# แสดงตำแหน่งไฟล์การกำหนดค่า
openspec config path

# แสดงการตั้งค่าทั้งหมด
openspec config list

# ดึงค่าที่กำหนดโดยเฉพาะ
openspec config get telemetry.enabled

# ตั้งค่า
openspec config set telemetry.enabled false

# ตั้งค่าแบบสตริงอย่างชัดเจน
openspec config set user.name "My Name" --string

# ลบการตั้งค่าที่กำหนดเอง
openspec config unset user.name

# ตั้งค่าเก็บข้อมูลเริ่มต้นระดับเครื่อง (เป็นรากสำรองเมื่อไม่มี --store,
# รากระดับเครื่อง หรือรากโปรเจกต์: ตัวชี้จะถูกแก้ไข)
openspec config set defaultStore team-plans

# รีเซ็ตการกำหนดค่าทั้งหมด
openspec config reset --all --yes

# แก้ไขการกำหนดค่าในโปรแกรมแก้ไขของคุณ
openspec config edit

# กำหนดค่าโปรไฟล์ด้วยวิซาร์ดที่อิงกับการดำเนินการ
openspec config profile

# พรีเซ็ตเร็ว: เปลี่ยนเวิร์กโฟลว์เป็น core (รักษาโหมดการส่งมอบ)
openspec config profile core

openspec config profile จะเริ่มด้วยสรุปสถานะปัจจุบัน จากนั้นให้คุณเลือก:

เปลี่ยนโหมดการส่งมอบ + เวิร์กโฟลว์
เปลี่ยนโหมดการส่งมอบเท่านั้น
เปลี่ยนเวิร์กโฟลว์เท่านั้น
เก็บการตั้งค่าปัจจุบัน (ออกจากโปรแกรม)

หากคุณเลือกเก็บการตั้งค่าปัจจุบัน จะไม่มีการบันทึกการเปลี่ยนแปลงใดๆ และจะไม่แสดงข้อความแจ้งเตือนให้อัปเดต หากไม่มีการเปลี่ยนแปลงการกำหนดค่า แต่ไฟล์โปรเจกต์ปัจจุบันไม่ตรงกับโปรไฟล์/โหมดการส่งมอบทั่วโลกของคุณ OpenSpec จะแสดงข้อความเตือนและแนะนำให้รัน openspec update กด Ctrl+C ก็สามารถยกเลิกกระบวนการอย่างสะอาด (ไม่มีสแตกเทรซ) และออกด้วยรหัส 130 ได้

ในรายการตรวจสอบเวิร์กโฟลว์ [x] หมายถึงเวิร์กโฟลว์นั้นถูกเลือกในการกำหนดค่าทั่วไป หากต้องการนำการเลือกนั้นไปใช้กับไฟล์โปรเจกต์ รัน openspec update (หรือเลือก นำการเปลี่ยนแปลงไปใช้กับโปรเจกต์นี้ทันที? เมื่อได้รับข้อความแจ้งเตือนในโปรเจกต์)

ตัวอย่างแบบโต้ตอบ:

bash

# อัปเดตเฉพาะโหมดการส่งมอบ
openspec config profile
# เลือก: เปลี่ยนโหมดการส่งมอบเท่านั้น
# เลือกโหมดการส่งมอบ: Skills เท่านั้น

# อัปเดตเฉพาะเวิร์กโฟลว์
openspec config profile
# เลือก: เปลี่ยนเวิร์กโฟลว์เท่านั้น
# เปิด/ปิดเวิร์กโฟลว์ในรายการตรวจสอบ จากนั้นยืนยัน

คำสั่งอรรถประโยชน์

`openspec feedback`

ส่งข้อเสนอแนะเกี่ยวกับ OpenSpec ระบบจะสร้างประเด็นใน GitHub อัตโนมัติ

openspec feedback <message> [options]

อาร์กิวเมนต์:

อาร์กิวเมนต์	จำเป็น	คำอธิบาย
`message`	ใช่	ข้อความเสนอแนะ

ตัวเลือก:

ตัวเลือก	คำอธิบาย
`--body <text>`	คำอธิบายอย่างละเอียด

ข้อกำหนด: ต้องติดตั้งและตรวจสอบสิทธิ์ GitHub CLI (gh) ก่อน

ตัวอย่าง:

bash

openspec feedback "Add support for custom artifact types" \
  --body "I'd like to define my own artifact types beyond the built-in ones."

`openspec completion`

จัดการการเติมคำอัตโนมัติสำหรับเชลล์กับ CLI ของ OpenSpec

openspec completion <subcommand> [shell]

คำสั่งย่อย:

คำสั่งย่อย	คำอธิบาย
`generate [shell]`	ส่งสคริปต์การเติมคำอัตโนมัติไปยังเอาต์พุตมาตรฐาน
`install [shell]`	ติดตั้งการเติมคำอัตโนมัติสำหรับเชลล์ของคุณ
`uninstall [shell]`	ลบการเติมคำอัตโนมัติที่ติดตั้งแล้ว

เชลล์ที่รองรับ: bash, zsh, fish, powershell

ตัวอย่าง:

bash

# ติดตั้งการเติมคำอัตโนมัติ (ตรวจพบเชลล์โดยอัตโนมัติ)
openspec completion install

# ติดตั้งสำหรับเชลล์ที่ระบุ
openspec completion install zsh

# สร้างสคริปต์สำหรับการติดตั้งด้วยตนเอง
openspec completion generate bash > ~/.bash_completion.d/openspec

# ถอนการติดตั้ง
openspec completion uninstall

รหัสออกจากโปรแกรม

รหัส	ความหมาย
`0`	สำเร็จ
`1`	ข้อผิดพลาด (การตรวจสอบล้มเหลว, ไม่พบไฟล์ ฯลฯ)

ตัวแปรสภาพแวดล้อม

ตัวแปร	คำอธิบาย
`OPENSPEC_TELEMETRY`	ตั้งค่าเป็น `0` เพื่อปิดการส่งข้อมูลเทเลเมทรี
`DO_NOT_TRACK`	ตั้งค่าเป็น `1` เพื่อปิดการส่งข้อมูลเทเลเมทรี (สัญญาณ DNT มาตรฐาน)
`OPENSPEC_CONCURRENCY`	ค่าการทำงานพร้อมกันเริ่มต้นสำหรับการตรวจสอบจำนวนมาก (ค่าเริ่มต้น: 6)
`EDITOR` หรือ `VISUAL`	โปรแกรมแก้ไขสำหรับ `openspec config edit`
`NO_COLOR`	ปิดการแสดงผลสีเมื่อมีการตั้งค่านี้

เอกสารที่เกี่ยวข้อง

คำสั่ง - คำสั่งสแลช AI (/opsx:propose, /opsx:apply ฯลฯ)
เวิร์กโฟลว์ - รูปแบบทั่วไปและเวลาที่ควรใช้แต่ละคำสั่ง
การปรับแต่ง - สร้างสคีม่าและเทมเพลตที่กำหนดเอง
เริ่มต้นใช้งาน - คู่มือติดตั้งสำหรับผู้เริ่มต้น

อ้างอิง CLI ​

Summary ​

คำสั่งสำหรับมนุษย์ vs เอเจนต์ ​

คำสั่งสำหรับมนุษย์เท่านั้น ​

คำสั่งที่รองรับเอเจนต์ ​

ตัวเลือกทั่วโลก ​

คำสั่งการตั้งค่า ​

openspec init ​

openspec update ​

สโตร์ (รีโป OpenSpec แยกต่างหาก) ​

openspec store setup ​

openspec store register ​

openspec store unregister ​

openspec store remove ​

openspec store list ​

openspec store doctor ​

การอ้างอิงสโตร์จากโปรเจกต์ ​

การบันทึกตำแหน่งที่สโตร์ถูกคลอนมาจาก ​

การประกาศสโตร์เริ่มต้น ​

Doctor (สุขภาพความสัมพันธ์) ​

Working context (ชุดที่ประกอบรวมกัน) ​

Worksets ส่วนบุคคล ​

คำสั่งสำหรับการเรียกดู ​

openspec list ​

openspec view ​

openspec show ​

คำสั่งสำหรับการตรวจสอบความถูกต้อง ​

openspec validate ​

คำสั่งสำหรับวงจรชีวิตของงาน ​

openspec archive ​

คำสั่งสำหรับเวิร์กโฟลว์ ​

openspec new change ​

openspec status ​

openspec instructions ​

openspec templates ​

openspec schemas ​

คำสั่งสคีม่า ​

openspec schema init ​

openspec schema fork ​

openspec schema validate ​

openspec schema which ​

คำสั่งการกำหนดค่า ​

openspec config ​

คำสั่งอรรถประโยชน์ ​

openspec feedback ​

openspec completion ​

รหัสออกจากโปรแกรม ​

ตัวแปรสภาพแวดล้อม ​

เอกสารที่เกี่ยวข้อง ​

อ้างอิง CLI

Summary

คำสั่งสำหรับมนุษย์ vs เอเจนต์

คำสั่งสำหรับมนุษย์เท่านั้น

คำสั่งที่รองรับเอเจนต์

ตัวเลือกทั่วโลก

คำสั่งการตั้งค่า

`openspec init`

`openspec update`

สโตร์ (รีโป OpenSpec แยกต่างหาก)

`openspec store setup`

`openspec store register`

`openspec store unregister`

`openspec store remove`

`openspec store list`

`openspec store doctor`

การอ้างอิงสโตร์จากโปรเจกต์

การบันทึกตำแหน่งที่สโตร์ถูกคลอนมาจาก

การประกาศสโตร์เริ่มต้น

Doctor (สุขภาพความสัมพันธ์)

Working context (ชุดที่ประกอบรวมกัน)

Worksets ส่วนบุคคล

คำสั่งสำหรับการเรียกดู

`openspec list`

`openspec view`

`openspec show`

คำสั่งสำหรับการตรวจสอบความถูกต้อง

`openspec validate`

คำสั่งสำหรับวงจรชีวิตของงาน

`openspec archive`

คำสั่งสำหรับเวิร์กโฟลว์

`openspec new change`

`openspec status`

`openspec instructions`

`openspec templates`

`openspec schemas`

คำสั่งสคีม่า

`openspec schema init`

`openspec schema fork`

`openspec schema validate`

`openspec schema which`

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

`openspec config`

คำสั่งอรรถประโยชน์

`openspec feedback`

`openspec completion`

รหัสออกจากโปรแกรม

ตัวแปรสภาพแวดล้อม

เอกสารที่เกี่ยวข้อง