New Context

1. 도메인 확인

• 인자로 도메인명이 주어지면 그대로 사용한다.
• 인자가 없으면 도메인명과 한 줄 설명을 묻는다.
• context/{도메인}/이 이미 존재하면 안내 후 종료한다.

2. 검증 질문 (1라운드)

AskUserQuestion으로 아래 4개를 한 번에 묻는다:

1. 문제: 이 도메인에서 풀려는 문제가 뭔가?
2. 현재 프로세스: 지금은 어떻게 하고 있는가?
3. 안 하면: 이걸 안 하면 어떻게 되는가?
4. 사용자/규모: 예상 사용자와 규모는?

3. 답변 품질 판단

답변을 받은 뒤 아래를 확인한다:

• 4개 중 3개 이상 구체적 → 4단계로 진행
• 모호한 답변이 2개 이상 → 심화 질문 1라운드 추가 (3-1단계)

모호함 판단 기준:

• 정량 수치 없이 "많다", "자주", "크다"만 있는 경우
• 대상이 불명확한 경우 ("사용자들", "팀원들")
• "효율화", "개선", "자동화" 등 추상어만 있는 경우

3-1. 심화 질문 (선택적, 최대 1라운드)

모호했던 항목에 대해서만 구체화를 요청한다:

• 현재 프로세스 비용을 정량화할 수 있는가? (주당 시간, 빈도, 인력)
• 성공 기준을 숫자로 말할 수 있는가?
• 더 단순한 대안은 검토했는가?
• 실패 시 영향 범위는?

여전히 모르는 항목은 ❓로 남기고 진행한다. 2라운드 이상 반복하지 않는다.

4. 관련 프로젝트 확인

AskUserQuestion으로 묻는다:

• 관련 레포: 이 도메인과 관련된 GHE 레포가 있는가? (예: xx/factory-api, yy/factory-admin)

레포가 있으면 각 레포의 역할도 함께 기록한다. 아직 없으면 빈 테이블로 생성한다.

5. 디렉토리 생성

context/{도메인}/
├── README.md          ← 검증 질문 답변 정리
├── PROJECTS.md        ← 관련 프로젝트(레포) 목록
├── glossary.md        ← 용어 사전 스켈레톤
├── architecture.md    ← 전체 구조 요약 + 주제 문서 링크 (인덱스)
└── status.md          ← 구현 추적

6. README.md 작성

검증 질문 답변을 아래 구조로 정리한다:

# {도메인명}

{한 줄 설명}

## 배경

{문제 + 현재 프로세스를 서술형으로 정리}

## 안 하면 어떻게 되는가

{답변 정리. 정량 수치 포함}

## 사용자와 규모

{누가, 몇 명, 얼마나 자주}

## 성공 기준

{정량적 기준. 미확인 시 ❓ 표기}

## 현재 상태

탐색 중

• 답변에서 ❓인 항목은 그대로 ❓로 남긴다.
• 사용자의 답변을 과도하게 다듬지 않는다. 핵심만 정리.

7. PROJECTS.md 작성

# {도메인명} 관련 프로젝트

| 레포 | 역할 |
|------|------|
| {org/repo} | {역할} |

관련 레포가 없으면 빈 테이블로 생성한다.

8. glossary.md 작성

# {도메인명} 용어 사전

| 용어 | 설명 |
|------|------|

9. architecture.md 작성

# {도메인명} 아키텍처

> 전체 구조 요약과 주제별 상세 문서 링크를 관리합니다.

## 시스템 구조

(확정 시 작성)

## 주제 문서

| 주제 | 설명 |
|------|------|

9-1. status.md 작성

# {도메인명} 구현 추적

> PRD 요구사항별 구현 상태를 추적합니다.

## 범례

- ✅ 반영됨 — 코드에 구현 완료
- ⬜ 미반영 — 정책/설계만 확정, 코드 미구현

주제 문서 헤더 템플릿

아래는 /dev 환류 등으로 주제 문서를 생성할 때 사용하는 헤더 형식이다. /new-context 실행 시에는 생성하지 않는다.

# {제목}

- 작성일: YYYY-MM-DD
- 수정일: YYYY-MM-DD
- 관련 레포: {org/repo}

10. 인덱스 업데이트

context/README.md의 도메인 테이블에 새 행을 추가한다.

11. 완료 안내

생성된 파일 목록과 ❓ 항목(있다면)을 안내한다.