> init은 docs 생성 후 Git 초기화/커밋(git init, git add, git commit)을 자동 시도합니다. 환경에 따라 자동 커밋이 생략될 수 있습니다.

$3

`bash


Single 프로젝트

| 옵션 | 설명 | 기본값 |
| ------------------- | -------------------------------------------- | ----------- |
| -r, --repo | multi 대상 컴포넌트 (하위호환 alias) | 대화형 선택 |
| --component | multi 대상 컴포넌트 | 대화형 선택 |
| --id | Feature ID (F001 형식) | 자동 생성 |
| -d, --desc | spec.md의 목적(설명) 기본 문구 | 빈 문자열 |
| --non-interactive | 사용자 입력이 필요하면 프롬프트 대신 즉시 실패 | false |
| --json | JSON 출력 (featureId, featurePath, component) | false |

$3

현재 작업 중인 Feature의 상태와 다음 할 일을 확인합니다. 특히 AI 에이전트가 프로세스를 준수하는 데 유용합니다.
단일 Feature 상세에서는 다음 작업을 항상 A/B/C 옵션으로 표시합니다.

`bash


자동 감지 (Git 브랜치 기준)

| 옵션 | 설명 |
| --------------- | ----------------------------------------------- |
| --json | 에이전트용 JSON 출력 |
| --repo | multi에서 대상 컴포넌트 지정 (예: fe, be, worker) |
| --all | 자동 감지 실패 시 완료된 Feature까지 포함해서 표시 |
| --done | 완료(workflow-done) Feature만 표시 |
| --approve | 라벨 승인 응답 (A 또는 A OK)으로 단일 옵션 선택 |
| --execute | --approve로 선택한 옵션이 command일 때 1개만 실행 |
| --execute-strict | --execute와 함께 사용 시 instruction-only 옵션이면 실패 |

--json 출력에는 다음 액션이 actions 배열로 포함됩니다.

- reasonCode: 상태 이유 코드 (SINGLE_MATCHED, MULTIPLE_ACTIVE_FEATURES 등)
- type: "command": scope(project|docs), cwd, cmd 제공 (복사하여 붙여넣기 가능한 형태로 cd ... && git ... 형태로 출력)
- type: "instruction": 사람이 수행해야 하는 안내 메시지
- actionOptions: label(A, B, C...)과 해당 action 매핑 + summary/approvalPrompt(라벨 설명 템플릿)
- category: 액션 분류 (자동화/반자동용 approval.mode: "category"에서 사용)
- requiresUserCheck: 사용자 확인 필요 여부 (에이전트는 사용자 응답을 <라벨> 또는 <라벨> OK 형식(예: A, A OK)으로 제한하는 것을 권장 / 설정의 approval로 오버라이드 가능)
- workflowPolicy: 현재 완료 조건 정책 (mode, requireIssue, requireBranch, requirePr, requireReview)

또한 checkPolicy가 포함되어, 에이전트가 사용자 확인 정책을 적용할 때 참고할 수 있습니다. (docPath, hint, token: "", acceptedTokens, tokenPattern, validLabels, requireExplanationBeforeApproval, requiredExplanationFields, contextVersion, config)

오류 응답(status: "error")에는 reasonCode와 suggestions(라벨형 다음 동작: A/B/C)가 포함됩니다. (예: INVALID_APPROVAL, CONTEXT_STALE, EXECUTION_FAILED, EXECUTION_NOT_COMMAND)

$3

`bash
npx lee-spec-kit view
npx lee-spec-kit view F001
npx lee-spec-kit view --all
npx lee-spec-kit view --json
`

옵션:

| 옵션 | 설명 |
| --------------- | ----------------------------------------------- |
| --json | 에이전트용 JSON 출력 |
| --repo | multi에서 대상 컴포넌트 지정 (예: fe, be, worker) |
| --all | 자동 감지 실패 시 완료된 Feature까지 포함해서 표시 |
| --done | 완료(workflow-done) Feature만 표시 |

$3

`bash
npx lee-spec-kit flow
npx lee-spec-kit flow F001 --approve A
npx lee-spec-kit flow F001 --approve "A OK" --execute
npx lee-spec-kit flow --strict
npx lee-spec-kit flow --json
`

옵션:

| 옵션 | 설명 |
| ------------------ | ---- |
| --json | 에이전트용 JSON 출력 |
| --repo | multi에서 대상 컴포넌트 지정 (예: fe, be, worker) |
| --all | 자동 감지 실패 시 완료된 Feature까지 포함해서 표시 |
| --done | 완료(workflow-done) Feature만 표시 |
| --approve | context 라벨 승인 응답 전달 (A 또는 A OK) |
| --execute | 승인한 옵션이 command일 때 실행 |
| --execute-strict | --execute와 함께 사용 시 instruction-only 옵션이면 실패 |
| --strict | status --strict, doctor --strict까지 함께 검사 |

$3

`bash


선택된 Feature 기준 Issue 본문 생성

핵심 동작:
- Issue/PR helper는 필수 섹션과 관련 문서 경로를 검증합니다.
- 라벨은 최소 1개 이상 필수입니다.
- PR helper는 기본적으로 tasks.md의 PR/PR Status를 동기화합니다. (--no-sync-tasks로 비활성화)
- merge 시 head 브랜치가 뒤쳐진 경우 fetch/rebase/force-push 후 재시도합니다.

$3

`bash


터미널에 출력

| 옵션 | 설명 |
| -------------- | --------------------------------------------- |
| --json | 에이전트용 JSON 출력 |
| -w, --write | features/status.md 파일 생성 |
| -s, --strict | 중복/누락 Feature ID 발견 시 종료 코드 1 반환 |

상태값은 구현 완료와 워크플로우 완료를 구분합니다.
- DONE: 태스크는 모두 완료됐지만 워크플로우 요구사항이 완전히 충족되진 않음
- WORKFLOW_DONE: 구현 + 워크플로우 요구사항까지 모두 충족

$3

`bash


도움말 배너 숨김

또는 환경변수 LEE_SPEC_KIT_NO_BANNER=1로 배너 출력을 비활성화할 수 있습니다.

$3

docs 구조 및 Feature 메타데이터(중복 ID, 누락된 파일/상태, 플레이스홀더 잔존 등)를 점검합니다.

`bash


진단 실행

- --decisions-placeholders
- off: decisions.md 플레이스홀더를 진단에서 제외
- info (기본): 정보 레벨로만 보고 (strict 실패 대상 아님)
- warn: 경고로 보고

$3

기본 동작은 docs/ 작업트리에 변경사항이 없을 때만 업데이트를 진행하며, 이 경우 변경된 파일은 확인 없이 덮어씁니다.
변경사항이 있는 상태에서 업데이트하려면 --force를 사용하세요.

