---
description: 작업 생성 후 spec.md, plan.md, tasks.md 전반에 걸쳐 비파괴적 교차 산출물 일관성 및 품질 분석을 수행합니다.
---

## 언어 설정

모든 출력과 사용자와의 대화는 **한국어**로 진행합니다.

## 사용자 입력

```text
$ARGUMENTS
```

입력이 비어있지 않다면 진행하기 전에 **반드시** 사용자 입력을 고려해야 합니다.

## 목표

구현 전에 세 가지 핵심 산출물(`spec.md`, `plan.md`, `tasks.md`) 전반에 걸쳐 불일치, 중복, 모호성, 미명세 항목을 식별합니다. 이 명령은 `/speckit.tasks`가 완전한 `tasks.md`를 성공적으로 생성한 후에만 실행해야 합니다.

## 운영 제약사항

**엄격한 읽기 전용**: 파일을 수정하지 **마세요**. 구조화된 분석 보고서를 출력합니다. 선택적 수정 계획 제공(사용자가 후속 편집 명령을 수동으로 호출하기 전에 명시적으로 승인해야 함).

**헌법 권한**: 프로젝트 헌법(`.specify/memory/constitution.md`)은 이 분석 범위 내에서 **협상 불가**입니다. 헌법 충돌은 자동으로 CRITICAL이며 명세서, 계획 또는 작업의 조정이 필요합니다—원칙의 희석, 재해석 또는 무시가 아닙니다. 원칙 자체를 변경해야 하는 경우 `/speckit.analyze` 외부의 별도 명시적 헌법 업데이트에서 발생해야 합니다.

## 실행 단계

### 1. 분석 컨텍스트 초기화

저장소 루트에서 `.specify/scripts/bash/check-prerequisites.sh --json --require-tasks --include-tasks`를 한 번 실행하고 JSON에서 FEATURE_DIR과 AVAILABLE_DOCS를 파싱합니다. 절대 경로 도출:

- SPEC = FEATURE_DIR/spec.md
- PLAN = FEATURE_DIR/plan.md
- TASKS = FEATURE_DIR/tasks.md

필수 파일이 없으면 오류 메시지와 함께 중단(사용자에게 누락된 전제조건 명령을 실행하도록 안내).
"I'm Groot"와 같이 인수에 작은따옴표가 있는 경우 이스케이프 구문 사용: 예: 'I'\''m Groot' (또는 가능하면 큰따옴표: "I'm Groot").

### 2. 산출물 로드(점진적 공개)

각 산출물에서 최소한 필요한 컨텍스트만 로드:

**spec.md에서:**

- 개요/컨텍스트
- 기능 요구사항
- 비기능 요구사항
- 사용자 스토리
- 엣지 케이스(있는 경우)

**plan.md에서:**

- 아키텍처/스택 선택
- 데이터 모델 참조
- 단계
- 기술적 제약사항

**tasks.md에서:**

- 작업 ID
- 설명
- 단계 그룹화
- 병렬 마커 [P]
- 참조된 파일 경로

**헌법에서:**

- 원칙 검증을 위해 `.specify/memory/constitution.md` 로드

### 3. 시맨틱 모델 구축

내부 표현 생성(출력에 원시 산출물 포함하지 않음):

- **요구사항 인벤토리**: 안정적인 키가 있는 각 기능 + 비기능 요구사항(명령형 구문에 기반한 슬러그 도출; 예: "사용자가 파일을 업로드할 수 있음" → `user-can-upload-file`)
- **사용자 스토리/동작 인벤토리**: 인수 기준이 있는 개별 사용자 동작
- **작업 범위 매핑**: 각 작업을 하나 이상의 요구사항 또는 스토리에 매핑(키워드/ID 또는 핵심 구문과 같은 명시적 참조 패턴에 의한 추론)
- **헌법 규칙 세트**: 원칙 이름과 MUST/SHOULD 규범적 진술 추출

### 4. 감지 패스(토큰 효율적 분석)

고신호 발견에 집중. 총 50개 발견으로 제한; 나머지는 오버플로우 요약에서 집계.

#### A. 중복 감지

- 거의 중복된 요구사항 식별
- 통합을 위해 낮은 품질의 표현 표시

#### B. 모호성 감지

- 측정 가능한 기준이 없는 모호한 형용사(빠른, 확장 가능한, 안전한, 직관적인, 견고한) 플래그
- 해결되지 않은 플레이스홀더(TODO, TKTK, ???, `<placeholder>` 등) 플래그

