OpenSpec

CLI ​

คำสั่งเทอร์มินัลของ openspec

คำสั่ง ​

การตั้งค่า

คำสั่งหน้าที่
openspec initเริ่มต้นใช้งาน OpenSpec ในโปรเจกต์
openspec updateอัปเดตไฟล์คำแนะนำที่ติดตั้งไว้ของ OpenSpec
openspec configดูและแก้ไขการตั้งค่าส่วนกลาง

การเปลี่ยนแปลงและสเปก

คำสั่งหน้าที่
openspec listแสดงรายการการเปลี่ยนแปลง หรือแสดงสเปกด้วย --specs
openspec showแสดงการเปลี่ยนแปลงหรือสเปกในรูปแบบ Markdown หรือ JSON
openspec viewแดชบอร์ดในหน้าจอเดียวสำหรับสเปกและการเปลี่ยนแปลง
openspec validateตรวจสอบปัญหาเชิงโครงสร้างของการเปลี่ยนแปลงและสเปก
openspec archiveย้ายการเปลี่ยนแปลงที่เสร็จแล้วไปยังคลังเก็บถาวร และอัปเดตสเปกหลัก

เวิร์กโฟลว์และสคีมา

เอเจนต์ของคุณจะเรียกใช้คำสั่งเหล่านี้ส่วนใหญ่ระหว่างเวิร์กโฟลว์

คำสั่งหน้าที่
openspec newสร้างไดเรกทอรีการเปลี่ยนแปลงใหม่
openspec statusสถานะการเสร็จสิ้นของอาร์ทิแฟกต์สำหรับการเปลี่ยนแปลงที่ใช้งานอยู่หนึ่งรายการหรือทั้งหมด
openspec instructionsคำแนะนำสำหรับการสร้างอาร์ทิแฟกต์ การนำไปใช้ หรือการเก็บถาวร
openspec templatesพาธของเทมเพลตที่ผ่านการ resolve แล้วสำหรับอาร์ทิแฟกต์ของสคีมา
openspec schemasแสดงรายการสคีมาของเวิร์กโฟลว์ที่มีอยู่
openspec schemaตรวจสอบ, fork หรือสร้างสคีมา (ทดลอง)

หลาย repository (เบต้า)

คำสั่งหน้าที่
openspec storeสร้างและจัดการสโตร์: repository OpenSpec แบบสแตนด์อโลนที่ลงทะเบียนบนเครื่องของคุณ
openspec doctorรายงานสถานะความสัมพันธ์สำหรับ root OpenSpec ที่ผ่านการ resolve แล้ว
openspec contextแสดงบริบทการทำงานสำหรับ root OpenSpec ที่ผ่านการ resolve แล้ว
openspec worksetสร้าง จัดเก็บ และเปิดมุมมองการทำงานส่วนบุคคล

ยูทิลิตี

คำสั่งหน้าที่
openspec versionรายงานเวอร์ชันที่ติดตั้ง และตรวจสอบการอัปเดตได้ตามต้องการ
openspec installติดตั้ง openspec แบบสแตนด์อโลน ซึ่งทำงานโดยไม่ต้องใช้ Node.js
openspec feedbackส่งข้อเสนอแนะเกี่ยวกับ OpenSpec
openspec completionติดตั้งหรือสร้าง shell completions

เลิกใช้แล้ว

คำสั่งหน้าที่
openspec changeรูปแบบคำนามของ show, list และ validate สำหรับการเปลี่ยนแปลง โดย CLI จะเตือนและชี้ไปยังคำสั่งที่ขึ้นต้นด้วยคำกริยา
openspec specรูปแบบคำนามของ show, list และ validate สำหรับสเปก พร้อมคำเตือนเดียวกัน

ทุกคำสั่งรองรับ -h, --help และคำสั่ง openspec แบบไม่ระบุคำสั่งย่อยยังรองรับตัวเลือกต่อไปนี้:

  • -V, --version: แสดงเวอร์ชันของ CLI
  • --no-color: ปิดการแสดงเอาต์พุตแบบมีสี## openspec init

เริ่มต้น OpenSpec ในโปรเจกต์

bash
openspec init                        # ไดเรกทอรีปัจจุบัน, ตัวเลือกเครื่องมือแบบอินเทอร์แอกทีฟ
openspec init --tools claude,cursor  # ตั้งค่าเครื่องมือเฉพาะ, ไม่มีพรอมป์
openspec init --tools none           # เฉพาะโครงสร้าง openspec/, ไม่มีไฟล์เครื่องมือ

หากไม่มี --tools คำสั่ง init จะแจ้งให้คุณเลือกเครื่องมือในเทอร์มินัลแบบอินเทอร์แอกทีฟ หากอยู่นอกเทอร์มินัล จะตั้งค่าเครื่องมือที่ตรวจพบในโปรเจกต์ หากตรวจไม่พบเลย จะออกด้วยรหัส 1 และแสดงรายการ id ที่ถูกต้อง

รีโปแบบ store-only

เมื่อ openspec/config.yaml มีบรรทัด store: และรีโปไม่มีสเปกหรือการเปลี่ยนแปลงภายในเครื่อง ให้รัน init จากรูทของรีโป:

bash
# ติดตั้งไฟล์ผสานรวม Claude Code ในรีโปโค้ด
openspec init --tools claude
  • ไฟล์ผสานรวม: เขียนไว้ในรีโปโค้ด
  • openspec/config.yaml: คงไว้แบบไบต์ต่อไบต์
  • openspec/specs/ และ openspec/changes/: ไม่ถูกสร้างในรีโปโค้ด

การรัน init จากไดเรกทอรีย่อยจะออกด้วยรหัส 1 และแจ้งให้รันจากรูทของรีโป --language ก็ออกด้วยรหัส 1 เช่นกัน เนื่องจากภาษานั้นอยู่ในคอนฟิกของที่จัดเก็บภายนอก ให้รัน init ในรูทของ store หรือแก้ไขคอนฟิกนั้นโดยตรง

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

อาร์กิวเมนต์ความหมาย
pathไดเรกทอรีโปรเจกต์ที่จะเริ่มต้น ค่าเริ่มต้น: ไดเรกทอรีปัจจุบัน จะถูกสร้างหากไม่มีอยู่

ตัวเลือก

แฟล็กผลลัพธ์
--tools <tools>id ของเครื่องมือที่คั่นด้วยจุลภาค, all หรือ none ข้ามตัวเลือก id ต่างๆ แสดงอยู่ใน เครื่องมือที่รองรับ
--language <language>เพิ่มคำแนะนำภาษาในคอนฟิกโปรเจกต์ใหม่ จะถูกปฏิเสธเมื่อบรรทัด store: ของรีโปชี้ไปยังที่จัดเก็บภายนอก
--forceลบไฟล์จากเลย์เอาต์ OpenSpec รุ่นเก่าโดยไม่ถาม การรันแบบอินเทอร์แอกทีฟจะยืนยันการล้างไฟล์ก่อน
--profile <profile>แทนที่โปรไฟล์คอนฟิกโกลบอลสำหรับการรันนี้: core (ชุดเวิร์กโฟลว์มาตรฐาน) หรือ custom (เวิร์กโฟลว์ที่บันทึกไว้ในคอนฟิกโกลบอล)
--no-animationแสดงหน้าจอต้อนรับแบบคงที่แทนแบบเคลื่อนไหว

เอาต์พุต

เครื่องมือที่เลือกแต่ละรายการจะได้รับสกิลและคำสั่งของ OpenSpec ในไดเรกทอรีของตนเอง:

▌ OpenSpec structure created
✔ Setup complete for Claude Code

OpenSpec Setup Complete

Created: Claude Code
6 skills and 6 commands in .claude/
Config: openspec/config.yaml (schema: spec-driven)

Getting started:
  Start your first change: /opsx:propose "your idea"

Restart your IDE for the new commands to take effect.

--tools none สร้างเฉพาะ openspec/config.yaml ในโปรเจกต์ที่เริ่มต้นแล้ว คำสั่ง init จะเขียนไฟล์ที่ติดตั้งไว้ใหม่ในตำแหน่งเดิม และสรุปผลจะแสดง Refreshed: Claude Code พร้อม Config: openspec/config.yaml (exists)

รหัสออก

  • 0: การตั้งค่าเสร็จสมบูรณ์
  • 1: ค่า --tools หรือ --profile ไม่ถูกต้อง, การรันแบบไม่ใช่อินเทอร์แอกทีฟที่ไม่ตรวจพบเครื่องมือและไม่มี --tools, หรือการเรียกใช้แบบ store-only ที่ไม่ถูกต้อง

openspec update ​

อัปเดตไฟล์คำแนะนำที่ติดตั้งไว้ของ OpenSpec

bash
openspec update             # รีเฟรชเครื่องมือที่ไฟล์เก่ากว่า CLI
openspec update --force     # เขียนไฟล์ใหม่แม้ไฟล์จะเป็นเวอร์ชันปัจจุบัน
openspec update --dry-run   # แสดงรายการสิ่งที่การอัปเดตจะเปลี่ยนแปลง โดยไม่เปลี่ยนแปลงอะไร

คำสั่ง update จะค้นหาเครื่องมือที่ init กำหนดค่าไว้ และเปรียบเทียบไฟล์ที่สร้างขึ้นกับเวอร์ชันของ CLI เมื่อมี OpenSpec รีลีสใหม่กว่า จะเสนอให้อัปเกรด CLI ก่อน จากนั้นรันซ้ำด้วยเวอร์ชันที่อัปเกรดแล้ว ตั้งค่า OPENSPEC_NO_UPDATE_CHECK=1 เพื่อข้ามการตรวจสอบ

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

อาร์กิวเมนต์ความหมาย
pathไดเรกทอรีโปรเจกต์ที่จะอัปเดต ค่าเริ่มต้น: ไดเรกทอรีปัจจุบัน

ตัวเลือก

แฟล็กผลลัพธ์
--forceเขียนไฟล์ของทุกเครื่องมือที่กำหนดค่าไว้ใหม่ แม้จะอัปทูเดตแล้ว
--dry-runรายงานทุกไฟล์ที่การอัปเดตจะเพิ่ม เปลี่ยน หรือลบ และไม่เขียนอะไรเลย ไม่มีการตรวจสอบการอัปเกรด CLI และไม่มีพรอมป์ รวมกับ --force เพื่อดูตัวอย่างการอัปเดตแบบบังคับ
--jsonใช้กับ --dry-run เพื่อพิมพ์แผนเป็น JSON หากไม่ใช้ --dry-run จะออกด้วยรหัส 1

การดูตัวอย่างการอัปเดต

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

  • การย้ายไฟล์ OpenSpec ออกจากไดเรกทอรีเดิมของเครื่องมือ (.kimi/ ไปยัง .kimi-code/, .windsurf/ ไปยัง .devin/, .codex/ และ .agent/ ไปยัง .agents/);
  • การบันทึกคอนฟิกโกลบอลเมื่อการติดตั้งจากก่อนยุคโปรไฟล์ได้รับคอนฟิกดังกล่าว;
  • การซิงก์ไฟล์ GitHub Copilot cloud agent;
  • เมื่อใช้ --force การตั้งค่าเครื่องมือที่พบเฉพาะในอาร์ติแฟกต์แบบเดิม และการล้างอาร์ติแฟกต์เหล่านั้น รวมถึงพรอมป์ Codex โกลบอลที่เลิกใช้แล้ว
bash
openspec update --dry-run
2 file(s) would change:
  update  .claude/skills/openspec-propose/SKILL.md  (claude)
  add     ~/.config/openspec/config.json  (openspec)

--dry-run --json พิมพ์แผนเดียวกันเป็นเอกสาร JSON หนึ่งฉบับ:

json
{
  "changes": [
    { "path": ".claude/skills/openspec-propose/SKILL.md", "action": "update", "tool": "claude" },
    { "path": "~/.config/openspec/config.json", "action": "add", "tool": "openspec" }
  ],
  "notes": [],
  "failures": []
}
ฟิลด์ข้อมูลที่เก็บ
changes[].pathพาธที่สัมพันธ์กับโปรเจกต์ ไฟล์ที่อยู่นอกโปรเจกต์ เช่น สกิลโกลบอลหรือคอนฟิกโกลบอล จะแสดงจากไดเรกทอรีโฮมของคุณเป็น ~/... หรือเป็นพาธแบบสัมบูรณ์เมื่ออยู่นอกโฮมเช่นกัน
changes[].actionadd, update หรือ delete ไฟล์ที่ไบต์ใหม่ตรงกับไบต์เดิมจะไม่ถูกแสดงรายการ
changes[].toolเครื่องมือที่กำหนดค่าไว้ซึ่งไฟล์นั้นเป็นของ เช่น claude ไฟล์ที่เป็นของ OpenSpec เองแทนที่จะเป็นของเครื่องมือใดเครื่องมือหนึ่ง ได้แก่ คอนฟิกโกลบอลและการล้างอาร์ติแฟกต์แบบเดิม จะเป็น openspec
notes[]{ code, message } สำหรับขั้นตอนที่ผู้ใช้ในเทอร์มินัลจะถูกถาม legacy-tool-directories: การย้ายที่การรันแบบอินเทอร์แอกทีฟจะถามก่อน; changes แสดงว่าดำเนินการแล้ว legacy-artifacts: พบไฟล์จากเลย์เอาต์เก่าของ OpenSpec เช่นคำสั่งสแลช openspec-proposal.md หรือบล็อกเครื่องหมาย OpenSpec ใน AGENTS.md หากไม่มี --force การอัปเดตแบบไม่ใช่อินเทอร์แอกทีฟจะปล่อยไว้ตามเดิม ดังนั้น changes ก็เช่นกัน; --dry-run --force จะแสดงรายการการล้างข้อมูลของไฟล์เหล่านี้ ว่างเปล่าสำหรับการรีเฟรชทั่วไป
failures[]{ tool, error } สำหรับแต่ละเครื่องมือที่การอัปเดตจริงจะล้มเหลว รวมถึงการเขียนที่ไม่สามารถทำได้: ไดเรกทอรีในตำแหน่งที่ควรเป็นไฟล์, ไฟล์ในตำแหน่งที่ควรเป็นไดเรกทอรี, หรือไฟล์หรือโฟลเดอร์ที่ไม่มีสิทธิ์เขียน สำหรับเครื่องมือนั้น changes จะหยุด ณ จุดที่การอัปเดตจริงหยุด; เครื่องมืออื่นยังคงถูกวางแผน ความล้มเหลวที่ดิสก์รายงานเฉพาะขณะเขียน เช่น พื้นที่เต็ม ไม่สามารถคาดการณ์ล่วงหน้าได้

ความล้มเหลวก่อนการวางแผน เช่น ไม่มีไดเรกทอรี OpenSpec ยังคงพิมพ์เอกสาร JSON หนึ่งฉบับพอดี: แผนว่างพร้อมอาร์เรย์ status ที่มี severity, code (update_error) และ message รหัสออกคือ 1

เอาต์พุต

เมื่อไฟล์ของทุกเครื่องมือตรงกับเวอร์ชัน CLI:

✓ All 1 tool(s) up to date (v1.7.0)
  Tools: claude

Use --force to refresh files anyway.

เมื่อไฟล์ของเครื่องมือมาจาก CLI รุ่นเก่า (หรือเมื่อใช้ --force ซึ่งจะพิมพ์ Force updating 1 tool(s): claude แทน):

