#太陽のような文章を書く

ユーザーがストーリー記事を提供し、その文章構成を抽出したり、ストーリー変数を置き換えたり、リミックス記事を生成したり、結果を短編ドラマの脚本に変換したりしたい場合に、このスキルを使用してください。

## 運営契約

- ユーザーが提供したソースコードに基づいて作業してください。ローカルパス、Obsidian Vault、データベース、APIキー、ネットワークサービス、または以前の会話状態を前提としないでください。

デフォルト言語は中国語です。指定された長さとトーンに合わせてください。指定がない場合は、下書きを作成する前に、不足している最低限のクリエイティブ要素を確認してください。

このスキルの製品ポリシーに従い、ソースをユーザー所有またはユーザー承認済みとして扱います。アップロード自体が公開権または改変権を証明するものではないことを示す、簡潔で邪魔にならない注意喚起を表示します。

デフォルトでは架空の人物を使用します。実在の人物名が入力された場合、または実在の人物が特定できる場合は、評判やプラットフォーム上のリスクについて警告し、架空の人物として扱うことを提案します。これはあくまでも創作上の警告であり、本人確認や法的助言ではありません。

- 高類似性リミックスがデフォルトです。文のリズム、段落のペース、物語の姿勢、対比表現、反復、そして展開のタイミングを維持します。登場人物、因果関係、舞台設定、そして意味内容を置き換えることで、単なる名前の置き換えではなく、全く新しい物語を作成します。

タイトルと冒頭部分を高忠実度領域として扱います。原文タイトルの文法的な位置、情報密度、対立構造を維持した上で、固有名詞や意味の詳細を置き換えます。原文タイトルが最小限の関係性＋名前の形式であれば、最小限のままにし、原文にない説明的な筋書きを追加しないでください。冒頭部分の情報順序と文の流れを維持します。具体的な対比や測定 → 直接的な要求／出来事 → 関係性を明らかにする操作の詳細 → 破綻や消失の早期の予兆 → 回想への転換。長い連続した文章をコピーしたり、原文独自の出来事の連鎖を保持したりしないでください。

ユーザーが作成した記事全文をこのスキルパッケージに含めないでください。分析結果には、必要最小限の短い引用のみを含めてください。

## モード

ユーザーのリクエストに基づいてモードを選択してください。明確なモードがない場合は、以下の6つのモードを提示し、どれを実行するかを尋ねてください。

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. 人間が読めるMarkdown形式の出力を生成する。

3. ユーザーが機械可読な出力を要求した場合、関連するスキーマから一致するJSON形式を提供します。

4. 未解決の決定事項は、黙って制約を作り出すのではなく、明確にしておく。

## 出力および品質ゲート

記事の出力には、要求されたタイトル、物語の視点、構成上のポイント、そして結びを含める必要があります。出典元の有用な仕組みはそのまま残し、固有名詞や事実の主張は削除してください。

記事のタイトルは、出典元の命名規則、文字数、情報密度を反映させる必要があります。出典元の固有名詞や事実は置き換えますが、ユーザーからタイトル変更の要望がない限り、出典元の最小限のタイトルをより説明的または長くしないでください。最初の段落は、出典元で分析された情報の流れに沿って、背景説明の前に読者の興味を引く内容にする必要があります。ユーザーが明示的に異なる冒頭部分を要求した場合は、その要望に従い、変更内容を記録してください。

- リミックスの出力には、変更されたキャラクター、イベント、設定、エンディング、タイトルの意味、およびオープニングの事実をリストした短い「変更の説明」を含める必要があります。これにより、意味的な変換を監査できます。

スクリプトの出力は、`references/drama-script-schema.md` に記載されている両方の成果物を提供する必要があります。デフォルトのプリセットは、1エピソードあたり60～90秒、12～24エピソードです。ユーザーが指定したプリセットも受け付けます。

レビューでは、前提、登場人物の目標、タイムライン、因果関係、モチーフの引用、長さ／時間的制約、セリフ、ユーモア、意味的な出来事の独創性、実在人物に関するフラグ、およびフォーマットの完全性を確認する必要があります。

自動採点が芸術的品質や法的承認を証明するものだと主張してはなりません。最終的な判断は人間の審査に委ねられます。