OPSX로 마이그레이션

이 가이드는 기존 OpenSpec 워크플로에서 OPSX로 전환하는 방법을 안내합니다. 마이그레이션은 원활하게 설계되어 있으며, 기존 작업은 보존되고 새로운 시스템은 더 많은 유연성을 제공합니다.

무엇이 변경되나요?

OPSX는 기존 단계 고정 워크플로를 유연한 액션 기반 접근 방식으로 대체합니다. 핵심 변화는 다음과 같습니다:

항목	기존(Legacy)	OPSX
명령어	`/openspec:proposal`, `/openspec:apply`, `/openspec:archive`	기본: `/opsx:propose`, `/opsx:explore`, `/opsx:apply`, `/opsx:update`, `/opsx:sync`, `/opsx:archive` (확장 워크플로 명령어 선택 가능)
워크플로	모든 산출물을 한 번에 생성	점진적으로 생성하거나 한 번에 생성—사용자 선택
되돌리기	어색한 단계 게이트	자연스러움—언제든 모든 산출물 업데이트 가능
커스터마이징	고정된 구조	스키마 기반, 완전한 해킹 가능
설정	마커 포함 `CLAUDE.md` + `project.md`	`openspec/config.yaml`에 깔끔한 설정

철학의 변화: 작업은 선형적이지 않습니다. OPSX는 더 이상 그렇지 않은 척하지 않습니다.

시작하기 전에

기존 작업물은 안전합니다

마이그레이션 프로세스는 보존을 염두에 두고 설계되었습니다:

openspec/changes/의 활성 변경사항 — 완전히 보존됩니다. OPSX 명령으로 계속 작업할 수 있습니다.
보관된 변경사항 — 그대로 유지됩니다. 기록은 그대로 남아 있습니다.
openspec/specs/의 주요 스펙 — 그대로 유지됩니다. 이는 신뢰할 수 있는 소스입니다.
CLAUDE.md, AGENTS.md 등의 콘텐츠 — 보존됩니다. OpenSpec 마커 블록만 제거되며, 작성한 내용은 모두 유지됩니다.

제거되는 항목

교체되는 OpenSpec 관리 파일만 제거됩니다:

항목	이유
레거시 슬래시 명령 디렉터리/파일	새 스킬 시스템으로 교체됨
`openspec/AGENTS.md`	더 이상 사용되지 않는 워크플로 트리거
`CLAUDE.md`, `AGENTS.md` 등의 OpenSpec 마커	더 이상 필요 없음

도구별 레거시 명령 위치 (예시 — 도구에 따라 다를 수 있음):

Claude Code: .claude/commands/openspec/
Cursor: .cursor/commands/openspec-*.md
Devin Desktop(구 Windsurf): .windsurf/workflows/openspec-*.md
Cline: .clinerules/workflows/openspec-*.md
Roo: .roo/commands/openspec-*.md
GitHub Copilot: .github/prompts/openspec-*.prompt.md (IDE 확장 전용, Copilot CLI에서는 지원되지 않음)
Codex: OpenSpec은 이제 표준 경로인 .agents/skills/openspec-*를 사용합니다. 이전 .codex/skills 경로 아래의 OpenSpec 관리 SKILL.md 파일은 교체 파일이 생성된 후에만 정리됩니다. 사용자 지정 파일과 분기된 복사본은 그대로 유지됩니다. 마커 없는 .agents 트리에 이미 OpenSpec 스킬이 포함된 경우, OpenSpec은 레거시 디렉터리에서 추측하는 대신 기존 Codex($openspec-*) 또는 범용(/openspec-*) 렌더링을 보존합니다. 소유권을 전환하려면 openspec init에서 codex를 명시적으로 선택하세요. 레거시 프롬프트 정리는 여전히 $CODEX_HOME/prompts 또는 ~/.codex/prompts의 OpenSpec 허용 목록 파일 이름만 대상으로 합니다.
기타 도구(Augment, Continue, Amazon Q 등)

마이그레이션은 구성된 도구를 감지하여 해당 레거시 파일을 정리합니다.

제거 목록이 길어 보일 수 있지만, 이는 모두 OpenSpec이 원래 생성한 파일입니다. 사용자의 콘텐츠는 절대 삭제되지 않습니다.

직접 확인이 필요한 항목

수동 마이그레이션이 필요한 파일이 하나 있습니다:

openspec/project.md — 이 파일은 직접 작성한 프로젝트 컨텍스트가 포함되어 있을 수 있으므로 자동으로 삭제되지 않습니다. 다음 단계를 수행해야 합니다:

내용 검토
유용한 컨텍스트를 openspec/config.yaml로 이동(아래 지침 참조)
준비가 되면 파일 삭제

변경 이유:

기존 project.md는 수동적이었습니다 — 에이전트가 읽을 수도, 읽지 않을 수도, 읽은 내용을 잊어버릴 수도 있었습니다. 신뢰성이 일관되지 않다는 것을 발견했습니다.

새로운 config.yaml 컨텍스트는 모든 OpenSpec 계획 요청에 적극적으로 주입됩니다. 즉, AI가 산출물을 생성할 때 프로젝트 규칙, 기술 스택, 가이드라인이 항상 포함됩니다. 신뢰성이 더 높아집니다.

절충점:

컨텍스트가 모든 요청에 주입되므로 간결하게 작성해야 합니다. 정말 중요한 것에 집중하세요:

기술 스택 및 주요 규칙
AI가 알아야 하는 명확하지 않은 제약 조건
이전에 자주 무시되었던 규칙

완벽하게 작성할 필요는 없습니다. 우리는 여전히 가장 효과적인 방법을 배우는 중이며, 컨텍스트 주입 방식을 실험하면서 개선해 나갈 것입니다.

마이그레이션 실행

openspec init와 openspec update 모두 레거시 파일을 감지하고 동일한 정리 프로세스를 안내합니다. 상황에 맞는 도구를 사용하세요:

새 설치의 기본 프로필은 core(propose, explore, apply, update, sync, archive)입니다.
마이그레이션된 설치는 필요 시 custom 프로필을 작성하여 기존에 설치된 워크플로를 보존합니다.

`openspec init` 사용

새 도구를 추가하거나 설정된 도구를 재구성하려면 다음을 실행하세요:

bash

openspec init

init 명령은 레거시 파일을 감지하고 정리 과정을 안내합니다:

새 OpenSpec으로 업그레이드

OpenSpec은 이제 코딩 에이전트 전반의 표준으로 자리 잡은
에이전트 스킬을 사용합니다. 이는 설정을 간소화하면서도
모든 것이 이전처럼 작동하도록 보장합니다.

제거할 파일
보존할 사용자 콘텐츠 없음:
  • .claude/commands/openspec/
  • openspec/AGENTS.md

업데이트할 파일
OpenSpec 마커는 제거되고 콘텐츠는 보존됩니다:
  • CLAUDE.md
  • AGENTS.md

주의 필요
  • openspec/project.md
    이 파일은 삭제하지 않습니다. 유용한 프로젝트 컨텍스트가 포함되어 있을 수 있습니다.

    새로운 openspec/config.yaml에는 계획 컨텍스트를 위한 "context:" 섹션이 있습니다.
    이는 모든 OpenSpec 요청에 포함되며 기존 project.md 방식보다
    더 안정적으로 작동합니다.

    project.md를 검토하고 유용한 콘텐츠를 config.yaml의 context 섹션으로
    이동한 후 파일을 삭제하세요.

? 업그레이드하고 레거시 파일을 정리하시겠습니까? (Y/n)

예라고 응답하면 발생하는 작업:

레거시 슬래시 명령 디렉터리가 제거됩니다
CLAUDE.md, AGENTS.md 등에서 OpenSpec 마커가 제거됩니다(콘텐츠는 유지)
openspec/AGENTS.md가 삭제됩니다
새 스킬이 .claude/skills/에 설치됩니다
기본 스키마로 openspec/config.yaml이 생성됩니다

`openspec update` 사용

기존 도구를 최신 버전으로 마이그레이션하고 새로고침하려면 다음을 실행하세요:

bash

openspec update

update 명령도 레거시 아티팩트를 감지하고 정리한 후, 현재 프로필 및 전달 설정에 맞게 생성된 스킬/명령을 새로고침합니다.

비대화형 / CI 환경

스크립트 기반 마이그레이션용:

bash

openspec init --force --tools claude

--force 플래그는 프롬프트를 건너뛰고 정리를 자동으로 수락합니다.

