개요
OpenSpec을 사용자 정의하기 위한 옵션입니다.
OpenSpec은 여러 가지 사용자 정의 옵션을 지원합니다. 이 페이지에서는 각 옵션이 무엇을 변경하는지와 언제 사용해야 하는지 보여줍니다.
사용자 정의할 수 있는 항목
| 옵션 | 변경되는 내용 | 사용 시점 |
|---|---|---|
| 프로필 | 설치되는 워크플로와 그것이 스킬, 명령, 또는 둘 다로 제공되는지 여부 | 추가 워크플로와 작업 패턴을 원하거나 필요 없는 워크플로를 제거하려는 경우 |
| 프로젝트 구성 | 모든 워크플로 실행에 주입되는 지침: 컨텍스트, 규칙, 작업 안내 (config.yaml) | 변경 사항이 원하는 방식으로 계획되기를 원하는 경우. 예: 작업에 항상 Playwright 테스트 포함 |
| 스키마 | OpenSpec이 생성하는 것: 아티팩트, 그 순서, 그리고 템플릿 | 변경 사항이 다른 계획 파일, 섹션, 또는 형식을 생성해야 하는 경우 |
어떤 것을 사용해야 할지 모르겠나요?
구성과 스키마는 두 가지 수준의 사용자 정의입니다. 얼마나 직접적으로 개입하고 싶은지에 따라 선택하세요:
- 먼저 프로젝트 구성으로 시작하세요: 더 가볍고, 대부분의 프로젝트에 충분합니다. 표준 아티팩트를 유지하면서 그 위에 자체 컨텍스트와 규칙을 추가합니다.
- 추가하는 것만으로 충분하지 않을 때 스키마를 포크하세요: 구성은 핵심 워크플로 위에 추가만 할 수 있습니다. "작업에 항상 테스트 포함"과 같은 규칙을 추가할 수는 있지만, 설계 문서를 제거하거나 파일 이름을 바꿀 수는 없습니다. 그것은 스키마의 영역입니다. 포크하면 편집할 수 있는 자체 복사본을 얻게 됩니다.
여기서 "포크"는 git 저장소를 포크하는 것이 아니라 openspec schema fork 명령을 의미합니다. 자세한 내용은 스키마에서 확인하세요.
flowchart LR
a["워크플로가 내 스택과 규칙을 알아야 함"] --> config
b["하나의 아티팩트에 추가 규칙이 필요함. 예: 작업에 항상 테스트 포함"] --> config
c["다른 아티팩트, 파일 이름, 또는 문서 구조"] --> schema
d["내장 지침이 우리 팀이 다르게 하는 방식을 말함"] --> schema
config["프로젝트 구성<br/>(config.yaml)"]
schema["스키마 포크<br/>(openspec schema fork)"]