---
name: dz-feature-planning
description: >
  This skill should be used when the user asks to "기능 기획해줘", "스펙 작성해줘",
  "요구사항 정리해줘", "사용자 스토리 만들어줘", "화면 목록 뽑아줘", "기능 분석해줘",
  "라이선스별로 나눠줘", 또는 Amaranth 10 모듈의 특정 기능에 대한 기획·설계 문서가 필요할 때.
  컨텍스트가 로드된 상태에서 구조화된 기능 스펙을 생성한다.
version: 0.2.0
---

# 기능 기획 스킬 (Feature Planning)

Amaranth 10 모듈의 기능을 구조화된 스펙으로 만드는 방법론.
로드된 컨텍스트(module-overview, conventions, GNB/LNB 파일)를 참고해 일관된 품질의 기획 문서를 생성한다.

## 기획 전 체크리스트

기능 스펙 작성 전에 반드시 확인한다.

1. `_개인/sessions/{모듈}/_current.md` 확인 — **세션 체크 필수!**
2. 같은 주제의 진행 중 세션이 있으면 먼저 확인
3. `module-overview.md`가 로드되어 있는가?
4. `conventions.md`가 로드되어 있는가?
5. 작업 대상 GNB/LNB 컨텍스트 파일이 로드되어 있는가?
6. 라이선스 구분이 있는 모듈이라면, 이 기능이 어느 라이선스에 해당하는가?

로드되지 않은 항목이 있으면 `/load-context` 커맨드로 먼저 로드한다.

## 세션 이어받기 (Resume Session)

**원칙**: 이미 진행 중인 세션이 있으면 중간 결론과 남은 이슈를 먼저 이어받는다.

예시:
```
1. sessions/_current.md 읽기
2. "상담관리 스펙 작성" 진행 중
3. 이미 작성한 부분: 개요, 기능 범위, 사용자 스토리
4. 남은 부분: 데이터 요구사항, 미결 사항, 검토
→ 새로 작성하지 말고, 남은 부분부터 이어받기
```

## 기능 스펙 구조

모든 기능 스펙은 아래 구조를 따른다. `/feature-spec` 커맨드 실행 시 이 구조로 생성된다.

```
# {기능명} 기능 스펙

## 선행 맥락 (Prior Context)
- 이 기능이 왜 필요한가? (요청 배경)
- 기존 구현과의 차이점
- 영향받는 기존 기능이 있는가?

## 개요
- 목적: {이 기능이 해결하는 문제}
- 대상 사용자: {사용자 유형}
- 라이선스 적용: {전체 / 법무법인용 / 기업법무팀용 / 해당 없음}

## 라이선스별 기능 범위
| 기능 항목 | 라이선스 A | 라이선스 B |
|----------|-----------|-----------|
| ...      | ✓         | ✗         |
※ 라이선스 구분이 없는 모듈은 이 섹션 삭제

## 사용자 스토리
- As a {사용자 유형}, I want to {행동}, so that {목적}.
- ...

## 기능 상세 요구사항
### 필수 기능 (Must Have)
- ...

### 선택 기능 (Nice to Have)
- ...

### 제외 범위 (Out of Scope)
- ...

## 화면 목록
| 화면명 | 경로/URL | 설명 |
|-------|---------|------|
| ...   | ...     | ...  |

## 데이터 요구사항
- 주요 엔티티: {테이블명 및 간략한 설명}
- 신규 필드: {추가 필요한 컬럼}
- 연관 테이블: {연관되는 기존 테이블}

## 비기능 요구사항
- 성능: {응답시간, 데이터 처리량 등}
- 보안: {접근 제어, 민감 데이터 처리}
- 기타: {제약사항}

## 연계 영향 (Integration Impact)
- 다른 시스템 또는 GNB와의 연계 필요 여부
- API/배치 연계 필요 여부
- 데이터 동기화 방식

## 테스트 관점 (Test Perspective)
- 주요 테스트 시나리오
- 라이선스별 테스트 분기 (있는 경우)
- 경계값/예외 케이스

## 감사 이력 고려 (Audit Trail)
- 감사 대상이 되는 기능인가?
- 기록해야 할 사항 (누가, 언제, 무엇을)
- 규제 또는 컴플라이언스 영향

## 회귀 영향 (Regression Impact)
- 이 기능 추가로 영향받을 기존 기능
- 변경되는 데이터 구조가 다른 기능에 미치는 영향
- 버전 호환성 고려사항

## 미결 사항 (Open Questions)
- [ ] {결정이 필요한 항목}
```

## 필수 체크 항목 (Required Checks)

스펙 작성 후 아래 항목을 반드시 확인한다:

- [ ] **라이선스 차이**: 라이선스별로 다른 기능이 명확히 분리되었는가? (해당 모듈에 한해)
- [ ] **권한 제어**: 어떤 사용자가 이 기능을 사용할 수 있는가? 권한별 제약이 있는가?
- [ ] **상태값**: 이 기능에서 다루는 모든 상태값이 나열되었는가?
- [ ] **연계/배치**: 다른 시스템이나 배치 작업과의 연계가 필요한가? (있으면 "연계 영향" 섹션에 기록)
- [ ] **감사 이력**: 감사 대상이면 감사 이력 방식이 명시되었는가?
- [ ] **회귀 영향**: 기존 기능에 미치는 부작용이 파악되었는가?

## 라이선스 분기 기획 가이드

라이선스 구분이 있는 모듈(예: 법무관리)에서는 기능을 세 가지로 분류한다.

**공통 기능:** 모든 라이선스에서 동일하게 제공
**라이선스별 기능:** 특정 라이선스에만 제공되거나 다르게 동작
**확장 기능:** 상위 라이선스에서만 제공

기획 문서 작성 시 각 기능 항목에 라이선스 태그를 명시해 개발자와 QA가 혼동하지 않도록 한다.

## 기획 품질 기준

생성된 스펙이 아래 기준을 충족하는지 확인한다.

- 사용자 스토리가 최소 3개 이상인가?
- 화면 목록이 있는가?
- 라이선스 구분이 명확한가? (해당 모듈에 한해)
- 미결 사항이 명시되어 있는가?
- 데이터 요구사항이 포함되어 있는가?

미충족 항목이 있으면 사용자에게 추가 정보를 요청하거나 가정 사항으로 명시한다.


## 마크다운 링크 규칙 (필수)

마크다운 파일 작성·업데이트 시 **모든 경로·파일 참조는 클릭 가능한 상대 링크**로 작성한다.

```markdown
# 나쁜 예 (클릭 불가)
법무관리/tasks/_current.md에서 확인

# 좋은 예 (클릭 가능)
[법무관리/tasks/_current.md](../법무관리/tasks/_current.md)에서 확인
```

- 상대 경로는 현재 파일 위치 기준
- 코드블록 안의 폴더 구조 다이어그램은 예외 (링크 불필요)
- 상세 규칙은 douzone-forge CLAUDE.md의 "마크다운 링크 표기 규칙" 섹션 참조