# 태양처럼 글쓰기

사용자가 스토리 기사를 제공하고 해당 기사의 작성 방식을 추출하거나, 스토리 변수를 바꾸거나, 재구성된 기사를 생성하거나, 결과를 짧은 드라마 대본으로 변환하려는 경우 이 스킬을 사용하십시오.

## 운영 계약

- 사용자가 제공한 소스를 기반으로 작업하십시오. 로컬 경로, Obsidian 볼트, 데이터베이스, API 키, 네트워크 서비스 또는 이전 대화 상태를 절대 추측하지 마십시오.

- 기본 언어는 중국어입니다. 요청된 길이와 어조에 맞춰 작성하십시오. 명시되지 않은 경우, 초안 작성 전에 필요한 최소한의 창작 변수를 요청하십시오.

- 이 스킬의 제품 정책에 따라 소스를 사용자 소유 또는 사용자 승인된 것으로 처리하십시오. 업로드 자체가 출판 또는 각색 권한을 증명하는 것은 아니라는 점을 간략하게 알려주는 알림을 표시하되, 차단되지 않도록 하십시오.

- 기본적으로 가상의 인물을 사용하십시오. 실존 인물의 이름이 제공되거나 식별 가능한 경우, 평판 및 플랫폼 위험에 대해 경고하고 허구화할 것을 제안하십시오. 이는 창작 관련 경고이며, 신원 확인이나 법률 자문이 아닙니다.

- 높은 유사도를 유지하는 리믹스가 기본 설정입니다. 문장 리듬, 문단 속도, 서술 시점, 대조 장치, 반복, 그리고 내용 전개 시점을 보존합니다. 등장인물, 인과 관계, 배경, 그리고 의미론적 내용을 대체하여 단순히 이름만 바꾸는 것이 아니라 완전히 새로운 이야기를 만들어냅니다.

- **제목과 도입부**는 원본의 핵심 요소로 간주하십시오. 원본 제목의 문법적 구조, 정보 밀도, 갈등을 드러내는 형태를 유지하되, 고유명사와 의미적 세부 사항은 교체하십시오. 원본 제목이 최소한의 관계와 이름만 포함하는 형식이라면, 그 형태를 그대로 유지하십시오. 원본에 없는 설명적인 줄거리 요소를 추가하지 마십시오. 도입부의 정보 순서와 문장 흐름을 유지하십시오: 구체적인 대조 또는 측정 -> 즉각적인 요청/사건 -> 관계를 드러내는 구체적인 세부 사항 -> 단절 또는 소멸에 대한 초기 암시 -> 회고로의 전환. 긴 연속된 문단을 그대로 복사하거나 원본의 고유한 사건 전개 방식을 그대로 사용하지 마십시오.

- 사용자가 제공한 전체 원문을 이 스킬 패키지에 넣지 마십시오. 분석 결과에는 필요한 짧은 증거 부분만 인용하십시오.

## 모드

사용자의 요청에 따라 모드를 선택하십시오. 적절한 모드가 없는 경우, 아래의 여섯 가지 모드를 제시하고 실행할 모드를 선택하도록 요청하십시오.

1. **분석**: 관찰된 사실, 후보 규칙, 스토리별 장치, 제목 구문, 도입부 정보 순서, 증거 범위, 신뢰도 및 전이 불가능한 표면적 특징을 추출합니다. `references/analysis-schema.md`를 참조하십시오.

2. **설정**: 전제, 주제, 등장인물, 관계, 욕망, 장애물, 배경, 시간 순서, 결말, 유머 강도, 길이 및 드라마 설정값을 수집하거나 표준화합니다. `references/story-bible-schema.md`를 참조하세요.

3. **리믹스**: 분석된 메커니즘을 구성된 변수에 적용합니다. 의미 이벤트와 캐릭터 로직을 변경하면서 상위 수준의 표면 동작은 유지합니다. 본문 작성 전에 제목과 오프닝 구성을 먼저 작성합니다. 분석 자료가 없는 경우, 소스 코드를 먼저 분석합니다.

4. **작성**: 스토리 바이블과 선택된 구성 요소를 바탕으로 중국 이야기 원고를 완성하세요. 본문을 확장하기 전에 제목과 도입부를 작성하고 검토하세요. 언급된 내용과 모티프는 인과적으로 의미를 갖도록 구성하고, 교훈을 설명하기보다는 극적으로 표현하세요.

5. **스크립트**: 이야기를 문학적 시나리오와 AI 제작 시트로 변환합니다. `references/drama-script-schema.md`를 참조하세요.

6. **검토**: 자동 검사를 실행하고 차단 요소, 경고, 점수 및 구체적인 수정 사항을 보고합니다. `references/quality-rubric.md`를 참조하십시오.

## 워크플로우

가장 짧은 완전한 경로를 따라가세요:

`분석 -> 구성 -> 리믹스/작성 -> 검토 -> 스크립트 작성 -> 검토`

단계별 입력, 출력, 연속 규칙 및 GitHub 벤치마크 정보는 `references/workflow.md` 파일을 참조하십시오. 사용자는 해당 단계에 필요한 아티팩트가 프롬프트 또는 작업 공간에 이미 있는 경우에만 단계를 건너뛸 수 있습니다.

모든 단계에서:

1. 사용된 아티팩트와 누락된 가정을 명시하십시오.

2. 사람이 읽기 쉬운 마크다운 결과물을 생성합니다.

3. 사용자가 기계 판독 가능한 출력을 요청하면 관련 스키마에서 일치하는 JSON 형식을 제공합니다.

4. 미해결된 결정 사항은 명시적으로 밝히고, 암묵적으로 제약 조건을 만들어내지 마십시오.

## 출력 및 품질 게이트

- 최종 결과물에는 요청된 제목, 서술 관점, 구성 요소 및 결론이 포함되어야 합니다. 원문의 유용한 문법적 요소는 유지하되, 고유명사나 사실적 주장은 제외하십시오.

- 기사 제목은 출처의 명명 규칙, 단어 수, 정보 밀도를 반영해야 합니다. 출처의 고유명사와 사실 관계는 그대로 사용하되, 사용자가 제목 변경을 요청하지 않는 한 간결한 출처 제목을 더 설명적이거나 길게 만들지 마십시오. 첫 단락은 출처에서 분석한 정보의 순서를 따라야 하며, 배경 설명을 하기 전에 독자의 흥미를 유발하는 내용을 제시해야 합니다. 사용자가 명시적으로 다른 도입부를 요청하는 경우, 해당 요청을 따르고 변경 사항을 기록하십시오.

- 리믹스 결과물에는 변경된 등장인물, 사건, 배경, 결말, 제목 의미, 시작 부분 정보 등을 간략하게 나열한 '변경 설명'이 포함되어야 의미 변환 과정을 검토할 수 있습니다.

- 대본 출력물은 `references/drama-script-schema.md`에 명시된 두 가지 필수 구성 요소를 모두 포함해야 합니다. 기본 설정은 에피소드당 60~90초, 총 에피소드 수는 12~24개입니다. 사용자가 제공하는 설정도 허용됩니다.

- 검토 시에는 전제, 등장인물의 목표, 시간 순서, 인과 관계, 모티프 반복, 분량/시간 제약, 대화, 유머, 의미론적 사건의 독창성, 실존 인물 언급 여부, 형식 완성도 등을 확인해야 합니다.

자동 채점 시스템이 예술적 품질이나 법적 적법성을 입증한다고 절대 주장하지 마십시오. 최종 검토는 반드시 사람의 손으로 이루어져야 합니다.