/propose

name: propose
description: "타겟 장르, 컨셉, 타겟 플랫폼을 입력하면 3개의 차별화된 웹소설 설계안을 제안한다. 플랫폼은 문피아, 네이버시리즈, 카카오페이지, 리디, 조아라, 노벨피아로 제한한다. 장르와 플랫폼이 지정되지 않으면 사용자에게 물어본다. 이미 설계가 진행 중인 프로젝트의 수정/보완은 이 스킬이 아니라 design을 사용하라."

Novel Propose — 웹소설 제안 오케스트레이터

타겟 장르, 컨셉, 플랫폼을 기반으로 3개의 차별화된 웹소설 설계안을 제안한다. 플랫폼은 지정된 웹소설 플랫폼만 다루며, 사용자가 "어떤 소설을 쓸까"부터 시작할 수 있도록 발상 단계를 지원한다.

실행 모드: 서브에이전트

워크플로우

Phase 1: 입력 파싱

1. 사용자 입력에서 다음 항목을 추출한다:

• **장르**: 회귀, 전문가물, 로맨스판타지, 현대판타지, 무협, SF, 게임판타지, 로맨스, BL, 호러, 추리/미스터리, 일상/힐링, 스포츠, 라이트노벨, 대체역사, 포스트아포칼립스, 던전/헌터, 아카데미, 빙의, 육아물, 궁정물, 경영/재벌 등
• **컨셉**: 직업, 소재, 분위기, 차별화 방향 (자유 형식)
• **타겟 플랫폼**: 문피아, 네이버시리즈, 카카오페이지, 리디, 조아라, 노벨피아

2. **플랫폼 정규화/검증 게이트**:

• canonical name은 `문피아`, `네이버시리즈`, `카카오페이지`, `리디`, `조아라`, `노벨피아`만 허용한다
• 아래 별칭은 canonical name으로 정규화할 수 있다:
• 문피아: `Munpia`, `munpia`, `문 피아`
• 네이버시리즈: `네이버 시리즈`, `Naver Series`, `naver series`
• 카카오페이지: `카카페`, `카카오 페이지`, `KakaoPage`, `kakaopage`
• 리디: `리디북스`, `RIDI`, `Ridi`
• 조아라: `Joara`, `joara`
• 노벨피아: `NovelPia`, `novelpia`, `노벨 피아`
• 해외 플랫폼명, 허용 집합 밖 국내 플랫폼명, 의미가 모호한 별칭은 자동 매핑하지 않는다
• 허용되지 않는 플랫폼 입력이면 아래 문구로 재질문한다:

현재는 아래 웹소설 플랫폼만 선택할 수 있습니다.
아래 중 하나를 선택해주세요:
- 문피아
- 네이버시리즈
- 카카오페이지
- 리디
- 조아라
- 노벨피아

3. **누락 항목 질문**: 장르 또는 플랫폼이 지정되지 않으면 사용자에게 질문한다:

웹소설 제안을 위해 몇 가지 정보가 필요합니다:

1. **장르**: 어떤 장르를 원하시나요?
   - 남성향: 회귀, 전문가물, 현대판타지, 무협, SF, 게임판타지, 던전/헌터, 아카데미, 대체역사 등
   - 여성향: 로맨스판타지, 로맨스, BL, 궁정물, 빙의, 육아물 등
   - 공용: 추리/미스터리, 호러, 일상/힐링, 스포츠, 경영/재벌 등
   - 장르 조합도 가능합니다 (예: 회귀×전문가물, 로판×궁정물)

2. **플랫폼**: 주요 연재 플랫폼은 어디인가요?
   - 문피아
   - 네이버시리즈
   - 카카오페이지
   - 리디
   - 조아라
   - 노벨피아

3. **컨셉/소재** (선택): 특별히 다루고 싶은 소재나 컨셉이 있나요?
   (예: 의료, 법조, 요리, 건축, 특정 시대배경 등)

4. **작품 가제 확정**: 컨셉이 확정되면 사용자에게 작품 가제를 확인한다.

Phase 2: 자동 리서치 (서브에이전트)

