CLI 참조

OpenSpec CLI(openspec)는 프로젝트 설정, 검증, 상태 검사 및 관리를 위한 터미널 명령을 제공합니다. 이러한 명령은 Commands에 문서화된 AI 슬래시 명령(예: /opsx:propose)을 보완합니다.

요약

카테고리	명령	목적
설정	`init`, `update`	프로젝트에서 OpenSpec 초기화 및 업데이트
스토어(독립형 OpenSpec 저장소)	`store setup`, `store register`, `store unregister`, `store remove`, `store list`, `store doctor`	등록된 독립형 OpenSpec 저장소인 스토어 관리
건강 상태	`doctor`	해석된 루트의 관계 건강 상태 보고
작업 컨텍스트	`context`	작업 세트(루트 + 참조된 스토어) 조립
개인 작업 세트	`workset create`, `workset list`, `workset open`, `workset remove`	도구에서 개인 및 로컬 작업 뷰 유지 및 열기
탐색	`list`, `view`, `show`	변경 사항 및 스펙 탐색
검증	`validate`	변경 사항 및 스펙의 문제점 검사
라이프사이클	`archive`	완료된 변경 사항 최종 처리
워크플로	`new change`, `status`, `instructions`, `templates`, `schemas`	아티팩트 기반 워크플로 지원
스키마	`schema init`, `schema fork`, `schema validate`, `schema which`	사용자 정의 워크플로 생성 및 관리
설정	`config`	설정 표시 및 수정
유틸리티	`feedback`, `completion`	피드백 및 셸 통합

Human vs Agent Commands

대부분의 CLI 명령은 터미널에서 사람이 사용하도록 설계되었습니다. 일부 명령은 JSON 출력을 통해 에이전트/스크립트 사용도 지원합니다.

Human-Only Commands

이 명령들은 대화형이며 터미널 사용을 위해 설계되었습니다:

Command	Purpose
`openspec init`	프로젝트 초기화 (대화형 프롬프트)
`openspec view`	대화형 대시보드
`openspec workset open <name>`	저장된 워크셋 열기 (에디터 창 또는 터미널 에이전트 세션)
`openspec config edit`	설정을 에디터에서 열기
`openspec feedback`	GitHub를 통해 피드백 제출
`openspec completion install`	셸 자동완성 설치

Agent-Compatible Commands

이 명령들은 AI 에이전트와 스크립트가 프로그래매틱하게 사용할 수 있도록 --json 출력을 지원합니다:

Command	Human Use	Agent Use
`openspec list`	변경사항/스펙 탐색	`--json`으로 구조화된 데이터
`openspec show <item>`	콘텐츠 읽기	`--json`으로 파싱
`openspec validate`	문제점 확인	`--all --json`으로 일괄 검증
`openspec status`	아티팩트 진행 상황 확인	`--json`으로 구조화된 상태
`openspec instructions`	다음 단계 확인	`--json`으로 에이전트 지침
`openspec templates`	템플릿 경로 찾기	`--json`으로 경로 해석
`openspec schemas`	사용 가능한 스키마 목록	`--json`으로 스키마 탐색; `--store <id>`로 등록된 루트 선택
`openspec store setup <id>`	로컬 스토어 생성 및 등록	`--json`과 명시적 입력으로 구조화된 설정 출력
`openspec store register <path>`	기존 스토어 등록	`--json`으로 구조화된 등록 출력
`openspec store unregister <id>`	로컬 스토어 등록 해제	`--json`으로 구조화된 정리 출력
`openspec store remove <id>`	등록된 로컬 스토어 폴더 삭제	`--yes --json`으로 비대화형 삭제
`openspec store list`	등록된 스토어 탐색	`--json`으로 구조화된 등록 정보
`openspec store doctor`	로컬 스토어 설정 확인	`--json`으로 구조화된 진단
`openspec new change <id>`	저장소 로컬 변경 스캐폴딩 생성	`--json`, `--store <id>`로 등록된 스토어를 OpenSpec 루트로 사용
`openspec workset create [name]`	개인 작업 뷰 구성	`--member <path> --json`으로 비대화형 구성
`openspec workset list`	저장된 워크셋 탐색	`--json`으로 구조화된 뷰
`openspec workset remove <name>`	저장된 뷰 삭제	`--yes --json`으로 비대화형 삭제

Global Options

이 옵션들은 모든 명령과 함께 작동합니다:

Option	Description
`--version`, `-V`	버전 번호 표시
`--no-color`	색상 출력 비활성화
`--help`, `-h`	명령 도움말 표시

Setup Commands

`openspec init`

프로젝트에 OpenSpec를 초기화합니다. 폴더 구조를 생성하고 AI 도구 통합을 구성합니다.

기본 동작은 전역 설정 기본값을 사용합니다: 프로필 core, 전달 방식 both, 워크플로 propose, explore, apply, update, sync, archive.

openspec init [path] [options]

--language <language>를 사용하여 새 프로젝트의 openspec/config.yaml에 언어 지시를 추가합니다. 기존 프로젝트의 경우 설정의 context 필드를 편집하여 OpenSpec가 프로젝트별 지침을 덮어쓰지 않도록 합니다.

Arguments:

Argument	Required	Description
`path`	No	대상 디렉터리 (기본값: 현재 디렉터리)

Options:

Option	Description
`--tools <list>`	AI 도구를 비대화형으로 구성합니다. `all`, `none`, 또는 쉼표로 구분된 목록 사용
`--language <language>`	새 설정을 생성할 때 이 언어로 아티팩트 작성
`--force`	프롬프트 없이 레거시 파일 자동 정리
`--profile <profile>`	이 초기화 실행에 대해 전역 프로필 재정의 (`core` 또는 `custom`)
`--no-animation`	애니메이션 대신 정적 환영 화면 표시
`--copilot-cloud`	프롬프트 없이 GitHub Copilot cloud coding-agent 파일 설정
`--no-copilot-cloud`	프롬프트 없이 GitHub Copilot cloud coding-agent 파일 건너뛰기

--profile custom은 전역 설정(openspec config profile)에서 현재 선택된 워크플로를 사용합니다.

환영 애니메이션은 OPENSPEC_NO_ANIMATION 환경 변수가 설정된 경우(빈 값 포함, 모든 값), NO_COLOR가 비어 있지 않은 값으로 설정된 경우, 또는 OS의 모션 감소 설정이 활성화된 경우(macOS Reduce Motion, GNOME 애니메이션 비활성화)에도 건너뜁니다.

Supported tool IDs (--tools) — windsurf도 devin의 별칭으로 허용됩니다: amazon-q, antigravity, auggie, bob, claude, cline, command-code, codeartsagent, codex, devin, forgecode, codebuddy, continue, costrict, crush, cursor, factory, gemini, github-copilot, hermes, iflow, junie, kilocode, kimi, kiro, lingma, minimax-code, vibe, oh-my-pi, opencode, pi, codeassistant, qoder, qwen, rovodev, roocode, trae, zed, zcode, agents