여기에는 전역 Codex 프롬프트 디렉터리의 OpenSpec 관리 Codex 프롬프트 파일 정리도 포함됩니다. 정리는 OpenSpec의 허용 목록에 있는 레거시 Codex 프롬프트 파일 이름만 대상으로 하며, 교체용 .agents/skills/openspec-* 스킬이 존재한 후에만 제거하고 다른 모든 파일은 보존합니다.

project.md를 config.yaml로 마이그레이션

기존 openspec/project.md는 프로젝트 컨텍스트를 위한 자유 형식 마크다운 파일이었습니다. 새로운 openspec/config.yaml은 구조화되어 있으며, 중요한 점은 모든 계획 요청에 주입되어 AI가 작업할 때 규칙이 항상 포함된다는 것입니다.

이전 (project.md)

markdown

# 프로젝트 컨텍스트

TypeScript 모노레포이며 React와 Node.js를 사용합니다.
테스트는 Jest를 사용하고 엄격한 ESLint 규칙을 따릅니다.
API는 RESTful이며 docs/api.md에 문서화되어 있습니다.

## 규칙

- 모든 공개 API는 하위 호환성을 유지해야 합니다
- 새 기능에는 테스트가 포함되어야 합니다
- 스펙에는 Given/When/Then 형식을 사용합니다

이후 (config.yaml)

yaml

schema: spec-driven

context: |
  기술 스택: TypeScript, React, Node.js
  테스트: React Testing Library와 함께 Jest 사용
  API: RESTful, docs/api.md에 문서화
  모든 공개 API의 하위 호환성 유지

rules:
  proposal:
    - 위험한 변경에는 롤백 계획 포함
  specs:
    - 시나리오에 Given/When/Then 형식 사용
    - 새 패턴을 만들기 전에 기존 패턴 참조
  design:
    - 복잡한 흐름에는 시퀀스 다이어그램 포함

주요 차이점

project.md	config.yaml
자유 형식 마크다운	구조화된 YAML
하나의 텍스트 블록	별도의 컨텍스트 및 산출물별 규칙
사용 시점이 불명확	컨텍스트는 모든 산출물에 포함, 규칙은 해당 산출물에만 포함
스키마 선택 없음	명시적 `schema:` 필드가 기본 워크플로 설정

유지할 항목, 제거할 항목

마이그레이션할 때는 선택적으로 접근하세요. 스스로에게 물어보세요: "AI가 모든 계획 요청에서 이 정보가 필요한가?"

context:에 적합한 항목

기술 스택(언어, 프레임워크, 데이터베이스)
주요 아키텍처 패턴(모노레포, 마이크로서비스 등)
명확하지 않은 제약 조건("라이브러리 X를 사용할 수 없는 이유...")
자주 무시되는 중요한 규칙

대신 rules:로 이동할 항목

산출물별 형식("스펙에 Given/When/Then 사용")
검토 기준("제안에는 롤백 계획이 포함되어야 함")
이는 해당 산출물에만 표시되므로 다른 요청은 더 가볍게 유지됩니다

완전히 제외할 항목

AI가 이미 알고 있는 일반적인 모범 사례
요약할 수 있는 장황한 설명
현재 작업에 영향을 주지 않는 과거 컨텍스트

마이그레이션 단계

config.yaml 생성 (init에서 이미 생성하지 않은 경우):
yaml
```
schema: spec-driven
```

컨텍스트 추가 (간결하게 — 모든 요청에 포함됩니다):

yaml

context: |
  프로젝트 배경이 여기에 들어갑니다.
  AI가 실제로 알아야 할 내용에 집중하세요.

산출물별 규칙 추가 (선택 사항):

yaml

rules:
  proposal:
    - 제안별 지침
  specs:
    - 스펙 작성 규칙

유용한 내용을 모두 옮긴 후 project.md 삭제

과도하게 고민하지 마세요. 핵심부터 시작하고 반복적으로 개선하세요. AI가 중요한 것을 놓치는 것을 발견하면 추가하세요. 컨텍스트가 비대해지면 줄이세요. 이는 살아있는 문서입니다.

도움이 필요하세요? 이 프롬프트를 사용하세요

project.md를 요약하는 방법이 확실하지 않다면 AI 어시스턴트에게 요청하세요:

OpenSpec의 기존 project.md에서 새 config.yaml 형식으로 마이그레이션 중입니다.

현재 project.md는 다음과 같습니다:
[project.md 내용 붙여넣기]