domain-researcher 서브에이전트를 호출하여 자동 리서치를 수행한다. 사용자 대기 없이 즉시 진행한다.

**서브에이전트: domain-researcher**

• subagent_type: `general-purpose`
• 리서치 항목:
• **R1 장르 DNA**: 해당 장르의 필수 공식, 독자 기대, 성공 패턴 분석
• **R2 플랫폼 전략**: 타겟 플랫폼의 유료 전환 구조, 독자 성향, 인기작 패턴
• **R5 기존작 분석**: 유사 장르/소재의 기존 웹소설을 분석하여 차별화 포인트 도출

• 프롬프트:

당신은 domain-researcher 서브에이전트입니다.
다음 리서치를 수행하세요:

1. R1 장르 DNA 분석:
   - 장르: {장르}
   - 분석 항목: 필수 서사 공식, 독자 기대 패턴, 성공작의 공통 요소, 차별화 가능 지점
   - `${CLAUDE_PLUGIN_ROOT}/skills/design/references/genre-dna-framework.md`를 읽고 프레임워크 숙지

2. R2 플랫폼 전략 분석:
   - 플랫폼: {플랫폼}
   - 분석 항목: 유료 전환 구조, 독자 성향, 인기 장르 분포, 무료/유료 구간 전략

3. R5 기존작 분석:
   - 장르: {장르}, 소재: {컨셉}
   - 분석 항목: 유사 소재 기존작 상위 10개, 각 작품의 셀링포인트와 구조, 독자 반응(칭찬/불만), 공통 클리셰, 차별화 성공 사례, 미개척 영역
   - 3개 안의 차별화를 위해 기존작과의 빈틈(gap)을 명확히 도출할 것

출력:
- _workspace/00_research/R1_장르DNA.md
- _workspace/00_research/R2_플랫폼전략.md
- _workspace/00_research/R5_기존작분석.md

Phase 3: 제안 생성 (서브에이전트)

proposal-generator 서브에이전트를 호출하여 3개의 차별화된 설계안을 생성한다.

**서브에이전트: proposal-generator**

• subagent_type: `general-purpose`
• 프롬프트:

당신은 proposal-generator 서브에이전트입니다.
`${CLAUDE_PLUGIN_ROOT}/agents/proposal-generator.md`를 읽고 역할과 출력 구조를 숙지하세요.

다음 문서를 읽으세요:
- _workspace/00_research/R1_장르DNA.md
- _workspace/00_research/R2_플랫폼전략.md
- _workspace/00_research/R5_기존작분석.md

사용자 입력:
- 장르: {장르}
- 컨셉: {컨셉}
- 플랫폼: {플랫폼}

`${CLAUDE_PLUGIN_ROOT}/agents/proposal-generator.md`에 정의된 출력 구조와 작업 원칙에 따라 3개의 차별화된 웹소설 설계안을 작성하세요.
R5 기존작 분석 결과를 반드시 참조하여 기존작과의 차별화를 명시하세요.

출력: _workspace/01_proposals.md

Phase 4: 사용자 제시 및 선택

1. `_workspace/01_proposals.md`를 읽어 3개 안을 비교표로 제시한다:

## 웹소설 설계안 비교

| 항목 | 1안: 정통파 | 2안: 변주형 | 3안: 도전형 |
|------|------------|------------|------------|
| 로그라인 | ... | ... | ... |
| 차별화 포인트 | ... | ... | ... |
| 플랫폼 적합도 | ★★★★★ | ★★★★☆ | ★★★☆☆ |
| 확장성 | ... | ... | ... |
| 리스크 | ... | ... | ... |

어떤 안을 선택하시겠습니까? (1/2/3)
혹은 특정 안의 요소를 조합하고 싶으시면 말씀해주세요.

2. 사용자의 선택을 받는다.

3. 선택된 안(또는 조합)을 프로젝트 루트에 `{작품가제}_제안서.md`로 저장한다.

Phase 5: 다음 단계 안내

## 제안서가 저장되었습니다.

파일: {작품가제}_제안서.md

### 다음 단계: 큰 설계 (design-big)