이 목록은 src/core/config.ts의 AI_TOOLS를 반영합니다. 각 도구의 스킬 및 명령 경로는 Supported Tools를 참조하세요.

Examples:

bash

# Interactive initialization
openspec init

# Initialize in a specific directory
openspec init ./my-project

# Non-interactive: configure for Claude and Cursor
openspec init --tools claude,cursor

# Non-interactive: configure global MiniMax Code skills
openspec init --tools minimax-code

# Configure for all supported tools
openspec init --tools all

# Override profile for this run
openspec init --profile core

# Skip prompts and auto-cleanup legacy files
openspec init --force

What it creates:

openspec/
├── specs/              # Your specifications (source of truth)
├── changes/            # Proposed changes
└── config.yaml         # Project configuration

.claude/skills/         # Claude Code skills (if claude selected)
.cursor/skills/         # Cursor skills (if cursor selected)
.cursor/commands/       # Cursor OPSX commands (if delivery includes commands)
.agents/skills/         # Shared skills for AGENTS.md-compatible tools (if agents selected)
... (other tool configs)

`openspec update`

CLI 업그레이드 후 OpenSpec 지침 파일을 업데이트합니다. 현재 전역 프로필, 선택된 워크플로, 전달 방식을 사용하여 AI 도구 구성 파일을 재생성합니다.

openspec update [path] [options]

Arguments:

Argument	Required	Description
`path`	No	대상 디렉터리 (기본값: 현재 디렉터리)

Options:

Option	Description
`--force`	파일이 최신 상태여도 강제 업데이트

Example:

bash

# Update instruction files after npm upgrade
npm install -g @fission-ai/openspec@latest
openspec update

먼저 패키지를 업그레이드하세요. 지침 파일은 설치된 CLI에 의해 생성되므로, 오래된 설치에 대해 openspec update를 실행하면 모든 것이 최신 상태라고 보고되며 새 릴리스에 포함된 워크플로가 추가되지 않습니다.

이를 가시화하기 위해 openspec update는 npm 레지스트리에 더 새로운 CLI가 게시되었는지 확인합니다. 사용 중인 버전이 뒤처져 있으면 업그레이드를 제안합니다:

text

A newer OpenSpec CLI is available (v1.6.0 → v1.7.0).
  Running from: /usr/local/lib/node_modules/@fission-ai/openspec
? Upgrade to v1.7.0 now? (Y/n)

예를 선택하면 npm install -g @fission-ai/openspec@latest를 실행한 후 새 CLI로 업데이트를 다시 실행하여 새 워크플로가 같은 명령에서 반영되도록 합니다. 업그레이드 확인은 npm의 종료 코드에 의존하지 않고 설치된 바이너리의 버전을 직접 조회하여 수행하므로, PATH에서 이전 위치에 다른 설치가 응답하고 있으면 성공을 주장하지 않고 알려줍니다. 아니오를 선택하면 명령을 출력하고 현재 CLI로 업데이트합니다. Ctrl-C로 명령을 중단할 수 있습니다.

이 제안은 대화형 터미널에서만 표시되며, npm이 설치를 소유한 경우에만 표시됩니다 — npm install -g가 실제로 수정할 수 있는 유일한 경우입니다. 그 외의 경우 설치 방식에 맞는 명령이 대신 표시됩니다:

How OpenSpec is installed	What you get
Global npm install	대화형 터미널에서 프롬프트와 업그레이드 실행 — 파이프 출력의 경우 출력된 명령 표시
Global pnpm, bun, yarn, or volta install	해당 매니저의 명령: `pnpm add -g …@latest`, `bun add -g …@latest`, `yarn global add …@latest`, 또는 `volta install …@latest`
A dependency of the project	패키지 매니저가 lockfile을 소유하므로 의존성 업데이트 안내
An `npx` / `dlx` cache	`npx @fission-ai/openspec@latest update` — 이 명령 자체가 업데이트이므로 추가 단계 없음
A git clone	없음 — 버전은 브랜치가 지정한 값

무엇이든 출력될 때 실행 중인 CLI가 로드된 디렉터리를 명시합니다 — 업그레이드를 했지만 오래된 shim이 여전히 PATH를 소유하고 있을 때 확인해야 할 대상입니다.

npm이 npm_config_registry를 내보내는 경우 해당 값으로 레지스트리에 문의하고, 그렇지 않으면 https://registry.npmjs.org를 사용합니다. .npmrc는 읽지 않습니다: 파일 내용으로 외부 요청의 대상이 결정되는 흐름은 피해야 하며, 프로젝트의 .npmrc는 저장소와 함께 이동하기 때문입니다. 사설 미러를 사용하는 경우 npm_config_registry를 내보내거나 OPENSPEC_NO_UPDATE_CHECK를 설정하여 확인을 완전히 건너뛸 수 있습니다. CI가 명시적 비활성 값(false, 0, no, off, 또는 빈 값)이 아닌 값으로 설정된 경우, NODE_ENV=test인 경우, OPENSPEC_NO_UPDATE_CHECK(모든 값), DO_NOT_TRACK=1, 또는 OPENSPEC_TELEMETRY=0이 설정된 경우에도 확인이 건너뜁니다. 업데이트 전에 실행되며 최대 1.5초까지 지연시킬 수 있습니다 — 네트워크가 패킷을 조용히 드롭하더라도 그 후 포기하며, 레지스트리에 도달할 수 없는 경우에도 조용히 넘어갑니다.

How "up to date" is decided: 스킬 파일은 생성된 버전을 기록하므로 OpenSpec는 이를 설치된 CLI와 비교합니다. 명령 파일에는 버전 스탬프가 없으므로 명령은 있지만 스킬은 없는 도구(전달 방식 commands)의 경우, OpenSpec는 파일 내용을 현재 생성할 내용과 비교합니다 — 해당 파일에 대한 편집은 드리프트로 간주되며 덮어쓰기됩니다. 전달 방식이 skills 또는 both인 경우, 기록된 버전만 확인되므로 버전이 여전히 일치하는 수동 편집 파일은 그대로 두며, --force를 사용하여 다시 작성할 수 있습니다. 어느 경우든 생성된 파일은 OpenSpec의 소유이므로, 자체 지침은 다른 곳에 보관하세요.

스토어(독립형 OpenSpec 저장소)

베타. 스토어와 이를 기반으로 구축된 기능(참조, 작업 컨텍스트, 작업셋)은 새로운 기능입니다. 명령 이름, 플래그, 파일 형식, JSON 출력은 릴리스 간에 변경될 수 있습니다. 문제 우선 워크스루는 스토어 가이드를 참조하세요.

스토어는 이 머신에 등록한 독립형 OpenSpec 저장소입니다. 예를 들어 계획 저장소 또는 계약 저장소가 이에 해당합니다. 스토어를 등록하면 --store <id>를 전달하여 어디서든 일반 명령(list, show, status, validate, new change, archive, ...)이 해당 스토어에서 작동할 수 있습니다.

`openspec store setup`