다음 항목이 포함된 config.yaml 작성을 도와주세요:
1. 간결한 `context:` 섹션 (모든 계획 요청에 주입되므로 간결하게 유지 — 기술 스택, 주요 제약 조건,
   자주 무시되는 규칙에 집중)
2. 콘텐츠가 산출물별 특성을 가진 경우 `rules:` (예: "Given/When/Then 사용"은 전역 컨텍스트가 아닌
   스펙 규칙에 속함)

AI 모델이 이미 알고 있는 일반적인 내용은 제외하세요. 간결함을 우선시하세요.

AI가 필수 항목과 생략 가능한 항목을 식별하는 데 도움을 줄 것입니다.

새 명령

명령 가용성은 프로필에 따라 다릅니다:

기본 (core 프로필):

명령	용도
`/opsx:propose`	변경사항 생성과 계획 산출물 생성을 한 단계로 수행
`/opsx:explore`	구조 없이 아이디어 탐색
`/opsx:apply`	tasks.md의 작업 구현
`/opsx:update`	변경사항의 계획 산출물 수정 및 일관성 유지
`/opsx:sync`	델타 스펙을 메인 스펙으로 병합
`/opsx:archive`	변경사항 최종화 및 보관

확장 워크플로 (custom 선택):

명령	용도
`/opsx:new`	새 변경사항 스캐폴드 시작
`/opsx:continue`	다음 산출물 생성(한 번에 하나씩)
`/opsx:ff`	빠른 진행 — 계획 산출물을 한 번에 생성
`/opsx:verify`	구현이 스펙과 일치하는지 검증
`/opsx:bulk-archive`	여러 변경사항을 한 번에 보관
`/opsx:onboard`	안내형 종단 간 온보딩 워크플로

openspec config profile로 확장 명령을 활성화한 후 openspec update를 실행하세요.

레거시 명령 매핑

레거시	OPSX 동등 명령
`/openspec:proposal`	`/opsx:propose` (기본) 또는 `/opsx:new` 후 `/opsx:ff` (확장)
`/openspec:apply`	`/opsx:apply`
`/openspec:archive`	`/opsx:archive`

새 기능

이러한 기능은 확장 워크플로 명령 세트의 일부입니다.

세분화된 산출물 생성:

/opsx:continue

의존성에 따라 한 번에 하나씩 산출물을 생성합니다. 각 단계를 검토하고 싶을 때 사용하세요.

탐색 모드:

/opsx:explore

변경사항을 확정하기 전에 파트너와 함께 아이디어를 심층적으로 논의하세요.

새로운 아키텍처 이해하기

고정된 단계에서 유동적인 구조로

레거시 워크플로는 선형적인 진행을 강요했습니다:

┌──────────────┐      ┌──────────────┐      ┌──────────────┐
│   PLANNING   │ ───► │ IMPLEMENTING │ ───► │   ARCHIVING  │
│    PHASE     │      │    PHASE     │      │    PHASE     │
└──────────────┘      └──────────────┘      └──────────────┘

구현 단계에 있는데 설계를 잘못했음을 깨달았다면?
안타깝습니다. 페이즈 게이트(phase gates)는 쉽게 뒤로 돌아가게 허용하지 않습니다.

OPSX는 페이즈가 아닌 액션(actions)을 사용합니다:

         ┌───────────────────────────────────────────────┐
         │           ACTIONS (not phases)                │
         │                                               │
         │     new ◄──► continue ◄──► apply ◄──► archive │
         │      │          │           │             │   │
         │      └──────────┴───────────┴─────────────┘   │
         │                    any order                  │
         └───────────────────────────────────────────────┘

의존성 그래프

아티팩트들은 방향성 그래프를 형성합니다. 의존성은 게이트가 아니라 활성화 조건(enablers)입니다:

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

/opsx:continue를 실행하면 준비된 항목을 확인하고 다음 생성할 아티팩트를 제안합니다. 또한 여러 개의 준비된 아티팩트를 원하는 순서대로 생성할 수도 있습니다.

스킬(Skills) vs 명령어(Commands)

레거시 시스템은 도구별 명령어 파일을 사용했습니다:

.claude/commands/openspec/
├── proposal.md
├── apply.md
└── archive.md

OPSX는 부상하는 스킬(skills) 표준을 사용합니다:

