@qualisoft/ai-skills 1.0.0

package/skills/project-interview/INTERVIEW.md

@@ -0,0 +1,221 @@
+# 인터뷰 질문 은행
+
+단계별 질문과 선택지. **순서대로 다 묻지 않는다.** 이미 알게 된 것은 건너뛰고,
+답에 따라 다음 질문을 바꾼다.
+
+`AskUserQuestion`은 한 번에 최대 4문항이다. **묶음 단위로 묻는다.**
+모든 문항에 `아직 모름` 성격의 선택지를 하나 둔다 — 모른다고 답할 수 있어야
+빈칸을 지어내지 않는다.
+
+---
+
+## A. 정체 — 누구의 무엇인가
+
+| 질문 | 선택지 |
+| --- | --- |
+| 이 프로젝트는 누구의 것인가? | 우리 회사 자체 / 클라이언트 수주 / 사내 특정 부서 / 개인 |
+| 클라이언트·회사 이름 | (자유 입력) |
+| 업종 | 제조 / 유통·커머스 / 의료 / 금융 / 교육 / 물류 / IT·SaaS / 전문서비스 / 기타 |
+| 프로젝트 가칭 | (자유 입력) |
+
+> 이름은 나중에 바뀌어도 된다. **지금 부를 이름**만 정하면 된다.
+
+---
+
+## B. 문제 — 왜 만드는가 (가장 중요)
+
+이 단계를 대충 넘기면 나머지 전부가 흔들린다. 답이 얕으면 한 번 더 파고든다.
+
+| 질문 | 선택지 |
+| --- | --- |
+| 지금 무엇이 문제인가? | (자유 입력 — 증상을 그대로) |
+| 그 문제의 비용은 어디에 나타나는가? | 사람 시간 / 매출 기회 / 고객 이탈 / 오류·재작업 / 의사결정 지연 / 아직 모름 |
+| 지금은 어떻게 처리하고 있는가? | 수작업 / 엑셀 / 외부 서비스 / 기존 시스템 / 아무것도 안 함 |
+| 아무것도 안 만들면 어떻게 되는가? | 그대로 감당 가능 / 점점 악화 / 곧 못 버팀 / 기회를 놓침 |
+
+**파고드는 방법** — "왜 그게 문제인가"를 두 번 더 묻는다.
+증상(느린 응대) → 원인(문의가 흩어짐) → 근본(창구가 여러 개다).
+근본에 닿아야 해법이 달라진다.
+
+---
+
+## C. 대상 — 누구를 위한 것인가
+
+| 질문 | 선택지 |
+| --- | --- |
+| 실제로 쓰는 사람은? | 일반 소비자 / 기업 담당자 / 우리 직원 / 파트너사 / 여럿 |
+| 돈을 내거나 도입을 결정하는 사람은? | 사용자와 같음 / 다름 (경영진·구매팀 등) / 무료 |
+| 대략 몇 명이 쓰는가? | 10명 미만 / 수십 / 수백 / 수천 이상 / 아직 모름 |
+| 기술 친숙도는? | 높음 / 보통 / 낮음 (안내가 많이 필요) / 섞여 있음 |
+
+> 사용자와 결정자가 다르면 화면이 두 벌 필요할 수 있다. 반드시 확인한다.
+
+---
+
+## D. 성공 — 무엇이 되면 된 것인가
+
+| 질문 | 선택지 |
+| --- | --- |
+| 출시 3개월 뒤 무엇이 달라져 있어야 하는가? | (자유 입력) |
+| 그걸 어떻게 확인하는가? | 숫자로 측정 / 사용자 피드백 / 담당자 체감 / 아직 정할 수 없음 |
+| 이번에 실패라고 부를 조건은? | (자유 입력) |
+
+**측정 불가한 목표는 되묻는다.**
+"사용자를 늘리고 싶다" → 몇 명에서 몇 명으로, 언제까지.
+숫자를 모르면 "관찰 가능한 상태"로라도 바꾼다 — "문의가 한 곳에 모인다" 같은.
+
+기준 데이터가 없으면 **목표 수치를 지어내지 않는다.** "출시 후 N주를 베이스라인으로"로 남긴다.
+
+---
+
+## E. 범위 — 무엇을 만드는가
+
+| 질문 | 선택지 |
+| --- | --- |
+| 형태는? | 웹사이트 / 웹 애플리케이션 / 모바일 앱 / 사내 시스템 / AI 기능 / 아직 모름 |
+| 없으면 출시 못 하는 것 3가지 | (자유 입력) |
+| 있으면 좋지만 없어도 되는 것 | (자유 입력) |
+| **이번에 하지 않을 것** | (자유 입력) |
+
+반드시 **최종 목표 범위**와 **첫 출시 범위**를 따로 확인한다.
+
+| 질문 | 선택지 |
+| --- | --- |
+| 최종적으로 어디까지 필요한가? | 전체 목표를 자유 입력 / 아직 모름 |
+| 첫 공개에 반드시 필요한 것은? | 핵심 기능 3개 / 전체 동시 공개 / 아직 모름 |
+| 구조만 준비하고 공개는 미룰 것은? | 콘텐츠·관리·자동화 후보 / 없음 / 아직 모름 |
+
+사용자가 "전체"를 고르면 반대하지 말고, 콘텐츠·일정과 충돌하는지만 한 번 확인한다.
+
+> **"하지 않을 것"이 비어 있으면 기획안이 아니다.** 반드시 받아낸다.
+> 답을 못 하면 후보를 제시한다: 로그인 / 결제 / 다국어 / 관리자 화면 / 모바일 앱 / 알림.
+
+---
+
+## E-2. 규모 — 이 프로젝트는 얼마만 한가
+
+**반드시 묻는다.** 이 답이 2단계의 문서 개수를 결정한다.
+안 물으면 2주짜리 랜딩과 7개월짜리 커머스가 똑같은 문서 세트를 받는다.
+
+| 질문 | 선택지 |
+| --- | --- |
+| 만드는 데 얼마나 걸릴 것 같은가 / 몇 명이 붙는가 | `solo` 혼자, 몇 주 / `small` 1~2명, 1~2개월 / `standard` 팀, 3~6개월 / `large` 다인원, 6개월 이상 |
+| 돈이나 민감정보를 다루는가 | `low` 정보 제공만 / `standard` 로그인·개인정보 / `regulated` 결제·금융·의료·법정 의무 |
+| 이번에 어디까지 내보내는가 | `prototype` 보여주기용 / `mvp` 최소 기능 출시 / `production` 실운영 |
+
+**scale 은 사용자가 고른다.** 나머지 둘은 앞선 답에서 유도되면 그 값을 제시하고 확인만 받는다.
+
+- E항에서 결제·주문이 범위에 있으면 `risk: regulated` 를 제시한다
+- E항이 "시안만" 이면 `delivery: prototype` 를 제시한다
+- C항 사용자 수가 수천 이상이면 `scale` 을 한 단계 올려 제안한다
+
+> **모르면 넓은 쪽으로 둔다.** `scale: large`, `risk: regulated`, `delivery: production` 이 기본값이다.
+> 작게 잡아 문서를 잃는 것보다 크게 잡아 지우는 편이 낫다.
+
+---
+
+## E-3. 산출물 — 무엇을 납품하는가
+
+**반드시 묻는다.** 이 답이 2단계의 **산출물 정의서 v1** 이 되고, 거기서 WBS 과업이 나온다.
+안 물으면 "만들어 달라고 한 적 없는 문서"를 만들거나, 오픈 직전에 없는 문서를 급조한다.
+
+먼저 표준 목록을 한 번에 보여주고 **골라내게** 한다. 하나씩 묻지 않는다.
+
+| 질문 | 선택지 |
+| --- | --- |
+| 고객에게 **문서로** 납품해야 하는 것은? | 요구사항 정의서 / 화면 설계서 / 데이터 모델(ERD) / API 명세서 / 테스트 계획 / 사용자 가이드 / 운영 이관 문서 (복수 선택) |
+| 그중 **고객이 직접 읽는** 것은? | (위에서 고른 것 중 복수 선택) |
+| 위 목록에 없는데 요구받은 산출물이 있는가 | 자유 입력 / 없음 |
+| 산출물 목록을 **승인하는 사람**은? | 이름·역할 / 아직 모름 |
+
+그다음 **빼는 것**을 받아낸다.
+
+| 질문 | 선택지 |
+| --- | --- |
+| **납품하지 않기로 한 문서**는? | (고르지 않은 항목을 제시해 확인) |
+
+> **"고객이 직접 읽는가"를 반드시 나눈다.** 이 값이 ELI5 적용 범위를 정한다.
+> 고객이 읽는 산출물은 2단계에서 본문 전체를 평문으로 쓰고, 내부 문서는 요약만 평문으로 쓴다.
+
+> 사용자가 "다 필요하다"고 하면 반대하지 않되 **한 가지만 확인한다** —
+> "이 중에 고객이 실제로 검수하는 문서는 몇 개인가요?"
+> 보통 그 숫자가 진짜 필요한 산출물 수다.
+
+모르는 항목은 **대신 정하지 않고** `TODO(client)` 로 남긴다.
+2단계가 "물어본 적 없음"과 "물었지만 미정"을 구분해야 한다.
+
+---
+
+## F. 제약 — 조건은 무엇인가
+
+| 질문 | 선택지 |
+| --- | --- |
+| 일정 | 마감 확정 / 대략 목표 / 없음 |
+| 그 날짜인 이유는? | 계약·법적 기한 / 행사·영업 일정 / 내부 목표 / 특별한 이유 없음 |
+| 초기 제작비 | 확정 / 상한만 있음 / 직접 제작 / 미정 / 말하기 어려움 |
+| 월 고정 운영비 | 0원 우선 / 상한 있음 / 품질 우선 / 아직 모름 |
+| 사용량 비용 | 허용 / 상한 필요 / 발생하지 않게 / 아직 모름 |
+| 운영 시간 부담 | 직접 관리 가능 / 자동화 우선 / 최소화 우선 / 아직 모름 |
+| 기존 시스템과 연동이 필요한가? | 필요 (ERP·CRM 등) / 불필요 / 아직 모름 |
+| 기술 제약 | 사내 표준 스택 있음 / 특정 클라우드 지정 / 보안 요건 / 없음 |
+| 법·규제 | 개인정보 취급 / 산업 규제(의료·금융) / 접근성 의무(공공) / 해당 없음 |
+
+> "예산은 나중에"라고 하면 **범위 상한만이라도** 받는다. 범위는 예산에 종속된다.
+
+---
+
+## G. 보유 자산 — 이미 가진 것
+
+없는 것이 곧 리스크다. 2번 스킬이 이걸 Blocker로 올린다.
+
+| 질문 | 선택지 |
+| --- | --- |
+| 브랜드 자산 | 로고·가이드 있음 / 로고만 / 없음 |
+| 콘텐츠(글·이미지) | 준비됨 / 일부 / 없음 |
+| 도메인 | 보유 / 미보유 |
+| 실제 사례·실적 데이터 | 공개 가능 / NDA로 익명만 / 없음 |
+| 기존 사이트·시스템 | 있음 (이전 필요) / 있음 (별개) / 없음 |
+
+---
+
+## H. 팀 — 누가 결정하고 누가 주는가
+
+| 질문 | 선택지 |
+| --- | --- |
+| 최종 승인자 | 정해짐 / 여러 명 / 아직 모름 |
+| 콘텐츠·자료 제공자 | 정해짐 / 미정 |
+| 우리 쪽 개발 리소스 | 전담 / 겸업 / 외부 |
+
+> 승인자가 여러 명이면 일정 리스크다. 기획안에 그대로 적는다.
+
+---
+
+## I. 참고 사례
+
+| 질문 | 선택지 |
+| --- | --- |
+| 좋게 본 서비스 | (자유 입력) |
+| 그 서비스의 **어느 부분**이 좋았나? | 정보 구조 / 비주얼 / 속도 / 카피 / 특정 기능 |
+| **싫은** 사례 | (자유 입력) |
+
+> **싫은 레퍼런스가 정보량이 더 크다.** 반드시 묻는다.
+> "이렇게는 하지 마세요"가 디자인 방향을 가장 빠르게 좁힌다.
+
+---
+
+## J. 다음 단계 힌트 (2번 스킬 전달용)
+
+인터뷰 중 자연스럽게 드러나면 기록하고, 안 드러나면 묻지 않는다.
+
+| 항목 | 판단 근거 |
+| --- | --- |
+| 추천 프리셋 | E항 형태 답변 |
+| 검색 노출 필요 여부 | 공개 사이트인가, 사내 시스템인가 |
+| 국내/해외 대상 | C항 |
+| 광고 집행 계획 | 마케팅 언급 여부 |
+| 다국어 | C항, F항 |
+| 개인정보 취급 | F항 |
+
+`option_hints`는 일부만 쓰지 말고 아래 13개를 모두 기록한다:
+`seo`, `naver`, `geo`, `analytics`, `tagmanager`, `adtracking`, `consent`,
+`a11y`, `perfbudget`, `i18n`, `cms`, `contactform`, `darkmode`.