`bash


전체 업데이트

init을 실행하면 문서 루트(기본: docs/)에 .lee-spec-kit.json이 생성됩니다.

`json
{
"projectName": "my-project",
"projectType": "single",
"lang": "ko",
"createdAt": "YYYY-MM-DD",
"docsRepo": "embedded",
"workflow": { "mode": "github", "codeDirtyScope": "auto" },
"pr": { "screenshots": { "upload": false } },
"approval": { "mode": "builtin" }
}
`

| 필드 | 설명 |
| ------------- | --------------------------------------- |
| projectName | 프로젝트 이름 |
| projectType | single 또는 multi (fullstack alias 지원) |
| components | (multi만) 컴포넌트 목록 (예: ["fe","be","worker"]) |
| lang | ko 또는 en |
| createdAt | 생성 날짜 |
| docsRepo | embedded 또는 standalone |
| pushDocs | (standalone만) docs 레포를 별도 Git으로 관리/푸시할지 여부 |
| docsRemote | (standalone+pushDocs) docs 레포 remote URL |
| projectRoot | (standalone만) 프로젝트 레포지토리 경로 (single: string, multi: { [component]: path }) |
| workflow | (선택) 워크플로우 요구사항 정책 (github/local, codeDirtyScope) |
| pr | (선택) PR 결과물 정책 (예: 스크린샷 업로드 여부) |
| approval | (선택) context 출력의 [확인 필요]/requiresUserCheck 정책 오버라이드 (자동화/반자동용) |

> docsRepo: "standalone"을 선택하면 pushDocs, docsRemote, projectRoot가 추가됩니다.

> 어디서 실행하든 설정을 찾을 수 있도록, CLI는 현재 디렉토리에서 상위로 올라가며 .lee-spec-kit.json 또는 docs/.lee-spec-kit.json을 탐색합니다.
> standalone 환경에서 docs 레포 바깥(예: 프로젝트 레포)에서 실행해야 한다면 LEE_SPEC_KIT_DOCS_DIR에 docs 레포 경로를 지정할 수 있습니다.

$3

approval은 context가 출력하는 다음 값에만 영향을 줍니다:

- 텍스트 출력의 [확인 필요] 표시
- context --json의 actions[].requiresUserCheck
- checkPolicy.token (context --json): 승인 토큰 형식 ()
- checkPolicy.acceptedTokens: 허용되는 승인 응답 템플릿 (예: ["", " OK"])
- checkPolicy.tokenPattern: 승인 응답 검증용 정규식
- checkPolicy.validLabels: 현재 선택 가능한 라벨 목록 (A, B, C...)
- checkPolicy.requireExplanationBeforeApproval: 승인 요청 전에 라벨별 설명을 포함해야 함
- checkPolicy.requiredExplanationFields: 라벨 설명에 사용할 필드 목록 (예: actionOptions[].summary)
- checkPolicy.contextVersion: stale context 검증용 스냅샷 해시

> 실제 명령 실행을 강제/차단하는 기능은 아닙니다. (에이전트가 참고하도록 신호를 제공)
> 기존 설정에 approval이 없으면 builtin으로 동작합니다. (마이그레이션 불필요)
> requiresUserCheck: true인 액션은 에이전트가 사용자로부터 정확히 <라벨> 또는 <라벨> OK 응답(예: A, A OK)을 받은 뒤 진행하는 것을 권장합니다.

$3

- workflow.mode: "github" (기본): Issue/브랜치/PR/리뷰 단계를 포함한 전체 워크플로우를 완료 조건으로 사용
- workflow.mode: "local": 로컬 중심 워크플로우로 동작하며 Issue/브랜치/PR/리뷰 단계를 필수로 요구하지 않음
- local 모드로 생성한 Feature 템플릿은 기본적으로 Issue/PR 중심 섹션을 축소합니다.
- workflow.codeDirtyScope:
- repo: 프로젝트 레포 전체 변경으로 코드 미커밋 여부를 판정
- component: 현재 Feature 컴포넌트 경로 변경만 판정 (multi 권장)
- auto: single => repo, multi => component
- workflow.componentPaths(선택): component 판정 경로를 컴포넌트별로 명시 (예: "web": ["apps/web", "packages/web-ui"])
- 하위 호환: 값이 없으면 기존 동작인 repo로 처리

예시:

`json
{
"workflow": { "mode": "local", "codeDirtyScope": "auto" }
}
`

#### 모드

- builtin (기본): 코드에 내장된 requiresUserCheck를 그대로 사용
- category (권장): actions[].category 기준으로 확인 정책을 제어
- steps: step 번호 기준(변경에 취약하므로 권장하지 않음)

#### 설정 필드

- default (category만): keep | require | skip (기본: keep)
- requireCheckCategories (category만): 확인을 항상 요구할 category 목록 (예: ["pr_create"], ["*"])
- skipCheckCategories (category만): 확인을 절대 요구하지 않을 category 목록 (예: ["docs_commit"], ["*"])
- requireCheckSteps (steps만): 확인이 필요한 step 번호 목록 (예: [3, 5, 12])

#### category 예시

`json
{
"approval": { "mode": "category", "default": "skip" }
}
`

`json
{
"approval": {
"mode": "category",
"default": "keep",
"skipCheckCategories": ["docs_commit"]
}
}
`

> 사용 가능한 category 값은 context --json의 actions[].category로 확인하는 것을 권장합니다.

$3

- pr.screenshots.upload (기본: false): true면 스크린샷을 업로드(예: GitHub Release assets)하고 PR 본문에 URL을 포함할 수 있습니다. false면 업로드/URL 포함을 하지 않으며 PR 본문에서도 스크린샷 섹션을 만들지 않는 것을 권장합니다.

$3

Single 프로젝트:

`json
{
"projectName": "my-project",
"projectType": "single",
"lang": "ko",
"createdAt": "YYYY-MM-DD",
"docsRepo": "standalone",
"pushDocs": false,
"projectRoot": "/path/to/my-project"
}
`

Multi 프로젝트:

`json
{
"projectName": "my-project",
"projectType": "multi",
"lang": "ko",
"createdAt": "YYYY-MM-DD",
"docsRepo": "standalone",
"pushDocs": false,
"projectRoot": {
"fe": "/path/to/frontend",
"be": "/path/to/backend"
}
}
`

$3

`bash


현재 설정 확인

| 옵션 | 설명 |
| -------------------- | ---- |
| --dir