로컬 스토어를 생성하고 등록합니다. 터미널에서 인수 없이 실행하면 OpenSpec이 사용자를 안내하여 설정을 진행합니다. 에이전트와 스크립트는 명시적 입력을 전달하고 --json을 사용해야 합니다.

bash

openspec store setup [id] [options]

옵션:

옵션	설명
`--path <path>`	스토어가 위치할 폴더(예: `~/openspec/<id>`)
`--remote <url>`	새 스토어의 `store.yaml`에 정식 원격 저장소를 기록
`--init-git`	초기 커밋이 포함된 Git 저장소 초기화(기본값)
`--no-init-git`	모든 Git 작업 건너뛰기: 초기화 없음, 초기 커밋 없음
`--json`	JSON 출력

비대화형 실행(--json, 스크립트, 에이전트)은 스토어 ID와 --path를 모두 전달해야 합니다. 대화형 터미널에서는 설정이 사용자 소유의 보이는 위치(예: ~/openspec/<id>)에 편집 가능한 제안과 함께 위치를 묻습니다. OpenSpec의 관리형 데이터 디렉터리로 기본 설정되지 않습니다.

예시:

bash

openspec store setup
openspec store setup team-context
openspec store setup team-context --path ~/openspec/team-context --no-init-git
openspec store setup team-context --path ~/openspec/team-context --no-init-git --json

`openspec store register`

기존 로컬 스토어 폴더를 등록합니다. 스토어 베타 기간 동안 변경 사항, 적용된 스펙, 보관된 변경 사항이 존재하기 전에 루트가 등록될 수 있습니다. 이 경우 openspec/changes/, openspec/specs/, openspec/changes/archive/는 일반 명령이 생성할 때까지 없을 수 있습니다. store: <id>를 선언하는 구성 전용 저장소는 다른 스토어를 가리키는 포인터로 유지되며, 해당 포인터가 제거되지 않는 한 스토어 루트로 등록되지 않습니다.

bash

openspec store register [path] [options]

옵션:

옵션	설명
`--id <id>`	스토어 ID, 스토어 메타데이터 또는 폴더 이름을 기본값으로 사용
`--yes`	정상적인 OpenSpec 루트에 대한 스토어 ID 메타데이터 생성 확인
`--json`	JSON 출력

`openspec store unregister`

파일을 삭제하지 않고 로컬 스토어 등록을 잊습니다.

bash

openspec store unregister <id> [--json]

스토어가 이동되었거나 다른 곳으로 클론되었거나 더 이상 이 머신에서 OpenSpec에 표시되지 않아야 하는 경우에 사용합니다.

`openspec store remove`

로컬 스토어 등록을 잊고 로컬 폴더를 삭제합니다.

bash

openspec store remove <id> [--yes] [--json]

remove는 대화형 터미널에서 삭제 전에 정확한 폴더를 표시합니다. 에이전트, 스크립트, JSON 호출자는 삭제를 확인하려면 --yes를 전달해야 합니다. OpenSpec은 일치하는 스토어 메타데이터가 포함되지 않은 폴더 삭제를 거부합니다.

`openspec store list`

로컬에 등록된 스토어를 나열합니다.

bash

openspec store list [--json]
openspec store ls [--json]

`openspec store doctor`

로컬 스토어 등록, 메타데이터, Git 존재 여부를 확인합니다.

bash

openspec store doctor [id] [--json]

Doctor는 진단 전용입니다. 누락된 루트, 메타데이터 불일치, 잘못된 로컬 레지스트리 상태를 보고하지만 스토어를 수정하지 않습니다.

프로젝트에서 스토어 참조

프로젝트 저장소는 openspec/config.yaml에서 작업이 참조하는 스토어를 선언할 수 있습니다:

yaml

schema: spec-driven
references:
  - team-context

이후 해당 저장소의 openspec instructions 출력(아티팩트별 및 apply 표면 모두, JSON 및 사람이 읽는 모드)에는 참조된 각 스토어의 스펙 색인이 포함됩니다 — 스펙 ID, 각 스펙의 Purpose 섹션에서 가져온 한 줄 요약, 가져오기 명령(openspec show <spec-id> --type spec --store <id>)입니다. 색인은 실행할 때마다 등록된 체크아웃에서 실시간으로 생성됩니다. 스펙 콘텐츠는 출력에 복사되지 않습니다.

참조는 읽기 전용 컨텍스트입니다. 참조가 명령이 작동하는 위치를 변경하지 않습니다. 작업은 저장소 자체 루트에 유지되며, 참조된 스토어에 쓰는 것은 명시적 --store 작업으로만 가능합니다. 해결할 수 없는 참조(예: 이 머신에 등록되지 않은 스토어)는 정확한 수정 방법과 함께 색인에서 경고로 처리되며, instructions는 여전히 생성됩니다. openspec doctor는 참조 상태를 한곳에서 보고합니다.

스토어가 클론된 위치 기록

스토어는 커밋된 ID 파일에 정식 클론 소스를 기록할 수 있으므로, 온보딩이 "스토어 등록"에서 막히지 않습니다:

bash

openspec store setup team-context --path ~/openspec/team-context \
  --remote git@github.com:acme/team-context.git

원격 저장소는 초기 커밋 내부의 .openspec-store/store.yaml에 기록되므로 모든 클론은 이를 알고 시작합니다. 기존 스토어의 경우 store.yaml을 수동으로 편집하고 커밋합니다. store doctor는 기록된 원격 저장소(및 체크아웃에서 관찰된 Git origin)를 표시합니다. setup/register 공유 안내는 이를 명명하며, register는 체크아웃의 origin을 머신 로컬 레지스트리에 기록합니다.

참조 선언도 클론 소스를 포함할 수 있으므로, 아직 스토어가 없는 팀원이 완전하고 붙여넣기 가능한 수정 방법(git clone <remote> <path> && openspec store register <path> --id <id>)을 얻을 수 있습니다:

yaml

references:
  - { id: team-context, remote: "git@github.com:acme/team-context.git" }

원격 저장소 기록은 동기화가 아닙니다. OpenSpec은 자체적으로 클론, pull, push를 수행하지 않습니다.

기본 스토어 선언

계획이 완전히 외부화된 저장소(로컬 openspec/specs/ 또는 openspec/changes/ 없음)는 모든 명령에 --store를 전달하는 대신 스토어를 한 번 선언할 수 있습니다:

yaml

# openspec/config.yaml (openspec/ 아래의 유일한 파일)
store: team-context

그러면 일반 명령이 선언된 스토어로 자동 해석됩니다. 루트 배너와 JSON root 블록은 스토어 ID와 함께 source: "declared"를 보고하며, 출력된 힌트에는 여전히 --store <id>가 포함됩니다. 선언은 폴백이지 재정의가 아닙니다. 명시적 --store가 항상 우선하며, 실제 계획 폴더가 있는 디렉터리는 포인터를 무시합니다(경고 포함). 포인터 저장소를 로컬 OpenSpec 루트로 변환하려면 store: 줄을 제거하고 openspec init을 실행합니다 — init은 선언이 있는 동안 스캐폴딩을 거부합니다.