package/skills/project-interview/SKILL.md

@@ -0,0 +1,156 @@
+---
+name: project-interview
+description: 아이디어나 문제만 있는 상태에서 대화형 인터뷰로 기획안(브리프)을 만든다. 클라이언트·프로젝트 이름부터 문제·대상·성공 기준·범위·제약·보유 자산까지 선택형으로 물어 정리하고, project-init 스킬이 바로 흡수할 수 있는 기획안 md를 Docs/_intake/ 에 쓴다. "기획안 만들어줘", "이런 걸 만들고 싶은데", "프로젝트 시작하려는데", "아이디어가 있는데 정리해줘", "브리프 작성", "요구사항 정리" 같은 요청에 해당한다.
+---
+
+# project-interview
+
+**1단계 — 기획안 작성.** 머릿속의 문제·아이디어를 인터뷰로 끌어내 기획안 하나로 만든다.
+
+산출물은 기획안 1개와 추적 기록 2개, 총 3개다.
+그 다음은 `project-init` 스킬이 받아 문서 22종과 HTML로 펼친다.
+
+```
+[1] project-interview   아이디어 → 기획안        ← 이 스킬
+[2] project-init        기획안 → 문서 + HTML
+```
+
+## 원칙
+
+**1. 문제부터, 해법은 나중.**
+사용자가 "○○를 만들어줘"로 시작하면 **한 번은 되돌린다.** 무엇을 만들지가 아니라
+무엇이 문제인지를 먼저 확정한다. 해법을 먼저 고정하면 잘못된 것을 잘 만들게 된다.
+
+**2. 모르면 모른다고 적는다.**
+빈칸을 그럴듯하게 채우지 않는다. 미확정은 미확정으로 넘긴다 —
+2단계가 그걸 Blocker로 승격시킨다. 지어낸 값은 그 기회를 없앤다.
+
+**3. 선택지를 먼저 준다.**
+"어떤 기능이 필요하세요?" 같은 백지 질문은 답하기 어렵다. 후보를 제시하고 고르게 한다.
+모든 문항에 **"아직 모름"** 성격의 선택지를 둔다.
+
+**4. 한 번에 최대 4문항.**
+인터뷰가 심문이 되면 답변 품질이 떨어진다. 묶음으로 나눠 묻고, 답을 확인하며 진행한다.
+
+**5. 답에 따라 다음 질문을 바꾼다.**
+사내 시스템이면 검색 노출을 묻지 않는다. B2C면 개인정보를 더 묻는다.
+이미 말한 것을 다시 묻지 않는다.
+
+**6. 얕은 답은 되묻는다.** 아래 표 참조.
+
+## 되물어야 하는 신호
+
+| 이렇게 말하면 | 이렇게 되묻는다 |
+| --- | --- |
+| "앱으로 만들고 싶어요" | 왜 앱이어야 하는지. 웹으로 안 되는 이유가 있는지 |
+| "AI를 넣고 싶어요" | 어떤 작업을 대체·보조하는지. 규칙으로 처리되는 일은 아닌지 |
+| "일단 다 되게" | 없으면 출시 못 하는 것 3가지만 |
+| "경쟁사처럼" | 그 서비스의 **어느 부분**이 좋은지 |
+| "빨리요" | 마감 날짜와, 그 날짜여야 하는 이유 |
+| "예산은 나중에" | 범위 상한만이라도. 범위는 예산에 종속된다 |
+| 목표가 측정 불가 | 숫자로, 안 되면 관찰 가능한 상태로 |
+| "하지 않을 것"이 비어 있음 | 후보를 제시해서라도 받아낸다 |
+
+되묻는 것은 반대하는 게 아니다. 사용자가 이미 정했다고 하면 그 결정을 존중하고,
+**근거를 기획안에 적는다.**
+
+## 진행
+
+1. **먼저 사용자가 이미 말한 것을 정리해 보여준다.** "지금까지 이해한 것" 3~5줄.
+   틀린 부분을 먼저 잡는 것이 질문보다 빠르다.
+2. `INTERVIEW.md`의 단계(A~I)를 참고해 **묶음으로** 묻는다. 전부 묻지 않는다.
+   - 최소 필수: **A 정체 · B 문제 · D 성공 · E 범위 · E-2 규모**
+   - 나머지는 프로젝트 성격에 따라
+   - **E-2 규모는 건너뛰지 않는다.** 이 답이 2단계 문서 세트의 크기를 정한다.
+     안 물으면 2주짜리 랜딩과 7개월짜리 커머스가 똑같은 문서 33개를 받는다.
+3. 답을 받을 때마다 **모순이나 공백을 지적한다.**
+   "목표는 신규 고객 확보인데 대상이 기존 직원으로 되어 있습니다" 같은 것.
+4. 인터뷰가 끝나면 `templates/brief.md` 형식으로 기획안을 쓴다.
+5. `Docs/_intake/` 가 없으면 만들고 거기에 저장한다.
+6. `node validate.mjs <기획안> <결정기록> <미결기록>`으로 전달 계약을 검증한다. 스킬 회귀 점검에는 `fixtures/`의 익명 샘플 3개를 사용한다.
+7. 사용자에게 **요약 + 미확정 목록**을 보여주고 다음 단계를 안내한다.
+
+## 산출물 — 파일 3개
+
+| 파일 | 내용 |
+| --- | --- |
+| `Docs/_intake/YYYY-MM-DD-<slug>.md` | **기획안** (`templates/brief.md`). 2단계 흡수 대기열 |
+| `Docs/_discovery/decisions.md` | **인터뷰 결정 기록** (`templates/decisions.md`) |
+| `Docs/_discovery/open-questions.md` | **인터뷰 미결 사항** (`templates/open-questions.md`) |
+
+기획안 프론트매터에 2단계가 쓸 힌트를 담는다 — `profile`, `suggested_preset`, `option_hints`.
+그래야 2단계에서 같은 질문을 반복하지 않는다.
+
+기획안 **§7 산출물 범위**는 2단계의 **산출물 정의서 v1** 이 된다.
+2단계는 그 표에서 WBS 과업을 뽑으므로, 여기가 비면 과업 근거가 사라진다.
+`필요` 와 `고객 공유` 두 칸을 특히 정확히 받는다 — 후자가 ELI5 적용 범위를 정한다.
+모르는 행은 대신 정하지 말고 `TODO(client)` 로 남긴다.
+
+`profile` 은 **문서 세트의 크기를 정하는 축**이다. `suggested_preset` 이 *어떤 종류*를
+고른다면 `profile` 은 *얼마만큼*을 고른다. 둘 다 있어야 프로젝트에 맞는 분량이 나온다.
+
+| 축 | 값 | 정하는 것 |
+| --- | --- | --- |
+| `scale` | `solo` `small` `standard` `large` | 공수·인력 규모. 문서 수에 가장 크게 작용한다 |
+| `risk` | `low` `standard` `regulated` | 돈·개인정보·법규 취급 여부. 보안·권한 문서를 켠다 |
+| `delivery` | `prototype` `mvp` `production` | 완성도 목표. 출시 관련 문서를 켠다 |
+
+**모르면 넓은 쪽으로 둔다** — `large` / `regulated` / `production`.
+작게 잡아 문서를 잃는 것보다 크게 잡아 지우는 편이 낫다.
+
+2단계가 흡수를 마치면 기획안도 `Docs/_discovery/`로 옮겨진다.
+결국 **1단계 기록 3종이 한 폴더에 모이고**, HTML에서 `1단계 · 기획` 메뉴로 따로 보인다.
+
+### 기록 규칙 — 2단계와 섞지 않는다
+
+| | 1단계 (이 스킬) | 2단계 (project-init) |
+| --- | --- | --- |
+| 결정 | `DI-001` — 사람이 말로 정한 것 | `D-001` — 문서·기술을 만들며 정한 것 |
+| 미결 | `OQ-01` — 묻고 답을 못 받은 것 | `B-01` `H-01` `M-01` — 등급이 매겨진 리스크 |
+| 메뉴 | `1단계 · 기획` | 단계별 문서 그룹 |
+
+**인터뷰 도중에 바로 기록한다.** 끝나고 몰아서 쓰면 근거가 사라진다.
+
+- 사용자가 **명시적으로 정한 것** → `decisions.md`에 질문·답변·근거까지
+- 사용자가 **"모르겠다 / 나중에 / 확인해봐야 안다"** → `open-questions.md`
+  대신 정하지 않는다. 추정으로 채우면 2단계가 리스크로 인식할 기회를 잃는다.
+
+### 로그 작성자 규칙
+
+- 모든 `DI-`·`OQ-` 기록에 `일자`, `AI`, `계정`을 남긴다.
+- 일자는 로컬 시간 `YYYY-MM-DD HH:mm` 형식이다.
+- AI는 실제 작업 도구명(`Claude Code`, `Codex`, `Cursor` 등), 계정은 해당 도구의 사용자명 또는 작업자명이다.
+- 계정을 알 수 없으면 한 번만 묻고, 답이 없으면 `미확인`으로 기록한다. 추정하지 않는다.
+- 날짜별 `## YYYY-MM-DD` 아래에 항목을 두어 2단계 HTML에서 날짜 토글로 렌더되게 한다.
+- 같은 질문 묶음에서 나온 결정은 주제별로 합쳐 기록한다. 단순 자산 사실과 의사결정을 분리한다.
+
+### 2단계 전달 계약
+
+- `profile` 의 세 축을 모두 채운다. 값은 위 표의 것만 쓴다.
+- `option_hints`는 2단계 옵션 13개를 모두 포함한다. 값은 `true`, `false`, `unknown`만 쓴다.
+- 전체 목표 범위와 첫 출시 범위를 분리한다.
+- 비용은 초기비, 월 고정비, 사용량 비용, 운영 시간 부담으로 나눈다.
+- 기술 스택은 확정하지 않고 원본이 강제한 제약만 `stack_hints`에 전달한다.
+
+끝낼 때 이렇게 안내한다:
+
+```
+기획안을 만들었습니다.
+  Docs/_intake/2026-08-13-프로젝트명.md   기획안
+  Docs/_discovery/decisions.md            결정 N건
+  Docs/_discovery/open-questions.md       미결 N건
+
+미결 중 프로젝트를 막을 만한 것:
+  · OQ-02 …
+
+다음: /project-init ingest
+```
+
+## 하지 말 것
+
+- **인터뷰 없이 기획안을 쓰기.** 한 문장만 듣고 그럴듯한 10페이지를 만들면 전부 추측이다.
+  최소 A·B·D·E는 묻는다.
+- 확인되지 않은 수치·경쟁사 정보·시장 규모를 채워 넣기.
+- 사용자가 "모르겠다"고 한 것을 대신 정하기. 그대로 미확정으로 남긴다.
+- 기술 스택을 여기서 확정하기. 스택은 4단계이고, 2단계에서 버전까지 따로 묻는다.
+- 한 번에 20개 질문 던지기.

