OPSX Workflow
Discord에서 피드백을 환영합니다.
개요
OPSX는 이제 OpenSpec의 표준 워크플로우입니다.
이는 OpenSpec 변경을 위한 유동적이고 반복적인 워크플로우입니다. 더 이상 경직된 단계는 없습니다 — 언제든지 실행할 수 있는 작업만 있을 뿐입니다.
존재 이유
기존 OpenSpec 워크플로우는 작동하지만 제한적입니다:
- 지시사항이 하드코딩되어 있습니다 — TypeScript에 묻혀 있어 변경할 수 없습니다
- 전부 아니면 전혀 없음 — 하나의 큰 명령어가 모든 것을 생성하므로 개별 요소를 테스트할 수 없습니다
- 고정된 구조 — 모든 사람에게 동일한 워크플로우, 사용자 정의 불가
- 블랙박스 — AI 출력이 좋지 않을 때 프롬프트를 조정할 수 없습니다
OPSX가 이를 개방합니다. 이제 누구나 다음을 할 수 있습니다:
- 지시사항 실험 — 템플릿을 편집하여 AI 성능이 개선되는지 확인할 수 있습니다
- 세밀한 테스트 — 각 아티팩트의 지시사항을 독립적으로 검증할 수 있습니다
- 워크플로우 사용자 정의 — 고유한 아티팩트와 의존성을 정의할 수 있습니다
- 빠른 반복 — 템플릿을 변경하고 즉시 테스트하며, 재빌드가 필요 없습니다
기존 워크플로우: OPSX:
┌────────────────────────┐ ┌────────────────────────┐
│ 패키지에 하드코딩됨 │ │ schema.yaml │◄── 여기를 편집하세요
│ (변경 불가) │ │ templates/*.md │◄── 또는 여기
│ ↓ │ │ ↓ │
│ 새 릴리스를 기다림 │ │ 즉시 적용됨 │
│ ↓ │ │ ↓ │
│ 개선되길 바람 │ │ 직접 테스트하세요 │
└────────────────────────┘ └────────────────────────┘이것은 모든 사람을 위한 것입니다:
- 팀 — 실제 업무 방식에 맞는 워크플로우를 생성할 수 있습니다
- 고급 사용자 — 프롬프트를 조정하여 코드베이스에 대한 더 나은 AI 출력을 얻을 수 있습니다
- OpenSpec 기여자 — 릴리스 없이 새로운 접근 방식을 실험할 수 있습니다
우리 모두 아직 가장 효과적인 방법을 배우는 중입니다. OPSX는 함께 배울 수 있게 해줍니다.
사용자 경험
선형 워크플로우의 문제점: 당신은 "계획 단계"에 있다가 "구현 단계"에 들어가고, 마침내 "완료"됩니다. 하지만 실제 업무는 그렇게 진행되지 않습니다. 무언가를 구현하다가 디자인이 잘못되었음을 깨닫고, 명세를 업데이트해야 하며, 구현을 계속해야 합니다. 선형 단계는 실제 업무 진행 방식과 맞지 않습니다.
OPSX 접근 방식:
- 단계가 아닌 액션 — 생성, 구현, 업데이트, 아카이브 — 언제든지 원하는 액션을 수행할 수 있습니다
- 의존성은 가능하게 하는 요소입니다 — 다음에 필요한 것이 아니라 가능한 것을 보여줍니다
proposal ──→ specs ──→ design ──→ tasks ──→ implement설정
bash
# openspec이 설치되어 있는지 확인하세요 — 스킬은 자동으로 생성됩니다
openspec init이는 .claude/skills/(또는 이에 상응하는 위치)에 AI 코딩 어시스턴트가 자동으로 감지할 수 있는 스킬을 생성합니다.
기본적으로 OpenSpec은 core 워크플로우 프로필(propose, explore, apply, sync, archive)을 사용합니다. 확장 워크플로우 명령어(new, continue, ff, verify, bulk-archive, onboard)를 사용하려면 openspec config profile로 구성한 후 openspec update로 적용하세요.
설정 중에 프로젝트 구성(openspec/config.yaml)을 생성하라는 메시지가 표시됩니다. 선택 사항이지만 권장됩니다.
프로젝트 구성
프로젝트 구성을 통해 기본값을 설정하고 모든 아티팩트에 프로젝트별 컨텍스트를 삽입할 수 있습니다.
구성 생성
구성은 openspec init 중에 자동으로 생성되거나 수동으로 생성할 수 있습니다:
yaml
# openspec/config.yaml
schema: spec-driven
context: |
Tech stack: TypeScript, React, Node.js
API conventions: RESTful, JSON responses
Testing: Vitest for unit tests, Playwright for e2e
Style: ESLint with Prettier, strict TypeScript
rules:
proposal:
- Include rollback plan
- Identify affected teams
specs:
- Use Given/When/Then format for scenarios
design:
- Include sequence diagrams for complex flows구성 필드
| Field | Type | Description |
|---|---|---|
schema | string | 새 변경에 대한 기본 스키마 (예: spec-driven) |
context | string | 모든 아티팩트 지시사항에 삽입되는 프로젝트 컨텍스트 |
rules | object | 아티팩트 ID를 키로 하는 아티팩트별 규칙 |
작동 방식
스키마 우선순위 (높은 순에서 낮은 순):
- CLI 플래그 (
--schema <이름>) - 변경 메타데이터 (변경 디렉토리의
.openspec.yaml) - 프로젝트 구성 (
openspec/config.yaml) - 기본값 (
spec-driven)
컨텍스트 삽입:
- 컨텍스트는 모든 아티팩트의 지시사항 앞에 추가됩니다
<context>...</context>태그로 감싸집니다- AI가 프로젝트 규칙을 이해하는 데 도움이 됩니다
규칙 삽입:
- 규칙은 일치하는 아티팩트에만 삽입됩니다
<rules>...</rules>태그로 감싸집니다- 컨텍스트 뒤, 템플릿 앞에 나타납니다
스키마별 아티팩트 ID
spec-driven (기본값):
proposal— 변경 제안서specs— 명세서design— 기술 설계tasks— 구현 작업
구성 유효성 검사
rules에 알 수 없는 아티팩트 ID가 있으면 경고가 생성됩니다- 스키마 이름은 사용 가능한 스키마와 대조하여 유효성 검사가 수행됩니다
- 컨텍스트는 50KB 크기 제한이 있습니다
- 잘못된 YAML은 줄 번호와 함께 보고됩니다
문제 해결
"rules에 알 수 없는 아티팩트 ID: X"
- 아티팩트 ID가 스키마와 일치하는지 확인하세요 (위 목록 참조)
- 각 스키마의 아티팩트 ID를 보려면
openspec schemas --json을 실행하세요
구성이 적용되지 않는 경우:
- 파일이
openspec/config.yaml에 있는지 확인하세요 (.yml이 아님) - 유효성 검사기로 YAML 구문을 확인하세요
- 구성 변경은 즉시 적용됩니다 (재시작 필요 없음)
컨텍스트가 너무 큰 경우:
- 컨텍스트는 50KB로 제한됩니다
- 대신 요약하거나 외부 문서에 링크하세요
명령어
| Command | What it does |
|---|---|
/opsx:propose | 변경을 생성하고 한 단계로 계획 아티팩트를 생성합니다 (기본 빠른 경로) |
/opsx:explore | 아이디어를 검토하고, 문제를 조사하며, 요구사항을 명확히 합니다 |
/opsx:new | 새 변경 스캐폴드를 시작합니다 (확장 워크플로우) |
/opsx:continue | 다음 아티팩트를 생성합니다 (확장 워크플로우) |
/opsx:ff | 계획 아티팩트를 빠르게 생성합니다 (확장 워크플로우) |
/opsx:apply | 작업을 구현하고 필요한 경우 아티팩트를 업데이트합니다 |
/opsx:update | 변경의 계획 아티팩트를 수정하고 일관성을 유지합니다 |
/opsx:verify | 아티팩트와 대조하여 구현을 검증합니다 (확장 워크플로우) |
/opsx:sync | 델타 명세를 메인에 동기화합니다 (기본 워크플로우, 선택 사항) |
/opsx:archive | 완료 시 아카이브합니다 |
/opsx:bulk-archive | 여러 완료된 변경을 아카이브합니다 (확장 워크플로우) |
/opsx:onboard | 엔드투엔드 변경에 대한 안내형 워크스루를 제공합니다 (확장 워크플로우) |
사용 방법
아이디어 탐색
/opsx:explore아이디어를 검토하고, 문제를 조사하며, 옵션을 비교하세요. 별도의 구조가 필요 없습니다 — 그냥 생각을 나눌 파트너 역할만 하면 됩니다. 통찰이 명확해지면 /opsx:propose(기본값) 또는 /opsx:new//opsx:ff(확장 워크플로우)로 전환하세요.
새 변경 시작
/opsx:propose변경을 생성하고 구현 전에 필요한 계획 아티팩트를 생성합니다.
확장 워크플로우를 활성화한 경우 다음을 대신 사용할 수 있습니다:
text
/opsx:new # 스캐폴드만 생성
/opsx:continue # 아티팩트를 하나씩 생성
/opsx:ff # 모든 계획 아티팩트를 한 번에 생성아티팩트 생성
/opsx:continue의존성을 기반으로 생성할 수 있는 아티팩트를 표시한 다음 하나의 아티팩트를 생성합니다. 변경 사항을 점진적으로 구축하려면 반복적으로 사용하세요.
/opsx:ff add-dark-mode한 번에 모든 계획 아티팩트를 생성합니다. 구축하려는 내용이 명확할 때 사용하세요.
구현 (유동적인 부분)
/opsx:apply작업을 진행하면서 완료 표시를 합니다. 여러 변경을 동시에 진행하는 경우 /opsx:apply <이름>을 실행할 수 있습니다. 그렇지 않으면 대화에서 추론하여 확인할 수 없는 경우 선택하라는 메시지가 표시됩니다.
변경 업데이트
/opsx:update add-dark-mode - we're storing the theme in a cookie now변경의 기존 계획 아티팩트를 수정하고 어떤 방향으로든 일관성을 유지합니다 (설계 편집이 제안서까지 영향을 미칠 수 있습니다). 계획 아티팩트만 해당됩니다: 코드를 편집하지 않으며, 누락된 아티팩트를 생성하지 않습니다 (그것은 /opsx:continue의 역할입니다). 모든 편집은 먼저 사용자 확인을 거칩니다. 변경이 이미 구현된 경우 수정된 계획에 맞춰 코드를 업데이트할 수 있도록 /opsx:apply를 권장합니다. 수정 내용이 변경의 의도를 바꾸는 경우 새로 시작하는 것이 좋습니다 — 업데이트 vs 새로 시작 시점을 참조하세요.
마무리
/opsx:archive # 완료 시 아카이브로 이동합니다 (필요한 경우 명세 동기화를 묻습니다)업데이트 vs 새로 시작 시점
구현 전에는 언제든지 제안서나 명세를 편집할 수 있습니다. 하지만 언제부터 수정이 "다른 작업"이 되는 걸까요?
제안서가 담는 내용
제안서는 다음 세 가지를 정의합니다:
- 의도 — 어떤 문제를 해결하고 있나요?
- 범위 — 포함/제외되는 내용은 무엇인가요?
- 접근 방식 — 어떻게 해결할 것인가요?
문제는 무엇이 변경되었고, 얼마나 변경되었는지입니다.
다음 경우 기존 변경을 업데이트하세요:
의도는 동일하고 실행이 개선된 경우
- 고려하지 않았던 엣지 케이스를 발견한 경우
- 접근 방식에 약간의 조정이 필요하지만 목표는 변하지 않은 경우
- 구현 과정에서 설계가 약간 잘못되었음이 드러난 경우
범위가 축소된 경우
- 전체 범위가 너무 크다는 것을 깨닫고 먼저 MVP를 출시하려는 경우
- "다크 모드 추가" → "다크 모드 토글 추가 (v2에서 시스템 기본값 지원)"
학습을 통한 수정
- 코드베이스가 생각했던 구조가 아닌 경우
- 의존성이 예상대로 작동하지 않는 경우
- "CSS 변수 사용" → "대신 Tailwind의 dark: 접두사 사용"
다음 경우 새 변경을 시작하세요:
의도가 근본적으로 변경된 경우
- 문제 자체가 달라진 경우
- "다크 모드 추가" → "사용자 정의 색상, 폰트, 간격을 지원하는 포괄적인 테마 시스템 추가"
범위가 급증한 경우
- 변경 사항이 너무 많아 본질적으로 다른 작업이 된 경우
- 업데이트 후 원래 제안서를 알아볼 수 없게 되는 경우
- "로그인 버그 수정" → "인증 시스템 재작성"
원본을 완료할 수 있는 경우
- 원래 변경을 "완료"로 표시할 수 있는 경우
- 새 작업이 독립적이며 개선이 아닌 경우
- "다크 모드 MVP 추가" 완료 → 아카이브 → 새 변경 "다크 모드 기능 강화"
경험적 규칙
┌─────────────────────────────────────┐
│ 이것이 같은 작업인가요? │
└──────────────┬──────────────────────┘
│
┌──────────────────┼──────────────────┐
│ │ │
▼ ▼ ▼
의도가 동일한가요? >50% 중복되는가요? 원본을
문제가 동일한가요? 범위가 동일한가요? 이 변경 없이
│ │ "완료"할 수 있는가요?
│ │ │
┌────────┴────────┐ ┌──────┴──────┐ ┌───────┴───────┐
│ │ │ │ │ │
YES NO YES NO NO YES
│ │ │ │ │ │
▼ ▼ ▼ ▼ ▼ ▼
UPDATE NEW UPDATE NEW UPDATE NEW| Test | Update | New Change |
|---|---|---|
| Identity | "동일한 작업, 개선됨" | "다른 작업" |
| Scope overlap | >50% 중복 | <50% 중복 |
| Completion | 변경 없이는 "완료"할 수 없음 | 원본을 완료할 수 있으며 새 작업이 독립적임 |
| Story | 업데이트 체인이 일관된 스토리를 전달함 | 패치가 명확히 하는 것보다 더 혼란스러움 |
원칙
업데이트는 컨텍스트를 보존합니다. 새 변경은 명확성을 제공합니다.
생각의 과정이 가치가 있을 때 업데이트를 선택하세요. 새로 시작하는 것이 패치하는 것보다 더 명확할 때 새 변경을 선택하세요.
git 브랜치로 생각해보세요:
- 동일한 기능을 작업하는 동안 커밋을 계속하세요
- 진정으로 새로운 작업일 때 새 브랜치를 시작하세요
- 때로는 부분 기능을 머지하고 2단계를 위해 새로 시작하세요
무엇이 다른가요?
Legacy (/openspec:proposal) | OPSX (/opsx:*) | |
|---|---|---|
| Structure | 하나의 큰 제안서 문서 | 의존성이 있는 개별 아티팩트 |
| Workflow | 선형 단계: 계획 → 구현 → 아카이브 | 유동적인 액션 — 언제든지 원하는 작업 수행 |
| Iteration | 돌아가기 어려움 | 배운 내용에 따라 아티팩트 업데이트 |
| Customization | 고정된 구조 | 스키마 기반 (고유한 아티팩트 정의 가능) |
핵심 통찰: 업무는 선형적이지 않습니다. OPSX는 더 이상 선형적인 것처럼 가장하지 않습니다.
아키텍처 심층 분석
이 섹션에서는 OPSX가 내부적으로 작동하는 방식과 기존 워크플로우와의 차이점을 설명합니다. 이 섹션의 예제는 확장 명령어 세트(new, continue 등)를 사용합니다; 기본 core 사용자는 동일한 흐름을 propose → apply → sync → archive로 매핑할 수 있습니다.
철학: 단계(Phases) vs 동작(Actions)
┌─────────────────────────────────────────────────────────────────────────────┐
│ 기존 워크플로우 │
│ (단계 고정, 전부 아니면 전무) │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
│ │ 계획 단계 │ ───► │ 구현 단계 │ ───► │ 보관 단계 │ │
│ └──────────────┘ └──────────────┘ └──────────────┘ │
│ │ │ │ │
│ ▼ ▼ ▼ │
│ /openspec:proposal /openspec:apply /openspec:archive │
│ │
│ • 모든 아티팩트를 한 번에 생성합니다 │
│ • 구현 중에 스펙을 업데이트하기 위해 돌아갈 수 없습니다 │
│ • 단계 게이트가 선형 진행을 강제합니다 │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────────────────────┐
│ OPSX 워크플로우 │
│ (유연한 동작, 반복형) │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ ┌────────────────────────────────────────────┐ │
│ │ 동작(단계가 아님) │ │
│ │ │ │
│ │ new ◄──► continue ◄──► apply ◄──► archive │ │
│ │ │ │ │ │ │ │
│ │ └──────────┴───────────┴───────────┘ │ │
│ │ 임의 순서 │ │
│ └────────────────────────────────────────────┘ │
│ │
│ • 아티팩트를 하나씩 생성하거나 빠른 진행을 할 수 있습니다 │
│ • 구현 중에 스펙/디자인/태스크를 업데이트할 수 있습니다 │
│ • 의존성이 진행을 가능하게 하며, 단계는 존재하지 않습니다 │
│ │
└─────────────────────────────────────────────────────────────────────────────┘컴포넌트 아키텍처
기존 워크플로우는 TypeScript에 하드코딩된 템플릿을 사용합니다:
┌─────────────────────────────────────────────────────────────────────────────┐
│ 기존 워크플로우 컴포넌트 │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ 하드코딩된 템플릿 (TypeScript 문자열) │
│ │ │
│ ▼ │
│ 도구별 설정기/어댑터 │
│ │ │
│ ▼ │
│ 생성된 명령어 파일 (.claude/commands/openspec/*.md) │
│ │
│ • 고정된 구조로 아티팩트를 인식하지 못합니다 │
│ • 변경하려면 코드 수정과 리빌드가 필요합니다 │
│ │
└─────────────────────────────────────────────────────────────────────────────┘OPSX는 외부 스키마와 의존성 그래프 엔진을 사용합니다:
┌─────────────────────────────────────────────────────────────────────────────┐
│ OPSX 컴포넌트 │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ 스키마 정의 (YAML) │
│ ┌─────────────────────────────────────────────────────────────────────┐ │
│ │ name: spec-driven │ │
│ │ artifacts: │ │
│ │ - id: proposal │ │
│ │ generates: proposal.md │ │
│ │ requires: [] ◄── 의존성 │ │
│ │ - id: specs │ │
│ │ generates: specs/**/*.md ◄── Glob 패턴 │ │
│ │ requires: [proposal] ◄── proposal 완료 후 활성화 │ │
│ └─────────────────────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ 아티팩트 그래프 엔진 │
│ ┌─────────────────────────────────────────────────────────────────────┐ │
│ │ • 위상 정렬 (의존성 순서 지정) │ │
│ │ • 상태 감지 (파일 시스템 존재 여부) │ │
│ │ • 풍부한 지시문 생성 (템플릿 + 컨텍스트) │ │
│ └─────────────────────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ 스킬 파일 (.claude/skills/openspec-*/SKILL.md) │
│ │
│ • 여러 편집기 호환 (Claude Code, Cursor, Windsurf) │
│ • 구조화된 데이터를 위한 스킬 쿼리 CLI │
│ • 스키마 파일을 통해 완전히 사용자 정의할 수 있습니다 │
│ │
└─────────────────────────────────────────────────────────────────────────────┘의존성 그래프 모델
아티팩트는 방향성 비순환 그래프(DAG)를 형성합니다. 의존성은 게이트가 아니라 활성화 요소입니다:
proposal
(루트 노드)
│
┌─────────────┴─────────────┐
│ │
▼ ▼
specs design
(필요 항목: (필요 항목:
proposal) proposal)
│ │
└─────────────┬─────────────┘
│
▼
tasks
(필요 항목:
specs, design)
│
▼
┌──────────────┐
│ 적용 단계 │
│ (필요 항목: │
│ tasks) │
└──────────────┘상태 전환:
차단됨 ────────────────► 준비됨 ────────────────► 완료됨
│ │ │
누락된 의존성 모든 의존성 파일 시스템에
이 완료됨 파일이 존재함정보 흐름
기존 워크플로우 — 에이전트가 정적 지시문을 수신합니다:
사용자: "/openspec:proposal"
│
▼
┌─────────────────────────────────────────┐
│ 정적 지시문: │
│ • proposal.md 생성 │
│ • tasks.md 생성 │
│ • design.md 생성 │
│ • specs/<기능>/spec.md 생성 │
│ │
│ 아티팩트의 존재 여부나 아티팩트 간 │
│ 의존성을 인식하지 못함 │
└─────────────────────────────────────────┘
│
▼
에이전트가 모든 아티팩트를 한 번에 생성합니다OPSX — 에이전트가 풍부한 컨텍스트를 쿼리합니다:
사용자: "/opsx:continue"
│
▼
┌──────────────────────────────────────────────────────────────────────────┐
│ 1단계: 현재 상태 쿼리 │
│ ┌────────────────────────────────────────────────────────────────────┐ │
│ │ $ openspec status --change "add-auth" --json │ │
│ │ │ │
│ │ { │ │
│ │ "artifacts": [ │ │
│ │ {"id": "proposal", "status": "done"}, │ │
│ │ {"id": "specs", "status": "ready"}, ◄── 첫 번째 준비됨 │ │
│ │ {"id": "design", "status": "ready"}, │ │
│ │ {"id": "tasks", "status": "blocked", "missingDeps": ["specs"]}│ │
│ │ ] │ │
│ │ } │ │
│ └────────────────────────────────────────────────────────────────────┘ │
│ │
│ 2단계: 준비된 아티팩트에 대한 풍부한 지시문 가져오기 │
│ ┌────────────────────────────────────────────────────────────────────┐ │
│ │ $ openspec instructions specs --change "add-auth" --json │ │
│ │ │ │
│ │ { │ │
│ │ "template": "# Specification\n\n## ADDED Requirements...", │ │
│ │ "dependencies": [{"id": "proposal", "path": "...", "done": true}│ │
│ │ "unlocks": ["tasks"] │ │
│ │ } │ │
│ └────────────────────────────────────────────────────────────────────┘ │
│ │
│ 3단계: 의존성 읽기 → 아티팩트 하나 생성 → 잠금 해제된 항목 표시 │
└──────────────────────────────────────────────────────────────────────────┘반복 모델
기존 워크플로우 — 반복하기 어려움:
┌─────────┐ ┌─────────┐ ┌─────────┐
│/proposal│ ──► │ /apply │ ──► │/archive │
└─────────┘ └─────────┘ └─────────┘
│ │
│ ├── "설계가 잘못됐는데요?"
│ │
│ ├── 옵션:
│ │ • 수동으로 파일 편집 (컨텍스트가 깨집니다)
│ │ • 포기하고 처음부터 다시 시작
│ │ • 그대로 진행하고 나중에 수정
│ │
│ └── 공식적인 "되돌아가기" 메커니즘 없음
│
└── 한 번에 모든 아티팩트를 생성합니다OPSX — 자연스러운 반복:
/opsx:new ───► /opsx:continue ───► /opsx:apply ───► /opsx:archive
│ │ │
│ │ ├── "설계가 잘못됐습니다"
│ │ │
│ │ ▼
│ │ design.md만 편집한 후
│ │ 계속 진행하세요!
│ │ │
│ │ ▼
│ │ /opsx:apply가 중단한 부분부터
│ │ 이어서 진행합니다
│ │
│ └── 한 번에 하나의 아티팩트를 생성하고, 잠금 해제된 항목을 표시합니다
│
└── 변경에 대한 스캐폴딩을 생성하고, 다음 지시를 기다립니다커스텀 스키마
스키마 관리 명령어를 사용해 사용자 정의 워크플로우를 생성하세요:
bash
# 새 스키마를 처음부터 생성합니다 (대화형)
openspec schema init my-workflow
# 또는 기존 스키마를 포크해 시작점으로 사용하세요
openspec schema fork spec-driven my-workflow
# 스키마 구조를 검증하세요
openspec schema validate my-workflow
# 스키마가 어디서 resolve 되는지 확인하세요 (디버깅에 유용합니다)
openspec schema which my-workflow스키마는 openspec/schemas/ (프로젝트 로컬, 버전 관리됨) 또는 ~/.local/share/openspec/schemas/ (사용자 전역)에 저장됩니다.
스키마 구조:
openspec/schemas/research-first/
├── schema.yaml
└── templates/
├── research.md
├── proposal.md
└── tasks.mdschema.yaml 예시:
yaml
name: research-first
artifacts:
- id: research # proposal 전에 추가됨
generates: research.md
requires: []
- id: proposal
generates: proposal.md
requires: [research] # 이제 research에 의존함
- id: tasks
generates: tasks.md
requires: [proposal]의존성 그래프:
research ──► proposal ──► tasks요약
| 항목 | 레거시 | OPSX |
|---|---|---|
| 템플릿 | 하드코딩된 TypeScript | 외부 YAML + 마크다운 |
| 의존성 | 없음 (한 번에 전체 생성) | 위상 정렬이 포함된 DAG |
| 상태 | 단계 기반의 마인드 모델 | 파일 시스템 존재 여부 |
| 커스터마이징 | 소스 수정 후 재빌드 | schema.yaml 생성 |
| 반복 | 단계 잠금 상태 | 자유롭게, 원하는 부분 수정 |
| 편집기 지원 | 도구별 설정기/어댑터 | 단일 스킬 디렉터리 |
스키마
스키마는 존재하는 아티팩트와 그 의존성을 정의합니다. 현재 사용 가능한 스키마:
- spec-driven (기본): proposal → specs → design → tasks
bash
# 사용 가능한 스키마 목록 확인
openspec schemas
# 모든 스키마와 resolve 소스를 확인
openspec schema which --all
# 새 스키마를 대화형으로 생성
openspec schema init my-workflow
# 기존 스키마를 포크해 커스터마이징
openspec schema fork spec-driven my-workflow
# 사용 전 스키마 구조 검증
openspec schema validate my-workflow팁
- 변경을 적용하기 전 아이디어를 검토하려면
/opsx:explore를 사용하세요 - 원하는 내용이 명확할 때는
/opsx:ff, 탐색 중일 때는/opsx:continue를 사용하세요 /opsx:apply중에 문제가 발생한 경우 아티팩트를 수정한 후 계속 진행하세요- 태스크는
tasks.md의 체크박스를 통해 진행 상황을 추적합니다 - 언제든지 상태 확인:
openspec status --change "name"
피드백
현재 버전은 초기 단계입니다. 이는 의도적인 것으로, 어떤 방식이 효과적인지 학습하는 과정에 있기 때문입니다.