머신 수준 변형은 모든 저장소를 한 번에 포함합니다: openspec config set defaultStore <id>(Configuration 참조). 이는 --store, 로컬 루트, 프로젝트 포인터가 모두 해석에 실패한 후에만 참조됩니다. 루트 배너와 JSON root 블록은 그때 source: "global_default"를 보고합니다.

Doctor (관계 상태 확인)

단일 읽기 전용 질문, 단일 위치: OpenSpec 루트가 정상인지, 그리고 해당 루트가 참조하는 저장소들이 이 머신에서 사용 가능한지 확인합니다.

bash

openspec doctor [--store <id>] [--json]

보고서는 루트 상태, 저장소 메타데이터 상태(기록된 원격 저장소와 체크아웃의 원본이 갈라졌을 때 및 저장소 체크아웃이 마지막 가져온上游 추적 참조보다 뒤처졌을 때에 대한 참고 사항 포함), 그리고 참조 상태(해결되지 않은 참조에 대한 복제 수정 사항을 포함한 동일한 진단 지침 표시)로 구분됩니다. 모든 심각도의 상태 발견은 종료 코드 0으로 처리됩니다(에이전트는 status 배열을 읽음). 명령 실패(루트 없음, 알 수 없는 저장소 등)인 경우에만 종료 코드 1을 반환합니다. Doctor는 절대 복제(clone), 동기화(sync), 복구(repair) 작업을 수행하지 않습니다. 상태가 아닌 조립된 세트 자체를 얻으려면 openspec context를 사용하십시오.

작업 컨텍스트 (조립된 세트)

OpenSpec 선언을 통해 이 작업과 관련된 모든 것을 하나의 작업 세트로 구성: OpenSpec 루트와 해당 루트가 참조하는 저장소들.

bash

openspec context [--store <id>] [--json] [--code-workspace <path> [--force]]

JSON 요약은 에이전트가 소비할 수 있는 형태입니다(사용 가능한 각 참조 저장소는 가져오기 레시피를 포함하며, 해결되지 않은 멤버는 동일한 수정 지침과 doctor 출력을 가짐). --code-workspace 플래그는 루트와 사용 가능한 참조 저장소(ref:<id> 폴더들)를 포함하는 VS Code 워크스페이스 파일을 추가로 작성합니다. 이는 이 명령이 수행하는 유일한 쓰기 작업이며, 파일이 이미 존재하면 --force 없이 거부됩니다. 사용할 수 없는 멤버는 보고되지만 추측하지는 않습니다.

"작업 컨텍스트"는 조립된 세트를 의미하며, openspec/config.yaml의 context: 필드는 지시사항에 주입되는 프로젝트 배경 정보입니다 — 둘은 서로 다른 것입니다. openspec doctor는 세트가 건강한지 여부를 답변하고, openspec context는 세트가 무엇인지 답변합니다.

개인 작업셋

베타. 작업셋은 새로운 베타 기능의 일부이므로 릴리스 간에 명령, 플래그 및 파일 형식이 변경될 수 있습니다. 단계별 가이드는 저장소 가이드를 참조하십시오.

작업셋은 함께 작업하는 폴더들의 개인적이고 이름 지정된 보기입니다 — 계획 루트와 사용자가 선택한 기타 요소들로 구성되며, 로컬 머신에 보관되고 도구에서 이름으로 다시 열립니다. 이는 순수하게 로컬적입니다: 절대 커밋되지 않으며, 공유되지도 않고, 선언으로부터 유도되지도 않으며, 하나를 제거해도 멤버 폴더에는 영향을 미치지 않습니다.

bash

openspec workset create [name] [--member <path> | --member <name>=<path>]... [--tool <id>] [--json]
openspec workset list [--json]
openspec workset open <name> [--tool <id>]
openspec workset remove <name> [--yes] [--json]

create는 짧은 안내 흐름을 실행하거나(비대화형 모드에서는 --member 플래그를 받음; 첫 번째 멤버가 기본값이며 세션은 여기서 시작됨) open은 선택한 도구를 실행합니다: 에디터(VS Code, Cursor)는 모든 멤버를 포함하는 창을 열고 종료됩니다. CLI 에이전트(Claude Code, codex)는 모든 멤버가 연결되고 프롬프트가 미리 채워지지 않은 세션으로 이 터미널을 인수하여 사용자가 종료할 때까지 지속됩니다. 오픈 시 누락된 멤버 폴더는 참고 사항과 함께 건너뛰고 나머지를 엽니다. 저장된 도구 선호도는 --tool 플래그를 사용하여 각 오픈마다 재정의할 수 있습니다.

새로운 도구를 지원하려면 코드가 아닌 구성만 필요합니다. 모든 도구는 두 가지 실행 스타일 중 하나입니다 — workspace-file(생성된 .code-workspace로 실행) 또는 attach-dirs(멤버마다 하나의 연결 플래그) — 그리고 전역 config.json( openspec config edit로 열 수 있음)의 openers 키는 필드별로 도구를 추가하거나 내장 기능을 조정합니다:

json

{
  "openers": {
    "zed": { "style": "workspace-file" },
    "claude": { "attach_flag": "--dir" }
  }
}

모든 작업셋 상태는 전역 데이터 디렉토리의 worksets/ 폴더 아래에 저장됩니다(저장된 뷰와 매번 오픈 시 재생성되는 <name>.code-workspace 파일들 포함); 해당 폴더를 삭제하면 모든 흔적이 제거됩니다.

탐색 명령

`openspec list`

프로젝트의 변경 사항이나 명세를 나열합니다.

openspec list [options]

옵션:

옵션	설명
`--specs`	변경 사항 대신 명세 나열
`--changes`	변경 사항 나열 (기본값)
`--sort <order>`	`recent`(기본값) 또는 `name` 기준 정렬
`--json`	JSON 형식으로 출력

예제:

bash

# 모든 활성 변경 사항 나열
openspec list

# 모든 명세 나열
openspec list --specs

# 스크립트를 위한 JSON 출력
openspec list --json

출력 (텍스트):

Changes:
  add-dark-mode     No tasks      just now

`openspec view`

명세와 변경 사항을 탐색하기 위한 대화형 대시보드를 표시합니다.

openspec view

프로젝트의 명세와 변경 사항을 탐색하기 위한 터미널 기반 인터페이스를 엽니다.

`openspec show`

변경 사항이나 명세의 세부 정보를 표시합니다.

openspec show [item-name] [options]

인수:

인수	필수	설명
`item-name`	아니요	변경 사항 또는 명세의 이름 (생략 시 프롬프트 표시)

옵션:

옵션	설명
`--type <type>`	유형 지정: `change` 또는 `spec` (모호하지 않으면 자동 감지)
`--json`	JSON 형식으로 출력
`--no-interactive`	프롬프트 비활성화

변경 사항 전용 옵션:

옵션	설명
`--deltas-only`	델타 명세만 표시 (JSON 모드)