제안서를 기반으로 전체 소설의 뼈대를 설계합니다:
- 부트스트랩 문서 (세계관, 서사 기점, 플랫폼 전략)
- 캐릭터 시트 (주인공, 조력자, 빌런 계층)
- 플롯 훅 가이드 (서사 아크, 카타르시스 리듬, 유료 전환)

큰 설계를 시작하시겠습니까?

에러 핸들링

| 상황 | 전략 | |------|------| | domain-researcher 실패 | 1회 재시도. 재실패 시 genre-dna-framework.md 기반으로 제안 진행, 보고서에 "자동 리서치 미반영" 명시 | | proposal-generator 실패 | 1회 재시도. 재실패 시 리더가 직접 3개 안 생성 | | 사용자가 3개 안 모두 거부 | 거부 사유를 파악하여 컨셉 재조정 후 Phase 3 재실행 | | 장르가 genre-dna-framework.md에 없음 | 유사 장르 프레임워크를 참고하되, 해당 장르 고유의 독자 기대를 웹 검색으로 보강 | | 허용되지 않는 플랫폼 입력 | 자동 변환하지 않고 허용 플랫폼 중 재선택 요청 | | 작품가제 미확정 | Phase 2 진행 전 반드시 확정. 파일명에 필요 |

데이터 흐름

[사용자] → 장르 + 컨셉 + 플랫폼 (한국 플랫폼만 허용, 또는 질문 후 확보)
    ↓
Phase 1: 입력 파싱 + 플랫폼 정규화/검증 + 작품가제 확정
    ↓
Phase 2: domain-researcher 서브에이전트 → _workspace/00_research/ (R1 + R2 + R5)
    ↓
Phase 3: proposal-generator 서브에이전트 → _workspace/01_proposals.md (R5 기존작 분석 반영)
    ↓
Phase 4: 비교표 제시 → 사용자 선택 → {작품가제}_제안서.md
    ↓
Phase 5: 큰 설계(design-big) 안내

테스트 시나리오

정상 흐름

1. 사용자가 "회귀×전문가물 웹소설 제안해줘, 문피아에서 연재할 건데 의료 쪽이었으면 좋겠어" 요청 2. Phase 1에서 장르(회귀×전문가물), 플랫폼(문피아), 컨셉(의료) 추출, 작품가제 확인 3. Phase 2에서 R1(장르 DNA) + R2(플랫폼 전략) + R5(기존작 분석) 자동 리서치 4. Phase 3에서 3개 안 생성 (정통파: 회귀한 외과의, 변주형: 법의학+추리, 도전형: 의료AI+SF) 5. Phase 4에서 비교표 제시, 사용자가 2안 선택 6. `{작품가제}_제안서.md` 저장 + 큰 설계 안내

입력 불완전 흐름

1. 사용자가 "소설 하나 만들어줘" 요청 2. Phase 1에서 장르/플랫폼/컨셉 모두 누락 감지 3. 질문으로 정보 수집 → 사용자가 "로판, 카카오페이지, 궁정물" 응답 4. 이후 정상 흐름과 동일

허용되지 않는 플랫폼 입력 흐름

1. 사용자가 "회귀물 제안해줘. 플랫폼은 해외 플랫폼" 요청 2. Phase 1에서 플랫폼 검증 실패 3. "현재는 아래 웹소설 플랫폼만 선택할 수 있습니다" 문구와 함께 6개 플랫폼 재제시 4. 사용자가 "문피아"로 재선택하면 정상 진행

별칭 정규화 흐름

1. 사용자가 "현판 제안해줘. 플랫폼은 Munpia" 요청 2. Phase 1에서 `Munpia`를 `문피아`로 정규화 3. 이후 모든 리서치/제안/설정 파일에는 `문피아`를 canonical 값으로 사용

조합 선택 흐름

1. Phase 4에서 사용자가 "1안의 주인공에 3안의 세계관을 합치고 싶어" 요청 2. 두 안의 요소를 조합하여 새 제안서 생성 3. 조합된 제안서를 사용자에게 확인 후 저장