การปรับแต่งเอง

OpenSpec มี 3 ระดับของการปรับแต่งเอง:

ระดับ	หน้าที่การทำงาน	เหมาะสำหรับ
การตั้งค่าโปรเจกต์	ตั้งค่าค่าเริ่มต้น, ฝังบริบท/กฎ	กับส่วนใหญ่ของทีม
สคีมที่กำหนดเอง	กำหนดอาร์ติแฟคต์เวิร์กโฟลว์ของคุณเอง	ทีมที่มีกระบวนการเฉพาะตัว
การแทนที่ทั่วโลก	แชร์สคีมข้ามทุกโปรเจกต์	ผู้ใช้ขั้นสูง

การตั้งค่าโปรเจกต์

ไฟล์ openspec/config.yaml เป็นวิธีที่ง่ายที่สุดในการปรับแต่ง OpenSpec สำหรับทีมของคุณ โดยช่วยให้คุณสามารถ:

ตั้งสคีมเป็นค่าเริ่มต้น - ข้ามการใส่ --schema ในทุกคำสั่ง
ฝังบริบทของโปรเจกต์ - AI จะเห็นสแต็กเทคโนโลยี, ข้อกำหนดมาตรฐาน และอื่นๆ ของคุณ
เพิ่มกฎเฉพาะอาร์ติแฟคต์ - กฎที่กำหนดเองสำหรับอาร์ติแฟคต์ที่ระบุ

การตั้งค่าอย่างรวดเร็ว

bash

openspec init

คำสั่งนี้จะช่วยคุณสร้างการตั้งค่าแบบโต้ตอบ หรือคุณสามารถสร้างเองด้วยตนเองได้:

yaml

# openspec/config.yaml
schema: spec-driven

context: |
  สแต็กเทคโนโลยี: TypeScript, React, Node.js, PostgreSQL
  รูปแบบ API: RESTful, อธิบายไว้ที่ docs/api.md
  การทดสอบ: Jest + React Testing Library
  เราให้ความสำคัญกับความเข้ากันได้ย้อนหลังสำหรับ API สาธารณะทั้งหมด

rules:
  proposal:
    - รวมแผนการย้อนกลับ
    - ระบุทีมที่ได้รับผลกระทบ
  specs:
    - ใช้รูปแบบ Given/When/Then
    - อ้างอิงแพทเทิร์นที่มีอยู่ก่อนที่จะสร้างแพทเทิร์นใหม่

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

สคีมค่าเริ่มต้น:

bash

# โดยไม่มีการตั้งค่า
openspec new change my-feature --schema spec-driven

# ด้วยการตั้งค่า - สคีมจะถูกใช้โดยอัตโนมัติ
openspec new change my-feature

การฝังบริบทและกฎ:

เมื่อสร้างอาร์ติแฟคต์ใดๆ ก็ตาม บริบทและกฎของคุณจะถูกฝังเข้าไปใน prompt ของ AI:

xml

<context>
สแต็กเทคโนโลยี: TypeScript, React, Node.js, PostgreSQL
...
</context>

<rules>
- รวมแผนการย้อนกลับ
- ระบุทีมที่ได้รับผลกระทบ
</rules>

<template>
[แม่แบบที่รวมอยู่ในสคีม]
</template>

บริบท จะปรากฏในอาร์ติแฟคต์ทั้งหมด
กฎ จะปรากฏเฉพาะสำหรับอาร์ติแฟคต์ที่ตรงกันเท่านั้น

ลำดับการค้นหาสคีม

เมื่อ OpenSpec ต้องการสคีม มันจะตรวจสอบตามลำดับนี้:

คล้าย CLI: --schema <name>
เมตาดาต้าของการเปลี่ยนแปลง (.openspec.yaml ในโฟลเดอร์ของการเปลี่ยนแปลง)
การตั้งค่าโปรเจกต์ (openspec/config.yaml)
ค่าเริ่มต้น (spec-driven)

สคีมที่กำหนดเอง

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

text

your-project/
├── openspec/
│   ├── config.yaml        # การตั้งค่าโปรเจกต์
│   ├── schemas/           # สคีมที่กำหนดเองอยู่ที่นี่
│   │   └── my-workflow/
│   │       ├── schema.yaml
│   │       └── templates/
│   └── changes/           # การเปลี่ยนแปลงของคุณ
└── src/

การใช้สคีมที่มีอยู่แล้วเป็นฐาน (Fork)

วิธีที่เร็วที่สุดในการปรับแต่งคือ การใช้สคีมในตัวของ OpenSpec เป็นฐาน:

bash

openspec schema fork spec-driven my-workflow