명세 전용 옵션:

옵션	설명
`--requirements`	요구사항만 표시, 시나리오 제외 (JSON 모드)
`--no-scenarios`	시나리오 콘텐츠 제외 (JSON 모드)
`-r, --requirement <id>`	1-based 인덱스로 특정 요구사항 표시 (JSON 모드)

예제:

bash

# 대화형 선택
openspec show

# 특정 변경 사항 표시
openspec show add-dark-mode

# 특정 명세 표시
openspec show auth --type spec

# 파싱을 위한 JSON 출력
openspec show add-dark-mode --json

Validation Commands

`openspec validate`

변경 사항과 스펙의 구조적 문제를 검증하고, 변경 사항의 MODIFIED 요구 사항을 대체할 메인 스펙과 대조하여 확인합니다.

openspec validate [item-name] [options]

스펙 델타가 0개인 변경 사항은 .openspec.yaml에 skip_specs: true가 선언되어 있지 않으면(순수 리팩토링, 도구, 또는 문서 작업의 경우 — Recipe 5 참조) 검증에 실패합니다.

Arguments:

Argument	Required	Description
`item-name`	No	검증할 특정 항목 (생략 시 프롬프트 표시)

Options:

Option	Description
`--all`	모든 변경 사항과 스펙을 검증
`--changes`	모든 변경 사항을 검증
`--specs`	모든 스펙을 검증
`--archived`	아카이브된 변경 사항의 모든 작업이 완료되었는지 검증 (pre-commit 린팅용)
`--type <type>`	이름이 모호할 때 유형 지정: `change` 또는 `spec`
`--strict`	엄격한 검증 모드 활성화
`--json`	JSON 형식으로 출력
`--concurrency <n>`	최대 병렬 검증 수 (기본값: 6 또는 `OPENSPEC_CONCURRENCY` 환경 변수)
`--no-interactive`	프롬프트 비활성화

--archived는 자체 범위를 가집니다: 스펙 델타를 검증하지 않습니다(아카이브 시점에 이미 적용됨). 대신 changes/archive/ 하위의 모든 변경 사항의 tasks.md 체크박스가 모두 체크되었는지 확인하며, 미완료 항목이 있으면 0이 아닌 종료 코드를 반환합니다. 이는 미완료 작업이 아카이브된 변경 사항을 잡아내는 데 유용하며, pre-commit 훅에서 특히 효과적입니다.

Examples:

bash

# Interactive validation
openspec validate

# Validate a specific change
openspec validate add-dark-mode

# Validate all changes
openspec validate --changes

# Validate everything with JSON output (for CI/scripts)
openspec validate --all --json

# Strict validation with increased parallelism
openspec validate --all --strict --concurrency 12

# Fail if any archived change still has unchecked tasks
openspec validate --archived

Output (text):

Validating add-dark-mode...
  ✓ proposal.md valid
  ✓ specs/ui/spec.md valid
  ⚠ design.md: missing "Technical Approach" section

1 warning found

Output (JSON):

json

{
  "version": "1.0.0",
  "results": {
    "changes": [
      {
        "name": "add-dark-mode",
        "valid": true,
        "warnings": ["design.md: missing 'Technical Approach' section"]
      }
    ]
  },
  "summary": {
    "total": 1,
    "valid": 1,
    "invalid": 0
  }
}

Lifecycle Commands

`openspec archive`

완료된 변경 사항을 아카이브하고 델타 스펙을 메인 스펙에 병합합니다.

openspec archive [change-name] [options]

Arguments:

Argument	Required	Description
`change-name`	No	아카이브할 변경 사항 (생략 시 프롬프트 표시; 프롬프트에 응답할 수 없는 경우 필수)

Options:

Option	Description
`-y, --yes`	확인 프롬프트 건너뛰기. 프롬프트에 응답할 수 없는 경우 필수 — AI 에이전트, CI 작업, 또는 stdin이 닫힌 모든 실행 환경
`--skip-specs`	한 번의 아카이브 실행에서 스펙 업데이트 건너뛰기. 영구적으로 스펙 델타가 없는 변경 사항은 대신 `.openspec.yaml`에 `skip_specs: true`를 선언해야 하며, 이 경우 플래그 없이 아카이브됩니다
`--no-validate`	검증 건너뛰기 (확인 필요). 기능 은퇴도 비활성화됩니다 — 검증판정이 없으므로 아무것도 은퇴되지 않습니다

Examples:

bash

# Interactive archive (asks which change, then confirms)
openspec archive

# Archive specific change
openspec archive add-dark-mode

# Archive without prompts (agents, CI, scripts)
openspec archive add-dark-mode --yes

# Archive a tooling change that doesn't affect specs
openspec archive update-ci-config --skip-specs

기능 은퇴: 변경 사항 메타데이터에 은퇴 마커를 추가합니다:

yaml

# openspec/changes/retire-legacy/.openspec.yaml
schema: spec-driven
retire_capabilities: true

그런 다음 변경 사항을 정상적으로 아카이브합니다:

bash

openspec archive retire-legacy --yes

변경 사항이 해당 기능의 마지막 요구 사항을 제거할 때, OpenSpec은 라이브 spec.md를 삭제합니다. 같은 변경 사항 내의 다른 기능 델타는 여전히 메인 스펙을 업데이트합니다. 마커가 없으면 아카이브는 파일 변경 전에 중단되며 마커를 추가하라는 안내를 표시합니다.

What it does:

변경 사항을 검증합니다 (--no-validate 제외)
확인을 프롬프트합니다 (--yes 제외)
메인 스펙 변경 전에 아카이브 대상 경로를 확보합니다
활성 델타 스펙을 검증하고 openspec/specs/에 병합합니다 — 변경 사항이 해당 기능의 마지막 요구 사항을 제거하면 해당 기능은 은퇴되고 스펙 파일이 삭제되지만, 변경 사항의 .openspec.yaml에 schema: 옆에 retire_capabilities: true가 선언된 경우에만 적용됩니다
변경 사항 폴더를 openspec/changes/archive/YYYY-MM-DD-<name>/로 이동합니다
완전한 아카이브가 확보되기 전에 스펙 변경 또는 최종 이동이 실패하면 스펙을 복원하고 변경 사항을 활성 경로에 남기거나 반환합니다
검증된 폴백 사본이 완료되었지만 스테이징 소스 정리 실패 시 완전한 아카이브와 커밋된 스펙 상태를 복구용으로 유지합니다

Without a terminal: AI 에이전트, CI 작업, 또는 stdin이 닫힌 모든 실행 환경은 2단계에 응답할 수 없으므로, 아카이브는 아무것도 건드리기 전에 중단되고 종료 코드 1을 반환하며 재실행할 명령을 표시합니다 — 전달한 다른 플래그를 그대로 포함하여 openspec archive <name> --yes입니다. 왕복을 건너뛰려면 처음부터 --yes(및 변경 사항 이름)를 전달하세요.

워크플로우 명령어

