# 6. 슬래시 명령어 레퍼런스 ← [[openspec-05-core-workflows|5. 핵심 워크플로우]] | 다음 → [[openspec-07-cli-commands-reference|7. CLI 명령어 레퍼런스]] --- > [!info] 슬래시 명령어는 AI 코딩 어시스턴트의 채팅 인터페이스에서 호출한다. ## 도구별 명령어 문법 AI 도구마다 슬래시 명령어 호출 문법이 다르다. | 도구 | 문법 | 예시 | |------|------|------| | Claude Code | `/opsx:propose` | `/opsx:propose add-dark-mode` | | Cursor | `/opsx-propose` | `/opsx-propose add-dark-mode` | | Windsurf | `/opsx-propose` | `/opsx-propose add-dark-mode` | | GitHub Copilot | `/opsx-propose` | `/opsx-propose add-dark-mode` | | Continue | `/opsx-propose` | `/opsx-propose add-dark-mode` | | Kimi CLI | `/skill:openspec-propose` | `/skill:openspec-propose add-dark-mode` | | Kiro | `/opsx-propose` | `/opsx-propose add-dark-mode` | | Trae | `/openspec-propose` | `/openspec-apply-change` (명령어 파일 미생성) | | ForgeCode | 스킬 기반 | `/openspec-*` 스킬 직접 호출 (명령어 파일 미생성) | > [!note] 이 가이드의 표기 기준 > 이후 모든 예시는 **Claude Code** 문법(`/opsx:`)을 기준으로 작성한다. 다른 도구 사용 시 위 표를 참고해 문법을 변환한다. > [!warning] GitHub Copilot CLI 미지원 > `.github/prompts/*.prompt.md` 명령어 파일은 VS Code, JetBrains, Visual Studio **IDE 확장에서만** 동작한다. GitHub Copilot CLI는 커스텀 프롬프트 파일을 지원하지 않는다. --- ## 6.1 Core 프로필 명령어 ### `/opsx:propose` **목적:** 변경사항과 모든 계획 아티팩트를 한 번에 생성한다. ``` /opsx:propose [변경명 또는 설명] ``` **예시:** ``` /opsx:propose add-dark-mode /opsx:propose fix-auth-token-expiry /opsx:propose 사용자 프로필 이미지 업로드 기능 /opsx:propose ← 이름 없이 실행 시 AI가 대화로 파악 ``` > [!tip] 공백이 포함된 설명을 인자로 넘길 때 > 도구에 따라 따옴표 없이도 동작하지만, 명확성을 위해 `kebab-case` 변경명을 권장한다. 예: `/opsx:propose add-user-avatar` (공백 없이) **생성 파일:** - `openspec/changes/{변경명}/proposal.md` - `openspec/changes/{변경명}/specs/*.md` - `openspec/changes/{변경명}/design.md` - `openspec/changes/{변경명}/tasks.md` > [!warning] > 생성된 아티팩트를 반드시 검토하고 수정한 뒤 구현으로 넘어갈 것. --- ### `/opsx:explore` **목적:** 코드베이스를 조사하고 아이디어를 탐색하되, 아무 파일도 생성하지 않는다. ``` /opsx:explore [주제] ``` **예시:** ``` /opsx:explore 인증 시스템 리팩터링 옵션 /opsx:explore 결제 모듈 성능 병목 원인 /opsx:explore 현재 API 설계의 문제점 ``` > [!tip] 언제 사용하나 > - 요구사항이 아직 모호할 때 > - 여러 구현 방법을 비교하고 싶을 때 > - 코드베이스를 처음 파악할 때 > - propose 전 범위를 명확히 하고 싶을 때 --- ### `/opsx:apply` **목적:** `tasks.md`의 체크리스트를 순회하며 코드를 작성한다. ``` /opsx:apply [변경명] ``` **동작 방식:** 1. 해당 변경의 `tasks.md`를 읽음 2. 미완료(`- [ ]`) 태스크를 순서대로 처리 3. 각 태스크 완료 시 `- [x]`로 표시 > [!tip] apply 전 새 대화를 시작하라 > 긴 탐색 대화가 구현 단계에 혼선을 줄 수 있다. `/opsx:apply` 전 새 AI 대화 창을 열어 컨텍스트를 정리하는 것을 권장한다. --- ### `/opsx:sync` **목적:** 변경사항의 Delta Specs를 메인 스펙(`openspec/specs/`)에 병합한다. ``` /opsx:sync [변경명] ``` > [!note] > `/opsx:archive`가 자동으로 sync 여부를 확인하므로, 직접 호출은 선택사항이다. **수동으로 sync를 호출해야 하는 시기:** | 시나리오 | sync 필요 여부 | |----------|--------------| | 장기 변경 중, 아카이브 전에 메인 스펙에 반영하고 싶을 때 | Yes | | 병렬 변경사항이 업데이트된 기본 스펙을 필요로 할 때 | Yes | | 병합을 미리 검토하고 싶을 때 | Yes | | 빠른 변경, 바로 archive로 진행할 때 | No (archive가 자동 처리) | --- ### `/opsx:archive` **목적:** 변경사항을 최종 완료 처리하고 아카이브로 이동한다. ``` /opsx:archive [변경명] ``` **동작 순서:** 1. 아티팩트 존재 확인 2. 스펙 동기화 여부 확인 (필요시 자동 sync) 3. `openspec/changes/archive/{날짜}-{변경명}/`으로 이동 --- ## 6.2 확장 프로필 명령어 > [!info] 활성화 필요 > `openspec config profile`로 활성화 후 사용한다. ### `/opsx:new` **목적:** 아티팩트 없이 변경 폴더 스캐폴드만 생성한다. ``` /opsx:new [변경명] [--schema <스키마명>] ``` | 명령어 | 동작 | |--------|------| | `propose` | 폴더 생성 + 모든 아티팩트 즉시 생성 | | `new` | 폴더 생성만 (이후 `continue`나 `ff`로 아티팩트 생성) | --- ### `/opsx:continue` **목적:** 의존성 그래프(DAG)에서 다음 준비된 아티팩트를 하나 생성한다. ``` /opsx:continue [변경명] ``` **반복 호출 예시:** ``` /opsx:continue add-dark-mode ← proposal.md 생성 /opsx:continue add-dark-mode ← specs/ 생성 /opsx:continue add-dark-mode ← design.md 생성 /opsx:continue add-dark-mode ← tasks.md 생성 ``` | 상황 | 선택 | |------|------| | 각 단계 검토 원함 | `continue` (반복 호출) | | 일괄 생성 원함 | `ff` | | 시간 압박 | `ff` | | 복잡한 변경, 세밀한 제어 | `continue` | --- ### `/opsx:ff` **목적:** 모든 계획 아티팩트를 의존성 순서에 따라 한 번에 생성한다. (`propose`와 유사하나 기존 폴더에 사용) ``` /opsx:ff [변경명] ``` --- ### `/opsx:verify` **목적:** 구현이 아티팩트와 일치하는지 완성도·정확성·일관성 3가지 차원으로 검증한다. ``` /opsx:verify [변경명] ``` 검증 결과는 `CRITICAL` / `WARNING` / `SUGGESTION` 세 수준으로 보고된다. **출력 예시:** ``` COMPLETENESS ✓ tasks.md의 모든 8개 항목 완료 ✓ 스펙의 모든 요구사항에 대응 코드 존재 ⚠ "시스템 환경설정 감지" 시나리오에 테스트 없음 CORRECTNESS ✓ 구현이 스펙 의도에 부합 ✓ 엣지 케이스 처리됨 COHERENCE ✓ 설계 결정이 코드 구조에 반영됨 ⚠ design.md에는 "CSS 변수" 명시, 구현은 Tailwind 클래스 사용 SUMMARY Critical issues: 0 / Warnings: 2 Ready to archive: Yes (경고와 함께) ``` > [!note] > 경고(Warning)가 있어도 아카이브는 가능하다. 다만 경고 내용을 검토 후 판단한다. --- ### `/opsx:bulk-archive` **목적:** 여러 완료된 변경사항을 한 번에 아카이브한다. ``` /opsx:bulk-archive [변경명1] [변경명2] ... ``` **예시:** ``` /opsx:bulk-archive add-dark-mode fix-login-bug update-api-docs ``` > [!note] > 동일 영역의 스펙 충돌을 자동으로 감지하고 해결 방법을 제안한다. --- ### `/opsx:onboard` **목적:** 실제 코드베이스를 사용한 대화형 튜토리얼. 전체 워크플로우를 처음부터 끝까지 단계별로 안내한다. ``` /opsx:onboard ``` **진행 단계:** 1. 환영 및 코드베이스 분석 2. 개선 기회 발굴 3. 변경 생성 (`/opsx:new`) 4. proposal 작성 5. specs 작성 6. design 작성 7. tasks 작성 8. 태스크 구현 (`/opsx:apply`) 9. 구현 검증 10. 변경 아카이브 11. 요약 및 다음 단계 안내 > [!success] 처음 OpenSpec을 사용하는 팀이라면 이 명령어부터 시작하는 것을 강력 권장한다. 실제 코드로 작업하며 15~30분 내에 전체 흐름을 익힐 수 있다. --- ## 6.3 레거시 명령어 호환성 구버전(`/openspec:*`) 명령어는 여전히 동작하지만 OPSX 명령어로 전환을 권장한다. | 레거시 명령어 | OPSX 동등 명령어 | |-------------|----------------| | `/openspec:proposal` | `/opsx:propose` 또는 `/opsx:new` + `/opsx:ff` | | `/openspec:apply` | `/opsx:apply` | | `/openspec:archive` | `/opsx:archive` | > [!note] > 레거시 변경사항은 OPSX 명령어로 그대로 이어받을 수 있다. 아티팩트 구조가 호환된다. --- ← [[openspec-05-core-workflows|5. 핵심 워크플로우]] | 다음 → [[openspec-07-cli-commands-reference|7. CLI 명령어 레퍼런스]]