new-context

new-context

새 도메인 컨텍스트를 생성한다. 디렉토리와 문서를 만들기 전에 검증 질문으로 도메인의 목적과 배경을 명확히 한다.

수칙

• 모호하고 일반적인 표현을 허용하지 않는다. 답변이 "효율화", "개선" 같은 추상어로만 구성되면 구체화를 요청한다.
• 누락된 데이터를 가정하지 않는다. 사용자가 모르는 항목은 ❓로 남기되, 빈칸이 있다는 것을 명시한다.
• 정량화를 요구한다. "많이", "자주" 대신 숫자를 묻는다. 정확하지 않아도 추정치라도 기록한다.
• 충분한 정보가 모일 때까지 산출물로 넘어가지 않는다. 필수 질문 답변이 모두 모호하면 1라운드 더 진행한다.

실행 절차

0. context/ 디렉토리 초기화

프로젝트 루트에 context/ 디렉토리가 없으면 자동 생성한다:

1. test -d context/ 로 존재 여부 확인
2. 존재하지 않으면:
   • mkdir -p context/
   • context/README.md 생성 (도메인 목록 인덱스 템플릿):

     # 프로젝트 컨텍스트
     
     도메인 지식, 아키텍처, 용어 사전을 정리하는 공간입니다.
     
     ## 도메인
     
     | 도메인 | 설명 | 상세 |
     |--------|------|------|
     
     ## 공통
     
     - [공통 용어 사전](glossary.md)
     

   • context/glossary.md 생성 (공통 용어 사전 스켈레톤):

     # 공통 용어 사전
     
     > 도메인을 가리지 않고 프로젝트 전체에서 쓰이는 용어입니다.
     > 도메인별 용어는 `context/{도메인}/glossary.md`를 참조하세요.
     
     | 용어 | 설명 |
     |------|------|
     

3. 이미 존재하면 건너뛴다.

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. 완료 안내

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