이 명령어들은 아티팩트 기반 OPSX 워크플로우를 지원합니다. 진행 상황을 확인하는 사람과 다음 단계를 결정하는 에이전트 모두에게 유용합니다.

`openspec new change`

해석된 OpenSpec 루트에 변경 사항 디렉토리와 선택적 체크인 메타데이터를 생성합니다.

bash

openspec new change <name> [options]

변경 이름은 소문자 케밥 표기법을 사용해야 합니다. 소문자, 숫자, 단일 하이픈만 허용됩니다. 공백, 밑줄, 대문자, 연속된 하이픈, 선행 또는 후행 하이픈은 사용할 수 없습니다. 숫자로 시작하는 것은 허용되므로, 예를 들어 100-add-feature나 00001-add-auth와 같이 이름에 접두사를 붙여 순서나 계층별 변경 사항을 구분할 수 있습니다.

옵션:

옵션	설명
`--description <text>`	`index.md`에 추가할 설명
`--goal <text>`	변경 사항과 함께 저장할 선택적 목표 메타데이터
`--schema <name>`	사용할 워크플로우 스키마
`--store <id>`	OpenSpec 루트로 사용할 저장소 ID (저장소는 등록한 독립형 OpenSpec 저장소입니다)
`--json`	JSON 출력

예:

bash

openspec new change add-billing-api
openspec new change add-billing-api --store team-context --json

`openspec status`

변경 사항의 아티팩트 완료 상태를 표시합니다.

openspec status [options]

옵션:

옵션	설명
`--change <id>`	변경 이름 (생략하면 프롬프트 표시)
`--schema <name>`	스키마 재정의 (변경 구성에서 자동 감지)
`--json`	JSON으로 출력

예:

bash

# 대화형 상태 확인
openspec status

# 특정 변경 사항 상태 확인
openspec status --change add-dark-mode

# 에이전트 사용을 위한 JSON
openspec status --change add-dark-mode --json

출력 (텍스트):

변경: add-dark-mode
스키마: spec-driven
진행률: 4개 중 2개 아티팩트 완료

[x] proposal
[x] specs
[ ] design
[-] tasks (차단됨: design)

skip_specs: true를 선언한 변경 사항은 사양 단계를 [~] specs (건너뜀: 변경 사항이 skip_specs 선언)으로 표시하고 진행률 계산에서 제외합니다.

출력 (JSON):

json

{
  "changeName": "add-dark-mode",
  "schemaName": "spec-driven",
  "isPlanningComplete": false,
  "isComplete": false,
  "applyRequires": ["tasks"],
  "artifacts": [
    {"id": "proposal", "outputPath": "proposal.md", "status": "done", "requires": []},
    {"id": "specs", "outputPath": "specs/**/*.md", "status": "done", "requires": ["proposal"]},
    {"id": "design", "outputPath": "design.md", "status": "ready", "requires": ["proposal"]},
    {"id": "tasks", "outputPath": "tasks.md", "status": "blocked", "requires": ["specs", "design"], "missingDeps": ["design"]}
  ]
}

isPlanningComplete는 건너뛰지 않은 모든 계획 아티팩트가 존재하는지 여부를 보고합니다. 건너뛴 아티팩트는 생성되지 않아도 충족된 것으로 간주됩니다. 이 값은 구현 작업이 완료되었는지는 보고하지 않습니다. isComplete는 동일한 값을 가진 호환성 별칭으로 유지됩니다.

아티팩트는 종속성 순서대로 나열됩니다. 즉, 종속된 항목이 그 종속성을 필요로 하는 항목보다 뒤에 나타나지 않습니다. 동시에 준비되는 아티팩트(예: spec-driven의 specs와 design은 모두 proposal만 필요)는 알파벳 순서가 아니라 스키마가 선언한 순서를 유지합니다. 따라서 첫 번째 ready 항목이 다음에 작성할 아티팩트가 됩니다.

`openspec instructions`

아티팩트 생성 또는 작업 적용을 위한 향상된 지침을 가져옵니다. AI 에이전트가 다음에 생성할 항목을 이해하는 데 사용됩니다.

openspec instructions [artifact] [options]

인수:

인수	필수	설명
`artifact`	아니오	아티팩트 ID 또는 워크플로우 입력 표면: `apply` 또는 `archive`

옵션:

옵션	설명
`--change <id>`	변경 이름 (비대화형 모드에서 필수)
`--schema <name>`	스키마 재정의
`--json`	JSON으로 출력

특별 케이스: apply를 사용하면 작업 구현 지침을 가져옵니다. archive를 사용하면 유효한 변경 사항에 대한 현재 읽기 전용 아카이브 입력(context와 operationGuidance)을 가져옵니다. 아카이브하거나 변경하지는 않습니다.

예:

bash

# 다음 아티팩트에 대한 지침 가져오기
openspec instructions --change add-dark-mode

# 특정 아티팩트 지침 가져오기
openspec instructions design --change add-dark-mode

# 적용/구현 지침 가져오기
openspec instructions apply --change add-dark-mode

# 아카이브하지 않고 현재 아카이브 작업 입력 가져오기
openspec instructions archive --change add-dark-mode --json

# 에이전트 소비용 JSON
openspec instructions design --change add-dark-mode --json

출력 내용:

아티팩트의 템플릿 콘텐츠
구성의 프로젝트 컨텍스트
종속성 아티팩트의 콘텐츠
구성의 아티팩트별 규칙
apply/archive에 대한 현재 프로젝트 컨텍스트와 일치하는 작업 안내

작업 입력은 매 호출 시 해석된 저장소나 선택한 저장소에서 읽습니다. 프로젝트 컨텍스트는 필수 프롬프트 수준 입력입니다. 에이전트는 이를 읽고 관련 프로젝트 사실, 규칙, 제약 조건을 적용합니다. 작업 안내는 선택적 추가 조언입니다. 에이전트는 모든 항목을 고려하고 기본 제공 워크플로우와 적용 가능하고 호환되는 항목만 따릅니다. 두 필드는 명시적 사용자 선택, CLI 제어 상태, 기본 제공 지침, 아티팩트 규칙과 분리되어 있습니다. 충돌하는 컨텍스트는 보고되고, 충돌하거나 적용할 수 없는 안내는 따르지 않으며 그 이유가 설명됩니다. 이는 생성된 에이전트의 행동 계약이며 강제 가능한 CLI 검사가 아닙니다. instructions archive는 선택한 변경 사항, 선택적 입력, 루트 메타데이터만 반환하며 정적 아카이브 워크플로우는 포함하지 않습니다.

skip_specs: true로 건너뛴 아티팩트의 경우 출력은 경고만 표시되며(JSON에는 skipped/warning 필드가 추가됨), 아티팩트를 생성해서는 안 됩니다.

`openspec templates`

스키마의 모든 아티팩트에 대해 해석된 템플릿 경로를 표시합니다.

openspec templates [options]

옵션:

옵션	설명
`--schema <name>`	검사할 스키마 (기본값: `spec-driven`)
`--json`	JSON으로 출력