Updating 1 tool(s): claude (1.6.0 → 1.7.0)

✔ Updated Claude Code

✓ Updated: Claude Code (v1.7.0)
Tools: Claude Code

Restart your IDE for changes to take effect.

ในไดเรกทอรีที่ไม่มี OpenSpec คำสั่ง update จะปฏิเสธ:

✖ Error: No OpenSpec directory found. Run 'openspec init' first.

รหัสออก

  • 0: อัปเดตไฟล์แล้ว หรือทุกอย่างอัปทูเดตอยู่แล้ว
  • 1: ไม่มีไดเรกทอรี OpenSpec ที่พาธ หรือการอัปเดตล้มเหลว

openspec config ​

ดูและเปลี่ยนแปลงคอนฟิกโกลบอล

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

คอนฟิกเป็นระดับโกลบอลของเครื่องคุณ จัดเก็บเป็น JSON ณ ตำแหน่งที่ config path ชี้: $XDG_CONFIG_HOME/openspec/config.json หากตั้งไว้ มิฉะนั้น ~/.config/openspec/config.json (macOS, Linux) หรือ %APPDATA%\openspec\config.json (Windows) ทุกซับคอมมานด์รองรับ --scope <scope> แต่ในปัจจุบันมีเฉพาะ global ที่ใช้งานได้ สโคปอื่นใดจะออกด้วยรหัส 1 พร้อมข้อความ Error: Project-local config is not yet implemented

openspec config path ​

bash
openspec config path
/Users/you/.config/openspec/config.json

openspec config list ​

bash
openspec config list          # การตั้งค่าที่อ่านได้พร้อมสรุปโปรไฟล์
openspec config list --json   # คอนฟิกดิบในรูปแบบ JSON

ตัวเลือก

แฟล็กผลลัพธ์
--jsonพิมพ์ออบเจกต์คอนฟิกเป็น JSON

เอาต์พุต

การตั้งค่าแต่ละรายการ จากนั้นสรุปโปรไฟล์ที่ระบุค่าต่างๆ ว่าเป็นค่าที่ตั้งไว้อย่างชัดเจนหรือค่าเริ่มต้น:

featureFlags: {}
profile: core
delivery: both

Profile settings:
  profile: core (default)
  delivery: both (default)
  workflows: propose, explore, apply, update, sync, archive (from core profile)

openspec config get ​

bash
openspec config get delivery

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

อาร์กิวเมนต์ความหมาย
keyคีย์ที่ต้องการอ่าน จุดเข้าถึงค่าที่ซ้อนกัน (featureFlags.workspaces)

เอาต์พุต

ค่าดิบพร้อมใช้ในสคริปต์ ออบเจกต์จะพิมพ์เป็น JSON แบบกะทัดรัด:

both

รหัสออก

  • 0: พิมพ์ค่าแล้ว
  • 1: คีย์ไม่มีค่า และไม่มีการพิมพ์อะไรเลย

openspec config set ​

bash
openspec config set delivery skills
openspec config set featureFlags.workspaces true

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

อาร์กิวเมนต์ความหมาย
keyคีย์ที่ต้องการเขียน ใช้จุดสำหรับค่าที่ซ้อนกัน
valueค่าใหม่ true/false จะกลายเป็นบูลีน สตริงตัวเลขจะกลายเป็นตัวเลข

ตัวเลือก

แฟล็กผลลัพธ์
--stringจัดเก็บค่าเป็นสตริง โดยข้ามการแปลงชนิดข้อมูล
--allow-unknownอนุญาตคีย์ที่สคีมาไม่รู้จัก

เอาต์พุต

Set featureFlags.workspaces = true

คีย์ที่ไม่รู้จักและค่าที่ไม่ถูกต้องจะล้มเหลวด้วยรหัสออก 1 ก่อนบันทึกสิ่งใด:

Error: Invalid configuration key "bogus.key". Unknown top-level key "bogus".
Use "openspec config list" to see available keys.
Pass --allow-unknown to bypass this check.
Error: Invalid configuration - delivery: Invalid option: expected one of "both"|"skills"|"commands"

หากไฟล์คอนฟิกมีอยู่แต่ไม่ได้เก็บออบเจกต์ JSON ไม่ว่าจะเพราะไม่ใช่ JSON ที่ถูกต้องเลย หรือเพราะรูทเป็นสิ่งอื่น เช่น null หรืออาร์เรย์ config set, config unset และ config profile จะออกด้วยรหัส 1 และปล่อยไฟล์ไว้ไม่เปลี่ยนแปลง แก้ไขด้วย openspec config edit หรือแทนที่ด้วย openspec config reset --all:

Error: /home/you/.config/openspec/config.json could not be parsed, so it was left unchanged.
Fix it with "openspec config edit", or reset it with "openspec config reset --all".

จนกว่าจะแก้ไข เทเลเมทรีและการตรวจสอบการอัปเดตจะปิดอยู่

openspec config unset ​

bash
openspec config unset delivery

ลบคีย์เพื่อให้ค่าเริ่มต้นมีผลอีกครั้ง คีย์ที่มีค่าเริ่มต้นในตัวจะถือว่าตั้งค่าไว้เสมอ ดังนั้นคำสั่งนี้จะรายงานความสำเร็จแม้คุณไม่เคยตั้งค่า:

Unset delivery (reverted to default)

คีย์ที่ไม่มีค่าเลยจะพิมพ์ Key "featureFlags.nothere" was not set ทั้งสองกรณีออกด้วยรหัส 0 ไฟล์คอนฟิกที่ไม่สามารถแยกวิเคราะห์ได้จะออกด้วยรหัส 1 แทน เช่นเดียวกับ config set

openspec config reset ​

bash
openspec config reset --all      # ขอการยืนยัน
openspec config reset --all -y   # ไม่มีพรอมป์

ตัวเลือก

แฟล็กผลลัพธ์
--allจำเป็น รีเซ็ตทุกอย่าง
-y, --yesข้ามพรอมป์ยืนยัน

เอาต์พุต

Configuration reset to defaults

หากไม่มี --all จะออกด้วยรหัส 1 และพิมพ์บรรทัดวิธีใช้งาน

รหัสออก

  • 0: รีเซ็ตเสร็จ หรือคุณตอบไม่ที่พรอมป์
  • 1: ไม่มี --all
  • 130: พรอมป์ถูกยกเลิกด้วย Ctrl-C

openspec config edit ​

bash
openspec config edit

เปิดไฟล์คอนฟิกใน $EDITOR (โดยถอยไปใช้ $VISUAL) สร้างไฟล์ด้วยค่าเริ่มต้นก่อนหากไม่มี เมื่อตัวแก้ไขปิด ไฟล์จะถูกตรวจสอบ JSON ที่ไม่ถูกต้องหรือคอนฟิกที่ไม่ถูกต้องจะออกด้วยรหัส 1

ค่าของตัวแก้ไขอาจมีอาร์กิวเมนต์และพาธที่ใส่เครื่องหมายคำพูด เช่น code --wait หรือ "/Applications/Sublime Text.app/Contents/SharedSupport/bin/subl" -w ค่านี้จะถูกแยกเป็นคำโดยไม่ผ่านเชลล์ ดังนั้น $VAR, ~ และ ; จะถูกส่งผ่านตามตัวอักษร ตัวแก้ไขที่ไม่สามารถเริ่มทำงานได้ หรือออกด้วยรหัสที่ไม่ใช่ศูนย์ จะพิมพ์ข้อผิดพลาดหนึ่งบรรทัดและออกด้วยรหัส 1

เมื่อไม่ได้กำหนดค่าตัวแก้ไข จะออกด้วยรหัส 1:

Error: No editor configured
Set the EDITOR or VISUAL environment variable to your preferred editor
Example: export EDITOR=vim

openspec config profile ​

bash
openspec config profile        # ตัวเลือกแบบอินเทอร์แอกทีฟ (ต้องมีเทอร์มินัล)
openspec config profile core   # ใช้พรีเซ็ต core โดยตรง

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

อาร์กิวเมนต์ความหมาย
presetชื่อพรีเซ็ตที่ไม่บังคับ ปัจจุบันมีเฉพาะ core ซึ่งเลือกเวิร์กโฟลว์หลักและคงการตั้งค่าการจัดส่งของคุณไว้

หากไม่มีพรีเซ็ต ตัวเลือกแบบอินเทอร์แอกทีฟจะแสดงการจัดส่งและเวิร์กโฟลว์ปัจจุบันของคุณ ให้คุณเปลี่ยนอย่างใดอย่างหนึ่งหรือทั้งสองอย่าง (การจัดส่ง: ทั้งสองอย่าง, เฉพาะสกิล หรือเฉพาะคำสั่ง; เวิร์กโฟลว์: รายการเช็กบ็อกซ์) พิมพ์ความแตกต่าง และภายในโปรเจกต์ OpenSpec จะเสนอให้รัน openspec update ให้คุณ นอกเทอร์มินัลจะออกด้วยรหัส 1:

Interactive mode required. Use `openspec config profile core` or set config via environment/flags.

เอาต์พุต

คอนฟิกที่เปลี่ยนแปลงจะไม่ไปถึงโปรเจกต์จนกว่าจะอัปเดต:

Config updated. Run `openspec update` in your projects to apply.

รหัสออก

  • 0: บันทึกโปรไฟล์แล้ว หรือคุณคงการตั้งค่าปัจจุบันไว้
  • 1: พรีเซ็ตที่ไม่รู้จัก ไม่มีเทอร์มินัล หรือ openspec update ที่เสนอให้รันล้มเหลว
  • 130: ตัวเลือกถูกยกเลิกด้วย Ctrl-C

openspec list ​

แสดงรายการการเปลี่ยนแปลง หรือสเปคด้วย --specs

bash
openspec list                    # การเปลี่ยนแปลงที่ใช้งานอยู่ เรียงตามที่แก้ไขล่าสุดก่อน
openspec list --archived         # การเปลี่ยนแปลงที่ถูกจัดเก็บ
openspec list --all              # การเปลี่ยนแปลงที่ใช้งานอยู่และที่ถูกจัดเก็บ
openspec list --specs            # สเปคพร้อมจำนวนข้อกำหนด
openspec list --json             # รูปแบบที่เครื่องอ่านได้ รวมถึงรากที่ระบุ

แถวมาจาก openspec/changes/ และ openspec/specs/ ภายใต้รากที่ระบุ รายการการเปลี่ยนแปลงเริ่มต้นจะข้าม openspec/changes/archive/

ตัวเลือก

ตัวเลือกผล
--specsแสดงรายการสเปคแทนการเปลี่ยนแปลง
--changesแสดงรายการการเปลี่ยนแปลง นี่คือค่าเริ่มต้น
--archivedแสดงเฉพาะการเปลี่ยนแปลงที่ถูกจัดเก็บ ไม่สามารถใช้ร่วมกับ --specs
--allแสดงการเปลี่ยนแปลงที่ใช้งานอยู่และที่ถูกจัดเก็บ ไม่สามารถใช้ร่วมกับ --specs มีลำดับความสำคัญสูงกว่า --archived
--sort <order>recent (แก้ไขล่าสุดก่อน) หรือ name ค่าเริ่มต้น: recent สเปคจะจัดเรียงตามชื่อเสมอ
--jsonพิมพ์ JSON แทนตาราง
--store <id>ใช้ store ที่ลงทะเบียนเป็นราก OpenSpec แทนโปรเจกต์ปัจจุบัน

ผลลัพธ์

หนึ่งแถวต่อการเปลี่ยนแปลง: ชื่อ, สถานะงาน, แก้ไขล่าสุด คอลัมน์สถานะจะแสดง No tasks, 2/5 tasks หรือ ✓ Complete

Changes:
  add-rate-limit     No tasks      just now

--all จัดกลุ่มการเปลี่ยนแปลงที่ใช้งานอยู่และที่ถูกจัดเก็บภายใต้หัวข้อแยกกัน แต่ละกลุ่มใช้การจัดเรียงที่เลือก:

Changes:
  add-rate-limit     No tasks      just now

Archived Changes:
  2026-08-10-add-login     ✓ Complete    2d ago
Specs:
  api     requirements 1

--json เพิ่มจำนวนงานและ status เป็น no-tasks, in-progress หรือ complete:

json
{
  "changes": [
    {
      "name": "add-rate-limit",
      "completedTasks": 0,
      "totalTasks": 0,
      "lastModified": "2026-08-11T13:44:40.171Z",
      "status": "no-tasks"
    }
  ],
  "root": {
    "path": "/Users/you/projects/my-app",
    "source": "nearest"
  }
}

ด้วย --archived หรือ --all วัตถุการเปลี่ยนแปลงทุกตัวจะมีบูลีน archived อาร์เรย์ที่รวมกันจะใช้การจัดเรียงที่เลือก การเปลี่ยนแปลงที่ถูกจัดเก็บยังคงมีสถานะ in-progress ได้เมื่อไฟล์งานที่ติดตามมีงานที่ยังไม่ได้ตรวจสอบ หากไม่มีตัวเลือกใดๆ รูปแบบ JSON จะยังคงไม่เปลี่ยนแปลง

รายการที่ว่างเปล่าจะพิมพ์ No active changes found., No archived changes found., No changes found. หรือ No specs found. และยังคงออกด้วยรหัส 0

การเปลี่ยนแปลงคือไดเรกทอรีโดยตรงภายใต้ openspec/changes/ ไม่เหมือนสเปค การเปลี่ยนแปลงไม่สามารถซ้อนกันในโฟลเดอร์เนมสเปซ โฟลเดอร์อย่าง changes/mobile/ ที่ห่อหุ้มเฉพาะการเปลี่ยนแปลง (changes/mobile/refresh-token/) จะถูกแสดงรายการด้วยสถานะ not a change ตามด้วยคำเตือนที่ระบุชื่อไดเรกทอรีที่ซ้อนกัน --json ทำเครื่องหมายรายการนั้นด้วยอาร์เรย์ nested และเพิ่มอาร์เรย์ warnings ระดับบนสุด show, status, validate และ archive ปฏิเสธโฟลเดอร์ด้วยข้อความเดียวกัน หากต้องการแก้ไข ให้ย้ายการเปลี่ยนแปลงขึ้นและพับเนมสเปซเข้าไปในชื่อ:

bash
mv openspec/changes/mobile/refresh-token openspec/changes/mobile-refresh-token
rmdir openspec/changes/mobile

รหัสการออก

  • 0: พิมพ์รายการแล้ว แม้ว่าจะว่างเปล่า
  • 1: ไม่พบราก OpenSpec (นอกโปรเจกต์ ไม่มี --store)

openspec show ​

พิมพ์การเปลี่ยนแปลงหรือสเปค เป็น markdown หรือ JSON

bash
openspec show add-rate-limit              # การเปลี่ยนแปลง: พิมพ์ proposal.md
openspec show add-rate-limit --diff       # การเปลี่ยนแปลง: เพิ่ม diffs ของข้อกำหนด
openspec show api                         # สเปค: พิมพ์ spec.md
openspec show api --json --no-scenarios   # สเปค JSON โดยไม่มีข้อความสถานการณ์

หากไม่มีชื่อ show จะถามว่าเป็นการเปลี่ยนแปลงหรือสเปค จากนั้นแสดงรายการให้เลือก นอกเทอร์มินัลแบบโต้ตอบจะออกด้วยรหัส 1 และพิมพ์รูปแบบโดยตรงแทน

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

