scope

name	scope
description	프로젝트 생성 이전 단계에서 요구사항·리서치를 바탕으로 프로젝트 범위산정(기능 목록·MoSCoW 우선순위·공수 추정)과 기술스택 확정(사용자 승인 게이트)을 수행하고 SCOPE 문서를 생성한다. 코드는 만들지 않는다. '/scope', '범위 산정', '스코프 잡아줘', 'MoSCoW', '기능 우선순위', '스택 확정', '뭘 만들지 정하자', '요구사항 정리해서 스택까지', 'PRD 비슷한 거' 등 언급 시 호출. 요구사항만으로 바로 프로젝트를 생성하기 전에, 무엇을 어느 범위로 어떤 스택으로 만들지 확정하는 결정 게이트가 필요할 때 반드시 사용.
argument-hint	[프로젝트명 또는 요구사항] [--from RESEARCH-*.md] [--quick] [--skip-stack] [--stdout]

Scope — 프로젝트 범위산정 + 기술스택 확정 게이트

$ARGUMENTS 에 대해 요구사항과 리서치를 종합하여 **무엇을 만들지(범위)**와 **무엇으로 만들지(스택)**를 확정하고, docs/scope/SCOPE-*.md를 생성한다.

PARSE → INTAKE → SCOPE → STACK(승인 게이트) → REPORT

존재 이유: 요구사항 한 줄만으로 스택을 채택해 프로젝트를 생성하는 것은 무리가 있다. 리서치가 시장성·경쟁·기술 트렌드를 조사한다면, /scope는 그 조사와 요구사항을 받아 결정을 내린다 — 기능 범위를 자르고, 우선순위를 매기고, 스택을 사용자 승인으로 확정한다. 이 산출물(SCOPE-*.md)은 이후 프로젝트 스캐폴딩·계획 워크플로우가 입력으로 사용한다.

경계

	리서치(조사)	/scope	프로젝트 생성(스캐폴딩)
역할	조사(넓게)	결정(자르고 확정)	코드 골격 생성
출력	RESEARCH-*.md	SCOPE-*.md	프로젝트 구조·설정
코드 변경	없음	없음	있음

---

Phase 0: PARSE — 인자 파싱

인자	기본값	설명
프로젝트명/요구사항	(필수)	첫 인자 또는 자연어. 없으면 AskUserQuestion으로 수집
--from {파일}	자동 탐색	참조할 RESEARCH-*.md 경로
--quick	OFF	스택 후보 간이 비교(3축) — 상세 트레이드오프 생략
--skip-stack	OFF	범위산정만 수행, 스택 확정 게이트 생략
--stdout	OFF	파일 생성 없이 대화에서 직접 출력

---

Phase 1: INTAKE — 요구사항·리서치 로드

1-1. 리서치 자료 확인

docs/research/RESEARCH-*.md를 Glob으로 탐색한다. team-research가 함께 설치돼 있으면 그 산출물(RESEARCH-*.md)을 결정 근거로 활용할 수 있다:

상황	동작
--from 지정 또는 RESEARCH 존재	Read → 시장성·경쟁·스택 후보·권장안을 결정 근거로 로드
RESEARCH 없음	요구사항만으로 진행하되, REPORT에 "리서치 미수행 — 사전 리서치 선행 권장"을 경고로 남긴다. 스택 확정 근거가 약해지므로 사용자에게 사전 리서치를 제안한다

기존 docs/scope/SCOPE-*.md가 있으면 덮어쓰지 않고 날짜로 구분한다.

1-2. 요구사항 명확화

요구사항이 모호하면 AskUserQuestion으로 핵심을 확정한다. 과도한 질문은 피하고, 범위·스택 결정에 실제로 영향을 주는 것만 묻는다:

1. 핵심 문제/타겟 사용자는? (범위의 기준선)
2. 반드시 있어야 할 기능 vs 있으면 좋은 기능? (MoSCoW의 원천)
3. 선호/제외 기술, 배포 환경 제약은? (스택의 하드 제약)
4. 규모 감(개인 토이 / MVP / 프로덕션)? (공수·스택 무게 결정)

---

Phase 2: SCOPE — 범위산정