예:

bash

# 기본 스키마의 템플릿 경로 표시
openspec templates

# 사용자 정의 스키마의 템플릿 표시
openspec templates --schema my-workflow

# 프로그래밍 용도를 위한 JSON
openspec templates --json

출력 (텍스트):

스키마: spec-driven

템플릿:
  proposal  → ~/.openspec/schemas/spec-driven/templates/proposal.md
  specs     → ~/.openspec/schemas/spec-driven/templates/specs.md
  design    → ~/.openspec/schemas/spec-driven/templates/design.md
  tasks     → ~/.openspec/schemas/spec-driven/templates/tasks.md

`openspec schemas`

설명 및 아티팩트 흐름과 함께 사용 가능한 워크플로우 스키마 목록을 표시합니다.

openspec schemas [options]

옵션:

옵션	설명
`--json`	JSON으로 출력
`--store <id>`	등록된 저장소를 OpenSpec 루트로 사용

예:

bash

openspec schemas

출력:

사용 가능한 스키마:

  spec-driven (패키지)
    기본 사양 중심 개발 워크플로우
    흐름: proposal → specs → design → tasks

  my-custom (프로젝트)
    이 프로젝트의 사용자 정의 워크플로우
    흐름: research → proposal → tasks

스키마 명령어

사용자 정의 워크플로 스키마를 생성하고 관리하는 명령어입니다.

`openspec schema init`

새 프로젝트-로컬 스키마를 생성합니다.

openspec schema init <name> [options]

인수:

인수	필수	설명
`name`	예	스키마 이름 (kebab-case)

옵션:

옵션	설명
`--description <text>`	스키마 설명
`--artifacts <list>`	쉼표로 구분된 아티팩트 ID (기본값: `proposal,specs,design,tasks`)
`--default`	프로젝트 기본 스키마로 설정
`--no-default`	기본으로 설정할지 묻지 않음
`--force`	기존 스키마 덮어쓰기
`--json`	JSON으로 출력

예시:

bash

# 대화형 스키마 생성
openspec schema init research-first

# 특정 아티팩트를 사용한 비대화형 생성
openspec schema init rapid \
  --description "Rapid iteration workflow" \
  --artifacts "proposal,tasks" \
  --default

생성되는 항목:

openspec/schemas/<name>/
├── schema.yaml           # 스키마 정의
└── templates/
    ├── proposal.md       # 각 아티팩트에 대한 템플릿
    ├── specs.md
    ├── design.md
    └── tasks.md

`openspec schema fork`

기존 스키마를 프로젝트에 복사하여 사용자 정의합니다.

openspec schema fork <source> [name] [options]

인수:

인수	필수	설명
`source`	예	복사할 스키마
`name`	아니요	새 스키마 이름 (기본값: `<source>-custom`)

옵션:

옵션	설명
`--force`	기존 대상 덮어쓰기
`--json`	JSON으로 출력

예시:

bash

# 내장 spec-driven 스키마 포크하기
openspec schema fork spec-driven my-workflow

`openspec schema validate`

스키마의 구조와 템플릿을 검증합니다.

openspec schema validate [name] [options]

인수:

인수	필수	설명
`name`	아니요	검증할 스키마 (생략 시 모든 스키마 검증)

옵션:

옵션	설명
`--verbose`	상세 검증 단계 표시
`--json`	JSON으로 출력

예시:

bash

# 특정 스키마 검증
openspec schema validate my-workflow

# 모든 스키마 검증
openspec schema validate

`openspec schema which`

스키마가 어디에서 해석되는지 표시합니다 (우선순위 디버깅에 유용).

openspec schema which [name] [options]

인수:

인수	필수	설명
`name`	아니요	스키마 이름

옵션:

옵션	설명
`--all`	모든 스키마와 해당 소스 나열
`--json`	JSON으로 출력

예시:

bash

# 스키마가 어디서 오는지 확인
openspec schema which spec-driven

출력:

spec-driven resolves from: package
  Source: /usr/local/lib/node_modules/@fission-ai/openspec/schemas/spec-driven

스키마 우선순위:

프로젝트: openspec/schemas/<name>/
사용자: ~/.local/share/openspec/schemas/<name>/
패키지: 내장 스키마

구성 명령어

`openspec config`

전역 OpenSpec 구성을 확인하고 수정합니다.

openspec config <subcommand> [options]

하위 명령어:

하위 명령어	설명
`path`	구성 파일 위치 표시
`list`	모든 현재 설정 표시
`get <key>`	특정 값 가져오기
`set <key> <value>`	값 설정
`unset <key>`	키 제거
`reset`	기본값으로 재설정
`edit`	`$EDITOR`로 열기
`profile [preset]`	워크플로 프로필을 대화형 또는 사전 설정으로 구성

예시:

bash

# 구성 파일 경로 표시
openspec config path

# 모든 설정 목록 표시
openspec config list

# 특정 값 가져오기
openspec config get telemetry.enabled

# 값 설정 (익명 사용 텔레메트리 비활성화)
openspec config set telemetry.enabled false

# 문자열 값을 명시적으로 설정
openspec config set user.name "My Name" --string

# 사용자 정의 설정 제거
openspec config unset user.name

# 머신 수준 기본 저장소 설정 (--store, 로컬 루트, 프로젝트 저장소 포인터가 없을 때 대체 루트)
openspec config set defaultStore team-plans

# 모든 구성 재설정
openspec config reset --all --yes

# 편집기에서 구성 편집
openspec config edit

# 액션 기반 마법사로 프로필 구성
openspec config profile

# 빠른 사전 설정: 워크플로를 core로 전환 (전달 모드 유지)
openspec config profile core

텔레메트리 거부: telemetry.enabled는 설정하지 않으면 기본적으로 켜져 있습니다(opt-out 모델). false로 설정하면 익명 사용 통계와 openspec update 버전 확인을 비활성화합니다. 환경 변수는 구성보다 우선합니다: OPENSPEC_TELEMETRY=0, DO_NOT_TRACK=1, 그리고 참인 CI 값(예: true/1/yes)은 구성 값과 관계없이 항상 텔레메트리를 비활성화합니다.

openspec config profile은 현재 상태 요약으로 시작한 후 다음을 선택할 수 있습니다:

전달과 워크플로 변경
전달만 변경
워크플로만 변경
현재 설정 유지(종료)

현재 설정을 유지하면 변경 사항이 기록되지 않으며 업데이트 프롬프트가 표시되지 않습니다. 구성 변경이 없지만 현재 프로젝트 파일이 전역 프로필/전달과 동기화되지 않은 경우 OpenSpec은 경고를 표시하고 openspec update를 제안합니다. Ctrl+C를 누르면 흐름이 깔끔하게 취소되고(스택 추적 없음) 코드 130으로 종료됩니다. 워크플로 체크리스트에서 [x]는 해당 워크플로가 전역 구성에서 선택되었음을 의미합니다. 이러한 선택을 프로젝트 파일에 적용하려면 openspec update를 실행하거나(프로젝트 내에서 지금 이 프로젝트에 변경 사항을 적용하시겠습니까?라는 프롬프트가 표시되면 선택) 하세요.