อาร์กิวเมนต์คืออะไร
item-nameการเปลี่ยนแปลงหรือสเปคที่จะแสดง โดยชื่อโฟลเดอร์ (add-rate-limit, api)

ตัวเลือก

ตัวเลือกผล
--jsonพิมพ์ JSON ที่มีโครงสร้างแทน markdown ดิบ
--type <change|spec>เลือกประเภทเมื่อการเปลี่ยนแปลงและสเปคมีชื่อเดียวกัน
--no-interactiveไม่ต้องถาม: ชื่อที่ขาดหายไปจะกลายเป็นข้อผิดพลาด
--deltas-onlyJSON, การเปลี่ยนแปลง: จำกัดผลลัพธ์เฉพาะ deltas JSON การเปลี่ยนแปลงเป็น delta เท่านั้นอยู่แล้ว ดังนั้นผลลัพธ์จะตรงกับ --json ธรรมดา
--requirements-onlyนามแฝงที่เลิกใช้ของ --deltas-only แจ้งเตือนบน stderr
--diffการเปลี่ยนแปลง: เพิ่ม delta diffs ต่อข้อกำหนด ถูกข้ามพร้อมคำเตือนสำหรับสเปค
--requirementsJSON, สเปค: เก็บข้อความข้อกำหนด ทำให้อาร์เรย์ scenarios ว่างเปล่า
--no-scenariosJSON, สเปค: ผลลัพธ์เดียวกับ --requirements
-r, --requirement <id>JSON, สเปค: แสดงข้อกำหนดหนึ่งรายการตามตำแหน่งที่ 1 ไม่สามารถใช้ร่วมกับ --requirements
--store <id>ใช้ store ที่ลงทะเบียนเป็นราก OpenSpec แทนโปรเจกต์ปัจจุบัน

ตัวเลือกที่ไม่เกี่ยวข้องกับประเภทที่ระบุจะถูกข้ามพร้อมคำเตือนบน stderr

ผลลัพธ์

โหมดข้อความเป็นการส่งผ่านดิบ: การเปลี่ยนแปลงจะพิมพ์ proposal.md สเปคจะพิมพ์ spec.md

# Add rate limiting## เหตุผล
ไคลเอนต์ที่ไม่ได้อuthenticate สามารถใช้ทรัพยากร API หมดลงได้

## สิ่งที่มีการเปลี่ยนแปลง
- เพิ่มการกำหนดอัตราการใช้งานรายไคลเอนต์ (per-client rate limiting) สำหรับ API สาธารณะ

สำหรับรายการเปลี่ยนแปลง การใช้งาน `--diff` จะพิมพ์ proposal ก่อน จากนั้นแสดงส่วน `Specifications Changed (diffs)` ข้อกำหนดที่ถูกเพิ่ม (ADDED) จะแสดงข้อความเต็ม ข้อกำหนดที่ถูกเอาออก (REMOVED) จะคงเหตุผล (Reason) และขั้นตอนการโยกย้าย (Migration) ไว้ ข้อกำหนดที่ถูกเปลี่ยนชื่อ (RENAMED) จะแสดง FROM และ TO ข้อกำหนดที่ถูกแก้ไข (MODIFIED) จะแสดง diff แบบรวม (unified diff) เทียบกับข้อกำหนดหลักที่สอดคล้องกัน

ถ้าส่วนหัว MODIFIED สอดคล้องกันก็ต่อเมื่อปรับรูปแบบตัวอักษรใหญ่-เล็กหรือช่องว่าง (case or whitespace folding) ในผลลัพธ์จะประกอบด้วยทั้ง diff และคำเตือนว่าการจับคู่ archive เป็นแบบ exact หาก spec หลักหรือข้อกำหนดไม่มีอยู่ ผลลัพธ์จะแสดงคำเตือนและพิมพ์ชุดข้อมูล delta ทั้งบล้อก หากบล้อก MODIFIED ไม่มีข้อแตกต่างในเชิงข้อความ จะพิมพ์ `(no textual changes)`

รายการเปลี่ยนแปลงด้วย `--json` จะมีรูปทรงแบบ delta:

```json
{
  "id": "add-rate-limit",
  "title": "Add rate limiting",
  "deltaCount": 1,
  "deltas": [
    {
      "spec": "api",
      "operation": "ADDED",
      "description": "Add requirement: The API SHALL limit each client to 100 requests per minute.",
      "requirement": {
        "name": "Rate limit",
        "text": "The API SHALL limit each client to 100 requests per minute.",
        "scenarios": [
          {
            "name": "Client exceeds the limit",
            "rawText": "- **WHEN** a client sends its 101st request within a minute\n- **THEN** the API responds 429"
          }
        ]
      },
      ...
    }
  ],
  "root": {
    "path": "/Users/you/projects/my-app",
    "source": "nearest"
  }
}

แต่ละข้อกำหนดมี name ของตนเอง ซึ่งคือข้อความส่วนหัวหลัง Requirement: นี่คือชื่อที่ archive ใช้จับคู่กับรายการ MODIFIED, REMOVED และ RENAMED แต่ละ scenario มี name ของตนเอง ซึ่งคือข้อความส่วนหัวหลัง Scenario: ตัว # ปิดท้ายในบรรทัดส่วนหัวทั้งสองไม่ถือเป็นส่วนหนึ่งของชื่อ

--json --diff คงรูปทรงระดับบนนี้ไว้ delta ประเภท MODIFIED จะมีตัวแปร diff เป็น string, ตัวแปร warning เป็น string หรือทั้งสองอย่าง การดำเนินการอื่นไม่เปลี่ยนแปลง

String ของ diff ที่ว่างเปล่าหมายความว่า บล็อกหลักและบล็อก delta เหมือนกันแบบตัวต่อตัว

Spec ที่ใช้งานร่วมกับ --json จะแสดงรายการข้อกำหนดพร้อม scenarios ทั้งข้อกำหนดและ scenarios มีฟิลด์ name แบบเดียวกับ JSON ของ change:

json
{
  "id": "api",
  "title": "api",
  "overview": "Public HTTP API behavior.",
  "requirementCount": 1,
  "requirements": [
    {
      "name": "Health endpoint",
      "text": "The API SHALL expose a health endpoint.",
      "scenarios": [
        {
          "name": "Health check succeeds",
          "rawText": "- **WHEN** a client requests GET /health\n- **THEN** the API responds 200"
        }
      ]
    }
  ],
  "metadata": {
    "version": "1.0.0",
    "format": "openspec"
  },
  "root": {
    "path": "/Users/you/projects/my-app",
    "source": "nearest"
  }
}

ชื่อที่ไม่รู้จักจะแนะนำการตรงใกล้เคียง: Unknown item 'does-not-exist'. Did you mean: add-rate-limit, api? ชื่อที่ตรงกับทั้ง change และ spec จะทำให้เกิดข้อผิดพลาดและขอ --type

Exit codes

  • 0: แสดงรายการแล้ว
  • 1: ชื่อไม่รู้จักหรือกำกวม, ไม่มีชื่อเมื่ออยู่นอก terminal, index ของ -r อยู่เกินขอบเขต, --requirements ใช้ร่วมกับ -r, หรือไม่สามารถอ่าน delta หรือ spec หลักได้สำหรับ --diff

openspec view ​

พิมพ์หน้าแดชบอร์ดขนาดหนึ่งหน้าจอของ spec และ change

bash
openspec view   # project summary in one screen

view จะพิมพ์แดชบอร์ดเพียงครั้งเดียวแล้วออก ไม่รับคีย์สโตรกใดๆ Changes จะถูกจัดกลุ่มตามความคืบหน้าของงาน: Draft (ยังไม่มีงาน), Active (งานกำลังดำเนินการ พร้อมแถบความคืบหน้าและเปอร์เซ็นต์), Completed (ตรวจสอบงานครบทุกข้อ) Specs จะแสดงรายการพร้อมจำนวนข้อกำหนด โดยเรียงจากมากไปน้อย

Options

Flagผล
--store <id>ใช้ store ที่ลงทะเบียนไว้เป็นรากของ OpenSpec แทนโปรเจกต์ปัจจุบัน

ผลลัพธ์

OpenSpec Dashboard

════════════════════════════════════════════════════════════
สรุป:
  ● Specifications: 1 spec, 1 requirement
  ● Draft Changes: 1
  ● Active Changes: 0 กำลังดำเนินการ
  ● Completed Changes: 0

Draft Changes
────────────────────────────────────────────────────────────
  ○ add-rate-limit

Specifications
────────────────────────────────────────────────────────────
  ▪ api                            1 requirement

════════════════════════════════════════════════════════════

ใช้ openspec list --changes หรือ openspec list --specs เพื่อดูรายละเอียด

บรรทัดสรุป Task Progress จะแสดงเมื่อมี change ใดมีงานกำลังดำเนินการ

แต่ละ active change จะแสดงสถานะของ schema และ artifacts ของมันใต้แถบความคืบหน้าของงานด้วย:

text
    └─ [spec-driven] proposal✓ specs→ design→ tasks✓
เครื่องหมายสถานะของ artifact
✓output ของมันมีอยู่ artifact ของ tasks ที่มีอยู่แล้วถือว่าเสร็จเรียบร้อย แม้ checklist จะยังไม่เสร็จก็ตาม
→พร้อมที่จะสร้างแล้ว
ไม่มีเครื่องหมายถูกบล็อกเพราะขาด dependency
(skipped)change ข้ามขั้นตอนนี้

หาก workflow ไม่สามารถโหลดได้ view จะแสดงคำเตือนและยังคงให้ความคืบหน้าของงานสำหรับ change นั้นๆ อยู่ ให้รัน openspec status --change <name> เพื่อตรวจสอบ workflow โดยเฉพาะ หลังจาก openspec view --store <id> แล้ว ให้ส่ง --store <id> เดียวกันไปยัง status

Exit codes

  • 0: พิมพ์แดชบอร์ดแล้ว
  • 1: ไม่พบรากของ OpenSpec (อยู่นอกโปรเจกต์, ไม่มี --store)

openspec validate ​

ตรวจสอบปัญหาเชิงโครงสร้างใน changes และ specs

bash
openspec validate add-rate-limit   # change หรือ spec เดียว, โดยชื่อ
openspec validate --all            # change และ spec ทั้งหมด

เมื่อไม่มีชื่อและไม่มี flag แบบรวม validate จะขอให้เลือก items เมื่ออยู่นอก interactive terminal มันจะออกด้วยค่า 1 และพิมพ์ flags แบบรวมแทน

Arguments

Argumentsคืออะไร
item-namechange หรือ spec ที่จะตรวจสอบ, โดยชื่อโฟลเดอร์ (add-rate-limit, api)

Options

Flagผล
--allตรวจสอบ change และ spec ทั้งหมด
--changesตรวจสอบ change ทั้งหมด
--specsตรวจสอบ spec ทั้งหมด
--archivedตรวจสอบการเสร็จสิ้นของงานใน archived changes, โดยไม่ตรวจสอบ delta ของ spec ที่ถูกนำไปใช้แล้ว
--strictถือว่าคำเตือนเป็นความล้มเหลว
--type <change|spec>เลือกประเภทเมื่อ change และ spec ใช้ชื่อเดียวกัน
--jsonพิมพ์รายงานแบบโครงสร้างแทนข้อความ
--report <mode>ผลลัพธ์แบบรวม: full (ค่าเริ่มต้น) หรือ findings ต้องระบุขอบเขตแบบรวมอย่างชัดเจน
--concurrency <n>จำนวน validation แบบขนานสูงสุดในการรันแบบรวม ค่าเริ่มต้น: OPENSPEC_CONCURRENCY หรือ 6 หากไม่มี
--no-interactiveห้ามถาม: ชื่อที่หายไปหรือกำกวมจะกลายเป็นข้อผิดพลาด
--store <id>ใช้ store ที่ลงทะเบียนไว้เป็นรากของ OpenSpec แทนโปรเจกต์ปัจจุบัน

ผลลัพธ์

การรันแบบรวมจะพิมพ์บรรทัดสถานะต่อ item หนึ่งบรรทัด ตามด้วย findings หากมี และปิดท้ายด้วยยอดรวม:

✓ change/add-rate-limit
✓ spec/api
สรุป: ผ่าน 2, ไม่ผ่าน 0 (2 รายการ)

Findings จาก checkbox ของงาน

ความคืบหน้านับแต่ checkbox เท่านั้น ดังนั้นไฟล์งานที่เขียนเป็น bullet ธรรมดาจะถูกร่วม 0 งาน: openspec list และ openspec status จะรายงานว่าจะไม่มีงาน และ openspec archive จะไม่มีอะไรให้ flag ว่าไม่สมบูรณ์ Validate จะรายงาน WARNING สำหรับแต่ละไฟล์งานที่ถูก track ที่มีการทำงานแต่ไม่มี checkbox:

text
⚠ [WARNING] tasks.md: การเปลี่ยนแปลงนี้ถูกนับว่า 0 งาน: ไม่มีบรรทัดในไฟล์งานที่ถูก track ใดเป็น checkbox ดังนั้น "openspec list" และ "openspec status" จึงรายงานว่าจะไม่มีงาน และ "openspec archive" จะไม่มีอะไรให้ flag ว่าไม่สมบูรณ์ เขียนแต่ละงานเป็น "- [ ] 1.1 Description"

คำเตือนนี้จะทำงานก็ต่อเมื่อชุดที่ track ทั้งหมดของ change นั้นไม่มี checkbox เลย ไฟล์ข้อความโปรสมายืนข้าง checklist จริงจะไม่ถูกร่วม และ change ที่กำลังเขียนอยู่จะคงความคืบหน้าทันทีที่ checkbox เพียงหนึ่งตัวมีอยู่ --strict จะเปลี่ยนคำเตือนนั้นเป็นความล้มเหลว หมายเลขบรรทัดจะอยู่ในรายงาน --json

Fenced blocks, HTML comments, YAML front matter และโค้ดแบบ indent จะไม่ถูกสแกน ดังนั้นตัวอย่าง terminal ที่วางลงมาแล้วจะไม่ถูกตีความว่าเป็นรายการงานโดยพลั้ง

Findings จาก archive merge

สำหรับ changes, validate จะรัน merge builder ของ archive กับ spec หลักปัจจุบันโดยไม่ได้เขียนไฟล์ มันจะรายงานความขัดแย้งในการ merge, ตัวอย่างเช่น MODIFIED target ที่ขาดหายหรือข้อกำหนด ADDED ที่ขัดแย้งกัน, เป็น INFO:

text
ℹ [INFO] api/spec.md: Archive ปฏิเสธ delta นี้: api MODIFIED ล้มเหลวสำหรับส่วนหัว "### Requirement: Rate limiting" - ไม่พบ

Findings เหล่านี้จะแสดงแม้ validation จะผ่าน ในทั้งผลลัพธ์แบบข้อความและ JSON INFO ไม่เปลี่ยน exit code, รวมถึงเมื่อใช้ --strict: target ที่ขาดหายอาจเป็นส่วนหนึ่งของ sibling change ที่ยังไม่ได้ archive อยู่ Deltas ที่ถูก sync เข้า spec หลักแล้วจะปฏิบัติตามกฎการ merge ที่มีอยู่เดิมของการ archive

การตรวจสอบนี้ไม่รันการตรวจสอบ merged-spec หรือการเกษียณในภายหลังของ archive รายงานที่สะอาดไม่การันตีว่า archive จะสำเร็จ

หาก merge preflight ไม่สามารถเริ่มได้ INFO finding จะอธิบายสาเหตุ Findings การตรวจสอบเดิมและ exit code จะไม่เปลี่ยนแปลง

item ที่ล้มเหลวจะแสดงปัญหาแต่ละอย่างและวิธีแก้ไข:

Change 'add-rate-limit' มีปัญหา
✗ [ERROR] api/spec.md: ADDED "Rate limiting" ต้องมี scenario อย่างน้อยหนึ่ง
ขั้นตอนต่อไป:
  - ให้ change มี deltas ใน specs/: ใช้ส่วนหัว ## ADDED/MODIFIED/REMOVED/RENAMED Requirements
  - แต่ละ requirement MUST มีบล็อก #### Scenario: อย่างน้อยหนึ่ง
  - Debug parsed deltas: openspec show add-rate-limit --json --deltas-only

--json จะพิมพ์รายงานหนึ่งรายงานสำหรับการรัน:

json
{
  "items": [
    {
      "id": "add-rate-limit",
      "type": "change",
      "valid": true,
      "issues": [],
      "durationMs": 2
    }
  ],
  "summary": {
    "totals": {
      "items": 1,
      "passed": 1,
      "failed": 0
    },
    "byType": {
      "change": {
        "items": 1,
        "passed": 1,
        "failed": 0
      }
    }
  },
  "version": "1.0",
  "root": {
    "path": "/Users/you/projects/my-app",
    "source": "nearest"
  }
}

entries ใน issues มี level เป็น ERROR, WARNING หรือ INFO

Exit codes

  • 0: item ที่ตรวจสอบทั้งหมดผ่าน, รวมถึงขอบเขตแบบรวมที่ว่างเปล่า
  • 1: item ล้มเหลว, คำขอให้รายงานไม่ถูกต้อง, openspec/config.yaml อ่านไม่ได้หรือไม่ใช่ YAML ที่ถูกต้อง, หรือการรันล้มเหลว (เช่น ชื่อไม่รู้จักหรือไม่มีรากของ OpenSpec) Config ที่อ่านหรือ parse ไม่ได้จะหยุดการรันก่อนตรวจสอบ item ใดๆ; เมื่อใช้ --json จะรายงานเป็น status entry เดียวโดยมี code ว่า unreadable_config หรือ unparseable_config

--report full|findings ​

เลือกผลลัพธ์สำหรับขอบเขตการตรวจสอบแบบรวมที่ระบุชัดเจน:

  • full: ทุก item นี่คือค่าเริ่มต้น --report full ที่ชัดเจนจะคงรูปทรงผลลัพธ์เดิมไว้โดยไม่เพิ่ม metadata ของรายงาน
  • findings: เฉพาะ items ที่มปัญหา, รวมถึง items ที่ผ่านแต่มีคำเตือนหรือข้อมูล ทุก item ยังคงถูกตรวจสอบ ยอดรวม, พฤติกรรมใน strict mode, และ exit codes ไม่เปลี่ยนแปลง
bash
openspec validate --all --report findings
openspec validate --archived --report findings --json

Scopes

FlagsFindings report.scope
--allall
--changeschanges
--specsspecs
--changes --specs, หรือ --all พร้อม flag ใดก็ได้all
--archivedarchived

โหมดรายงานที่ชัดเจนทั้งสองแบบจะปฏิเสธการระบุชื่อ item แบบ positional, ขอบเขตแบบรวมที่หายไป, หรือการรวม scope ของ archive และ active

Findings แบบข้อความ ​

ผลลัพธ์แบบมนุษย์: stdout จะพิมพ์ Scope: <scope> (<count> รายการ), จากนั้นเป็นยอดรวม เมื่อไม่มี items ที่มีปัญหา:

text
Scope: all (2 รายการ)
ไม่มี findings ในรายการ
สรุป: ผ่าน 2, ไม่ผ่าน 0 (2 รายการ)

ป้ายชื่อ items ที่มีปัญหา, ป้ายระดับความรุนแรง, paths, และข้อความจะถูกพิมพ์ไปยัง stderr ความล้มเหลวใน active scope จะคงการแจ้งเตือนในการรันซ้ำ Details: ไว้หลังยอดรวม root banner และผลลัพธ์ progress เดิมอาจมาก่อนรายงาน

Findings แบบ JSON ​

--report findings --json จะพิมพ์เอกสารหนึ่ง ตัวอย่างนี้มี items ที่สะอาดสองตัว:

json
{
  "report": {
    "kind": "validation-findings",
    "version": "1.0",
    "scope": "all",
    "returnedItems": 0,
    "totalItems": 2
  },
  "itemFindings": [],
  "summary": {
    "totals": { "items": 2, "passed": 2, "failed": 0 },
    "byType": {
      "change": { "items": 1, "passed": 1, "failed": 0 },
      "spec": { "items": 1, "passed": 1, "failed": 0 }
    }
  },
  "root": { "path": "/Users/you/projects/my-app", "source": "nearest" }
}
  • report.kind และ report.version: ระบุรูปทรงของ validation-findings, เวอร์ชัน 1.0 ไม่มีส่วน version หรือ items ระดับบน
  • report.returnedItems และ report.totalItems: นับ record ที่ส่งกลับและ items ที่ตรวจสอบทั้งหมด
  • itemFindings: รายการ item โดยสมบูรณ์ที่ issues array ของมันไม่ว่างเปล่า รวม issues ประเภท ERROR, WARNING และ INFO แต่ละ record มี id, type, valid, issues และ durationMs Archived items ใช้ type: "change"
  • summary: ยอดรวมของการรันทั้งหมดและจำนวนต่อประเภท ไม่ใช่จำนวนของ subset ที่ส่งกลับ ขอบเขตที่ว่างมียอดรวมเป็นศูนย์และออกด้วย 0
  • root: metadata ของ root ที่เลือกแบบเดียวกับรายงานเต็ม

การอนุรักษ์ record: items ที่ส่งกลับจะคงลำดับของรายงานเต็มและฟิลด์ที่เพิ่มเข้ามาใน items หรือ issues การกรองจะไม่เขียนข้อความหรือตำแหน่งใหม่ รวมถึงฟิลด์ line และ column ที่เป็นตัวเลือก

ความล้มเหลวของคำสั่ง: ความล้มเหลวในการเลือก root หรือการค้นพบ items จะคง diagnostic ของ status ที่มีอยู่เดิมและออกด้วย 1 ไม่ส่งกลับรายงาน findings ที่เสร็จสมบูรณ์หรือรายงานว่างที่สำเร็จ

คำขอรายงานที่ไม่ถูกต้อง ​

โหมดรายงานที่ชัดเจนทั้งสองแบบจะปฏิเสธคำขอเหล่านี้ก่อนการเลือก root หรือการค้นพบ items:

  • ค่า report ที่ไม่รองรับ, รวมถึง string ที่ว่างเปล่า
  • ชื่อ item แบบ positional, แม้มี flag แบบรวม
  • ไม่มีขอบเขตแบบรวมที่ระบุชัดเจน
  • --archived ใช้ร่วมกับ --all, --changes หรือ --specs

ในโหมด JSON คำขอที่ถูกปฏิเสธจะออกด้วย 1 พร้อม status array ที่มีองค์ประกอบเดียว ไม่มี root หรือข้อมูล payload ของรายงาน:

bash
openspec validate --all --report bogus --json
json
{
  "status": [
    {
      "severity": "error",
      "code": "invalid_validation_report_request",
      "message": "Unknown validation report 'bogus'.",
      "fix": "ใช้ --report full|findings กับ --all, --changes, --specs, หรือ --archived โดยไม่มีชื่อ item ห้ามรวม scope ของ archived และ active"
    }
  ]
}

โหมดมนุษย์จะพิมพ์ความผิดพลาดไปยัง stderr --report เปล่าๆ โดยไม่มีค่าจะเป็นข้อผิดพลาด syntax ของ Commander บน stderr, รวมถึงเมื่อใช้ --json; มันจะไม่ใช้ diagnostic envelope นี้

กรองรายงานเต็มจากภายนอก ​

สำหรับมุมมอง JSON แบบกำหนดเอง ให้กรองรายงานเต็มด้วย jq หรือ PowerShell ตัวอย่างสคริปต์เหล่านี้จะคง exit code ของ validation ไว้และละเว้นเอกสารความผิดพลาดของคำสั่ง

ใน Bash กับ jq:

bash
if validation_json=$(openspec validate --all --json); then
  validation_exit=0
else
  validation_exit=$?
fi
printf '%s\n' "$validation_json" |
  jq 'if has("items") then .items |= map(select(.issues | length > 0)) else . end'
exit "$validation_exit"

ใน PowerShell:

powershell
$validationJson = openspec validate --all --json
$validationExit = $LASTEXITCODE
$validationReport = $validationJson | ConvertFrom-Json
if ($validationReport.PSObject.Properties.Name -contains 'items') {
  $validationReport.items = @($validationReport.items | Where-Object { $_.issues.Count -gt 0 })
}
$validationReport | ConvertTo-Json -Depth 100
exit $validationExit

มุมมองแบบกำหนดเองเหล่านี้จะคง keys ของรายงานเต็มไว้แต่ละเว้น items ที่สะอาด มันไม่ใช่ทั้งรายงานเต็ม v1 ที่สมบูรณ์และไม่ใช่รูปทรงของ --report findings ที่มีเวอร์ชัน

openspec archive ​

ย้ายการเปลี่ยนแปลงที่เสร็จสมบูรณ์ไปยังไฟล์เก็บถาวรและอัปเดตสเปกหลัก

bash
openspec archive add-rate-limit -y                # archive one change, merge its deltas
openspec archive add-rate-limit -y --skip-specs   # archive without touching the specs

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

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

อาร์กิวเมนต์ความหมาย
change-nameการเปลี่ยนแปลงที่จะเก็บถาวร โดยใช้ชื่อโฟลเดอร์ (add-rate-limit)

ตัวเลือก

แฟล็กผลลัพธ์
-y, --yesตอบว่าใช่สำหรับการยืนยันทุกครั้ง: การอัปเดตสเปก งานที่ไม่สมบูรณ์ การข้ามการตรวจสอบ
--skip-specsเก็บถาวรโดยไม่แตะต้องสเปกหลัก (การเปลี่ยนแปลงโครงสร้างพื้นฐาน เครื่องมือ หรือเอกสารเท่านั้น)
--no-validateข้ามการตรวจสอบ คำสั่ง archive จะถามให้คุณยืนยันก่อน และ -y จะตอบให้
--jsonพิมพ์ผลลัพธ์แบบมีโครงสร้างแทนข้อความ ต้องใช้ --yes เพื่อยืนยันการอัปเดตสเปก
--store <id>ใช้ store ที่ลงทะเบียนเป็นรากของ OpenSpec แทนโปรเจกต์ปัจจุบัน

ผลลัพธ์

การรันที่สำเร็จจะรายงานสถานะงาน แสดงตัวอย่างการอัปเดตสเปก นำไปใช้ และระบุชื่อโฟลเดอร์เก็บถาวร:

Task status: ✓ Complete

Specs to update:
  api: update
Applying changes to openspec/specs/api/spec.md:
  + 1 added
Totals: + 1, ~ 0, - 0, → 0
Specs updated successfully.
Change 'add-rate-limit' archived as '2026-08-11-add-rate-limit'.

โฟลเดอร์การเปลี่ยนแปลงจะถูกย้ายทั้งโฟลเดอร์ไปยัง openspec/changes/archive/2026-08-11-add-rate-limit/ โดยมีวันที่วันนี้เป็นคำนำหน้าชื่อ เดลต้าแต่ละรายการจะถูกรวมเข้ากับสเปกหลัก: ข้อกำหนด ADDED ด้านบนถูกผนวกเข้ากับ openspec/specs/api/spec.md หากไม่ใช้ -y คำสั่ง archive จะแสดงตัวอย่างและถามก่อนอัปเดต การปฏิเสธจะยังคงเก็บถาวรการเปลี่ยนแปลงและปล่อยสเปกไว้ตามเดิม

ด้วย --json --yes:

json
{
  "archive": {
    "change": "add-rate-limit",
    "archivedAs": "2026-08-11-add-rate-limit",
    "path": "/Users/you/projects/my-app/openspec/changes/archive/2026-08-11-add-rate-limit",
    "specsUpdated": true,
    "totals": {
      "added": 1,
      "modified": 0,
      "removed": 0,
      "renamed": 0
    }
  },
  "root": {
    "path": "/Users/you/projects/my-app",
    "source": "nearest"
  }
}

คำสั่ง archive จะตรวจสอบการเปลี่ยนแปลงก่อน และปฏิเสธหากไม่ผ่าน:

Validation errors in change delta specs:
  ✗ ADDED "Rate limiting" must include at least one scenario

Validation failed. Please fix the errors before archiving.
To skip validation (not recommended), use --no-validate flag.

งานที่ไม่สมบูรณ์จะเตือนแต่ไม่บล็อก หากใช้โหมดโต้ตอบ คำสั่ง archive จะถามว่าจะดำเนินการต่อหรือไม่ และ -y จะดำเนินการต่อเอง:

Task status: 1/2 tasks
Warning: 1 incomplete task(s) found. Continuing due to --yes flag.

รหัสออก

  • 0: การเปลี่ยนแปลงถูกเก็บถาวรแล้ว ไม่ว่าจะมีการอัปเดตสเปกหรือไม่
  • 1: การตรวจสอบล้มเหลว ชื่อการเปลี่ยนแปลงไม่รู้จัก หรือจำเป็นต้องยืนยันแต่ไม่สามารถอ่านคำตอบได้

openspec new ​

สร้างไดเรกทอรีการเปลี่ยนแปลงใหม่

bash
openspec new change add-caching                                # metadata only
openspec new change add-search --goal "Users can search docs"  # record a goal

new มีซับคอมมานด์เดียวคือ new change <name> ซึ่งสร้าง openspec/changes/<name>/ ที่มีไฟล์เมทาดาทา .openspec.yaml เพียงไฟล์เดียว:

yaml
schema: spec-driven
created: 2026-08-11

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

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

อาร์กิวเมนต์ความหมาย
nameชื่อโฟลเดอร์สำหรับการเปลี่ยนแปลง (add-caching)

ตัวเลือก

แฟล็กผลลัพธ์
--description <text>สร้าง README.md ในไดเรกทอรีการเปลี่ยนแปลงพร้อมข้อความนี้ด้วย
--goal <text>เก็บบรรทัด goal: ไว้ใน .openspec.yaml
--schema <name>สคีมาเวิร์กโฟลว์สำหรับการเปลี่ยนแปลง ค่าเริ่มต้น: spec-driven ซึ่งเป็นสคีมาเดียวที่มาพร้อมกับเครื่องมือ
--jsonพิมพ์การเปลี่ยนแปลงที่สร้างเป็น JSON แทนข้อความ
--store <id>ใช้ store ที่ลงทะเบียนเป็นรากของ OpenSpec แทนโปรเจกต์ปัจจุบัน

ผลลัพธ์

Created change 'add-caching' at openspec/changes/add-caching/
Schema: spec-driven
Next: openspec status --change add-caching

เมื่อไม่พบไดเรกทอรี openspec/ คำสั่ง new change จะสร้างหนึ่งในตำแหน่งที่คุณอยู่และแจ้งให้ทราบ:

Created change 'add-caching' at openspec/changes/add-caching/
Schema: spec-driven
Next: openspec status --change add-caching

Note: no OpenSpec root was found here, so one was created at openspec/.
Run `openspec init` to finish setting this project up, or delete that directory if you meant a different project.

ข้อความแจ้งเตือนจะไปที่ stdout พร้อมกับเอาต์พุตอื่น ๆ สำหรับมนุษย์ และจะไม่ปรากฏเมื่อใช้ --json

เมื่อใช้ --json ในโปรเจกต์ที่มี openspec/ อยู่แล้ว:

json
{
  "change": {
    "id": "add-caching",
    "path": "/Users/you/projects/my-app/openspec/changes/add-caching",
    "metadataPath": "/Users/you/projects/my-app/openspec/changes/add-caching/.openspec.yaml",
    "schema": "spec-driven"
  },
  "root": {
    "path": "/Users/you/projects/my-app",
    "source": "nearest"
  }
}

เมื่อไม่พบไดเรกทอรี openspec/ และ new change สร้างขึ้นมา JSON จะมีรูปแบบเดียวกัน root.path คือไดเรกทอรีที่คุณรันคำสั่ง และ root.source จะเป็น implicit:

json
"root": {
  "path": "/Users/you/projects/my-app",
  "source": "implicit"
}

รหัสออก

  • 0: สร้างการเปลี่ยนแปลงแล้ว
  • 1: การเปลี่ยนแปลงมีอยู่แล้ว หรือสคีมาไม่รู้จัก## openspec status

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

bash
openspec status --change add-rate-limit          # checklist view
openspec status --change add-rate-limit --json   # structured report
openspec status --all                            # every active change
openspec status --all --json                     # one batch report

เมื่อมีการเปลี่ยนแปลงที่ยังดำเนินอยู่ ให้ใช้ --change หรือ --all อย่างใดอย่างหนึ่งเท่านั้น หากไม่ระบุทั้งสอง คำสั่ง status จะออกด้วยรหัส 1 และแสดงรายการการเปลี่ยนแปลงที่มีอยู่ แม้จะมีเพียงรายการเดียวก็ตาม:

text
✖ Error: Missing required option --change (or --all for every active change). Available changes:
  add-rate-limit

เมื่อโปรเจกต์ไม่มีการเปลี่ยนแปลงที่ยังดำเนินอยู่ status จะพิมพ์ No active changes. Create one with: openspec new change <name> และออกด้วยรหัส 0 แม้จะไม่ได้ระบุแฟล็กใด ๆ เมื่อใช้ --all --json สถานะว่างแบบเดียวกันจะแสดงเป็น { "changes": [], "message": "No active changes.", "root": ... }

ตัวเลือก

แฟล็กผล
--change <id>การเปลี่ยนแปลงที่ต้องการรายงาน โดยใช้ชื่อโฟลเดอร์
--allรายงานทุกการเปลี่ยนแปลงที่ยังดำเนินอยู่ เรียงตามชื่อ ไม่สามารถใช้ร่วมกับ --change ได้
--schema <name>แทนที่สคีมาที่ตรวจพบอัตโนมัติจาก openspec/config.yaml ชื่อที่ไม่รู้จักถือเป็นข้อผิดพลาด
--jsonพิมพ์รายงานแบบมีโครงสร้างแทนข้อความ
--store <id>ใช้สโตร์ที่ลงทะเบียนไว้เป็นรูทของ OpenSpec แทนโปรเจกต์ปัจจุบัน

เอาต์พุต

รายการตรวจสอบอาร์ติแฟกต์ของสคีมา: [x] เสร็จแล้ว, [ ] พร้อมเขียน, [-] ถูกบล็อกจนกว่าอาร์ติแฟกต์ที่ต้องพึ่งพาจะมีอยู่

Change: add-rate-limit
Schema: spec-driven
Change root: /Users/you/projects/my-app/openspec/changes/add-rate-limit
Progress: 2/4 artifacts complete

[x] proposal
[x] specs
[ ] design
[-] tasks (blocked by: design)

Next: openspec instructions design --change "add-rate-limit" --json

บรรทัด Next: ระบุคำสั่งเดียวที่ทำให้การเปลี่ยนแปลงเดินหน้าต่อ ดังนั้น openspec status จึงเพียงพอสำหรับกลับมาทำการเปลี่ยนแปลงต่อในเซสชันใหม่ บรรทัดนี้จะระบุอาร์ติแฟกต์ถัดไปที่พร้อมใช้งานในขณะที่การวางแผนยังไม่เสร็จสิ้น และจะระบุ openspec instructions apply เมื่ออาร์ติแฟกต์การวางแผนทั้งหมดมีอยู่แล้ว:

[x] proposal
[x] specs
[x] design
[x] tasks

All planning artifacts complete!
Next: openspec instructions apply --change "add-rate-limit" --json

บรรทัดนี้จะมี --store <id> ทุกครั้งที่รูทที่ได้รับการแก้ไขแล้วเป็นสโตร์ และระบุคำสั่งเดียวกับประโยค nextSteps ใน JSON

--json จะเพิ่มการพึ่งพาของแต่ละอาร์ติแฟกต์ พาธไฟล์ที่แก้ไขแล้ว และขั้นตอนถัดไปที่แนะนำ ตัวอย่างแบบตัดทอน:

json
{
  "changeName": "add-rate-limit",
  "schemaName": "spec-driven",
  "isComplete": false,
  "nextSteps": [
    "Run openspec instructions design --change \"add-rate-limit\" --json before writing that artifact."
  ],
  "artifacts": [
    {
      "id": "proposal",
      "outputPath": "proposal.md",
      "status": "done",
      "requires": []
    },
    {
      "id": "design",
      "outputPath": "design.md",
      "status": "ready",
      "requires": [
        "proposal"
      ]
    },
    {
      "id": "tasks",
      "outputPath": "tasks.md",
      "status": "blocked",
      "requires": [
        "specs",
        "design"
      ],
      "missingDeps": [
        "design"
      ]
    }
  ]
}

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

json
{
  "changes": [
    {
      "changeName": "add-rate-limit",
      "schemaName": "spec-driven",
      "artifacts": []
    }
  ],
  "root": {
    "path": "/Users/you/projects/my-app",
    "source": "nearest"
  }
}

หากการเปลี่ยนแปลงหนึ่งรายการโหลดไม่ได้ การประมวลผลแบบกลุ่มจะดำเนินต่อไป รายการนั้นจะมี changeName และข้อมูลวินิจฉัยใน status ในขณะที่รายการอื่นยังคงใช้งานได้ คำสั่งจะออกด้วยรหัส 1 รวมถึงในโหมด JSON เพื่อให้ CI ไม่ถือรายงานที่ไม่สมบูรณ์ว่าเสร็จสมบูรณ์ เอาต์พุต JSON ยังคงเป็นเอกสารเดียวที่แยกวิเคราะห์ได้

รหัสออก

  • 0: สถานะที่ร้องขอทั้งหมดถูกพิมพ์แล้ว รายงาน --all ที่ว่างเปล่าก็ออกด้วยรหัส 0 เช่นกัน
  • 1: การเปลี่ยนแปลงที่ร้องขอโหลดไม่สำเร็จ, ไม่มี --change หรือ --all, ใช้สองแฟล็กร่วมกัน, ไม่พบการเปลี่ยนแปลงนั้น, หรือการแทนที่สคีมาไม่รู้จัก

openspec instructions ​

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

bash
openspec instructions proposal --change add-rate-limit   # how to write one artifact
openspec instructions apply --change add-rate-limit      # how to implement the change
openspec instructions archive --change add-rate-limit    # inputs for archiving

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

อาร์กิวเมนต์ความหมาย
artifactไอดีอาร์ติแฟกต์จากสคีมา (proposal, specs, design, tasks ใน spec-driven) หรือคำสงวน apply และ archive

ตัวเลือก

แฟล็กผล
--change <id>การเปลี่ยนแปลงที่ต้องการสร้างคำแนะนำ จำเป็นต้องระบุ
--schema <name>แทนที่สคีมา มิฉะนั้นจะตรวจพบอัตโนมัติจาก config.yaml
--jsonพิมพ์ออบเจกต์แบบมีโครงสร้างแทนข้อความ
--store <id>ใช้สโตร์ที่ลงทะเบียนไว้เป็นรูทของ OpenSpec แทนโปรเจกต์ปัจจุบัน

เอาต์พุต

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

<artifact id="proposal" change="add-rate-limit" schema="spec-driven">

<task>
Create the proposal artifact for change "add-rate-limit".
Initial proposal document outlining the change
</task>

<output>
Write to: /Users/you/projects/my-app/openspec/changes/add-rate-limit/proposal.md
</output>

<instruction>
Create the proposal document that establishes WHY this change is needed.
...

apply จะพิมพ์ไฟล์บริบท ความคืบหน้าของงาน และคำแนะนำในการทำงาน:

## Apply: add-rate-limit
Schema: spec-driven

### Context Files
- proposal: /Users/you/projects/my-app/openspec/changes/add-rate-limit/proposal.md
- specs: /Users/you/projects/my-app/openspec/changes/add-rate-limit/specs/api/spec.md
- tasks: /Users/you/projects/my-app/openspec/changes/add-rate-limit/tasks.md

### Progress
1/3 complete

### Tasks
- [x] 1.1 Add rate limit middleware
- [ ] 1.2 Return 429 with Retry-After header
- [ ] 1.3 Add tests for burst traffic

### Instruction
Read context files, work through pending tasks, mark complete as you go.
Pause if you hit blockers or need clarification.

No project context or operation guidance configured.

เมื่ออาร์ติแฟกต์ที่จำเป็นขาดหายไป apply จะรายงาน ### ⚠️ Blocked และระบุชื่ออาร์ติแฟกต์เหล่านั้นแทน archive จะพิมพ์ชื่อการเปลี่ยนแปลงพร้อมบริบทของโปรเจกต์และคำแนะนำการดำเนินงานจากคอนฟิก หากไม่ได้กำหนดค่าไว้เลย จะแจ้งเพียงเท่านั้นและไม่มีอย่างอื่นอีก

เมื่อใช้ --json แต่ละรูปแบบจะคืนค่าหนึ่งออบเจกต์ รูปแบบอาร์ติแฟกต์เริ่มต้นดังนี้:

json
{
  "changeName": "add-rate-limit",
  "artifactId": "proposal",
  "schemaName": "spec-driven",
  "changeDir": "/Users/you/projects/my-app/openspec/changes/add-rate-limit",
  ...

และดำเนินต่อไปด้วย outputPath, existingOutputPaths, สตริง instruction และ template แบบเต็ม, dependencies, unlocks และ root รูปแบบ apply จะมี contextFiles, tasks, taskTrackingConfigured, state (blocked, ready, all_done) และ instruction

แต่ละรายการใน tasks จะมี id, description, done, sourcePath และ line โดย sourcePath คือพาธแบบสัมบูรณ์ของไฟล์ที่ติดตามซึ่งเป็นแหล่งที่มาของงาน และ line คือหมายเลขบรรทัด (เริ่มนับที่หนึ่ง) ของช่องทำเครื่องหมายงานในไฟล์นั้น

taskTrackingConfigured เป็นค่าบูลีนเสมอ: เป็น true เมื่อสคีมากำหนด apply.tracks ที่ไม่ใช่ null แม้จะไม่มีไฟล์ใดตรงกัน และเป็น false ในกรณีอื่น หากไฟล์ติดตามที่ตรงกันไม่สามารถอ่านได้ unavailableTrackingFiles จะมี path แบบสัมบูรณ์และ reason ของข้อผิดพลาด ฟิลด์นี้จะถูกละไว้เมื่อไฟล์ที่ตรงกันทั้งหมดอ่านได้ ไฟล์ที่อ่านได้ยังคงมีส่วนร่วมใน tasks และ progress แต่ state จะไม่สามารถเป็น all_done ได้จนกว่าจะอ่านไฟล์ที่ตรงกันทั้งหมด

รหัสออก

  • 0: พิมพ์คำแนะนำแล้ว
  • 1: อาร์ติแฟกต์ไม่รู้จัก, การเปลี่ยนแปลงไม่รู้จัก, สคีมาไม่รู้จัก หรือไม่มี --change แต่ละข้อผิดพลาดจะแสดงรายการค่าที่ถูกต้อง

openspec templates ​

แสดงเส้นทางเทมเพลตที่ resolve แล้วสำหรับ artifacts ของ schema

bash
openspec templates          # schema เริ่มต้น: spec-driven
openspec templates --json   # แม็ปจาก artifact id ไปยังเส้นทาง

ตัวเลือก

แฟล็กเอฟเฟกต์
--schema <name>Schema ที่ต้องการ resolve ค่าเริ่มต้น: spec-driven
--jsonแสดงผลแม็ป JSON จาก artifact id ไปยังเส้นทางเทมเพลต

ผลลัพธ์

Schema: spec-driven
Source: package

proposal:
  /usr/local/lib/node_modules/@fission-ai/openspec/schemas/spec-driven/templates/proposal.md
specs:
  /usr/local/lib/node_modules/@fission-ai/openspec/schemas/spec-driven/templates/spec.md
design:
  /usr/local/lib/node_modules/@fission-ai/openspec/schemas/spec-driven/templates/design.md
tasks:
  /usr/local/lib/node_modules/@fission-ai/openspec/schemas/spec-driven/templates/tasks.md

Source ระบุว่า schema ถูก resolve มาจากแหล่งใด: project (openspec/schemas/ ในโปรเจกต์ของคุณ) user (การ override ระดับ global) หรือ package (built-in ใน CLI) โดย project มีลำดับความสำคัญสูงกว่า user และ user สูงกว่า package

json
{
  "proposal": {
    "path": "/usr/local/lib/node_modules/@fission-ai/openspec/schemas/spec-driven/templates/proposal.md",
    "source": "package"
  },
  "specs": {
    "path": "/usr/local/lib/node_modules/@fission-ai/openspec/schemas/spec-driven/templates/spec.md",
    "source": "package"
  },
  "design": {
    "path": "/usr/local/lib/node_modules/@fission-ai/openspec/schemas/spec-driven/templates/design.md",
    "source": "package"
  },
  "tasks": {
    "path": "/usr/local/lib/node_modules/@fission-ai/openspec/schemas/spec-driven/templates/tasks.md",
    "source": "package"
  }
}

รหัส exit

  • 0: แสดงผลเส้นทางสำเร็จ
  • 1: ไม่รู้จัก schema ที่ระบุ ข้อความแสดงข้อผิดพลาดจะแสดงรายการ schema ที่มีให้ใช้งาน

openspec schemas ​

แสดงรายการ workflow schemas ที่มีให้ใช้งาน

bash
openspec schemas          # ชื่อ คำอธิบาย ลำดับของ artifacts
openspec schemas --json   # เครื่องอ่านได้ สำหรับใช้งานโดย agent

ตัวเลือก

แฟล็กเอฟเฟกต์
--jsonแสดงผลเป็น JSON (สำหรับให้ agent ใช้งาน)

ผลลัพธ์

Available schemas:

  spec-driven
    Default OpenSpec workflow - proposal → specs → design → tasks
    Artifacts: proposal → specs → design → tasks

Schemas จากโปรเจกต์ของคุณจะมีป้ายกำกับ (project) และการ override ระดับ global จะมีป้ายกำกับ (user override)

json
[
  {
    "name": "spec-driven",
    "description": "Default OpenSpec workflow - proposal → specs → design → tasks",
    "artifacts": [
      "proposal",
      "specs",
      "design",
      "tasks"
    ],
    "source": "package"
  }
]

รหัส exit

  • 0: แสดงรายการ schemas สำเร็จ
  • 1: ไม่สามารถอ่านรายการ schemas ได้## openspec schema

ตรวจสอบ (inspect) แยก fork หรือสร้าง schema (การทดลองใช้) ทุกคำสั่งย่อยจะพิมพ์ข้อความ Note: Schema commands are experimental and may change. ไปยัง stderr ก่อนเสมอ

bash
openspec schema which spec-driven          # ระบุตำแหน่งที่ schema ถูกแก้ไขให้สอดคล้อง
openspec schema fork spec-driven my-flow   # คัดลอก schema เข้ามาในโปรเจกต์
openspec schema init my-schema             # สร้าง schema ใหม่จากศูนย์
คำสั่งย่อยรายละเอียดการทำงาน
whichแสดงแหล่งที่มาของ schema ที่ถูกแก้ไขให้สอดคล้อง
validateตรวจสอบโครงสร้างและเทมเพลตของ schema
forkคัดลอก schema ที่มีอยู่เข้ามาในโปรเจกต์เพื่อปรับแต่ง
initสร้าง schema ในระดับโปรเจกต์ใหม่

Schema จะถูกแก้ไขให้สอดคล้องจากสามตำแหน่ง โดยตำแหน่งแรกที่ตรงกันจะมีผลก่อน:

แหล่งที่มาตำแหน่ง
projectopenspec/schemas/ ในโปรเจกต์ปัจจุบัน
user~/.local/share/openspec/schemas/ (เคารพค่า XDG_DATA_HOME และ %LOCALAPPDATA% บน Windows)
packageSchema ที่มากับ CLI spec-driven อยู่ในตำแหน่งนี้

openspec schema which ​

แสดงว่า CLI จะใช้สำเนาของ schema ตัวใด

bash
openspec schema which spec-driven
openspec schema which --all        # แสดงทุก schema จัดกลุ่มตามแหล่งที่มา

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

อาร์กิวเมนต์รายละเอียด
nameชื่อของ schema ที่ต้องการค้นหา จำเป็นต้องมี เว้นแต่มีการตั้งค่า --all หากไม่มีทั้งสองอย่าง คำสั่งนี้จะออกด้วยสถานะ 1

ตัวเลือก

แฟลกผลลัพธ์
--allแสดงรายการทุก schema พร้อมแหล่งที่มาของการแก้ไขให้สอดคล้อง
--jsonพิมพ์ผลการแก้ไขให้สอดคล้องในรูปแบบ JSON

ผลลัพธ์

Schema: spec-driven
Source: package
Path: /usr/local/lib/node_modules/@fission-ai/openspec/schemas/spec-driven

เมื่อมีสำเนาที่มีความสำคัญสูงกว่าบังสำเนาอื่นไว้ ส่วน Shadows: จะแสดงรายการสำเนาที่ถูกบัง ด้วย --json:

json
{
  "name": "my-flow",
  "source": "project",
  "path": "/Users/you/projects/my-app/openspec/schemas/my-flow",
  "shadows": []
}

หากชื่อไม่ถูกต้อง คำสั่งจะออกด้วยสถานะ 1 และแสดงรายการ schema ที่มีอยู่

openspec schema validate ​

ตรวจสอบโครงสร้างและเทมเพลตของ schema

bash
openspec schema validate spec-driven   # schema เดียว จากแหล่งที่มาใดก็ได้
openspec schema validate               # ทุก schema ในระดับโปรเจกต์

คำสั่งนี้จะยืนยันว่า schema.yaml มีอยู่และอ่านได้ โครงสร้างตรงกับรูปแบบ schema ไฟล์เทมเพลตของ artifact แต่ละตัวมีอยู่ในไดเรกทอรี templates/ ของ schema กราฟการพึ่งพา (dependency graph) ไม่มีวัฏจักรหรือการอ้างอิงที่ไม่รู้จัก รวมถึงใน apply.requires ค่าของ apply.tracks ที่ไม่ตรงกับค่า generates ของ artifact ตัวใดตัวหนึ่งเป๊ะๆ จะพิมพ์บรรทัด warning: แต่จะไม่ทำให้การตรวจสอบล้มเหลว เนื่องจาก OpenSpec จะไม่สามารถระบุว่าไฟล์นั้นเป็นความคืบหน้าของ artifact ตัวใด

ตัวเลือก

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

ผลลัพธ์

✓ Schema 'spec-driven' is valid

หากไม่ระบุชื่อ แต่ละ schema ในโปรเจกต์จะถูกแสดงในบรรทัดเดียวภายใต้หัวข้อ Validation Results: Schema ที่ล้มเหลวจะแสดงปัญหาที่เกิดขึ้น และการรันจะออกด้วยสถานะ 1:

✗ Schema 'my-schema' has errors:
  error: Template file 'tasks.md' not found for artifact 'tasks'

openspec schema fork ​

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

bash
openspec schema fork spec-driven my-flow

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

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

ตัวเลือก

แฟลกผลลัพธ์
--forceทับซ้อน schema ที่มีอยู่ที่ปลายทาง
--jsonพิมพ์ผลลัพธ์ในรูปแบบ JSON

ผลลัพธ์

✔ Forked 'spec-driven' to 'my-flow'

Source: /usr/local/lib/node_modules/@fission-ai/openspec/schemas/spec-driven (package)
Destination: /Users/you/projects/my-app/openspec/schemas/my-flow

การ fork จะลงเอยใน openspec/schemas/ และฟิลด์ name: ใน schema.yaml ของมันจะถูกเขียนใหม่ให้เป็นชื่อใหม่:

openspec/schemas/my-flow/
├── schema.yaml
└── templates/
    ├── design.md
    ├── proposal.md
    ├── spec.md
    └── tasks.md

หากมีปลายทางอยู่แล้วจะเป็นข้อผิดพลาด เว้นแต่คุณจะส่ง --force การ fork ที่คงชื่อเดิมของแหล่งที่มาไว้จะบังต้นฉบับ

openspec schema init ​

สร้าง schema ใหม่ในระดับโปรเจกต์พร้อมเทมเพลตเริ่มต้น

bash
openspec schema init my-schema --description "Lightweight flow" --artifacts proposal,tasks

หากไม่มี --description และไม่มี --artifacts ในเทอร์มินัลแบบโต้ตอบ init จะถามหาคำอธิบาย รายการตรวจสอบ artifact และว่าจะกำหนดให้ schema เป็นค่าเริ่มต้นของโปรเจกต์หรือไม่ นอกเหนือจากเทอร์มินัล มันจะใช้ค่าเริ่มต้นด้านล่าง

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

อาร์กิวเมนต์รายละเอียด
nameชื่อสำหรับ schema ใหม่ รูปแบบ kebab-case (my-workflow)

ตัวเลือก

แฟลกผลลัพธ์
--description <text>คำอธิบายของ schema ค่าเริ่มต้น: Custom workflow schema for <name>
--artifacts <list>รหัส artifact ที่คั่นด้วยจุลภาค จาก proposal, specs, design, tasks ค่าเริ่มต้น: ทั้งสี่ตัว
--defaultเขียน schema: <name> ลงใน openspec/config.yaml หรือ openspec/config.yml ที่มีอยู่ สร้าง openspec/config.yaml หากไม่มีทั้งคู่ การเปลี่ยนแปลงใหม่จะใช้ schema นี้
--no-defaultข้ามการถามเกี่ยวกับค่าเริ่มต้น
--forceทับซ้อน schema ที่มีอยู่แล้วด้วยชื่อเดียวกัน
--jsonพิมพ์ผลลัพธ์ในรูปแบบ JSON

การสร้าง schema และการอัปเดต config --default เป็นการดำเนินการเดียว หาก OpenSpec ไม่สามารถตรวจสอบหรือเขียน config ได้ มันจะทิ้งทั้ง config และ schema ที่มีอยู่โดยไม่เปลี่ยนแปลง

ผลลัพธ์

✔ Created schema 'my-schema'

Schema created at: /Users/you/projects/my-app/openspec/schemas/my-schema

Artifacts: proposal, tasks

โครงสร้างบนดิสก์:

openspec/schemas/my-schema/
├── schema.yaml
└── templates/
    ├── proposal.md
    └── tasks.md

schema.yaml เชื่อมต่อ artifact ที่เลือกกับ dependencies ของพวกมัน เมื่อรวม tasks ไว้ มันจะได้รับเฟส apply ที่ติดตาม tasks.md ใช้ schema นี้กับ openspec new --schema my-schema

openspec store ​

สร้างและจัดการ stores: รีโป OpenSpec แบบสแตนด์อโลนที่ลงทะเบียนบนเครื่องของคุณ

bash
openspec store setup team-context --path ~/openspec/team-context   # สร้างและลงทะเบียน
openspec store register ~/stores/design-system                     # ลงทะเบียน checkout ที่มีอยู่
openspec store list                                                # ดูสิ่งที่ลงทะเบียนแล้ว

การลงทะเบียนอยู่ในรีจิสตรีต่อเครื่อง: ~/.local/share/openspec/stores/registry.yaml หรือ $XDG_DATA_HOME/openspec/stores/registry.yaml เมื่อตั้งค่า XDG_DATA_HOME ทุกคำสั่งย่อยรองรับ --json เพื่อพิมพ์รายงานแบบมีโครงสร้างแทนข้อความธรรมดา การรัน openspec store ด้วยคำสั่งย่อยที่หายไปหรือไม่รู้จักจะออกด้วยสถานะ 1 และแสดงรายการคำสั่งย่อย

คำสั่งย่อยรายละเอียดการทำงาน
setup [id]สร้างโฟลเดอร์ store และลงทะเบียน
register [path]ลงทะเบียนโฟลเดอร์ store ที่มีอยู่
unregister <id>ลืมการลงทะเบียน โฟลเดอร์ยังคงอยู่บนดิสก์
remove <id>ลืมการลงทะเบียนและลบโฟลเดอร์
list (alias ls)แสดงรายการ store ที่ลงทะเบียนแล้ว
doctor [id]ตรวจสอบการลงทะเบียน metadata และสถานะ Git สำหรับ store ที่ลงทะเบียนแล้ว

openspec store setup ​

สร้างโฟลเดอร์ store และลงทะเบียน

bash
openspec store setup team-context --path ~/openspec/team-context

ในเทอร์มินัลแบบโต้ตอบ setup จะถามหาชื่อและตำแหน่งที่ขาดหายไประบุก่อนสร้างอะไรก็ตาม นอกเหนือจากนั้น หากชื่อหรือ --path หายไป คำสั่งจะออกด้วยสถานะ 1 พร้อมแนะนำแฟลกที่ต้องส่ง การรัน setup ซ้ำสำหรับ store ที่ลงทะเบียนแล้วจะรายงาน Registry: already registered

setup จะออกด้วยสถานะ 1 พร้อมข้อความ store_setup_inside_git_repo เมื่อ --path อยู่ภายในรีโป Git อื่น เนื่องจากการเริ่มใช้ store ที่นั่นจะทำให้เกิด nested repository การใช้ --no-init-git จะไม่สร้าง repository ดังนั้นจึงข้ามการตรวจสอบนั้น ใช้เพื่อเก็บ store ไว้ที่ ~/openspec/<id> เมื่อไดเรกทอรี home ของคุณเองเป็นรีโป Git เช่น รีโป dotfiles

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

อาร์กิวเมนต์รายละเอียด
idชื่อของ store มันจะกลายเป็น id ที่คุณส่งไปยัง --store

ตัวเลือก

แฟลกผลลัพธ์
--path <path>โฟลเดอร์ที่ store ควรอาศัยอยู่ (~ จะถูกขยาย)
--init-gitเริ่มใช้รีโป Git พร้อม commit เริ่มต้น ค่าเริ่มต้น
--no-init-gitข้ามการดำเนินการ Git ทั้งหมด: ไม่มีการเริ่มใช้ ไม่มีการ commit เริ่มต้น
--remote <url>แหล่งที่มาสำหรับการ clone แบบ canonical ที่บันทึกไว้ใน store.yaml

ผลลัพธ์

Store ready: team-context
Location: /Users/you/stores/team-context
OpenSpec root: ready
Registry: registered

Next: run normal OpenSpec commands against this store, for example:
  openspec new change <change-id> --store team-context
Share this store by committing and pushing it like any Git repo.

--json รายงานสิ่งที่ถูกสร้างและลงทะเบียนไว้ที่ไหน:

json
{
  "store": {
    "id": "design-system",
    "root": "/Users/you/stores/design-system",
    "metadata_path": "/Users/you/stores/design-system/.openspec-store/store.yaml"
  },
  "registry": {
    "path": "/Users/you/.local/share/openspec/stores/registry.yaml",
    "registered": true,
    "already_registered": false
  },
  "git": {
    "is_repository": true,
    "initialized": true,
    "committed": true
  },
  "created_files": [
    "openspec/",
    "openspec/specs/",
    "openspec/changes/",
    "openspec/changes/archive/",
    "openspec/config.yaml",
    "openspec/specs/.gitkeep",
    "openspec/changes/archive/.gitkeep",
    ".openspec-store/store.yaml"
  ],
  "status": []
}

openspec store register ​

ลงทะเบียนโฟลเดอร์ store ที่มีอยู่ เช่น store ของเพื่อนร่วมทีมที่คุณ clone มา

bash
openspec store register ~/stores/design-system

โฟลเดอร์ต้องมีราก openspec/ ที่สมบูรณ์ หากมี .openspec-store/store.yaml อยู่ register จะใช้ id ที่บันทึกไว้ หากไม่มี register จะถามก่อนสร้าง metadata นั้น นอกเหนือจากเทอร์มินัลแบบโต้ตอบ ให้ส่ง --yes แทน เครื่องสามารถลงทะเบียน checkout ได้หนึ่งครั้งต่อ id ของ store เส้นทางที่สองภายใต้ id เดียวกัน หรือเส้นทางเดียวกันภายใต้ id ที่สอง จะออกด้วยสถานะ 1

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

อาร์กิวเมนต์รายละเอียด
pathโฟลเดอร์ store ที่จะลงทะเบียน (~ จะถูกขยาย) จำเป็นต้องมี

ตัวเลือก

แฟลกผลลัพธ์
--id <id>id ของ store ค่าเริ่มต้นมาจาก metadata หรือชื่อโฟลเดอร์
--yesยืนยันการสร้าง metadata อัตลักษณ์ของ store สำหรับราก OpenSpec ที่สมบูรณ์

ผลลัพธ์

Store registered: design-system
Location: /Users/you/stores/design-system
OpenSpec root: ready
Registry: registered

--json พิมพ์โครงสร้างเอกสารเดียวกันกับ store setup --json

openspec store unregister ​

ลืมการลงทะเบียน โฟลเดอร์ยังคงอยู่บนดิสก์

bash
openspec store unregister design-system
Unregistered store: design-system
Files kept at: /Users/you/stores/design-system

openspec store remove ​

ลืมการลงทะเบียนและลบโฟลเดอร์

bash
openspec store remove design-system --yes

แบบโต้ตอบ remove จะถามก่อนลบ ด้วย --json หรือนอกเหนือจากเทอร์มินัลแบบโต้ตอบ การลบจำเป็นต้องใช้ --yes:

Error: Pass --yes to delete store files non-interactively.
Fix: openspec store remove design-system --yes

remove จะออกด้วยสถานะ 1 และไม่ลบอะไรเลยเมื่อโฟลเดอร์ไม่มี metadata ของ store ที่ตรงกัน หรือเมื่อมี store ที่ลงทะเบียนอื่นอยู่ (เช่น store ที่ vendored เป็น Git submodule) ในกรณีนั้น ข้อผิดพลาดคือ store_remove_contains_registered_store: รัน openspec store unregister <nested-id> ก่อน หรือ openspec store unregister <id> เพื่อลืม store โดยไม่ต้องลบไฟล์

ตัวเลือก

แฟลกผลลัพธ์
--yesยืนยันการลบโฟลเดอร์ store ในเครื่อง

ผลลัพธ์

Removed store: design-system
Deleted: /Users/you/stores/design-system

openspec store list ​

แสดงรายการ store ที่ลงทะเบียนแล้ว ls เป็น alias

bash
openspec store list
OpenSpec stores (2)

ID              Location
design-system   /Users/you/stores/design-system
team-context    /Users/you/stores/team-context

หากไม่มีสิ่งใดลงทะเบียน list จะพิมพ์ No stores registered. และแสดงคำสั่ง setup และ register ที่ควรรันถัดไป

openspec store doctor ​

ตรวจสอบการลงทะเบียน metadata และสถานะ Git สำหรับ store ที่ลงทะเบียนแล้ว

bash
openspec store doctor                # ทุก store ที่ลงทะเบียน
openspec store doctor team-context  # store เดียว

ผลลัพธ์

Store doctor

team-context
  Location: /Users/you/stores/team-context
  OpenSpec root: ok
  Metadata: ok
  Git: repository detected (commits: yes, uncommitted changes: no, remote: none)
  Issues: none

รหัสการออก (Exit codes)

  • 0: รายงานถูกพิมพ์ แม้เมื่อ store รายงานปัญหา
  • 1: รายงานไม่สามารถรันได้ (เช่น id ของ store ไม่รู้จัก)

openspec doctor ​

รายงานสุขภาพความสัมพันธ์ของ OpenSpec root ที่ resolve แล้ว

bash
openspec doctor                       # openspec/ root ที่ใกล้ที่สุดเหนือ cwd ของคุณ
openspec doctor --store team-context  # store ที่ลงทะเบียนไว้เป็น root

Doctor เป็นแบบอ่านอย่างเดียว: จะไม่ clone, sync หรือซ่อมแซมใด ๆ จะรายงานว่า root มีสุขภาพดีหรือไม่ และ reference แต่ละรายการที่ประกาศใน openspec/config.yaml resolve ได้บนเครื่องนี้หรือไม่ หากไม่มี root อยู่เหนือ cwd ของคุณและไม่ได้ระบุ --store จะออกด้วยรหัส 1 พร้อมแสดงชื่อ store ที่คุณลงทะเบียนไว้

ตัวเลือก

แฟล็กผลลัพธ์
--store <id>ใช้ store ที่ลงทะเบียนไว้เป็น OpenSpec root แทนโปรเจกต์ปัจจุบัน
--jsonพิมพ์รายงานสุขภาพเป็น JSON

ผลลัพธ์

Doctor

Root
  Location: /Users/you/projects/my-app
  OpenSpec root: ok

References
  - team-context: ok (/Users/you/stores/team-context)

เมื่อใช้ --store, root คือ store และรายงานจะมีบรรทัด store เพิ่มเข้ามา:

Using OpenSpec root: team-context (/Users/you/stores/team-context)
Doctor

Root
  Location: /Users/you/stores/team-context
  OpenSpec root: ok
  Store: team-context (metadata ok)

References
  (none declared)
json
{
  "root": {
    "path": "/Users/you/projects/my-app",
    "source": "nearest",
    "healthy": true,
    "status": []
  },
  "store": null,
  "references": [
    {
      "store_id": "team-context",
      "root": "/Users/you/stores/team-context",
      "status": []
    }
  ],
  "status": []
}

รหัสออก

  • 0: พิมพ์รายงานแล้ว รวมถึงกรณีที่รายงานระบุปัญหา
  • 1: ไม่สามารถ resolve root ได้ (ไม่มี openspec/ อยู่เหนือ cwd และไม่ได้ระบุ --store) หรือ id ของ --store ไม่รู้จัก

openspec context ​

พิมพ์บริบทการทำงานสำหรับ OpenSpec root ที่ resolve แล้ว: root พร้อม store ที่ถูกอ้างอิงทุกรายการที่ประกาศใน openspec/config.yaml โดยแต่ละรายการมีคำสั่ง fetch

bash
openspec context                       # openspec/ root ที่ใกล้ที่สุดเหนือ cwd ของคุณ
openspec context --store team-context  # store ที่ลงทะเบียนไว้เป็น root
openspec context --json                # สรุปสำหรับ agent

Reference ที่ resolve ไม่ได้บนเครื่องนี้จะไปอยู่ในส่วน Not available on this machine พร้อมวิธีแก้ไขสำหรับแต่ละรายการ

ตัวเลือก

แฟล็กผลลัพธ์
--store <id>ใช้ store ที่ลงทะเบียนไว้เป็น OpenSpec root แทนโปรเจกต์ปัจจุบัน
--jsonพิมพ์สรุปสำหรับ agent เป็น JSON
--code-workspace <path>เขียนไฟล์ workspace ของ VS Code สำหรับชุดนี้ด้วย
--forceเขียนทับไฟล์ที่มีอยู่แล้วเมื่อใช้ --code-workspace

ผลลัพธ์

Working context for my-app (/Users/you/projects/my-app)

OpenSpec root
  my-app  /Users/you/projects/my-app

Referenced stores
  team-context  /Users/you/stores/team-context
    Fetch: openspec show <spec-id> --type spec --store team-context

เมื่อใช้ --store, store นี้คือทั้งชุดการทำงาน:

Using OpenSpec root: team-context (/Users/you/stores/team-context)
Working context for team-context (/Users/you/stores/team-context)

OpenSpec root
  team-context  /Users/you/stores/team-context

No references declared; the working set is this root alone.
json
{
  "root": {
    "path": "/Users/you/projects/my-app",
    "source": "nearest",
    "role": "openspec_root"
  },
  "members": [
    {
      "role": "referenced_store",
      "id": "team-context",
      "path": "/Users/you/stores/team-context",
      "fetch": "openspec show <spec-id> --type spec --store team-context",
      "status": []
    }
  ],
  "status": []
}

การเขียนไฟล์ workspace

--code-workspace จะเขียนไฟล์ workspace ของ VS Code ไปยังพาธที่คุณระบุ: หนึ่งโฟลเดอร์สำหรับ root และหนึ่งโฟลเดอร์ ref:<id> สำหรับ referenced store ที่พร้อมใช้งานแต่ละรายการ reference ที่ไม่พร้อมใช้งานจะถูกข้ามและระบุชื่อไว้ในบรรทัดสรุป Wrote /Users/you/projects/my-app/openspec.code-workspace (2 folders) บรรทัดสรุปจะพิมพ์ไปยัง stderr ดังนั้น stdout ของ --json จึงยังคงเป็นเอกสาร JSON หนึ่งเอกสาร หากไฟล์มีอยู่แล้วจะออกด้วยรหัส 1 เว้นแต่คุณจะส่ง --force

json
{
  "folders": [
    {
      "name": "my-app",
      "path": "/Users/you/projects/my-app"
    },
    {
      "name": "ref:team-context",
      "path": "/Users/you/stores/team-context"
    }
  ]
}

รหัสออก

  • 0: พิมพ์รายงานแล้ว
  • 1: ไม่สามารถ resolve root ได้ (ไม่มี openspec/ อยู่เหนือ cwd และไม่ได้ระบุ --store) หรือการเขียน --code-workspace ถูกปฏิเสธ## openspec workset

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

bash
openspec workset create checkout --member ~/projects/checkout-api --member web=~/projects/checkout-web
openspec workset list
openspec workset remove checkout --yes
คำสั่งย่อยสิ่งที่ทำได้
create [name]ประกอบและบันทึกมุมมองการทำงานที่ตั้งชื่อของโฟลเดอร์ที่คุณเลือก
list, lsแสดง workset ที่บันทึกพร้อมสมาชิก
open <name>เปิด workset ที่บันทึกในเครื่องมือของคุณ (หน้าต่างเอดิเตอร์หรือเซสชันของเอเจนต์)
remove <name>ลบ workset ที่บันทึก (โฟลเดอร์สมาชิกจะไม่ถูกแตะต้อง)

workset เป็นข้อมูลเฉพาะในเครื่อง:

  • สถานะของมันถูกเก็บไว้ในโฟลเดอร์เดียว: ~/.local/share/openspec/worksets/ (ถ้ากำหนด $XDG_DATA_HOME/openspec/worksets/ ไว้; บน Windows คือ %LOCALAPPDATA%\openspec\worksets\)
  • ไม่มีสิ่งใดถูกเขียนลงในโฟลเดอร์สมาชิก และไม่มีการ commit หรือแชร์ใด ๆ
  • การลบโฟลเดอร์นั้นจะลบร่องรอยทั้งหมด

openspec workset create ​

บันทึกมุมมองการทำงานที่ตั้งชื่อของโฟลเดอร์

bash
openspec workset create checkout \
  --member ~/projects/checkout-api \
  --member web=~/projects/checkout-web

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

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

อาร์กิวเมนต์คืออะไร
nameชื่อของ workset รูปแบบ kebab-case: ตัวอักษรพิมพ์เล็ก ตัวเลข และขีดกลางเดี่ยว จำเป็นเมื่ออยู่นอกเทอร์มินัลแบบโต้ตอบ

ตัวเลือก

แฟล็กผล
--member <member>โฟลเดอร์สมาชิกในรูปแบบ <path> หรือ <name>=<path> และระบุซ้ำได้ สมาชิกตัวแรกคือตัวหลัก พาธต้องเป็นโฟลเดอร์ที่มีอยู่จริง และป้ายชื่อเริ่มต้นคือชื่อของโฟลเดอร์เอง
--tool <id>เครื่องมือที่ต้องการสำหรับเปิด workset นี้ ไอดีในตัว: code (VS Code), cursor (Cursor) โดย claude และ codex ถูกปิดใช้งานชั่วคราว
--jsonแสดง workset ที่บันทึกเป็น JSON

ผลลัพธ์

Saved workset 'checkout' (2 members) to your machine.
Open it any time with: openspec workset open checkout

openspec workset list ​

แสดง workset ที่บันทึกพร้อมสมาชิก โดยเรียงตามชื่อ

bash
openspec workset list   # นามแฝง: ls

ตัวเลือก

แฟล็กผล
--jsonแสดงรายการ workset เป็น JSON

ผลลัพธ์

หนึ่งบล็อกต่อหนึ่ง workset: ชื่อ, เครื่องมือของมันถ้ามี, จากนั้นเป็นแถว name path หนึ่งแถวต่อสมาชิกหนึ่งตัว หากยังไม่มีสิ่งที่บันทึกไว้ list จะแสดง No worksets saved. Create one with: openspec workset create

checkout
  checkout-api  /Users/you/projects/checkout-api
  web           /Users/you/projects/checkout-web
checkout-tool  (opens in VS Code)
  checkout-api  /Users/you/projects/checkout-api

เมื่อใช้ --json:

json
{
  "worksets": [
    {
      "name": "checkout",
      "members": [
        {
          "name": "checkout-api",
          "path": "/Users/you/projects/checkout-api"
        },
        {
          "name": "web",
          "path": "/Users/you/projects/checkout-web"
        }
      ]
    }
  ],
  "status": []
}

openspec workset open ​

เปิด workset ที่บันทึกไว้ในเครื่องมือของคุณ เครื่องมือเอดิเตอร์ (code, cursor) จะได้รับไฟล์ .code-workspace ที่สร้างขึ้น หน้าต่างจะถูกเปิดแล้วคำสั่งจะคืนค่า เครื่องมือเอเจนต์ CLI (claude, codex) จะเข้าควบคุมเทอร์มินัลนี้พร้อมแนบสมาชิกทั้งหมด แต่ถูกปิดใช้งานชั่วคราวระหว่างปรับขั้นตอนดังกล่าว ดังนั้นตอนนี้ workset จะเปิดใน IDE

bash
openspec workset open checkout                # เครื่องมือที่บันทึกไว้ หรือให้ถาม
openspec workset open checkout --tool cursor  # ใช้เครื่องมือนี้เฉพาะครั้งนี้

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

อาร์กิวเมนต์คืออะไร
nameworkset ที่จะเปิด

ตัวเลือก

แฟล็กผล
--tool <id>เปิดด้วยเครื่องมือนี้เฉพาะครั้งนี้

เมื่อไม่มี --tool และไม่มีเครื่องมือที่บันทึกไว้ open จะถามให้คุณเลือกเครื่องมือที่ติดตั้งไว้ เมื่ออยู่นอกเทอร์มินัลแบบโต้ตอบจะออกด้วยรหัส 1 แทน

  • โฟลเดอร์สมาชิกที่ไม่อยู่แล้วจะถูกข้ามพร้อมคำเตือน เมื่อตัวหลักหายไป สมาชิกตัวถัดไปที่ยังอยู่จะกลายเป็นตัวหลักสำหรับการเปิดครั้งนี้ เมื่อไม่มีโฟลเดอร์สมาชิกอยู่เลย การเปิดจะล้มเหลว
  • --json จะถูกปฏิเสธ: open จะส่งเทอร์มินัลให้เครื่องมือและไม่มีโหมด JSON
  • เมื่อการเริ่มทำงานล้มเหลว ข้อผิดพลาดจะลงท้ายด้วยวิธีทำด้วยตนเอง: พาธของไฟล์ workspace และรายการสมาชิก

รหัสออก

  • สะท้อนเครื่องมือ: คำสั่งจะออกด้วยรหัสออกของเครื่องมือเอง และสัญญาณจะกลายเป็น 128+n (130 หลัง Ctrl-C)
  • 1: ไม่รู้จัก workset, ไม่มีโฟลเดอร์สมาชิกที่ใช้ได้, หรือไม่มีเครื่องมือที่ใช้งานได้

openspec workset remove ​

ลบ workset ที่บันทึกไว้และไฟล์ .code-workspace ที่สร้างขึ้น โฟลเดอร์สมาชิกจะไม่ถูกแตะต้อง

bash
openspec workset remove checkout --yes

ในเทอร์มินัลแบบโต้ตอบ remove จะแสดง workset และขอให้ยืนยัน เมื่อใช้ --json หรืออยู่นอกเทอร์มินัล จะต้องมี --yes และจะออกด้วยรหัส 1 หากไม่มี

ตัวเลือก

แฟล็กผล
--yesยืนยันการลบแบบไม่โต้ตอบ
--jsonแสดงการลบเป็น JSON

ผลลัพธ์

Removed workset 'checkout'. Member folders were not touched.

openspec version ​

รายงานเวอร์ชันของ OpenSpec ที่กำลังทำงานและวิธีติดตั้งสำเนานี้

bash
openspec version                 # เวอร์ชันในเครื่องและรายละเอียดการติดตั้ง
openspec version --json          # รายงานในเครื่องแบบมีโครงสร้าง
openspec version --check         # ตรวจหาการอัปเดตจาก registry ด้วย
openspec version --check --json  # รายงานในเครื่องและการอัปเดตแบบมีโครงสร้าง

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

ตัวเลือก

แฟล็กผล
--jsonแสดงเอกสาร JSON แบบมีเวอร์ชันหนึ่งชุดแทนข้อความ
--checkตรวจหารุ่นที่ใหม่กว่าจาก registry ที่กำหนดไว้

ผลลัพธ์

สำหรับการติดตั้ง npm แบบ global:

text
OpenSpec 1.13.2 (npm, global)

ขอบเขตการติดตั้งคือ global, project, temporary สำหรับตัวรันชั่วคราวเช่น npx, source สำหรับ checkout หรือ standalone สำหรับ การติดตั้งแบบ standalone OpenSpec จะละเว้นรายละเอียดที่ไม่สามารถระบุได้แทนการเดา

--json จะคงรายละเอียดที่ไม่รู้จักเป็นค่า null อย่างชัดเจน:

json
{
  "schemaVersion": 1,
  "version": "1.13.2",
  "install": {
    "location": "/opt/homebrew/lib/node_modules/@fission-ai/openspec",
    "packageManager": "npm",
    "scope": "global"
  }
}

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

text
OpenSpec 1.13.2 (npm, global)
Update available: 1.14.0
  npm install -g @fission-ai/openspec@latest
json
{
  "schemaVersion": 1,
  "version": "1.13.2",
  "install": {
    "location": "/opt/homebrew/lib/node_modules/@fission-ai/openspec",
    "packageManager": "npm",
    "scope": "global"
  },
  "update": {
    "status": "available",
    "latest": "1.14.0",
    "command": "npm install -g @fission-ai/openspec@latest",
    "canSelfUpgrade": true
  }
}

ค่าสถานะการอัปเดต:

สถานะความหมาย
availableregistry ส่งเวอร์ชันที่ปลอดภัยซึ่งใหม่กว่าเวอร์ชันที่กำลังทำงานกลับมา
currentการตรวจสอบเสร็จสมบูรณ์และไม่พบเวอร์ชันที่ใหม่กว่า
disabledการตั้งค่าความเป็นส่วนตัวหรือการตรวจหาการอัปเดตที่มีอยู่ปิดกั้นการเข้าถึง registry โดย latest เป็น null
offlineregistry ไม่พร้อมใช้งานหรือส่งคำตอบที่ใช้ไม่ได้ โดย latest เป็น null

สำหรับการติดตั้งแบบ standalone คำสั่งอัปเดตคือ openspec install

DO_NOT_TRACK, การเลือกไม่ส่ง telemetry, OPENSPEC_NO_UPDATE_CHECK, การตรวจพบ CI และการกำหนดค่า registry แบบ non-HTTPS ที่ถูกปฏิเสธ จะปิดการตรวจสอบ การตรวจสอบที่ถูกปิดและออฟไลน์ยังคงออกด้วยรหัส 0 เพราะความพร้อมของการอัปเดตเป็นเพียงคำแนะนำ คำสั่งนี้จะไม่อัปเกรด OpenSpec; canSelfUpgrade รายงานเพียงว่าเส้นทาง openspec update ที่มีอยู่สามารถอัปเกรดสำเนานี้อย่างปลอดภัยได้หรือไม่

รหัสออก

  • 0: รายงานในเครื่องถูกแสดงแล้ว รวมถึงการตรวจหาการอัปเดตที่ถูกปิดหรือออฟไลน์
  • 1: ไวยากรณ์คำสั่งไม่ถูกต้อง เช่น ตัวเลือก --upgrade ที่ไม่รองรับ

openspec install ​

ติดตั้ง openspec แบบสแตนด์อโลน รันคำสั่งนี้จากระบบที่ติดตั้งผ่าน npm หรือ Homebrew เพื่อสลับไปใช้แบบสแตนด์อโลน หรือรันจากระบบที่ติดตั้งแบบสแตนด์อโลนเพื่ออัปเกรดในตำแหน่งเดิม

bash
openspec install          # รีลีสใหม่ล่าสุด
openspec install 1.15.0   # รีลีสที่ระบุ

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

  • จากตัวจัดการแพ็กเกจ: ติดตั้งไปที่ ~/.local/bin (Windows: %LOCALAPPDATA%\Programs\openspec) และพิมพ์คำสั่งที่ใช้ลบสำเนาเก่า เช่น npm uninstall -g @fission-ai/openspec ตัวคำสั่งจะไม่ลบสำเนานั้นเอง
  • จากการติดตั้งแบบสแตนด์อโลน: แทนที่ไฟล์ที่กำลังรันอยู่ ณ ตำแหน่งเดิม โดยใช้ชื่อของไฟล์นั้นเอง

หลังจากนั้นคำสั่งจะแจ้งว่าตอนนี้ openspec รันจากสำเนาใด เนื่องจากสำเนาที่ติดตั้งผ่านตัวจัดการแพ็กเกจซึ่งอยู่ก่อนหน้าใน PATH ของคุณจะยังคงถูกเรียกใช้จนกว่าคุณจะลบมันออก

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

อาร์กิวเมนต์คืออะไร
versionรีลีสที่จะติดตั้ง เช่น 1.15.0 ไม่บังคับ; ค่าเริ่มต้นคือรีลีสล่าสุด

OPENSPEC_INSTALL_DIR และ OPENSPEC_INSTALL_NAME ใช้เลือกโฟลเดอร์หรือชื่อไฟล์อื่น

รหัสออก

  • 0: ติดตั้งแล้ว
  • 1: เวอร์ชันที่ระบุไม่ใช่เวอร์ชันรีลีส หรือดาวน์โหลดหรือติดตั้งล้มเหลว สำเนาปัจจุบันของคุณจะคงอยู่ตามเดิม

openspec feedback ​

ส่งข้อเสนอแนะเกี่ยวกับ OpenSpec

bash
openspec feedback "Validate output is hard to scan"
openspec feedback "Archive fails on Windows" --body "Steps: init, propose, archive. Error: EPERM."

CLI จะบันทึกข้อความของคุณเป็น issue บน GitHub ในรีโพ Fission-AI/OpenSpec ผ่าน gh CLI ของคุณ ชื่อ issue จะเป็น Feedback: <message> เนื้อหา issue จะใช้หัวข้อจากแบบฟอร์มแจ้งบั๊ก: ข้อความของคุณจะอยู่ภายใต้ What happened ข้อความจาก --body จะอยู่ภายใต้ Details และมีส่วน Minimal steps to reproduce ที่ขอให้คุณเพิ่มขั้นตอน เนื่องจาก CLI ไม่สามารถกรอกส่วนเหล่านั้นให้ได้ ส่วนท้ายจะเพิ่มเวอร์ชัน CLI แพลตฟอร์ม และเวลา issue จะได้รับเลเบล feedback หากรีโพไม่ได้กำหนดเลเบลดังกล่าว CLI จะลองใหม่โดยไม่ใส่เลเบลนั้นและแจ้งให้ทราบ

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

อาร์กิวเมนต์คืออะไร
messageสรุปความยาวหนึ่งบรรทัด ใช้เป็นชื่อ issue จำเป็นต้องระบุ

ตัวเลือก

แฟลกผลลัพธ์
--body <text>คำอธิบายที่ยาวขึ้นซึ่งเพิ่มเข้าไปในเนื้อหา issue

เอาต์พุต

เมื่อสำเร็จ:

✓ Feedback submitted successfully!
Issue URL: https://github.com/Fission-AI/OpenSpec/issues/1234

หากไม่ได้ติดตั้ง gh หรือ gh ยังไม่ได้เข้าสู่ระบบ จะไม่มีการส่งข้อมูลใด ๆ CLI จะพิมพ์ข้อเสนอแนะที่จัดรูปแบบแล้วของคุณระหว่างเครื่องหมาย --- FORMATTED FEEDBACK --- จากนั้นจะแสดงลิงก์ที่เปิดแบบฟอร์มแจ้งบั๊กโดยกรอกชื่อ issue, what happened (ข้อความของคุณและข้อความจาก --body), เวอร์ชัน CLI และสภาพแวดล้อม (แพลตฟอร์มและเวอร์ชัน Node) ไว้ให้ คุณกรอกส่วนที่เหลือของแบบฟอร์มในเบราว์เซอร์ เส้นทางการไม่เข้าสู่ระบบจะเพิ่ม To auto-submit in the future: gh auth login

รหัสออก

  • 0: สร้าง issue แล้ว หรือใช้เส้นทางการส่งด้วยตนเองแทน (ไม่มี gh หรือ gh ไม่ได้เข้าสู่ระบบ)
  • 1: ไม่ได้ระบุข้อความ
  • รหัสของ gh เอง: gh ล้มเหลวหลังการยืนยันตัวตน (เครือข่าย, การจำกัดอัตรา, issues ถูกปิดใช้งาน) CLI จะพิมพ์ข้อเสนอแนะของคุณและ URL สำหรับส่งด้วยตนเองอีกครั้งก่อน

openspec completion ​

ติดตั้งหรือสร้าง completion ของ shell

bash
openspec completion install        # ตรวจหา shell ของคุณ ติดตั้ง และเชื่อมต่อการกำหนดค่า
openspec completion generate zsh   # พิมพ์สคริปต์ไปยัง stdout

shell ที่รองรับ: zsh, bash, fish, powershell ทุกคำสั่งย่อยรับอาร์กิวเมนต์ shell ที่ไม่บังคับ หากไม่ระบุ CLI จะตรวจหา shell ของคุณจากสภาพแวดล้อม

คำสั่งย่อยสิ่งที่ทำ
generate [shell]พิมพ์สคริปต์ completion ไปยัง stdout
install [shell]เขียนสคริปต์และกำหนดค่าไฟล์เริ่มต้นของ shell
uninstall [shell]ลบสคริปต์และบล็อกการกำหนดค่า

หากติดตั้งด้วย Nix จะมี completion อยู่แล้ว: แพ็กเกจ flake มาพร้อมสคริปต์ Bash, Fish และ Zsh ในตำแหน่งมาตรฐาน ดังนั้นจึงไม่จำเป็นต้องใช้ install (การติดตั้ง)

openspec completion generate ​

พิมพ์สคริปต์และไม่เขียนอะไรเลย

#compdef openspec

# สคริปต์ completion สำหรับ Zsh ของ OpenSpec CLI
# สร้างอัตโนมัติ - ห้ามแก้ไขด้วยตนเอง

_openspec() {
  local context state line
  typeset -A opt_args
...

openspec completion install ​

เขียนสคริปต์และแก้ไขคอนฟิกของ shell การแก้ไขคอนฟิกจะอยู่ระหว่างเครื่องหมาย # OPENSPEC:START และ # OPENSPEC:END สคริปต์ที่มีอยู่จะถูกสำรองไว้ก่อน (สำเนา .backup-<timestamp>)

Shellตำแหน่งสคริปต์คอนฟิกที่ถูกแก้ไข
zsh~/.zsh/completions/_openspec$ZDOTDIR/.zshrc เมื่อ ZDOTDIR เป็นพาธแบบสัมบูรณ์ มิฉะนั้นจะเป็น ~/.zshrc
bash~/.local/share/bash-completion/completions/openspec~/.bashrc
fish~/.config/fish/completions/openspec.fishไม่มี: fish โหลดอัตโนมัติ
powershellOpenSpecCompletion.ps1 ข้างโปรไฟล์ของคุณ$PROFILE

หากติดตั้ง Oh My Zsh ไว้ สคริปต์จะไปอยู่ใน $ZSH_CUSTOM/completions/_openspec แทน (ค่าเริ่มต้นคือ ~/.oh-my-zsh/custom/completions/_openspec)

ZDOTDIR ที่เป็นพาธสัมพัทธ์หรือขึ้นต้นด้วย ~ จะถูกเพิกเฉย และจะแก้ไข ~/.zshrc แทน การรัน install อีกครั้งเมื่อสคริปต์เป็นเวอร์ชันปัจจุบันอยู่แล้วจะยังคงเพิ่มบล็อกลงใน .zshrc ที่ zsh อ่าน

ตัวเลือก

แฟลกผลลัพธ์
--verboseพิมพ์พาธที่ติดตั้ง พาธสำรอง (ถ้ามี) และไฟล์คอนฟิกที่ถูกแก้ไขด้วย

เอาต์พุต

✓ Completion script installed and .zshrc configured successfully

Restart your shell or run: exec zsh

openspec completion uninstall ​

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

สำหรับ zsh คำสั่งนี้จะล้าง .zshrc ที่ install แก้ไข และล้าง ~/.zshrc ด้วยเมื่อการติดตั้งเวอร์ชันเก่าได้ทิ้งบล็อกไว้ที่นั่นภายใต้ ZDOTDIR หากไม่สามารถลบบล็อกได้ uninstall จะระบุชื่อไฟล์และออกด้วยรหัส 1

ตัว選択

แฟลกผลลัพธ์
-y, --yesข้ามคำถามยืนยัน

เอาต์พุต

✓ Completion script removed from /Users/you/.zsh/completions/_openspec. Removed OpenSpec configuration from ~/.zshrc

รหัสออก

  • 0: สร้าง ติดตั้ง หรือลบสคริปต์แล้ว การยกเลิก uninstall ก็ออกด้วยรหัส 0 เช่นกัน
  • 1: ไม่รองรับหรือตรวจไม่พบ shell หรือขั้นตอนการติดตั้งหรือถอนการติดตั้งล้มเหลว

openspec change ​

รูปแบบคำนามที่เลิกใช้แล้วของ show, list และ validate ทุกครั้งที่รันจะแจ้งเตือนและชี้ไปยังคำสั่งที่ขึ้นต้นด้วยคำกริยา จากนั้นจึงรันต่อไป:

Warning: The "openspec change ..." commands are deprecated. Prefer verb-first commands (e.g., "openspec list", "openspec validate --changes").
Warning: "openspec change list" is deprecated. Use "openspec list".
add-rate-limit
ที่เลิกใช้ใช้แทน
openspec change show <name>openspec show <name>
openspec change listopenspec list
openspec change validate <name>openspec validate <name> (change ทั้งหมด: openspec validate --changes)

ส่วนของคำสั่งที่ขึ้นต้นด้วยคำกริยาจะอธิบายแฟลกต่าง ๆ

openspec spec ​

รูปแบบคำนามที่เลิกใช้แล้วของ show, list และ validate ทุกครั้งที่รันจะแจ้งเตือนและชี้ไปยังคำสั่งที่ขึ้นต้นด้วยคำกริยา จากนั้นจึงรันต่อไป:

Warning: The "openspec spec ..." commands are deprecated. Prefer verb-first commands (e.g., "openspec show", "openspec validate --specs").
api
ที่เลิกใช้ใช้แทน
openspec spec show <id>openspec show <id>
openspec spec listopenspec list --specs
openspec spec validate <id>openspec validate <id> (spec ทั้งหมด: openspec validate --specs)

ส่วนของคำสั่งที่ขึ้นต้นด้วยคำกริยาจะอธิบายแฟลกต่าง ๆ