package/skills/project-interview/fixtures/brief.md

@@ -0,0 +1,49 @@
+---
+id: discovery-brief
+title: Example
+handoff_version: 4
+profile:
+  scale: standard
+  risk: standard
+  delivery: production
+suggested_preset: web-corporate
+option_hints:
+  seo: true
+  naver: true
+  geo: false
+  analytics: true
+  tagmanager: false
+  adtracking: false
+  consent: false
+  a11y: true
+  perfbudget: true
+  i18n: false
+  cms: false
+  contactform: true
+  darkmode: false
+---
+# Example
+
+## 최종 목표 범위
+기업 웹사이트.
+
+## 첫 출시 범위
+핵심 소개와 문의.
+
+## 이번에 하지 않는 것
+회원가입과 결제.
+
+## 산출물 범위
+
+| 산출물 | 필요 | 고객 공유 | 근거 |
+| --- | --- | --- | --- |
+| 요구사항 정의서 | 필수 | 공유 | 착수 협의 |
+| 화면 설계서 | 필수 | 공유 | 착수 협의 |
+| 데이터 모델(ERD) | 선택 | 내부 | 문의 폼만이라 단순 |
+| API 명세서 | 불필요 | — | 외부 연동 없음 |
+| 테스트 계획 | 선택 | 내부 | TODO(client) |
+| 사용자 가이드 | 불필요 | — | 공개 사이트라 불필요 |
+| 운영 이관 문서 | 필수 | 공유 | 고객사 자체 운영 |
+
+## 만들지 않기로 한 것
+API 명세서, 사용자 가이드.