#### C. 미명세

- 동사가 있지만 객체나 측정 가능한 결과가 없는 요구사항
- 인수 기준 정렬이 누락된 사용자 스토리
- 명세서/계획에 정의되지 않은 파일이나 컴포넌트를 참조하는 작업

#### D. 헌법 정렬

- MUST 원칙과 충돌하는 요구사항 또는 계획 요소
- 헌법에서 요구하는 섹션이나 품질 게이트 누락

#### E. 범위 갭

- 연관된 작업이 0개인 요구사항
- 매핑된 요구사항/스토리가 없는 작업
- 작업에 반영되지 않은 비기능 요구사항(예: 성능, 보안)

#### F. 불일치

- 용어 드리프트(동일한 개념이 파일에 따라 다르게 명명됨)
- 계획에서 참조되지만 명세서에 없는(또는 그 반대) 데이터 엔티티
- 작업 순서 모순(예: 의존성 노트 없이 기반 설정 작업 전 통합 작업)
- 충돌하는 요구사항(예: 하나는 Next.js를 요구하고 다른 하나는 Vue를 지정)

### 5. 심각도 할당

이 휴리스틱을 사용하여 발견 우선순위 지정:

- **CRITICAL**: 헌법 MUST 위반, 핵심 명세서 산출물 누락, 또는 기본 기능을 차단하는 범위가 0인 요구사항
- **HIGH**: 중복 또는 충돌하는 요구사항, 모호한 보안/성능 속성, 테스트 불가능한 인수 기준
- **MEDIUM**: 용어 드리프트, 누락된 비기능 작업 범위, 미명세 엣지 케이스
- **LOW**: 스타일/표현 개선, 실행 순서에 영향을 주지 않는 사소한 중복

### 6. 간결한 분석 보고서 생성

다음 구조로 마크다운 보고서 출력(파일 쓰기 없음):

## 명세서 분석 보고서

| ID | 카테고리 | 심각도 | 위치 | 요약 | 권장사항 |
|----|----------|--------|------|------|----------|
| A1 | 중복 | HIGH | spec.md:L120-134 | 두 개의 유사한 요구사항 ... | 표현 병합; 더 명확한 버전 유지 |

(발견당 한 행 추가; 카테고리 이니셜이 접두사로 붙은 안정적인 ID 생성.)

**범위 요약 테이블:**

| 요구사항 키 | 작업 있음? | 작업 ID | 참고사항 |
|-------------|-----------|---------|----------|

**헌법 정렬 문제:** (있는 경우)

**매핑되지 않은 작업:** (있는 경우)

**지표:**

- 총 요구사항
- 총 작업
- 범위 % (≥1 작업이 있는 요구사항)
- 모호성 수
- 중복 수
- Critical 문제 수

### 7. 다음 조치 제공

보고서 끝에 간결한 다음 조치 블록 출력:

- CRITICAL 문제가 있으면: `/speckit.implement` 전에 해결 권장
- LOW/MEDIUM만 있으면: 사용자가 진행할 수 있지만 개선 제안 제공
- 명시적 명령 제안 제공: 예: "정제와 함께 /speckit.specify 실행", "아키텍처 조정을 위해 /speckit.plan 실행", "'performance-metrics'에 대한 범위 추가를 위해 tasks.md 수동 편집"

### 8. 수정 제공

사용자에게 질문: "상위 N개 문제에 대한 구체적인 수정 편집을 제안해 드릴까요?" (자동으로 적용하지 마세요.)

## 운영 원칙

### 컨텍스트 효율성

- **최소한의 고신호 토큰**: 철저한 문서화가 아닌 실행 가능한 발견에 집중
- **점진적 공개**: 산출물을 점진적으로 로드; 모든 내용을 분석에 덤프하지 않음
- **토큰 효율적 출력**: 발견 테이블을 50행으로 제한; 오버플로우 요약
- **결정론적 결과**: 변경 없이 재실행하면 일관된 ID와 수를 생성해야 함

### 분석 가이드라인

- **파일 수정 안 함** (이것은 읽기 전용 분석)
- **누락된 섹션을 환각하지 않음** (없으면 정확하게 보고)
- **헌법 위반 우선순위 지정** (이것들은 항상 CRITICAL)
- **철저한 규칙보다 예시 사용** (일반적인 패턴이 아닌 구체적인 인스턴스 인용)
- **문제 없음을 우아하게 보고** (범위 통계와 함께 성공 보고서 출력)

## 컨텍스트

$ARGUMENTS
