write-book

Files (4)

• SKILL.md
• business-rules.md · templates/
• features.md · templates/
• readme.md · templates/

SKILL.md (first lines)

# Skill: Write Book

## 목적

각 도메인의 **Domain Book을 완성**하고 최종 검증

**철학**: "책의 모든 장(chapter)을 완벽하게 마무리"

---

## 입력

- 도메인 이름 (예: "users")
- Phase 3 결과 (`domain-model.md`)
- Phase 4 결과 (`api-spec.md`)
- SESSION.md (Phase 1-2 결과)

---

## 출력

각 도메인당 5개 파일:
- `README.md` (도메인 개요)
- `features.md` (기능 정의)
- `domain-model.md` ✅ (Phase 3 완성)
- `api-spec.md` ✅ (Phase 4 완성)
- `business-rules.md` (비즈니스 규칙)

---

## 작동 방식

### 1. 도메인 의존성 분석

각 domain-model.md에서 다른 도메인을 참조하는지 확인한다:

```
domain-model.md 검토:
  - "번역 기록은 반드시 한 명의 사용자에게 속한다" → translations는 users에 의존

의존성 맵:
  users:        []              (독립)
  translations: [users]         (users 완료 후 작성)
  missions:     [users]         (users 완료 후 작성)
  phrases:      []              (독립)
```

### 2. Topological Sort로 작성 순서 결정

의존성이 없는 도메인부터 먼저 작성하고, 의존 도메인은 선행 도메인 완료 후 작성한다:

```
1단계 (동시): users, phrases
2단계 (동시): translations, missions  ← users 완료 후
```

### 3. 각 도메인 파일 작성

domain-model.md + api-spec.md + SESSION.md를 읽고 3개 파일을 생성한다:

**README.md**: 도메인 역할 한 줄 요약 + 목차 + 다른 도메인과의 관계 + 통계
**features.md**: 기능별 사용자 시나리오 + 범위 밖(Out of Scope) 명시
**business-rules.md**: 제약 조건 + 상태 전이(있으면) + 권한 규칙 + 예외 처리

### 4. 최종 검증

5개 파일이 모두 존재하고, 기술 용어가 없으며, 상호 참조가 일관된지 확인한다.

---

## README.md 템플릿

```markdown
# {Domain} 도메인

> **역할**: {한 줄 설명}

---

## 📚 목차

1. [기능 정의](./features.md) - 이 도메인이 하는 일
2. [도메인 모델](./domain-model.md) - 유비쿼터스 언어 명세
3. [API 명세](./api-spec.md) - API 상세 설계
4. [비즈니스 규칙](./business-rules.md) - 제약조건, 정책

---

## 🔗 도메인 관계

### 의존하는 도메인
- `users` - 사용자 정보 필요

### 이 도메인을 사용하는 도메인
- `missions` - 번역 기록 조회

---

## 📊 요약

- **엔티티 수**: {수}
- **API 수**: {수}
- **상태 전이**: {있음/없음}

---

## 🎯 핵심 가치

{이 도메인의 핵심 가치를 한 문장으로}
```

### 사용 예시

```markdown
# users 도메인

> **역할**: 앱 사용자 관리

---

From ureca-corp/claude, MIT.

More from ureca-corp/claude