package/skills/project-interview/fixtures/decisions.md

@@ -0,0 +1,13 @@
+---
+id: discovery-decisions
+title: Decisions
+---
+# Decisions
+
+## 2026-08-24
+
+### DI-001. 범위
+
+| 일자 | AI | 계정 |
+| --- | --- | --- |
+| `2026-08-24 13:00` | `Codex` | `example` |

package/skills/project-interview/fixtures/open-questions.md

@@ -0,0 +1,9 @@
+---
+id: discovery-open-questions
+title: Questions
+---
+# Questions
+
+| ID | 질문 | 일자 | AI | 계정 |
+| --- | --- | --- | --- | --- |
+| OQ-001 | 도메인 확정? | 2026-08-24 13:00 | Codex | example |

package/skills/project-interview/templates/brief.md

@@ -0,0 +1,179 @@
+---
+project: {{프로젝트명}}
+client: {{클라이언트/회사 — 자체 프로젝트면 자사명}}
+date: {{YYYY-MM-DD}}
+author: {{작성자}}
+handoff_version: 4
+# --- 2단계(project-init) 전달 힌트 ---
+# 프로젝트 프로필 — 문서 세트의 크기를 결정한다. 모르면 넓은 쪽으로 둔다.
+profile:
+  scale: {{solo | small | standard | large}}
+  risk: {{low | standard | regulated}}
+  delivery: {{prototype | mvp | production}}
+suggested_preset: {{web-corporate | mobile-app | internal-system | ai-product}}
+option_hints:
+  seo: {{true|false|unknown}}
+  naver: {{true|false|unknown}}
+  geo: {{true|false|unknown}}
+  analytics: {{true|false|unknown}}
+  tagmanager: {{true|false|unknown}}
+  adtracking: {{true|false|unknown}}
+  consent: {{true|false|unknown}}
+  a11y: {{true|false|unknown}}
+  perfbudget: {{true|false|unknown}}
+  i18n: {{true|false|unknown}}
+  cms: {{true|false|unknown}}
+  contactform: {{true|false|unknown}}
+  darkmode: {{true|false|unknown}}
+stack_hints: []
+---
+
+# {{프로젝트명}} 기획안
+
+> 이 문서는 인터뷰로 작성된 **기획안**이다. 확정된 것과 미확정을 구분해 적었다.
+> 여기 없는 내용은 아직 정해지지 않은 것이며, 추측으로 채우지 않았다.
+
+## 1. 개요
+
+| 항목 | 내용 |
+| --- | --- |
+| 프로젝트 | |
+| 클라이언트 | |
+| 업종 | |
+| 형태 | 웹사이트 / 웹앱 / 모바일 앱 / 사내 시스템 / AI 기능 |
+| 관계 | 자체 / 수주 / 사내 |
+
+## 2. 배경과 문제
+
+**증상** — 지금 무엇이 문제로 나타나고 있는가.
+
+**근본 원인** — 왜 그 문제가 생기는가.
+
+**비용** — 그 문제가 어디서 손해를 만드는가 (시간 / 매출 / 이탈 / 재작업 / 의사결정 지연).
+
+**현행 처리 방식** — 지금은 어떻게 버티고 있는가.
+
+**만들지 않으면** — 그대로 두면 어떻게 되는가.
+
+## 3. 목표와 성공 기준
+
+| # | 목표 | 성공 판단 |
+| --- | --- | --- |
+| G-01 | | |
+
+**실패 조건** — 무엇이 되면 이번 프로젝트는 실패인가.
+
+> 기준 데이터가 없으면 목표 수치를 만들지 않는다. "출시 후 N주를 베이스라인으로"로 남긴다.
+
+## 4. 대상 사용자
+
+| 구분 | 내용 |
+| --- | --- |
+| 실제 사용자 | |
+| 도입·구매 결정자 | (사용자와 다르면 반드시 구분) |
+| 규모 | |
+| 기술 친숙도 | |
+
+## 5. 범위
+
+**최종 목표 범위**
+
+**첫 출시 범위**
+
+**반드시 있어야 하는 것**
+
+1.
+2.
+3.
+
+**있으면 좋은 것**
+
+**이번에 하지 않는 것** ← 비어 있으면 안 된다
+
+## 6. 주요 기능 후보
+
+| 기능 | 필요 이유 | 우선도 |
+| --- | --- | --- |
+| | | 필수 / 선택 |
+
+> 여기서는 후보만. 요구사항 정의(수용 기준 포함)는 2단계 요구사항 정의서에서 한다.
+
+## 7. 산출물 범위
+
+2단계의 **산출물 정의서 v1** 이 되는 표다. 고객에게 무엇을 납품하는지의 최초 합의다.
+
+> 전부 채우지 못해도 된다. **모르는 행은 `TODO(client)` 로 두고 남긴다.**
+> 비워두면 2단계가 "물어본 적 없음"과 "물었지만 미정"을 구분할 수 없다.
+
+| 산출물 | 필요 | 고객 공유 | 근거 |
+| --- | --- | --- | --- |
+| 요구사항 정의서 | 필수 / 선택 / 불필요 | 공유 / 내부 | |
+| 화면 설계서 | | | |
+| 데이터 모델(ERD) | | | |
+| API 명세서 | | | |
+| 테스트 계획 | | | |
+| 사용자 가이드 | | | |
+| 운영 이관 문서 | | | |
+
+**이 프로젝트만의 산출물** — 위 목록에 없는데 고객이 요구한 것.
+
+| 산출물 | 요구한 사람 | 근거 |
+| --- | --- | --- |
+| | | |
+
+**만들지 않기로 한 것** ← 비어 있으면 안 된다
+
+> 납품 목록에서 **뺀 것을 적어두지 않으면** 오픈 직전에 "이건 왜 없냐"가 나온다.
+
+## 8. 제약
+
+| 구분 | 내용 |
+| --- | --- |
+| 일정 | (마감일과 그 날짜인 이유) |
+| 초기 제작비 | |
+| 월 고정 운영비 | |
+| 사용량 비용 | |
+| 운영 시간 부담 | |
+| 기존 시스템 연동 | |
+| 기술 제약 | |
+| 법·규제 | |
+
+## 9. 보유 자산과 부재
+
+| 자산 | 상태 |
+| --- | --- |
+| 로고·브랜드 가이드 | 있음 / 없음 |
+| 콘텐츠(글·이미지) | |
+| 도메인 | |
+| 실제 사례·실적 | 공개 가능 / NDA / 없음 |
+| 기존 사이트·시스템 | |
+
+> **없는 것이 곧 리스크다.** 2단계가 이 표를 보고 Blocker를 만든다.
+
+## 10. 이해관계자
+
+| 역할 | 담당 | 비고 |
+| --- | --- | --- |
+| 최종 승인 | | |
+| 콘텐츠 제공 | | |
+| 개발 | | |
+
+## 11. 참고 사례
+
+| 구분 | 사례 | 어느 부분이 |
+| --- | --- | --- |
+| 좋게 본 것 | | |
+| **피하고 싶은 것** | | |
+
+## 12. 미확정 목록
+
+인터뷰에서 답이 나오지 않은 것. **2단계에서 등급을 매겨 리스크 대장으로 올라간다.**
+
+| 항목 | 왜 필요한가 | 결정 주체 |
+| --- | --- | --- |
+| | | |
+
+## 13. 인터뷰 기록
+
+날짜, 참여자, 그리고 위 내용의 근거가 된 발언 요약.
+나중에 "이건 누가 정한 거지"를 되짚을 수 있게 남긴다.

