OPSX 워크플로

Discord에서 피드백을 환영합니다.

개요

OPSX는 이제 OpenSpec의 표준 워크플로입니다.

이것은 OpenSpec 변경사항을 위한 유연하고 반복적인 워크플로입니다. 더 이상 경직된 단계가 없습니다 — 언제든 수행할 수 있는 액션만 있습니다.

Why This Exists

레거시 OpenSpec 워크플로우는 작동하지만 잠겨 있습니다:

• 지시사항이 하드코딩되어 있음 — TypeScript 안에 숨겨져 있어 수정할 수 없음
• 전체 또는 아무것도 없음 — 하나의 큰 명령어로 모든 것을 생성하며, 개별 조각을 테스트할 수 없음
• 고정된 구조 — 모든 사람에게 동일한 워크플로우, 커스터마이징 불가
• 블랙박스 — AI 출력 품질이 나쁠 때 프롬프트를 조정할 수 없음

OPSX는 이를 개방합니다. 이제 누구나 다음을 할 수 있습니다:

1. 지시사항 실험 — 템플릿을 편집하여 AI가 더 잘하는지 확인
2. 세밀한 테스트 — 각 아티팩트의 지시사항을 독립적으로 검증
3. 워크플로우 커스터마이징 — 자체 아티팩트와 의존성을 정의
4. 빠른 반복 — 템플릿 변경 후 즉시 테스트, 재빌드 불필요

