Agent skill · product strategy · aiskillstore
scope
프로젝트 생성 이전 단계에서 요구사항·리서치를 바탕으로 프로젝트 범위산정(기능 목록·MoSCoW 우선순위·공수 추정)과 기술스택 확정(사용자 승인 게이트)을 수행하고 SCOPE 문서를 생성한다. 코드는 만들지 않는다. '/scope', '범위 산정', '스코프 잡아줘', 'MoSCoW', '기능 우선순위', '스택 확정', '뭘 만들지 정하자', '요구사항 정리해서 스택까지', 'PRD 비슷한 거' 등 언급 시 호출. 요구사항만으로 바로 프로젝트를 생성하기 전에, 무엇을 어느 범위로 어떤 스택으로 만들지 확정하는 결정 게이트가 필요할 때 반드시 사용.
Why this skill is useful
Adds a structured decision-making process for project scope and technology stack that the AI wouldn't reliably generate on its own.
What it needs
About 5k tokens when loaded. Last updated 2026-08-07. 405 stars on the source repository.
What this skill does
Scope — 프로젝트 범위산정 + 기술스택 확정 게이트 $ARGUMENTS 에 대해 요구사항과 리서치를 종합하여 무엇을 만들지(범위)와 무엇으로 만들지(스택)를 확정하고, docs/scope/SCOPE-.md를 생성한다. 존재 이유: 요구사항 한 줄만으로 스택을 채택해 프로젝트를 생성하는 것은 무리가 있다. 리서치가 시장성·경쟁·기술 트렌드를 조사한다면, /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 사이즈로 매긴다. 정밀 추정이 아니라 상대 규모와 리스크 식별이 목적이다. …
How to use it
Reference it in AdaL, Claude Code, Cursor or any coding agent — nothing to install:
@skills aiskillstore/scope