.claude/skills/
├── openspec-explore/SKILL.md
├── openspec-new-change/SKILL.md
├── openspec-continue-change/SKILL.md
├── openspec-apply-change/SKILL.md
└── ...

스킬은 여러 AI 코딩 도구에서 인식되며 더 풍부한 메타데이터를 제공합니다.

Codex는 OPSX에서 스킬 전용으로 동작합니다. OpenSpec은 이제 Codex용 커스텀 프롬프트 파일을 생성하지 않으며, 대신 생성된 .agents/skills/openspec-* 디렉토리를 사용해야 합니다.

기존 변경 사항 계속하기

진행 중인 변경 사항은 OPSX 명령어와 원활하게 작동합니다.

레거시 워크플로우에서 활성 변경 사항을 보유하고 있나요?

/opsx:apply add-my-feature

OPSX는 기존 아티팩트를 읽고 중단했던 지점부터 이어서 작업합니다.

기존 변경 사항에 더 많은 아티팩트를 추가하고 싶으신가요?

/opsx:continue add-my-feature

이미 존재하는 것을 기반으로 생성할 준비가 된 항목을 표시합니다.

상태를 확인하고 싶으신가요?

bash

openspec status --change add-my-feature

새로운 구성 시스템

config.yaml 구조

yaml

# 필수: 새 변경 사항의 기본 스키마
schema: spec-driven

# 선택: 프로젝트 컨텍스트 (최대 50KB)
# 모든 아티팩트 지침에 주입됨
context: |
  프로젝트 배경, 기술 스택,
  관례 및 제약 사항 등.

# 선택: 아티팩트별 규칙
# 일치하는 아티팩트에만 주입됨
rules:
  proposal:
    - 롤백 계획 포함
  specs:
    - Given/When/Then 형식 사용
  design:
    - 대체 전략 문서화
  tasks:
    - 최대 2시간 단위로 분할

스키마 결정(Order of Resolution)

어떤 스키마를 사용할지 결정할 때 OPSX는 다음 순서로 확인합니다:

CLI 플래그: --schema <name> (가장 높은 우선순위)
변경 사항 메타데이터: 변경 사항 디렉토리의 .openspec.yaml
프로젝트 구성: openspec/config.yaml
기본값: spec-driven

사용 가능한 스키마

스키마	아티팩트	적합한 용도
`spec-driven`	proposal → specs → design → tasks	대부분의 프로젝트

사용 가능한 모든 스키마 목록 보기:

bash

openspec schemas

커스텀 스키마

자체 워크플로우 만들기:

bash

openspec schema init my-workflow

또는 기존 스키마 포크하기:

bash

openspec schema fork spec-driven my-workflow

자세한 내용은 Customization을 참조하십시오.

문제 해결

"비대화형 모드에서 레거시 파일 감지됨"

CI 또는 비대화형 환경에서 실행 중입니다. 다음을 사용하십시오:

bash

openspec init --force

마이그레이션 후 명령어가 표시되지 않음

IDE를 재시작하십시오. 스킬은 시작 시 감지됩니다.

"rules에 알 수 없는 아티팩트 ID"

rules: 키가 스키마의 아티팩트 ID와 일치하는지 확인하십시오:

spec-driven: proposal, specs, design, tasks

유효한 아티팩트 ID를 보려면 다음을 실행하십시오:

bash

openspec schemas --json

구성이 적용되지 않음

파일이 openspec/config.yaml에 있는지 확인하십시오 (.yml이 아님).
YAML 구문을 검증하십시오.
구성 변경은 즉시 적용되며 재시작이 필요하지 않습니다.

project.md 마이그레이션 안 됨

시스템은 사용자 정의 콘텐츠가 포함되어 있을 수 있으므로 project.md를 의도적으로 보존합니다. 수동으로 검토한 후 유용한 부분을 config.yaml로 이동하고 삭제하십시오.

정리될 내용을 미리 보고 싶으신가요?

init을 실행하고 정리(prompt)를 거부하면 아무런 변경 없이 전체 감지 요약을 볼 수 있습니다.

빠른 참조

마이그레이션 후 파일 구조