Legacy workflow:                      OPSX:
┌────────────────────────┐           ┌────────────────────────┐
│  Hardcoded in package  │           │  schema.yaml           │◄── You edit this
│  (can't change)        │           │  templates/*.md        │◄── Or this
│        ↓               │           │        ↓               │
│  Wait for new release  │           │  Instant effect        │
│        ↓               │           │        ↓               │
│  Hope it's better      │           │  Test it yourself      │
└────────────────────────┘           └────────────────────────┘

모두를 위한 도구:

• 팀 — 실제 작업 방식에 맞는 워크플로우 생성
• 파워 유저 — 코드베이스에 더 적합한 AI 출력을 위해 프롬프트 조정
• OpenSpec 기여자 — 릴리스 없이 새로운 접근법 실험

우리는 모두 무엇이 가장 효과적인지 계속 학습 중입니다. OPSX는 함께 학습할 수 있게 해줍니다.

The User Experience

선형 워크플로우의 문제: "계획 단계"에 있고, 그다음 "구현 단계"에 있고, 그다음 "완료". 하지만 실제 작업은 그렇게 작동하지 않습니다. 무언가를 구현하다가 설계가 잘못되었음을 깨닫고, 스펙을 업데이트해야 하고, 다시 구현을 계속합니다. 선형 단계는 실제 작업 방식과 충돌합니다.

OPSX 접근법:

• 단계가 아닌 액션 — 생성, 구현, 업데이트, 아카이브 — 언제든 어떤 액션도 수행 가능
• 의존성은 활성화자 — 다음에 필요한 것이 아니라 가능한 것을 보여줌

  proposal ──→ specs ──→ design ──→ tasks ──→ implement

Setup

# Make sure you have openspec installed — skills are automatically generated
openspec init

이 명령은 .claude/skills/ (또는 동등한 위치)에 스킬을 생성하며, AI 코딩 어시스턴트가 자동으로 감지합니다.

기본적으로 OpenSpec는 core 워크플로우 프로필(propose, explore, apply, update, sync, archive)을 사용합니다. 확장된 워크플로우 명령(new, continue, ff, verify, bulk-archive, onboard)을 사용하려면 openspec config profile로 설정하고 openspec update로 적용하세요.

설정 중에 프로젝트 설정(openspec/config.yaml)을 생성하라는 프롬프트가 표시됩니다. 선택 사항이지만 권장합니다.

Project Configuration

프로젝트 설정을 통해 기본값을 설정하고 모든 아티팩트에 프로젝트 고유 컨텍스트를 주입할 수 있습니다.

Creating Config

설정 파일은 openspec init 중에 생성되거나 수동으로 생성할 수 있습니다:

# 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

Config Fields

필드	타입	설명
schema	string	새 변경사항의 기본 스키마 (예: spec-driven)
context	string	모든 아티팩트 지시사항에 주입되는 프로젝트 컨텍스트
rules	object	아티팩트 ID를 키로 하는 아티팩트별 규칙

How It Works

스키마 우선순위 (높은 순서):

1. CLI 플래그 (--schema <name>)
2. 변경사항 메타데이터 (변경사항 디렉토리의 .openspec.yaml)
3. 프로젝트 설정 (openspec/config.yaml)
4. 기본값 (spec-driven)

컨텍스트 주입:

• 컨텍스트는 모든 아티팩트의 지시사항 앞에 추가됩니다
• <context>...</context> 태그로 감싸집니다
• AI가 프로젝트 컨벤션을 이해하는 데 도움을 줍니다

규칙 주입:

• 규칙은 일치하는 아티팩트에 대해서만 주입됩니다
• <rules>...</rules> 태그로 감싸집니다
• 컨텍스트 이후, 템플릿 이전에 표시됩니다

Artifact IDs by Schema

spec-driven (기본값):

• proposal — 변경 제안
• specs — 명세
• design — 기술 설계
• tasks — 구현 작업

Config Validation

• rules에 알 수 없는 아티팩트 ID가 있으면 경고가 발생합니다
• 스키마 이름은 사용 가능한 스키마와 대조하여 검증됩니다
• 컨텍스트에는 50KB 크기 제한이 있습니다
• 잘못된 YAML은 줄 번호와 함께 보고됩니다

Troubleshooting

"Unknown artifact ID in rules: X"

• 아티팩트 ID가 스키마와 일치하는지 확인 (위 목록 참조)
• 각 스키마의 아티팩트 ID를 보려면 openspec schemas --json 실행

설정 적용 안 됨:

• 파일이 openspec/config.yaml에 있는지 확인 (.yml이 아님)
• 검증기로 YAML 구문 확인
• 설정 변경은 즉시 적용됩니다 (재시작 불필요)

컨텍스트가 너무 큼:

• 컨텍스트는 50KB로 제한됩니다
• 요약하거나 외부 문서로 링크하는 것이 좋습니다

Commands

명령어	기능
/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	끝-to-끝 변경사항 가이드 워크스루 (확장 워크플로우)

Usage

아이디어 탐색

/opsx:explore

아이디어를 고민하고, 문제를 조사하고, 옵션을 비교합니다. 구조는 필요하지 않으며, 단순히 사고 파트너 역할을 합니다. 인사이트가 구체화되면 /opsx:propose (기본값) 또는 /opsx:new//opsx:ff (확장)로 전환합니다.

새 변경사항 시작

/opsx:propose

변경사항을 생성하고 구현 전에 필요한 계획 아티팩트를 생성합니다.

확장 워크플로우를 활성화했다면 대신 다음을 사용할 수 있습니다:

/opsx:new        # scaffold only
/opsx:continue   # create one artifact at a time
/opsx:ff         # create all planning artifacts at once

아티팩트 생성

/opsx:continue

의존성에 기반하여 생성할 수 있는 것을 표시한 후 하나의 아티팩트를 생성합니다. 반복하여 변경사항을 점진적으로 구축합니다.

/opsx:ff add-dark-mode

모든 계획 아티팩트를 한 번에 생성합니다. 무엇을 만들지 명확한 경우 사용하세요.

구현 (유연한 부분)

/opsx:apply

작업을 진행하면서 완료 표시를 해줍니다. 여러 변경사항을 동시에 다루고 있다면 /opsx:apply <name>을 실행할 수 있으며, 그렇지 않으면 대화에서 추론하고 판단이 불가능하면 선택을 요청합니다.

변경사항 업데이트

/opsx:update add-dark-mode - we're storing the theme in a cookie now

변경사항의 기존 계획 아티팩트를 수정하고 일관성을 유지합니다 — 어떤 방향이든 (설계 편집이 제안서로 역파급될 수 있음). 계획 아티팩트만 대상입니다: 코드는 절대 편집하지 않으며, 누락된 아티팩트를 생성하지도 않습니다 (그것은 /opsx:continue의 역할입니다). 모든 편집은 먼저 사용자와 확인합니다. 변경사항이 이미 구현되었다면, 코드가 수정된 계획에 따라잡도록 /opsx:apply를 권장합니다. 수정이 변경사항의 의도를 바꾼다면 새로 시작하는 것이 좋습니다 - 업데이트 vs. 새로 시작 시점 참조.

델타 스펙 동기화

/opsx:sync

현재 변경사항의 델타 스펙을 메인 openspec/specs/에 병합하되 아카이브하지 않습니다 — 변경사항은 활성 상태로 유지됩니다. 전체 델타를 적용합니다: ## REMOVED 아래에 있는 요구사항은 메인 스펙에서 삭제되고, 이름이 변경된 항목은 제자리에서 제목이 변경되며, 델타에 언급되지 않은 내용은 그대로 두어집니다. 동기화는 선택 사항입니다 — 동기화하지 않았다면 아카이브 시 먼저 동기화를 요청합니다. 아카이브 전에 메인 스펙을 업데이트하고 싶을 때, 병렬 변경사항이 이 변경사항이 추가한 스펙을 기반으로 해야 할 때, 또는 아카이브 전에 병합된 메인 스펙을 검토하고 싶을 때 사용하세요.

마무리

/opsx:archive   # Move to archive when done (prompts to sync specs if needed)

When to Update vs. Start Fresh

구현 전에 제안서나 스펙을 항상 수정할 수 있습니다. 하지만 언제 정교화가 "이것은 다른 작업"이 되는 것일까요?

What a Proposal Captures

제안서는 세 가지를 정의합니다:

1. 의도 — 어떤 문제를 해결하는가?
2. 범위 — 무엇이 포함/제외되는가?
3. 접근법 — 어떻게 해결할 것인가?

질문은 이것입니다: 무엇이 바뀌었고, 얼마나 바뀌었는가?

Update the Existing Change When:

같은 의도, 정교화된 실행

• 고려하지 않았던 엣지 케이스를 발견했을 때
• 접근법을 조정해야 하지만 목표는 변하지 않았을 때
• 구현 중 설계가 약간 어긋남을 알게 되었을 때

범위가 축소될 때

• 전체 범위가 너무 크다는 것을 깨닫고 MVP를 먼저 출시하고 싶을 때
• "다크 모드 추가" → "다크 모드 토글 추가 (시스템 설정은 v2에서)"

학습 기반 수정

• 코드베이스가 생각한 구조와 다름을 알게 되었을 때
• 의존성이 예상대로 작동하지 않을 때
• "CSS 변수 사용" → "Tailwind의 dark: 접두사 사용"

Start a New Change When:

의도가 근본적으로 변경되었을 때

• 문제 자체가 달라졌을 때
• "다크 모드 추가" → "커스텀 색상, 폰트, 간격을 포함한 종합 테마 시스템 추가"

범위가 폭발적으로 증가했을 때

• 변경사항이 너무 커져서 사실상 다른 작업이 되었을 때
• 업데이트 후 원래 제안서는 알아보지 못할 정도일 때
• "로그인 버그 수정" → "인증 시스템 재작성"

원래 작업이 완료 가능할 때

• 원래 변경사항을 "완료"로 표시할 수 있을 때
• 새 작업이 독립적이며 정교화가 아닐 때
• "다크 모드 MVP 추가" 완료 → 아카이브 → 새 변경사항 "다크 모드 강화"

The Heuristics

                        ┌─────────────────────────────────────┐
                        │     Is this the same work?          │
                        └──────────────┬──────────────────────┘
                                       │
                    ┌──────────────────┼──────────────────┐
                    │                  │                  │
                    ▼                  ▼                  ▼
             Same intent?      >50% overlap?      Can original
             Same problem?     Same scope?        be "done" without
                    │                  │          these changes?
                    │                  │                  │
          ┌────────┴────────┐  ┌──────┴──────┐   ┌───────┴───────┐
          │                 │  │             │   │               │
         YES               NO YES           NO  NO              YES
          │                 │  │             │   │               │
          ▼                 ▼  ▼             ▼   ▼               ▼
       UPDATE            NEW  UPDATE       NEW  UPDATE          NEW

테스트	업데이트	새 변경사항
정체성	"같은 것, 정교화"	"다른 작업"
범위 중복	50% 이상 중복	50% 미만 중복
완료 가능성	변경 없이는 "완료" 불가	원래 작업 완료 가능, 새 작업 독립적
스토리	업데이트 체인이 일관된 스토리를 전달	패치는 혼란을 더 줄 수 있음

The Principle

업데이트는 컨텍스트를 보존합니다. 새 변경사항은 명확성을 제공합니다.

사고의 역사가 가치 있을 때 업데이트를 선택하세요. 패치보다 새로 시작하는 것이 더 명확할 때 새 변경사항을 선택하세요.

Git 브랜치를 생각하면 됩니다:

• 같은 기능 작업 중에는 계속 커밋하세요
• 진정으로 새로운 작업일 때 새 브랜치를 시작하세요
• 때로는 부분 기능을 병합하고 2단계에서 새로 시작하세요

무엇이 다른가?

	레거시 (/openspec:proposal)	OPSX (/opsx:*)
구조	하나의 큰 제안 문서	의존성을 가진 개별 아티팩트
워크플로우	선형 단계: 계획 → 구현 → 보관	유연한 작업 — 언제든 무엇이든 수행
반복	되돌아가기 어색함	배우면서 아티팩트 업데이트
커스터마이징	고정된 구조	스키마 기반 (자체 아티팩트 정의)

핵심 통찰: 작업은 선형적이지 않습니다. OPSX는 더 이상 작업이 선형적이라고 가장하지 않습니다.

아키텍처 심층 분석

이 섹션에서는 OPSX가 내부적으로 어떻게 작동하는지, 그리고 기존 워크플로우와 어떻게 비교되는지 설명합니다. 이 섹션의 예제는 확장된 명령 세트(new, continue 등)를 사용합니다. 기본 core 사용자는 동일한 흐름을 propose → apply → sync → archive에 매핑할 수 있습니다.

철학: 단계(Phases) vs 액션(Actions)

┌─────────────────────────────────────────────────────────────────────────────┐
│                         LEGACY WORKFLOW                                      │
│                    (Phase-Locked, All-or-Nothing)                           │
├─────────────────────────────────────────────────────────────────────────────┤
│                                                                             │
│   ┌──────────────┐      ┌──────────────┐      ┌──────────────┐             │
│   │   PLANNING   │ ───► │ IMPLEMENTING │ ───► │   ARCHIVING  │             │
│   │    PHASE     │      │    PHASE     │      │    PHASE     │             │
│   └──────────────┘      └──────────────┘      └──────────────┘             │
│         │                     │                     │                       │
│         ▼                     ▼                     ▼                       │
│   /openspec:proposal   /openspec:apply      /openspec:archive              │
│                                                                             │
│   • Creates ALL artifacts at once                                          │
│   • Can't go back to update specs during implementation                    │
│   • Phase gates enforce linear progression                                  │
│                                                                             │
└─────────────────────────────────────────────────────────────────────────────┘


┌─────────────────────────────────────────────────────────────────────────────┐
│                            OPSX WORKFLOW                                     │
│                      (Fluid Actions, Iterative)                             │
├─────────────────────────────────────────────────────────────────────────────┤
│                                                                             │
│              ┌────────────────────────────────────────────┐                 │
│              │           ACTIONS (not phases)             │                 │
│              │                                            │                 │
│              │   new ◄──► continue ◄──► apply ◄──► archive │                 │
│              │    │          │           │           │    │                 │
│              │    └──────────┴───────────┴───────────┘    │                 │
│              │              any order                     │                 │
│              └────────────────────────────────────────────┘                 │
│                                                                             │
│   • Create artifacts one at a time OR fast-forward                         │
│   • Update specs/design/tasks during implementation                        │
│   • Dependencies enable progress, phases don't exist                       │
│                                                                             │
└─────────────────────────────────────────────────────────────────────────────┘

컴포넌트 아키텍처

기존 워크플로우는 TypeScript에 하드코딩된 템플릿을 사용합니다:

┌─────────────────────────────────────────────────────────────────────────────┐
│                      LEGACY WORKFLOW COMPONENTS                              │
├─────────────────────────────────────────────────────────────────────────────┤
│                                                                             │
│   Hardcoded Templates (TypeScript strings)                                  │
│                    │                                                        │
│                    ▼                                                        │
│   Tool-specific configurators/adapters                                      │
│                    │                                                        │
│                    ▼                                                        │
│   Generated Command Files (.claude/commands/openspec/*.md)                  │
│                                                                             │
│   • Fixed structure, no artifact awareness                                  │
│   • Change requires code modification + rebuild                             │
│                                                                             │
└─────────────────────────────────────────────────────────────────────────────┘

OPSX는 외부 스키마와 의존성 그래프 엔진을 사용합니다:

┌─────────────────────────────────────────────────────────────────────────────┐
│                         OPSX COMPONENTS                                      │
├─────────────────────────────────────────────────────────────────────────────┤
│                                                                             │
│   Schema Definitions (YAML)                                                 │
│   ┌─────────────────────────────────────────────────────────────────────┐   │
│   │  name: spec-driven                                                  │   │
│   │  artifacts:                                                         │   │
│   │    - id: proposal                                                   │   │
│   │      generates: proposal.md                                         │   │
│   │      requires: []              ◄── Dependencies                     │   │
│   │    - id: specs                                                      │   │
│   │      generates: specs/**/*.md  ◄── Glob patterns                    │   │
│   │      requires: [proposal]      ◄── Enables after proposal           │   │
│   └─────────────────────────────────────────────────────────────────────┘   │
│                    │                                                        │
│                    ▼                                                        │
│   Artifact Graph Engine                                                     │
│   ┌─────────────────────────────────────────────────────────────────────┐   │
│   │  • Topological sort (dependency ordering)                           │   │
│   │  • State detection (filesystem existence)                           │   │
│   │  • Rich instruction generation (templates + context)                │   │
│   └─────────────────────────────────────────────────────────────────────┘   │
│                    │                                                        │
│                    ▼                                                        │
│   Skill Files (.claude/skills/openspec-*/SKILL.md)                          │
│                                                                             │
│   • Cross-editor compatible (Claude Code, Cursor, Devin)                    │
│   • Skills query CLI for structured data                                    │
│   • Fully customizable via schema files                                     │
│                                                                             │
└─────────────────────────────────────────────────────────────────────────────┘

의존성 그래프 모델

아티팩트는 방향성 비순환 그래프(DAG)를 형성합니다. 의존성은 활성화자(enabler)이며, 게이트(gate)가 아닙니다:

                              proposal
                             (root node)
                                  │
                    ┌─────────────┴─────────────┐
                    │                           │
                    ▼                           ▼
                 specs                       design
              (requires:                  (requires:
               proposal)                   proposal)
                    │                           │
                    └─────────────┬─────────────┘
                                  │
                                  ▼
                               tasks
                           (requires:
                           specs, design)
                                  │
                                  ▼
                          ┌──────────────┐
                          │ APPLY PHASE  │
                          │ (requires:   │
                          │  tasks)      │
                          └──────────────┘

상태 전이:

   BLOCKED ────────────────► READY ────────────────► DONE
      │                        │                       │
   Missing                  All deps               File exists
   dependencies             are DONE               on filesystem

정보 흐름

기존 워크플로우 — 에이전트가 정적 지시를 수신합니다:

  User: "/openspec:proposal"
           │
           ▼
  ┌─────────────────────────────────────────┐
  │  Static instructions:                   │
  │  • Create proposal.md                   │
  │  • Create tasks.md                      │
  │  • Create design.md                     │
  │  • Create delta spec files              │
  │                                         │
  │  No awareness of what exists or         │
  │  dependencies between artifacts         │
  └─────────────────────────────────────────┘
           │
           ▼
  Agent creates ALL artifacts in one go

OPSX — 에이전트가 풍부한 컨텍스트를 조회합니다:

  User: "/opsx:continue"
           │
           ▼
  ┌──────────────────────────────────────────────────────────────────────────┐
  │  Step 1: Query current state                                             │
  │  ┌────────────────────────────────────────────────────────────────────┐  │
  │  │  $ openspec status --change "add-auth" --json                      │  │
  │  │                                                                    │  │
  │  │  {                                                                 │  │
  │  │    "artifacts": [                                                  │  │
  │  │      {"id": "proposal", "status": "done"},                         │  │
  │  │      {"id": "specs", "status": "ready"},      ◄── First ready      │  │
  │  │      {"id": "design", "status": "ready"},                          │  │
  │  │      {"id": "tasks", "status": "blocked",                          │  │
  │  │       "missingDeps": ["specs", "design"]}                          │  │
  │  │    ]                                                               │  │
  │  │  }                                                                 │  │
  │  └────────────────────────────────────────────────────────────────────┘  │
  │                                                                          │
  │  Step 2: Get rich instructions for ready artifact                        │
  │  ┌────────────────────────────────────────────────────────────────────┐  │
  │  │  $ openspec instructions specs --change "add-auth" --json          │  │
  │  │                                                                    │  │
  │  │  {                                                                 │  │
  │  │    "template": "# Specification\n\n## ADDED Requirements...",      │  │
  │  │    "dependencies": [{"id": "proposal", "path": "...", "done": true}│  │
  │  │    "unlocks": ["tasks"]                                            │  │
  │  │  }                                                                 │  │
  │  └────────────────────────────────────────────────────────────────────┘  │
  │                                                                          │
  │  Step 3: Read dependencies → Create ONE artifact → Show what's unlocked  │
  └──────────────────────────────────────────────────────────────────────────┘

반복 모델

기존 워크플로우 — 반복이 어색합니다:

  ┌─────────┐     ┌─────────┐     ┌─────────┐
  │/proposal│ ──► │ /apply  │ ──► │/archive │
  └─────────┘     └─────────┘     └─────────┘
       │               │
       │               ├── "Wait, the design is wrong"
       │               │
       │               ├── Options:
       │               │   • Edit files manually (breaks context)
       │               │   • Abandon and start over
       │               │   • Push through and fix later
       │               │
       │               └── No official "go back" mechanism
       │
       └── Creates ALL artifacts at once

OPSX — 자연스러운 반복:

  /opsx:new ───► /opsx:continue ───► /opsx:apply ───► /opsx:archive
      │                │                  │
      │                │                  ├── "The design is wrong"
      │                │                  │
      │                │                  ▼
      │                │            Just edit design.md
      │                │            and continue!
      │                │                  │
      │                │                  ▼
      │                │         /opsx:apply picks up
      │                │         where you left off
      │                │
      │                └── Creates ONE artifact, shows what's unlocked
      │
      └── Scaffolds change, waits for direction

사용자 정의 스키마

스키마 관리 명령을 사용하여 사용자 정의 워크플로우를 생성합니다:

# Create a new schema from scratch (interactive)
openspec schema init my-workflow

# Or fork an existing schema as a starting point
openspec schema fork spec-driven my-workflow

# Validate your schema structure
openspec schema validate my-workflow

# See where a schema resolves from (useful for debugging)
openspec schema which my-workflow

스키마는 openspec/schemas/ (프로젝트 로컬, 버전 관리됨) 또는 ~/.local/share/openspec/schemas/ (사용자 전역)에 저장됩니다.

스키마 구조:

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

예제 schema.yaml:

name: research-first
artifacts:
  - id: research        # Added before proposal
    generates: research.md
    requires: []

  - id: proposal
    generates: proposal.md
    requires: [research]  # Now depends on research

  - id: tasks
    generates: tasks.md
    requires: [proposal]

의존성 그래프:

   research ──► proposal ──► tasks

요약

항목	기존 워크플로우	OPSX
템플릿	하드코딩된 TypeScript	외부 YAML + Markdown
의존성	없음 (일괄 생성)	위상 정렬을 사용하는 DAG
상태	단계 기반 정신 모델	파일시스템 존재 여부
사용자 정의	소스 수정 후 재빌드	schema.yaml 생성
반복	단계 고정	유연, 무엇이든 수정 가능
에디터 지원	도구별 구성기/어댑터	단일 스킬 디렉터리

스키마

스키마는 존재하는 아티팩트와 그 종속성을 정의합니다. 현재 사용 가능한 것들:

• spec-driven (기본값): proposal → specs → design → tasks

# 사용 가능한 스키마 나열
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에 이슈를 열어주세요.