요구사항을 실행 가능한 기능 단위로 분해하고 우선순위·공수를 매긴다. 이 단계의 목적은 "다 만들 수 없다"를 전제로 무엇을 먼저·무엇을 나중·무엇을 안 할지 명시적으로 자르는 것이다.

2-1. 기능 목록 도출

요구사항에서 사용자 관점의 기능(feature)을 추출한다. 구현 태스크가 아닌 사용자가 얻는 가치 단위로 쓴다 (예: "JWT 토큰 검증"이 아니라 "로그인해서 내 데이터에 접근").

2-2. MoSCoW 우선순위

각 기능을 4등급으로 분류한다. 근거를 한 줄씩 남긴다 — 나중에 왜 그렇게 잘랐는지 추적 가능해야 한다.

등급	의미	기준
Must	없으면 제품이 성립 안 됨	핵심 가치의 최소 집합
Should	중요하나 초기엔 없어도 됨	1차 릴리스 직후
Could	있으면 좋음	여유 시
Won't (now)	이번엔 안 함	명시적 제외 — 스코프 크립 방지

Must는 냉정하게 줄인다. Must가 전체의 절반을 넘으면 우선순위가 서지 않은 것이다. MVP의 Must는 보통 3~7개다.

2-3. 공수 추정

각 기능(최소 Must+Should)에 대략적 규모를 T-shirt 사이즈로 매긴다. 정밀 추정이 아니라 상대 규모와 리스크 식별이 목적이다.

사이즈	감각	표시
S	반나절 이하	낮은 리스크
M	1~2일	보통
L	3~5일	검증 필요
XL	1주+ 또는 불확실	⚠️ 분할·선행 리서치 후보

XL 항목은 "왜 큰지 / 쪼갤 수 있는지"를 함께 적는다. 불확실성이 큰 XL은 선행 리서치 대상으로 표시한다.

---

Phase 3: STACK — 기술스택 확정 (사용자 승인 게이트)

--skip-stack 시 이 단계를 건너뛴다.

범위(특히 Must 기능)가 요구하는 기술 역량을 기준으로 스택을 확정한다. 조사가 목적이 아니라 결정이 목적이다 — 폭넓은 조사가 필요하면 리서치 스킬(research·team-research가 설치돼 있으면 활용)로 위임하고, 여기서는 그 결과 위에서 채택 결정을 내린다.

3-1. 후보 도출

상황	방식
RESEARCH 존재	권장안을 1순위 후보로, 대안을 2순위로 사용 (재조사 안 함)
RESEARCH 없음	Must 기능이 요구하는 카테고리(프론트/백엔드/DB/인증/배포 등)별로 표준 후보를 제시. 논쟁적·고위험 선택은 "사전 리서치 선행 권장"으로 표시하고 임의 확정하지 않는다

3-2. 카테고리별 비교

범위에 필요한 카테고리만 다룬다 (없는 카테고리는 생략). --quick 시 3축(적합성/생태계/학습곡선)만, 기본은 트레이드오프까지.

카테고리: {예: 프론트엔드 프레임워크}
후보:     A / B
비교축:   범위 적합성 · 생태계·유지보수 · 학습곡선 · (기본) 성능·확장성
추천:     A — {한 줄 근거, Must 기능과 연결}

3-3. 확정 게이트 ⏸

카테고리별 추천안을 모아 AskUserQuestion으로 사용자 승인을 받는다. 이 게이트가 이 스킬의 핵심이다 — 스택은 되돌리기 비싼 결정이므로 모델이 임의 확정하지 않는다.

응답	동작
승인	확정 스택으로 REPORT 진행
특정 카테고리 변경	해당 카테고리만 교체 후 재확인
리서치 필요	사전 리서치 선행 권장 후 종료

확정된 각 선택에 **채택 근거 한 줄(ADR-lite)**을 기록한다 — 나중에 "왜 이걸 골랐지"에 답할 수 있도록.

---

Phase 4: REPORT — SCOPE 문서 생성

--stdout 시 파일 생성 없이 아래 내용을 대화에 출력하고 종료한다.

4-1. 파일 경로

mkdir -p {프로젝트 루트}/docs/scope

주제 슬러그(영문 kebab-case, 한글은 의미 번역, ≤30자)를 결정하여:

docs/scope/SCOPE-{슬러그}-{YYYY-MM-DD}.md

4-2. 문서 포맷

# {프로젝트명} 범위·스택 확정서

> 생성일: {날짜}
> 기반 리서치: {RESEARCH 파일명 또는 "없음 — 사전 리서치 미수행"}
> 상태: 확정 (스택 사용자 승인 완료 / 또는 --skip-stack)

---

## 1. 프로젝트 정의
- 해결 문제 / 타겟 사용자:
- 성공 기준(무엇이 되면 1차 완성인가):
- 규모 포지션: 토이 / MVP / 프로덕션

## 2. 기능 범위 (MoSCoW)

### Must (핵심 — 이게 없으면 성립 안 됨)
| 기능 | 공수 | 근거 |
|---|---|---|
| ... | S/M/L/XL | ... |

### Should / Could
| 기능 | 등급 | 공수 |
|---|---|---|

### Won't (now) — 명시적 제외
- ... (스코프 크립 방지용)

## 3. 확정 기술 스택
| 카테고리 | 채택 | 대안 | 채택 근거(ADR-lite) |
|---|---|---|---|
| ... | ... | ... | ... |

> ⚠️ (리서치 미수행 시) 이 스택은 요구사항 기반 잠정 추천이다. 확정 전 사전 리서치 권장.

## 4. 리스크 & 선행 과제
- XL·불확실 항목: {분할/리서치 필요}
- 미해결 결정:

---
> 이 문서는 이후 프로젝트 스캐폴딩·계획 워크플로우의 입력 기준이다.

4-3. 요약 출력

📐 범위·스택 확정 완료
══════════════════════════════════
프로젝트:  {이름}
문서:      docs/scope/SCOPE-{슬러그}-{날짜}.md
──────────────────────────────────
[범위]   Must {n} · Should {n} · Could {n} · Won't {n}
[공수]   Must 합 ≈ {S×n M×n L×n XL×n}
[스택]   {카테고리별 확정 요약 한 줄}
[리스크] {XL·미해결 건수}
══════════════════════════════════
→ 이 확정서 기반으로 프로젝트 스캐폴딩·계획 워크플로우 진행
→ 불확실 XL 항목은 사전 리서치로 선행 조사

---

후속 워크플로우와의 연결

• 리서치 → /scope: RESEARCH-*.md를 근거로 로드하여 스택 확정에 사용. 조사↔결정 역할 분리. (team-research가 함께 설치돼 있으면 그 산출물을 자동 활용)
• /scope → 프로젝트 스캐폴딩: SCOPE-*.md가 프로젝트 구조 생성 워크플로우의 입력이 된다. 스캐폴딩 단계는 확정 스택으로 구조만 세운다.
• /scope → 계획 수립: 확정된 Must/Should 기능이 이후 SubTask 수립의 원천.
• 사전 리서치: 스택 확정 게이트에서 논쟁적 선택이나 불확실 XL이 나오면 선행 위임.

---

특수 인자

인자	설명
--from {파일}	참조할 RESEARCH-*.md 명시 (미지정 시 docs/research/ 자동 탐색)
--quick	스택 비교 3축만 — 빠른 확정
--skip-stack	범위산정만, 스택 확정 게이트 생략
--stdout	파일 생성 없이 대화 출력

---

주의사항

• 코드 수정 금지 — 이 스킬은 결정과 문서화만 한다. 구조·코드 생성은 이후 스캐폴딩 워크플로우 역할.
• 조사를 재발명하지 않는다 — 폭넓은 조사는 리서치 스킬에 위임. 여기서는 그 위에서 결정한다.
• 스택은 사용자 승인 없이 확정하지 않는다 — 되돌리기 비싼 결정이므로 게이트를 건너뛰지 않는다(--skip-stack 명시 제외).
• Must를 냉정하게 자른다 — 우선순위가 서지 않은 범위는 산정이 아니다.
• 리서치 미수행 시 스택은 "잠정"으로 표기하고 사전 리서치 선행을 권장한다.
• 기존 SCOPE-*.md는 덮어쓰지 않고 날짜로 구분한다.
• 문서에 API 키·비밀번호 등 민감 정보를 포함하지 않는다.