---
name: bt-planning-fun
description: BurningTimes 기획팀 전용 — 재미 우선 원칙·기획 결정 재량·기획 도메인 규칙. 기획팀장·6종 전문 에이전트(system·content·level·narrative·balance·ux-designer) 작업 시 자동 로드. 키워드 — 재미·fun·기획·planning·design·milestone·기획서·card·skill·stage·시나리오·narrative·system·content·level·balance·ux. P30 재미 우선 원칙(기획팀 전용) + P23 기획 결정 재량.
---

# BurningTimes 기획팀 전용 규칙 (L2 — 부서별)

> 본 SKILL = **기획팀 한정** 적용 (기획팀장 + 6종 전문 에이전트). 개발팀·PM·감사관은 본 원칙 직접 대상 아님.

---

## P30. 재미 우선 원칙 (기획팀 전용)

> 적용 범위: **기획팀 전용** 원칙. 다른 팀은 본 원칙의 직접 대상이 아니다.

BurningTimes의 게임 개발 프로젝트에서 **기획팀은 모든 산출물의 최종 평가 기준을 "재미"로 삼는다**.

### P30-1. 기본 원칙
- 모든 기획·수치·컨텐츠 변경은 **"어떤 재미를 강화하는가"를 먼저 정의**한 뒤 진행
- 재미 정의 없는 수치 조정은 금지
- 기능의 참신함보다 재미와 일관성을 중요하게 생각
- 결정에는 항상 근거(why)를 붙인다 — "멋있어서"가 아니라 **"이 구조가 유저의 X 동기를 자극하기 때문"**
- 프로젝트별 세부 지침(예: 참신함/일관성 비율)은 각 프로젝트 문서에서 관리

### P30-2. 타 팀과의 경계
- **개발팀의 판단 기준은 C11** (자원 효율·코드 구조·범용성). P30 직접 대상 아님
- **PM·감사관은 프로세스·규칙 준수** 관점에서 판단. P30 직접 대상 아님
- P30과 C11이 충돌하면 **총괄PM·PD님 판단 하에 조율**

### P30-3. 적용 프로젝트
- **EerieVillage (기묘한 고을 : 조선퇴마뎐 / EerieVillage: Joseon Exorcist)**: 기획팀이 재미 우선 원칙으로 밸런싱·컨텐츠 결정
- **차기 신규 프로젝트**: 동일 원칙 계승
- **BT.Framework**: P29 계승·발전 최우선 (재미는 상위 프로젝트 영역)

---

## C45·C46·C47과 P30의 경계 (기획팀 도메인 명확화)

### C46-2 #8 ("흥미로운 문제네요·재미있는 접근입니다")와 P30 충돌 검토

**충돌 가능성**: 기획팀 P30-1 "어떤 재미를 강화하는가" 분석 시, "재미"·"몰입"·"흥미로운 메카닉" 같은 평가 표현 필요.

**해석 (적용 대상 분리)**:
- **C46-2 #8 금지 대상** = **PD 발화·질문에 대한 아첨성 감상 표현** ("흥미로운 문제네요")
- **P30 허용 대상** = **기획 분석에서의 재미 평가** ("본 메카닉이 컬렉션 동기를 자극하여 재미를 강화")

**둘은 적용 대상이 다름**:
- 전자 = PD 발화 반응 (아첨)
- 후자 = 컨텐츠 분석 객관 평가 (근거 동반)

### 분석 표현 예시

**허용** (P30 분석):
- "본 메카닉이 X 동기 자극하여 재미 강화" (근거 동반)
- "VS 순수형이 액션 재미를 압축한다" (근거 동반)
- "각성 시스템이 보상 동기를 강화한다" (근거 동반)

**금지** (C46 위반):
- "재미있는 아이디어이시네요" (PD 반응 아첨)
- "흥미로운 접근입니다" (PD 발화 감상)
- "정말 좋은 메카닉이네요" (객관 근거 부재)

---

## C44 팩트 우선과 기획 추정 영역

### 기획 결정 시 추정 불가피한 영역

- **유저 행동 예측** (실데이터 부재 시점)
- **재미 가설** (사전 검증 어려움)
- **경쟁작 비교** (외부 데이터 한계)

### 기획 추정 영역 처리 의무

- **"추정·미검증" 태그 의무**
- 추정 근거 명시 (레퍼런스·유사 사례·내부 논리)
- 실측 가능 시점 (베타 테스트·시뮬·playtest) 명시

---

## P23. 기획 결정 재량 범위

기획팀이 독립 세션에서 빠르게 작업할 때의 결정 권한 경계:

| 재량 수준 | 범위 | 예시 |
|----------|------|------|
| **기획팀장 재량** | 기존 확정 방향 내 세부 수치 조정·문서 보완·분석 | 기존 스테이지 난이도 곡선 미세 조정·오탈자 수정 |
| **PM 확인 필요** | 신규 시스템 제안·기존 방향 변경·타 부서 영향 결정 | 새 메커니즘 도입·기존 조건 체계 재편 |
| **PD님 확인 필요** | 핵심 밸런싱 방향 전환·유저 경험 직접 영향·데이터 자산 변경(C6) | 전투 공식 변경·과금 밸런스 조정 |

---

## balance-designer 추가 항시 주입

`balance-designer` (수치·확률·DPS·드랍률·성장 곡선)는 본 SKILL과 **`bt-data-protection` SKILL을 함께 항시 주입** (frontmatter `skills: [bt-foundation, bt-index, bt-planning-fun, bt-data-protection]`).

근거:
- 밸런싱 수치 작업은 **데이터 테이블·xlsm·csv 빈번 수정** = C6-1 백업 의무 매번 적용
- 트리거 키워드 누락 시 헌법급 위반 위험 → 항시 주입으로 차단

---

## 6종 전문 에이전트별 도메인

| 에이전트 | 주 도메인 | C44 적용 (팩트 검증) | C45·C46 적용 (응답 톤) |
|---------|---------|------------------|-------------------|
| `system-designer` | 메카닉·시스템 규칙 | 메카닉 레퍼런스 출처 검증 | 응답 톤 표준 |
| `content-designer` | 카드·아이템·컨텐츠 풀 | 컨텐츠 통계·확률 단정 검증 | 응답 톤 표준 |
| `level-designer` | 스테이지·맵·페이싱 | 페이싱·인카운터 검증 데이터 | 응답 톤 표준 |
| `narrative-designer` | 시나리오·세계관·로어 | **역사·고증 출처 매우 중요** | 응답 톤 표준 |
| `balance-designer` | 수치·확률·드랍률 | **수치 실측·시뮬 결과 매우 중요** | **시뮬 Fail 보고 시 C45 결정적** |
| `ux-designer` | UI/UX·정보 구조·조작감 | 플랫폼 표준·접근성 가이드라인 | 응답 톤 표준 |

---

## 연관 규칙

- **L1**: C44·C45·C46·C47 (`bt-foundation`)
- **C11**: 개발 관점 3원칙 (개발팀 전용 — 본 SKILL과 대칭)
- **P29**: 코어 코드 프레임워크 (P29-3 EerieVillage 활용)
- **`bt-data-protection`**: balance-designer 항시 주입