คำสั่งนี้จะคัดลอกสคีม spec-driven ทั้งหมดไปยัง openspec/schemas/my-workflow/ ที่คุณสามารถแก้ไขได้อย่างอิสระ

สิ่งที่คุณได้รับ:

text

openspec/schemas/my-workflow/
├── schema.yaml           # การกำหนดเวิร์กโฟลว์
└── templates/
    ├── proposal.md       # แม่แบบสำหรับอาร์ติแฟคต์ข้อเสนอ
    ├── spec.md           # แม่แบบสำหรับสเปค
    ├── design.md         # แม่แบบสำหรับการออกแบบ
    └── tasks.md          # แม่แบบสำหรับรายการงาน

ตอนนี้แก้ไขไฟล์ schema.yaml เพื่อเปลี่ยนแปลงเวิร์กโฟลว์ หรือแก้ไขแม่แบบเพื่อเปลี่ยนแปลงสิ่งที่ AI จะสร้าง

สร้างสคีมใหม่ตั้งแต่เริ่มต้น

สำหรับเวิร์กโฟลว์ที่ใหม่ทั้งหมด:

bash

# แบบโต้ตอบ
openspec schema init research-first

# แบบไม่โต้ตอบ
openspec schema init rapid \
  --description "Rapid iteration workflow" \
  --artifacts "proposal,tasks" \
  --default

โครงสร้างสคีม

สคีมกำหนดอาร์ติแฟคต์ในเวิร์กโฟลว์ของคุณ และการ 의依赖ระหว่างกันของแต่ละอาร์ติแฟคต์:

yaml

# openspec/schemas/my-workflow/schema.yaml
name: my-workflow
version: 1
description: เวิร์กโฟลว์ที่กำหนดเองของทีมเรา

artifacts:
  - id: proposal
    generates: proposal.md
    description: เอกสารข้อเสนอเริ่มต้น
    template: proposal.md
    instruction: |
      สร้างข้อเสนอที่อธิบายว่าทำไมการเปลี่ยนแปลงนี้จึงจำเป็น
      ให้โฟกัสกับปัญหา ไม่ใช่กับโซลูชัน
    requires: []

  - id: design
    generates: design.md
    description: การออกแบบทางเทคนิค
    template: design.md
    instruction: |
      สร้างเอกสารออกแบบที่อธิบายวิธีการนำไปปฏิบัติใช้
    requires:
      - proposal    # ไม่สามารถสร้างการออกแบบได้จนกว่าจะมีข้อเสนอที่มีอยู่

  - id: tasks
    generates: tasks.md
    description: รายการตรวจสอบการนำไปปฏิบัติใช้
    template: tasks.md
    requires:
      - design

apply:
  requires: [tasks]
  tracks: tasks.md

ฟิลด์หลัก:

ฟิลด์	วัตถุประสงค์
`id`	ตัวระบุที่ไม่ซ้ำกัน ใช้ในคำสั่งและกฎ
`generates`	ชื่อไฟล์เอาต์พุต (รองรับ globs เช่น `specs/*/.md`)
`template`	ไฟล์แม่แบบในโฟลเดอร์ `templates/`
`instruction`	คำสั่งสำหรับ AI เมื่อสร้างอาร์ติแฟคต์นี้
`requires`	ข้อ 의依赖 - อาร์ติแฟคต์ใดต้องมีอยู่ก่อน

แม่แบบ

แม่แบบเป็นไฟล์ markdown ที่นำทาง AI โดยจะถูกฝังเข้าไปใน prompt เมื่อสร้างอาร์ติแฟคต์นั้น

markdown

<!-- templates/proposal.md -->
## เหตุผล

<!-- อธิบายเหตุผลเบื้องต้นของการเปลี่ยนแปลงนี้ ปัญหาใดที่กำลังแก้ไข? -->

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

<!-- อธิบายสิ่งที่将会เปลี่ยนแปลง ระบุอย่างเจาะจงเกี่ยวกับความสามารถใหม่หรือการแก้ไข -->

## ผลกระทบ

<!-- โค้ด, APIs, ข้อ 의依赖, ระบบที่ได้รับผลกระทบ -->

แม่แบบสามารถมีได้:

หัวข้อส่วนต่างๆ ที่ AI ควรจะกรอกข้อมูล
ความคิดเห็น HTML ที่มีคำแนะนำสำหรับ AI
รูปแบบตัวอย่างที่แสดงโครงสร้างที่คาดหวัง

ตรวจสอบความถูกต้องของสคีมของคุณ

ก่อนใช้งานสคีมที่กำหนดเอง ตรวจสอบความถูกต้องของมันก่อน:

bash

openspec schema validate my-workflow

คำสั่งนี้จะตรวจสอบ:

ไวยากรณ์ของ schema.yaml ถูกต้อง
แม่แบบทั้งหมดที่อ้างอิงมีอยู่
ไม่มีการ 의依赖วน
รหัสอาร์ติแฟคต์ถูกต้อง

ใช้งานสคีมที่กำหนดเองของคุณ

หลังจากสร้างแล้ว ใช้งานสคีมของคุณด้วย:

bash

# ระบุในคำสั่ง
openspec new change feature --schema my-workflow

# หรือตั้งเป็นค่าเริ่มต้นในไฟล์ config.yaml
schema: my-workflow

ตรวจสอบการแก้ปัญหาการค้นหาสคีม

ไม่แน่ใจว่ากำลังใช้สคีม哪一个? ตรวจสอบด้วย:

bash

# ดูว่าสคีมที่ระบุถูกโหลดจากที่ใด
openspec schema which my-workflow

# แสดงรายการสคีมทั้งหมดที่มีอยู่
openspec schema which --all

ผลลัพธ์จะแสดงว่าสคีมมาจากโปรเจกต์ของคุณ, โฟลเดอร์ผู้ใช้, หรือแพคเกจ:

text

สคีม: my-workflow
แหล่งที่มา: โปรเจกต์
เส้นทาง: /path/to/project/openspec/schemas/my-workflow

หมายเหตุ: OpenSpec ยังรองรับสคีมระดับผู้ใช้ที่ ~/.local/share/openspec/schemas/ สำหรับการแชร์ข้ามโปรเจกต์ แต่สคีมระดับโปรเจกต์ใน openspec/schemas/ ถูกแนะนำกว่าเนื่องจากมีการควบคุมเวอร์ชันร่วมกับโค้ดของคุณ

ตัวอย่าง

เวิร์กโฟลว์การพัฒนาอย่างรวดเร็ว (Rapid Iteration)

เวิร์กโฟลว์ขั้นต่ำสำหรับการพัฒนาอย่างรวดเร็ว:

yaml

# openspec/schemas/rapid/schema.yaml
name: rapid
version: 1
description: การพัฒนาอย่างรวดเร็วด้วยความซับซ้อนน้อยที่สุด

artifacts:
  - id: proposal
    generates: proposal.md
    description: ข้อเสนออย่างรวดเร็ว
    template: proposal.md
    instruction: |
      สร้างข้อเสนอที่สั้นสำหรับการเปลี่ยนแปลงนี้
      ให้โฟกัสกับอะไรและทำไม, ข้ามรายละเอียดสเปค
    requires: []

  - id: tasks
    generates: tasks.md
    description: รายการตรวจสอบการนำไปปฏิบัติใช้
    template: tasks.md
    requires: [proposal]

apply:
  requires: [tasks]
  tracks: tasks.md

การเพิ่มอาร์ติแฟคต์การตรวจสอบ (Review)

ใช้สคีมเริ่มต้นเป็นฐานและเพิ่มขั้นตอนการตรวจสอบ:

bash

openspec schema fork spec-driven with-review

จากนั้นแก้ไขไฟล์ schema.yaml เพื่อเพิ่ม:

yaml

  - id: review
    generates: review.md
    description: รายการตรวจสอบก่อนการนำไปปฏิบัติใช้
    template: review.md
    instruction: |
      สร้างรายการตรวจสอบบนพื้นฐานของเอกสารออกแบบ
      รวมถึงข้อ Bocorด้านความปลอดภัย, ประสิทธิภาพ, และการทดสอบ
    requires:
      - design

  - id: tasks
    # ... การตั้งค่า tasks ที่มีอยู่ ...
    requires:
      - specs
      - design
      - review    # ตอนนี้ tasks ต้องการการตรวจสอบด้วยเช่นกัน

สคีมจากชุมชน

OpenSpec ยังรองรับสคีมที่ดูแลรักษาโดยชุมชนที่กระจายผ่าน repositories แยกต่างหาก สคีมเหล่านี้มีเวิร์กโฟลว์ที่มีมุมมองที่ผสานรวม OpenSpec กับเครื่องมือหรือระบบอื่นๆ อย่างคล้ายคลึงกับวิธีที่ แคตตาล็อกส่วนขยายชุมชนของ github/spec-kit ทำงานสำหรับ spec-kit

สคีมจากชุมชนไม่ได้รวมอยู่ในแกนกลางของ OpenSpec — พวกมันอยู่ใน repositories ของตนเองด้วยจังหวะการเปิดตัวของตัวเอง หากต้องการใช้งาน ให้คัดลอกชุดสคีมไปยังโฟลเดอร์ openspec/schemas/<schema-name>/ ของโปรเจกต์ของคุณ (README ของแต่ละ repo มีคำแนะนำในการติดตั้ง)