대화형 예시:

bash

# 전달만 업데이트
openspec config profile
# 선택: 전달만 변경
# 전달 선택: Skills만

# 워크플로만 업데이트
openspec config profile
# 선택: 워크플로만 변경
# 체크리스트에서 워크플로를 토글한 후 확인

유틸리티 명령어

`openspec feedback`

OpenSpec에 대한 피드백을 제출합니다. GitHub 이슈를 생성합니다.

openspec feedback <message> [options]

인수:

인수	필수	설명
`message`	예	피드백 요약; 긴 텍스트는 이슈 제목에서 축약되고 본문에 보존됩니다

옵션:

옵션	설명
`--body <text>`	요약 뒤에 포함될 추가 세부 정보

요구 사항: GitHub CLI(gh)가 설치되어 있고 인증되어 있어야 합니다.

예시:

bash

openspec feedback "Add support for custom artifact types" \
  --body "I'd like to define my own artifact types beyond the built-in ones."

`openspec completion`

OpenSpec CLI용 셸 완성(completion)을 관리합니다.

openspec completion <subcommand> [shell]

하위 명령어:

하위 명령어	설명
`generate [shell]`	stdout으로 완성 스크립트 출력
`install [shell]`	셸에 완성 설치
`uninstall [shell]`	설치된 완성 제거

지원되는 셸: bash, zsh, fish, powershell

예시:

bash

# 완성 설치 (셸 자동 감지)
openspec completion install

# 특정 셸에 설치
openspec completion install zsh

# 수동 설치용 스크립트 생성 (bash)
openspec completion generate bash > ~/.bash_completion.d/openspec

# 제거
openspec completion uninstall

Windows (PowerShell): 현재 PowerShell 호스트에 완성을 설치합니다:

powershell

$env:PROFILE = $PROFILE
openspec completion install powershell
. $PROFILE

$env:PROFILE은 OpenSpec에 이 세션에서 구성할 프로필을 알려줍니다. 설치 프로그램은 누락된 프로필 디렉터리를 생성하고 OpenSpecCompletion.ps1을 로드하는 관리 블록을 추가합니다. 프로필을 다시 로드하면 완성이 즉시 활성화됩니다.

현재 호스트에서 제거하려면 다음을 실행하세요:

powershell

$env:PROFILE = $PROFILE
openspec completion uninstall powershell

제거 후 현재 세션에서 완성을 지우려면 PowerShell을 다시 시작하세요.

완성은 옵트인(opt-in)입니다. CLI는 대화형 터미널에서 처음 명령을 실행할 때 stderr에 한 번만 언급하며 그 이후로는 다시 언급하지 않습니다. 또한 완성이 이미 설치되어 있으면 조용히 넘어갑니다. OPENSPEC_NO_COMPLETIONS=1을 설정하면 해당 팁을 완전히 숨길 수 있습니다.

종료 코드

코드	의미
`0`	성공
`1`	오류 (검증 실패, 파일 누락 등)

환경 변수

변수	설명
`OPENSPEC_TELEMETRY`	`0`으로 설정하면 텔레메트리와 `openspec update` 버전 확인을 비활성화합니다 (전역 구성의 `telemetry.enabled`를 재정의)
`DO_NOT_TRACK`	`1`로 설정하면 텔레메트리와 `openspec update` 버전 확인을 비활성화합니다 (표준 DNT 신호; 구성 재정의)
`OPENSPEC_CONCURRENCY`	대량 검증의 기본 동시성 (기본값: 6)
`EDITOR` 또는 `VISUAL`	`openspec config edit`에 사용할 편집기
`NO_COLOR`	설정되면 색상 출력 비활성화
`OPENSPEC_NO_ANIMATION`	설정되면 `openspec init` 환영 애니메이션 비활성화
`OPENSPEC_NO_COMPLETIONS`	셸 완성에 대한 일회성 팁을 숨기려면 `1`로 설정
`OPENSPEC_NO_UPDATE_CHECK`	설정되면(빈 값을 포함한 모든 값) 최신 게시된 CLI에 대한 `openspec update` 확인을 비활성화합니다. `CI`가 설정된 경우(`false`/`0`/`no`/`off` 제외) 또는 `NODE_ENV=test`인 경우에도 건너뜁니다.
`npm_config_registry`	`openspec update` 버전 확인이 참조하는 레지스트리입니다. `http(s)` URL이어야 하며 그렇지 않으면 `https://registry.npmjs.org`로 대체됩니다. `.npmrc` 파일은 읽지 않습니다.

CLI 참조 ​

요약 ​

Human vs Agent Commands ​

Human-Only Commands ​

Agent-Compatible Commands ​

Global Options ​

Setup Commands ​

openspec init ​

openspec update ​

스토어(독립형 OpenSpec 저장소) ​

openspec store setup ​

openspec store register ​

openspec store unregister ​

openspec store remove ​

openspec store list ​

openspec store doctor ​

프로젝트에서 스토어 참조 ​

스토어가 클론된 위치 기록 ​

기본 스토어 선언 ​

Doctor (관계 상태 확인) ​

작업 컨텍스트 (조립된 세트) ​

개인 작업셋 ​

탐색 명령 ​

openspec list ​

openspec view ​

openspec show ​

Validation Commands ​

openspec validate ​

Lifecycle Commands ​

openspec archive ​

워크플로우 명령어 ​

openspec new change ​

openspec status ​

openspec instructions ​

openspec templates ​

openspec schemas ​

스키마 명령어 ​

openspec schema init ​

openspec schema fork ​

openspec schema validate ​

openspec schema which ​

구성 명령어 ​

openspec config ​

유틸리티 명령어 ​

openspec feedback ​

openspec completion ​

종료 코드 ​

환경 변수 ​

관련 문서 ​

CLI 참조

요약

Human vs Agent Commands

Human-Only Commands

Agent-Compatible Commands

Global Options

Setup Commands

`openspec init`

`openspec update`

스토어(독립형 OpenSpec 저장소)

`openspec store setup`

`openspec store register`

`openspec store unregister`

`openspec store remove`

`openspec store list`

`openspec store doctor`

프로젝트에서 스토어 참조

스토어가 클론된 위치 기록

기본 스토어 선언

Doctor (관계 상태 확인)

작업 컨텍스트 (조립된 세트)

개인 작업셋

탐색 명령

`openspec list`

`openspec view`

`openspec show`

Validation Commands

`openspec validate`

Lifecycle Commands

`openspec archive`

워크플로우 명령어

`openspec new change`

`openspec status`

`openspec instructions`

`openspec templates`

`openspec schemas`

스키마 명령어

`openspec schema init`

`openspec schema fork`

`openspec schema validate`

`openspec schema which`

구성 명령어

`openspec config`

유틸리티 명령어

`openspec feedback`

`openspec completion`

종료 코드

환경 변수

관련 문서