package/skills/project-interview/templates/decisions.md

@@ -0,0 +1,55 @@
+---
+id: discovery-decisions
+title: 인터뷰 결정 기록
+summary: 1단계 인터뷰에서 확정된 것과 그 근거.
+date: {{YYYY-MM-DD}}
+---
+
+# 인터뷰 결정 기록
+
+> **1단계 기록이다.** 2단계의 의사결정 기록과 별개다.
+> 여기에는 *기획 단계에서 사람이 말로 정한 것*이 쌓이고,
+> 2단계에는 *문서·기술을 만들며 정한 것*이 쌓인다.
+
+## 기록 규칙
+
+- 인터뷰 중 사용자가 **명시적으로 정한 것**만 적는다. 추정은 적지 않는다.
+- 되물었을 때 사용자가 기존 판단을 유지했다면 그것도 결정이다. 근거를 함께 남긴다.
+- ID는 `DI-001` 형식. 2단계의 `D-001`과 구분된다.
+- 날짜별 H2 아래에 항목을 두고, 각 항목의 작성자 속성 표를 채운다.
+
+---
+
+## {{YYYY-MM-DD}}
+
+### DI-001. 제목
+
+| 일자 | AI | 계정 |
+| --- | --- | --- |
+| `{{YYYY-MM-DD HH:mm}}` | `{{AI}}` | `{{계정}}` |
+
+**질문** 무엇을 물었는가
+**답변** 사용자가 무엇이라 답했는가
+**결정** 그래서 무엇으로 확정했는가
+**근거** 사용자가 든 이유. 없으면 "근거 미제시"라고 적는다
+**영향** 이 결정이 이후 무엇을 제약하는가
+
+---
+
+## 템플릿
+
+```
+## YYYY-MM-DD
+
+### DI-00N. 제목
+
+| 일자 | AI | 계정 |
+| --- | --- | --- |
+| `YYYY-MM-DD HH:mm` | `Claude Code|Codex|Cursor|기타` | `계정 또는 작업자명` |
+
+**질문**
+**답변**
+**결정**
+**근거**
+**영향**
+```