OPSX 워크플로우
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설정 필드
| 필드 | 타입 | 설명 |
|---|---|---|
schema | string | 새 변경사항의 기본 스키마 (예: spec-driven) |
context | string | 모든 아티팩트 명령어에 주입되는 프로젝트 컨텍스트 |
rules | object | 아티팩트 ID별 규칙 |
작동 방식
스키마 우선순위 (높은 순서대로):
- CLI 플래그 (
--schema <name>) - 변경 메타데이터 (변경 디렉토리의
.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가 스키마와 일치하는지 확인하세요 (위 목록 참조)
openspec schemas --json을 실행하여 각 스키마의 아티팩트 ID를 확인하세요
설정이 적용되지 않음:
- 파일이
openspec/config.yaml에 있는지 확인하세요 (.yml아님) - YAML 구문을 검증기로 확인하세요
- 설정 변경은 즉시 적용됩니다 (재시작 불필요)
컨텍스트가 너무 큰 경우:
- 컨텍스트는 50KB로 제한됩니다
- 요약하거나 외부 문서에 링크하세요
명령어
| 명령어 | 기능 |
|---|---|
/opsx:propose | 변경사항을 생성하고 계획 아티팩트를 한 단계에 생성 (기본 빠른 경로) |
/opsx:explore | 아이디어를 생각하고, 문제를 조사하고, 요구사항을 명확히 함 |
/opsx:new | 새 변경사항 스캐폴드 시작 (확장 워크플로우) |
/opsx:continue | 다음 아티팩트 생성 (확장 워크플로우) |
/opsx:ff | 계획 아티팩트 패스트포워드 (확장 워크플로우) |
/opsx:apply | 태스크를 구현하고 필요에 따라 아티팩트 업데이트 |
/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 <name>을 실행할 수 있습니다; 그렇지 않으면 대화에서 추론하고 판단할 수 없을 때 선택을 요청합니다.
마무리
/opsx:archive # 완료 시 아카이브로 이동 (필요 시 사양 동기화를 요청)업데이트할 때 vs 새로 시작할 때
구현 전에 항상 제안이나 사양을 편집할 수 있습니다. 하지만 정제가 "이건 다른 작업이다"가 되는 시점은 언제일까요?
제안이 포착하는 것
제안은 세 가지를 정의합니다:
- 의도 — 어떤 문제를 해결하고 있나요?
- 범위 — 범위 안팎에 무엇이 있나요?
- 접근 방식 — 어떻게 해결할 건가요?
핵심은: 무엇이 얼마나 변했는가입니다.
기존 변경사항을 업데이트해야 할 때:
같은 의도, 정제된 실행
- 고려하지 못한 엣지 케이스를 발견한 경우
- 접근 방식은 조정이 필요하지만 목표는 변하지 않은 경우
- 구현过程中 설계가 약간 벗어났다는 것이 드러난 경우
범위가 축소됨
- 전체 범위가 너무 크다는 것을 깨닫고 MVP를 먼저 출시하려는 경우
- "다크 모드 추가" → "다크 모드 토글 추가 (v2에서 시스템 기본 설정)"
학습 기반 수정
- 코드베이스가 생각한 구조가 아닌 경우
- 의존성이 예상대로 작동하지 않는 경우
- "CSS 변수 사용" → "대신 Tailwind의 dark: 접두사 사용"
새 변경사항을 시작해야 할 때:
의도가 근본적으로 변경됨
- 문제 자체가 달라진 경우
- "다크 모드 추가" → "커스텀 색상, 폰트, 간격을 포함한 포괄적인 테마 시스템 추가"
범위가 폭발적으로 증가함
- 변경사항이 너무 커져서 본질적으로 다른 작업이 된 경우
- 업데이트 후 원래 제안을 알아볼 수 없게 되는 경우
- "로그인 버그 수정" → "인증 시스템 재작성"
원본이 완료 가능한 경우
- 원래 변경사항을 "완료"로 표시할 수 있는 경우
- 새 작업이 독립적이며 정제가 아닌 경우
- "다크 모드 MVP 추가" 완료 → 아카이브 → 새 변경사항 "다크 모드 개선"
휴리스틱
┌─────────────────────────────────────┐
│ 이것이 동일한 작업인가요? │
└──────────────┬──────────────────────┘
│
┌──────────────────┼──────────────────┐
│ │ │
▼ ▼ ▼
같은 의도? >50% 겹침? 원본이 이 변경
같은 문제? 같은 범위? 없이 "완료" 가능한가?
│ │ │
┌────────┴────────┐ ┌──────┴──────┐ ┌───────┴───────┐
│ │ │ │ │ │
예 아니오 예 아니오 아니오 예
│ │ │ │ │ │
▼ ▼ ▼ ▼ ▼ ▼
업데이트 새로 업데이트 새로 업데이트 새로| 테스트 | 업데이트 | 새 변경사항 |
|---|---|---|
| 정체성 | "같은 것, 정제됨" | "다른 작업" |
| 범위 겹침 | >50% 겹침 | <50% 겹침 |
| 완료 | 변경 없이 "완료" 불가 | 원본을 완료할 수 있고, 새 작업이 독립적 |
| 스토리 | 업데이트 체인이 일관된 스토리를 전달 | 패치가 명확히 하기보다 혼란을 야기 |
원칙
업데이트는 컨텍스트를 보존합니다. 새 변경사항은 명확성을 제공합니다.
사고의 역사가 가치 있을 때 업데이트를 선택하세요. 패치하는 것보다 새로 시작하는 것이 더 명확할 때 새 변경사항을 선택하세요.
git 브랜치처럼 생각하세요:
- 같은 기능을 작업하는 동안 계속 커밋
- 진정으로 새로운 작업일 때 새 브랜치 시작
- 때로는 부분 기능을 머지하고 2단계를 위해 새로 시작
무엇이 다른가요?
레거시 (/openspec:proposal) | OPSX (/opsx:*) | |
|---|---|---|
| 구조 | 하나의 큰 제안 문서 | 의존성이 있는 개별 아티팩트 |
| 워크플로우 | 선형 단계: 계획 → 구현 → 보관 | 유동적 작업 — 언제든 무엇이든 수행 가능 |
| 반복 | 되돌아가기 어색함 | 학습하면서 아티팩트 업데이트 |
| 사용자 정의 | 고정된 구조 | 스키마 기반 (자신만의 아티팩트 정의) |
핵심 통찰: 작업은 선형적이지 않습니다. OPSX는 이를 가장하지 않습니다.
아키텍처 심층 분석
이 섹션에서는 OPSX의 내부 작동 방식과 레거시 워크플로와의 비교를 설명합니다. 이 섹션의 예제는 확장된 명령어 집합(new, continue 등)을 사용합니다. 기본 core 사용자는 동일한 흐름을 propose → apply → sync → archive에 매핑할 수 있습니다.
철학: 단계 대 액션
┌─────────────────────────────────────────────────────────────────────────────┐
│ 레거시 워크플로 │
│ (단계 고정, 전부 아니면 무) │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
│ │ 계획 수립 │ ───► │ 구현 단계 │ ───► │ 아카이브 │ │
│ │ 단계 │ │ 단계 │ │ 단계 │ │
│ └──────────────┘ └──────────────┘ └──────────────┘ │
│ │ │ │ │
│ ▼ ▼ ▼ │
│ /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 ◄── 글롭 패턴 │ │
│ │ requires: [proposal] ◄── proposal 이후 활성화 │ │
│ └─────────────────────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ 아티팩트 그래프 엔진 │
│ ┌─────────────────────────────────────────────────────────────────────┐ │
│ │ • 위상 정렬 (의존성 순서 지정) │ │
│ │ • 상태 감지 (파일시스템 존재 여부) │ │
│ │ • 풍부한 지시 생성 (템플릿 + 컨텍스트) │ │
│ └─────────────────────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ 스킬 파일 (.claude/skills/openspec-*/SKILL.md) │
│ │
│ • 크로스 에디터 호환 (Claude Code, Cursor, Windsurf) │
│ • 스킬이 구조화된 데이터를 위해 CLI를 쿼리 │
│ • 스키마 파일을 통해 완전히 사용자 정의 가능 │
│ │
└─────────────────────────────────────────────────────────────────────────────┘의존성 그래프 모델
아티팩트는 방향 비순환 그래프(DAG)를 형성합니다. 의존성은 활성화 요소이지, 게이트가 아닙니다:
proposal
(루트 노드)
│
┌─────────────┴─────────────┐
│ │
▼ ▼
specs design
(requires: (requires:
proposal) proposal)
│ │
└─────────────┬─────────────┘
│
▼
tasks
(requires:
specs, design)
│
▼
┌──────────────┐
│ APPLY 단계 │
│ (requires: │
│ tasks) │
└──────────────┘상태 전이:
BLOCKED ────────────────► READY ────────────────► DONE
│ │ │
누락된 모든 의존성 파일이
의존성 완료됨 파일시스템에 존재정보 흐름
레거시 워크플로 — 에이전트가 정적 지시를 수신:
사용자: "/openspec:proposal"
│
▼
┌─────────────────────────────────────────┐
│ 정적 지시: │
│ • proposal.md 생성 │
│ • tasks.md 생성 │
│ • design.md 생성 │
│ • specs/<capability>/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
# 스키마가 어디서 해석되는지 확인 (디버깅에 유용)
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 + Markdown |
| 의존성 | 없음 (모두 한 번에) | 위상 정렬을 사용하는 DAG |
| 상태 | 단계 기반 정신 모델 | 파일시스템 존재 여부 |
| 사용자 정의 | 소스 편집, 재빌드 | schema.yaml 생성 |
| 반복 | 단계 고정 | 유동적, 아무 것이나 편집 가능 |
| 에디터 지원 | 도구별 설정기/어댑터 | 단일 스킬 디렉토리 |
스키마
스키마는 어떤 아티팩트가 존재하고 그 종속 관계를 정의합니다. 현재 사용 가능한 스키마:
- 스펙 기반 (기본값): 제안 → 스펙 → 설계 → 태스크
bash
# 사용 가능한 스키마 목록
openspec schemas
# 모든 스키마와 해당 해석 소스 확인
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"
피드백
이것은 거친 버전입니다. 의도적인 것입니다 — 우리는 무엇이 효과적인지 배워가고 있습니다.
버그를 발견하셨나요? 아이디어가 있으신가요? Discord에 참여하시거나 GitHub에서 이슈를 열어주세요.