project/
├── openspec/
│   ├── specs/                    # 변경 없음
│   ├── changes/                  # 변경 없음
│   │   └── archive/              # 변경 없음
│   └── config.yaml               # NEW: 프로젝트 구성
├── .claude/
│   └── skills/                   # NEW: OPSX 스킬
│       ├── openspec-propose/     # 기본 핵심 프로필
│       ├── openspec-explore/
│       ├── openspec-apply-change/
│       ├── openspec-update-change/
│       ├── openspec-sync-specs/
│       ├── openspec-archive-change/
│       └── ...                   # 확장 프로필은 new/continue/ff 등을 추가
├── CLAUDE.md                     # OpenSpec 마커 제거됨, 사용자 콘텐츠 보존
└── AGENTS.md                     # OpenSpec 마커 제거됨, 사용자 콘텐츠 보존

제거된 항목

.claude/commands/openspec/ — .claude/skills/로 대체됨
openspec/AGENTS.md — obsolete(더 이상 사용되지 않음)
openspec/project.md — config.yaml로 마이그레이션 후 삭제
CLAUDE.md, AGENTS.md 등의 OpenSpec 마커 블록

명령어 치트시트

text

/opsx:propose      빠르게 시작 (기본 핵심 프로필)
/opsx:apply        작업 구현
/opsx:archive      완료 및 보관

# 확장 워크플로우 (활성화된 경우):
/opsx:new          변경 사항 구조화
/opsx:continue     다음 아티팩트 생성
/opsx:ff           계획 아티팩트 생성

도움 받기

Discord: discord.gg/YctCnvvshC
GitHub Issues: github.com/Fission-AI/OpenSpec/issues
문서: 전체 OPSX 참조는 docs/opsx.md를 참조하십시오

OPSX로 마이그레이션 ​

무엇이 변경되나요? ​

시작하기 전에 ​

기존 작업물은 안전합니다 ​

제거되는 항목 ​

직접 확인이 필요한 항목 ​

마이그레이션 실행 ​

openspec init 사용 ​

openspec update 사용 ​

비대화형 / CI 환경 ​

project.md를 config.yaml로 마이그레이션 ​

이전 (project.md) ​

이후 (config.yaml) ​

주요 차이점 ​

유지할 항목, 제거할 항목 ​

마이그레이션 단계 ​

도움이 필요하세요? 이 프롬프트를 사용하세요 ​

새 명령 ​

레거시 명령 매핑 ​

새 기능 ​

새로운 아키텍처 이해하기 ​

고정된 단계에서 유동적인 구조로 ​

의존성 그래프 ​

스킬(Skills) vs 명령어(Commands) ​

기존 변경 사항 계속하기 ​

새로운 구성 시스템 ​

config.yaml 구조 ​

스키마 결정(Order of Resolution) ​

사용 가능한 스키마 ​

커스텀 스키마 ​

문제 해결 ​

"비대화형 모드에서 레거시 파일 감지됨" ​

마이그레이션 후 명령어가 표시되지 않음 ​

"rules에 알 수 없는 아티팩트 ID" ​

구성이 적용되지 않음 ​

project.md 마이그레이션 안 됨 ​

정리될 내용을 미리 보고 싶으신가요? ​

빠른 참조 ​

마이그레이션 후 파일 구조 ​

제거된 항목 ​

명령어 치트시트 ​

도움 받기 ​

OPSX로 마이그레이션

무엇이 변경되나요?

시작하기 전에

기존 작업물은 안전합니다

제거되는 항목

직접 확인이 필요한 항목

마이그레이션 실행

`openspec init` 사용

`openspec update` 사용

비대화형 / CI 환경

project.md를 config.yaml로 마이그레이션

이전 (project.md)

이후 (config.yaml)

주요 차이점

유지할 항목, 제거할 항목

마이그레이션 단계

도움이 필요하세요? 이 프롬프트를 사용하세요

새 명령

레거시 명령 매핑

새 기능

새로운 아키텍처 이해하기

고정된 단계에서 유동적인 구조로

의존성 그래프

스킬(Skills) vs 명령어(Commands)

기존 변경 사항 계속하기

새로운 구성 시스템

config.yaml 구조

스키마 결정(Order of Resolution)

사용 가능한 스키마

커스텀 스키마

문제 해결

"비대화형 모드에서 레거시 파일 감지됨"

마이그레이션 후 명령어가 표시되지 않음

"rules에 알 수 없는 아티팩트 ID"

구성이 적용되지 않음

project.md 마이그레이션 안 됨

정리될 내용을 미리 보고 싶으신가요?

빠른 참조

마이그레이션 후 파일 구조

제거된 항목

명령어 치트시트

도움 받기