สคีม	ผู้ดูแล	Repository	คำอธิบาย
`superpowers-bridge`	@JiangWay	JiangWay/openspec-schemas	ผสานรวมการจัดการอาร์ติแฟคต์ของ OpenSpec กับทักษะการทำงานของ obra/superpowers (brainstorming, การเขียนแผน, TDD ผ่าน subagents, การตรวจสอบโค้ด, การเสร็จสิ้น) เพิ่มอาร์ติแฟคต์ `retrospective` ที่เน้นหลักฐานเพื่อเติมช่องว่างที่ Superpowers ไม่รองรับโดยพื้นฐาน
`nanopm`	@nmrtn	nmrtn/nanopm	เวิร์กโฟลว์ที่เน้น PM เป็นหลัก รัน pipeline การวางแผนของ nanopm (audit → กลยุทธ์ → แผนทาง → PRD) ขั้นตอนก่อนของการนำไปปฏิบัติใช้ เชื่อมโยงการวางแผนผลิตภัณฑ์กับเวิร์กโฟลว์วิศวกรรมที่ขับเคลื่อนด้วยสเปคของ OpenSpec อาร์ติแฟคต์จะอ่านจาก `.nanopm/` หากมีอยู่ — ข้อเสนอใช้ข้อมูลจาก audit, การออกแบบใช้ข้อมูลจาก กลยุทธ์, และรายการงานใช้ข้อมูลจาก PRD ที่แบ่งส่วนแล้ว
`e2e-runbooks`	@Lukk17	Lukk17/openspec-schemas	รันบุ๊คทดสอบ end-to-end ระดับความสามารถ แต่ละความสามารถจะมีสเปคที่ไม่สามารถแก้ไขได้, แม่แบบรายการงานที่ไม่สามารถแก้ไขได้, และหนึ่งบันทึกการรันที่มีการประทับเวลาเวลาต่อการรันแต่ละครั้ง การตรวจสอบ (Assertions) เป็นเพียงพฤติกรรมที่สามารถสังเกตได้เท่านั้น (สถานะ HTTP, ร่างตอบกลับ, สถานะที่บันทึกไว้ — ไม่ใช่สตริงใน log); การรันแต่ละครั้งจะบันทึกเวลาเริ่ม/สิ้นสุดเป็น UTC, ระยะเวลา, และการบริโภคโทเคน LLM ที่ประมาณการได้ดีที่สุด

ต้องการมีส่วนร่วมส่งสคีมจากชุมชน? เปิด issue พร้อมลิงก์ไปยัง repository ของคุณ หรือส่ง PR เพิ่มแถวในตารางนี้

ดูเพิ่มเติม

CLI Reference: Schema Commands - เอกสารคำสั่งทั้งหมด

การปรับแต่งเอง ​

การตั้งค่าโปรเจกต์ ​

การตั้งค่าอย่างรวดเร็ว ​

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

ลำดับการค้นหาสคีม ​

สคีมที่กำหนดเอง ​

การใช้สคีมที่มีอยู่แล้วเป็นฐาน (Fork) ​

สร้างสคีมใหม่ตั้งแต่เริ่มต้น ​

โครงสร้างสคีม ​

แม่แบบ ​

ตรวจสอบความถูกต้องของสคีมของคุณ ​

ใช้งานสคีมที่กำหนดเองของคุณ ​

ตรวจสอบการแก้ปัญหาการค้นหาสคีม ​

ตัวอย่าง ​

เวิร์กโฟลว์การพัฒนาอย่างรวดเร็ว (Rapid Iteration) ​

การเพิ่มอาร์ติแฟคต์การตรวจสอบ (Review) ​

สคีมจากชุมชน ​

ดูเพิ่มเติม ​

การปรับแต่งเอง

การตั้งค่าโปรเจกต์

การตั้งค่าอย่างรวดเร็ว

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

ลำดับการค้นหาสคีม

สคีมที่กำหนดเอง

การใช้สคีมที่มีอยู่แล้วเป็นฐาน (Fork)

สร้างสคีมใหม่ตั้งแต่เริ่มต้น

โครงสร้างสคีม

แม่แบบ

ตรวจสอบความถูกต้องของสคีมของคุณ

ใช้งานสคีมที่กำหนดเองของคุณ

ตรวจสอบการแก้ปัญหาการค้นหาสคีม

ตัวอย่าง

เวิร์กโฟลว์การพัฒนาอย่างรวดเร็ว (Rapid Iteration)

การเพิ่มอาร์ติแฟคต์การตรวจสอบ (Review)

สคีมจากชุมชน

ดูเพิ่มเติม