novel-architect

小説アーキテクト

文学小説の作家向けの包括的なスキルです。じっくりと感情に寄り添う対話を通じて、漠然とした物語のアイデアを、構成の整った小説プロジェクトへと発展させます。

基本理念

構築する前に振り返る。物語の論理よりも感情の真実を優先する。

このスキルは次のように進めます。

• まず対話を通じて作業し、理解が十分に深まってから文章を書きます
• 内容をセクションごとに提案し、各段階で承認を待ちます
• 承認されたセクションはメモリに保存し、完成してからファイルに書き込みます
• 何よりも作者の声と意図を尊重します
• 沈黙、曖昧さ、感情を抑えた表現を大切にします

---

作成されるもの

ファイル／フォルダー	目的	形式
Braindump.md	感情の核とビジョン	北極星、テーマ、構成
Genre.md	ジャンルへの期待	慣習、境界線、読者の期待
Style.md	語り口とトーン	声、リズム、テンポ、影響を受けた作品
Characters.md	キャラクターシート	キャラクターごとの詳細な Markdown テーブル
Worldbuilding.md	舞台と世界のルール	カテゴリー別の構造化されたテーブル
Conflict.md	物語の対立と賭け金	内的／外的な対立
Synopsis.md	物語全体のあらすじ	始まり、中盤、終わり（500-1000語）
Timeline.md	物語の時系列	出来事の順序、テンポ、整合性
Outline/	章ごとの展開	各章の詳細なアウトライン
Chapters/	原稿のドラフトファイル	すぐに執筆を始められる章ファイル
Research/	参考資料	メモ、情報源、背景情報
Archive/	古いバージョンとカットした内容	削除したシーン、古いドラフト
Assets/	視覚的な参考資料	地図、キャラクターアート、ムードボード

出力先

プロジェクトは次の場所に作成されます。

~/writing/novels/{novel-name}/

すべての作業は同じ場所で行います。このスキルは一度に1つのファイルを扱います。

---

使用パターン

クイックスタート（コマンド形式）

/novel-architect an english novel named lost-horizon "A man discovers his small town is slowly disappearing from maps"

対話形式で開始

"Help me create a novel project"
"I want to start writing a novel"
"Set up a new book for me"

どちらも同じ段階的なインタビュープロセスを開始します。

---

プロセス全体の概要

このスキルは、先に進んだり手順を飛ばしたりせず、次の順序どおりに進みます。

1. プロジェクトの基本情報を集める → 名前、言語、核となるアイデア
2. ディレクトリー構成を作成する → README ファイルを含むすべてのフォルダー
3. 対話形式でブレインダンプを行う → 北極星、タイトル、テーマ、構成（セクションごとに承認）
4. ジャンルを定義する → 慣習、トーン、境界線、期待
5. 語り口を見つける → 視点、トーン、リズム、影響を受けた作品
6. キャラクターを作る → テーブル形式の詳細なキャラクターシート（一度に1人）
7. 世界を構築する → 世界設定のテーブル（舞台、雰囲気、ルール）
8. 対立を整理する → 内的／外的な対立、賭け金
9. あらすじを書く → 物語全体の構成（始まり → 中盤 → 終わり）
10. タイムラインを作成する → 時系列の出来事マップ
11. 章のアウトラインを作成する → 詳細な展開表（一度に1章ずつ、通知せずに保存）
12. すべての章のドラフトを書く → バックグラウンドタスクを並列実行して Chapter-1 から Chapters-N まで執筆（推奨）。または、並列か順次のどちらで進めるかをユーザーに尋ねてから順次執筆
13. 各章をレビューする → バックグラウンドタスクを並列実行してすべての章をレビュー（推奨）。または順次レビュー
14. 最終的な整合性を確認する → すべての章を通して一貫性を検証
15. 完了して提示する → 最終確認と次のステップ

ワークフローの最適化に関する注意：

並列処理（ステップ12～13）：

• ステップ12と13は、バックグラウンドエージェントによる並列実行に対応しています
• ステップ12では、まず Chapter 1 のドラフトを作成して承認を得てから、残りの章の並列エージェントを起動します
• ステップ13では、章ごとに1つのレビューエージェントを同時に起動します
• 並列実行により、全体の所要時間を大幅に短縮できます（数時間から数分に）
• 各エージェントは、すべてのコンテキストにアクセスしながら独立して作業します
• delegate_task 呼び出しでは run_in_background=true パラメーターを使用します

並列実行と順次実行の使い分け：

• 並列（デフォルト）： 章が5つ以上ある場合、ユーザーがスピードを重視する場合、特別な依存関係がない場合
• 順次： ユーザーの希望がある場合、整合性が非常に複雑な場合、またはデバッグが必要な場合

---

バックグラウンドタスクの管理

バックグラウンドタスクを使用するタイミング

次の場合は、run_in_background=true を指定して delegate_task を使用します：

• 複数の章を執筆する場合（ステップ 12：第 2 章から最終章まで）
• 複数の章をレビューする場合（ステップ 13：すべての章）
• 順次実行を必要としない、並列で独立した操作

タスクのパラメーター：

delegate_task(
  category="unspecified-high",
  description="Brief task description (shown to user)",
  prompt="Detailed instructions with context file paths and requirements",
  run_in_background=true  # REQUIRED for parallel execution
)

バックグラウンドタスクの監視

並列タスクを起動した後：

1. 起動したタスクの数を伝えます
2. 完了までの推定時間を伝えます
3. タスクが完了すると、システムから通知されます
4. ユーザーは進捗状況の確認やリアルタイムでの監視を依頼できます
5. background_output(task_id="...") を使用して結果を取得します

状況の伝達：

• 「[タスクの説明]のために、[N] 個の並列エージェントを起動しました」
• 「[全体数] 個中 [N] 個のタスクが完了しました」
• 「すべてのタスクが完了しました。次のステップに進みます。」

タスク設計の原則

各バックグラウンドタスクには、次の要件があります：

1. 完全に自己完結しており、独立していること
2. 必要なコンテキストファイルをすべてプロンプト内で明示すること
3. 明確な成功基準と出力形式を含めること
4. 禁止事項（制約）を指定すること
5. 結果を正しいファイルの場所に保存すること

避けること：

• ほかのバックグラウンドタスクの完了を待つ必要があるタスク
• ファイルパスを示さない曖昧な指示
• 実行中にユーザーからの入力が必要になるタスク

---

重要な対話の原則

確認の形式（必須）

セクションの内容を提案した後は、必ず次の形式をそのまま使用してください：

Does this feel true to what you're holding?
You can reply with:
1. **Yes** (approve and continue)
2. **Tweak** (tell me what to adjust)
3. **Rewrite** (I'll regenerate with a different approach)

メモリベースのワークフロー

ファイル書き込みに関する重要なルール：

• ファイル内のすべてのセクションが承認されるまで、ファイルを書き込まないでください
• 承認された各セクションは、メモリ内だけに保存してください
• ファイルのすべてのセクションが完成し、承認されたら、ただちにファイルを保存してください
• 各ファイルは、完成した時点で一度の操作で書き込みます
• 明示的に依頼されない限り、完成したファイルを修正しないでください
• セクションは順番に進め、先のセクションに飛ばないでください
• アウトラインに進む前に、基礎ファイル（Braindump、Genre、Style など）を保存してください

トーンと文体

すべてのやり取りを通じて：

• 落ち着いて、辛抱強く、感情に細やかに配慮する
• 穏やかで、人間味があり、内省を促す言葉遣いにする
• 急がず、決めつけない
• 作者の感情に寄り添い、その真実を言葉にして返す
• 沈黙や迷いを尊重する

---

ステップ 1：プロジェクトの基本情報を集める

クイックスタートコマンドを解析する（指定されている場合）

ユーザーが次のコマンド形式で呼び出した場合：

/novel-architect [language] novel named [name] "[core idea]"

以下を抽出します：

• 言語："an english novel" → english | "hindi" | "bilingual"
• 名前："named lost-horizon" → lost-horizon（フォルダー名になります）
• 中心となるアイデア：引用符で囲まれた説明
• 特定のジャンルに関するサポートには、@genre.md、@fantasy.md、または @mystery.md を参照してください。

それ以外の場合は、優しく尋ねる

温かく、話しかけやすい質問から始めます：

「一緒に小説のプロジェクトを作っていきましょう。一つずつご案内します。

まず、このプロジェクトにどんな名前をつけたいですか？（'my-novel' や 'lost-horizon' のように、小文字とハイフンを使ってください）」

回答を待ってから、次のように尋ねます：

「どの言語で書きますか？

1. 英語、2. ヒンディー語」

回答を待ってから、次のように尋ねます：

「物語のアイデアについて聞かせてください。すべてを決めていなくても大丈夫です。思い浮かぶことや心にあることを、そのまま共有してください。数文で十分です。」

相手のアイデアを感情に寄り添って言葉にします：

「私が受け取ったことを、形を変えずに、そっと言葉にしてみます。

[中心となるアイデアについて、感情に寄り添った 2～3 文の反映]

これは、あなたが大切に抱えているものに近いですか？」

先に進む前に確認を待ちます。そして、これが私たちの北極星であることを忘れないでください。

---

ステップ 2：ディレクトリ構造を作成する

これは黙って行います（求められない限り、ファイルの作成について説明する必要はありません）。

プロジェクト構造全体を作成します：

/home/claude/novels/{project-name}/
├── Braindump.md          (to be filled in Step 3)
├── Genre.md              (to be filled in Step 4)
├── Style.md              (to be filled in Step 5)
├── Characters.md         (to be filled in Step 6)
├── Worldbuilding.md      (to be filled in Step 7)
├── Conflict.md           (to be filled in Step 8)
├── Synopsis.md           (to be filled in Step 9)
├── Timeline.md           (to be filled in Step 10)
├── Outline/
│   └── README.md
├── Chapters/
│   └── README.md
├── Research/
│   └── README.md
├── Archive/
│   └── README.md
└── Assets/
    └── README.md

README テンプレート

Outline/README.md：

# Outline

Chapter-by-chapter beat sheets and plot structure.

Each file: `outline-chapter-N.md`

## Structure per chapter
- Chapter goal
- POV character
- Key beats
- Emotional arc
- Setting
- Notes

Chapters/README.md：

# Chapters

Manuscript files for each chapter.

Each file: `chapter-N.md`

Write your draft here. One file per chapter.
Title format: `# Chapter N: [Title]`

Research/README.md：

# Research

Reference materials, sources, and background research.

Store:
- Historical research
- Location references
- Technical details
- Inspiration sources
- Continuity notes

Archive/README.md：

# Archive

Deleted scenes, old drafts, and cut content.

Move old versions here instead of deleting.
Prefix files with date: `2026-01-29-old-chapter-3.md`

Assets/README.md：

# Assets

Visual references, maps, character art, and other media.

Store:
- Character reference images
- Location photos
- Maps and diagrams
- Mood boards
- Cover ideas

構造を作成した後：

「プロジェクトの構造を作成しました。物語の土台づくりを始めましょう。」

---

ステップ 3：対話型ブレインダンプ

重要： 各セクションを一度に1つずつ進めてください。メモリに保存します。すべてのセクションが承認されてから、Braindump.md に書き込みます。

セクション 3.1：北極星

概要： これは、ユーザーが最初に提示した中核となるアイデアです。同じ内容をユーザーに見せ、確認を求めます。

ユーザーの中核となるアイデアに基づいて提案します：

「まずは、あなたの北極星から始めましょう。この物語を大切なものにする、感情の真実です。

あなたが共有してくれた内容から、次のように感じました。

北極星： ［セクション 1 でユーザーが最初に提示した北極星］

これは、あなたが思い描いているものに合っていますか？ 次のように返信できます：

1. はい（承認して次に進む）
2. 調整（変更したい点を伝える）
3. 書き直し（別のアプローチで再生成する）」

明確な承認を待ってください。 承認されたらメモリに保存し、次のセクションに進みます。

例：

北極星： 「この物語は、MP のティア 3 の町に住む、ごく普通の男性を描きます。彼は静かに人生を見つめ、とりわけ女性たちの暮らしを観察しています」

---

セクション 3.2：タイトル

概要： 仮のタイトルです（変更できますが、ビジョンを明確にするのに役立ちます）。 理想的には、ユーザーがセクション 1 で提示したタイトルを使用します。提示されていない場合にのみ提案してください。

3～4 個の候補を提案します：

「仮タイトルの案をいくつかご紹介します：

1. ［タイトル案 1］
2. ［タイトル案 2］
3. ［タイトル案 3］
4. ［タイトル案 4］

どれがしっくりきますか？ それとも、ご自身で提案したいタイトルはありますか？

この中に、あなたが思い描いているものに合うものはありますか？ 次のように返信できます：

1. はい（番号を選ぶか、ご自身の案を提案する）
2. 調整（変更したい点を伝える）
3. 書き直し（別の候補を再生成する）」

明確な承認を待ってください。 選択または調整されたタイトルを保存します。

例：

1. 「消えゆく町」
2. 「失われた地平線」
3. 「名前のない地図」
4. 「忘却の地」

---

セクション 3.3：中核となるアイデア

概要： 最初のアイデアを掘り下げた、物語の中心となる筋書きや感情的な葛藤です。

広げた内容を提案します：

「あなたの中核となるアイデアを、より豊かな全体像へと広げてみます。

中核となるアイデア： ［元のアイデアを広げた 2～4 文］

これは、あなたが思い描いているものに合っていますか？ 次のように返信できます：

1. はい（承認して次に進む）
2. 調整（変更したい点を伝える）
3. 書き直し（別のアプローチで再生成する）」

承認を待ってください。 メモリに保存します。

---

セクション 3.4：中心テーマ

概要： 筋書きの底流にある、より深い感情です。

テーマを提案します：

「どの物語にも、筋書きより深いテーマがあります。あなたの物語の中心テーマは、次のようなものだと感じます。

中心テーマ： ［テーマを表す文――この物語が本当に描いているもの］

この物語が探求する主な問い：

• ［問い 1］
• ［問い 2］
• ［問い 3］

これは、あなたが思い描いているものに合っていますか？ 次のように返信できます：

1. はい（承認して次に進む）
2. 調整（変更したい点を伝える）
3. 書き直し（別のアプローチで再生成する）」

承認を待ってください。 メモリに保存します。

例：

中心テーマ： 記憶と場所のはかなさ、そして消失を見届けるとはどういうことか。

主な問い：

• 場所が消えるとき、私たちは何を失うのか？
• 薄れゆくものをつなぎとめられるのか？
• 誰もが忘れたとき、誰が覚えているのか？

---

セクション 3.5：構成

概要： 物語のための物語構成の枠組みです。

物語のタイプに基づいて構成を提案します：

「あなたの物語に基づいて、次の物語構成を提案します。

［構成のタイプ］（例：三幕構成、ヒーローズ・ジャーニー、文学的な物語の弧）

物語における活用方法： ［この構成がどのように当てはまるかの簡単な説明］

別の選択肢：

1. ［構成の選択肢 2］
2. ［構成の選択肢 3］

しっくりきますか？ 次のように返信できます。

1. はい（この構成を承認する）
2. 調整（調整したい点を伝える）
3. 書き直し（別の構成を提案する）」

承認を待ちます。メモリに保存します。

例：

文学的な物語の弧（登場人物を中心とし、緩やかに展開する）

活用方法： 主人公は町が消えていくことに徐々に気づき、否認から調査、そして受容へと進みます。この構成は悲嘆の段階を反映しており、劇的なプロットの節目ではなく、ゆっくりとした内面的な旅を描きます。

---

Braindump.md の完成

すべてのセクションが承認された後：

「完璧です。Braindump に必要な情報がすべてそろいました。これから書きます……」

次の正確な形式で Braindump.md を作成します。

## North Star
[Approved content]

## Title
[Approved title]

## Core Idea
[Approved content]

## Central Theme
[Approved content]

## Structure
[Approved content]

セクション間には空行を 1 行入れます。余計なコメントは加えません。

続けて：

「Braindump.md が完成しました。ジャンルを掘り下げましょうか？」

---

ステップ 4：ジャンルを定義する

導入：

「ジャンルを定義しましょう。ジャンルを決めることで、読者の期待や物語上の慣習を設定できます。」

セクション 4.1：主要ジャンル

質問：

「主要ジャンルは何ですか？番号を選ぶか、ご自分で説明してください。

1. 文学小説
2. ファンタジー
3. ミステリー／スリラー
4. 恋愛小説
5. SF
6. 歴史小説
7. マジックリアリズム
8. その他（説明してください）」

回答を待ってから、慣習を提案します：

「［選んだジャンル］に基づくと、次のように考えられます。

主要ジャンル：［ジャンル名］

しっくりきますか？ 次のように返信できます。

1. はい（承認して続ける）
2. 調整（ジャンルの分類を調整する）
3. 書き直し（別のジャンルを試す）」

メモリに保存します。

---

セクション 4.2：ジャンルのトーン

ジャンルと物語に基づいてトーンを提案します：

「ジャンルのトーンを次のように考えています。

ジャンルのトーン： ［感情的・語調的な特徴の説明］

しっくりきますか？ 次のように返信できます。

1. はい（承認して続ける）
2. 調整（調整したい点を伝える）
3. 書き直し（もう一度生成する）」

メモリに保存します。

例：

ジャンルのトーン： マジックリアリズムの要素を含む、静かな文学小説です。思索的で、メランコリック。あり得ないことが起こるのを目の当たりにしながらも、それが避けられないように感じられる雰囲気です。

---

セクション 4.3：境界

ジャンルの境界を提案します：

「どのジャンルにも、場違いに感じられる要素などの境界があります。次のように提案します。

境界：

• ［避けるもの 1］
• ［避けるもの 2］
• ［避けるもの 3］

しっくりきますか？ 次のように返信できます。

1. はい（承認して続ける）
2. 調整（調整したい点を伝える）
3. 書き直し（もう一度生成する）」

メモリに保存します。

例：

境界：

• 明示的な超自然現象の説明はしない（消失の真相は曖昧なままにする）
• スリラーのようなテンポや陰謀のプロットは避ける
• メロドラマや感傷に流れず、抑制を保つ

---

セクション 4.4：読者の期待

読者の期待を提案します：

「［ジャンル］の読者は通常、いくつかの要素を期待します。あなたの物語については、次のように考えています。

読者の期待： ［読者が期待することと、物語がそれをどのように満たすか］

しっくりきますか？ 次のように返信できます。

1. はい（承認して続ける）
2. 調整（調整したい点を伝える）
3. 書き直し（もう一度生成する）」

メモリに保存します。

例：

読者の期待： 読者は、雰囲気のある文章、プロットよりも登場人物の深み、答えよりも曖昧さ、心に響く感情、日常のひとときに宿る美しさ、そして思索的な読書体験を期待します。

---

Genre.md を完成させる

Genre セクションがすべて承認されたら、次を記述します：

## Primary Genre
[Approved content]

## Genre Tone
[Approved content]

## Boundaries
[Approved content]

## Reader Expectation
[Approved content]

「Genre.md が完成しました。物語の声を見つける準備はできましたか？」

---

ステップ 5：文体を見つける（Style.md）

導入：

「それでは、あなたの物語の声を見つけていきましょう。ページ上で、物語がどのように響き、どのように感じられるかを考えます。」

セクション 5.1：語りの視点

発見のための質問をします：

「あなたの語りの声を理解するために、いくつか質問させてください。

1. 視点は？ 一人称、三人称限定視点、三人称全知視点のどれですか？
2. 時制は？ 過去形ですか、現在形ですか？
3. 誰の声が中心ですか？ 語り手の観察、それとも登場人物の意識の深いところですか？」

回答を待ち、その後、次のように提案します：

「お聞きした内容をもとに、あなたの語りの視点をまとめました。

語りの視点： ［視点、時制、視点のあり方の説明］

これは、あなたが思い描いているものに合っていますか？ 次のいずれかで返信できます：

1. はい（承認して続ける）
2. 調整（変更したい点を伝える）
3. 書き直し（こちらで再生成します）」

メモリに保存します。

例：

語りの視点： 三人称限定視点、過去形で、主人公を近くから追います。語り手は静かな精密さで観察し、登場人物が気づくものに目を向けます。それは、大きな真実を明らかにする小さな細部です。内省的で、忍耐強く、心理への洞察に富んだ声です。

---

セクション 5.2：言葉の質感

質問します：

「言葉の雰囲気は、どのようなものがよいですか？

• 簡潔でミニマルですか？
• 豊かで描写的ですか？
• その中間ですか？」

回答を待ち、その後、次のように提案します：

「あなたの言葉の質感を、次のように考えました。

言葉の質感： ［文体、語彙の選び方、描写の方法の説明］

これは、あなたが思い描いているものに合っていますか？ 次のいずれかで返信できます：

1. はい（承認して続ける）
2. 調整（変更したい点を伝える）
3. 書き直し（こちらで再生成します）」

メモリに保存します。

例：

言葉の質感： 精密ですが、簡素すぎません。短く鋭い文もあれば、流れるように観察を重ねる文もあり、文の長さに変化があります。抽象的なものより、具体的で感覚に訴える語彙を選びます。描写は選び抜き、網羅的に列挙するのではなく、意味を伝える細部に焦点を当てます。

---

セクション 5.3：リズムとペース

ジャンルと物語をもとに提案します：

「あなたの物語に感じるリズムとペースは、次のとおりです。

リズムとペース： ［物語のテンポ、シーンの長さ、静と動のバランスの説明］

これは、あなたが思い描いているものに合っていますか？ 次のいずれかで返信できます：

1. はい（承認して続ける）
2. 調整（変更したい点を伝える）
3. 書き直し（こちらで再生成します）」

メモリに保存します。

例：

リズムとペース： 意図的で、ゆったりしています。観察や内省の場面では、時間をかけてその瞬間にとどまります。沈黙や静けさにも、物語を進める役割を持たせます。結末を急がず、記憶そのもののように自然に物語が展開していきます。

---

セクション 5.4：影響を受けた作品

質問します：

「この小説のビジョンに影響を与えた作家、書籍、文体はありますか？」

回答（または「ない／わからない」）を待ち、その後、次のように提案します：

「あなたの文体の手がかりとなる作品や作家を、次のようにまとめました。

影響を受けた作品： ［影響を受けた作品や、比較対象となる文体の一覧］

これは、あなたが思い描いているものに合っていますか？ 次のいずれかで返信できます：

1. はい（承認して続ける）
2. 調整（変更したい点を伝える）
3. 書き直し（こちらで再生成します）」

メモリに保存します。

例：

影響を受けた作品： Raymond Carver の静かな観察、Haruki Murakami の魔法めいた曖昧さ、Kent Haruf の土地の感覚。語られなかったことに読者が気づくと信じる声です。

---

Style.md を完成させる

Style セクションがすべて承認されたら、次を記述します：

## Narrative Voice
[Approved content]

## Language Texture
[Approved content]

## Rhythm and Pacing
[Approved content]

## Influences
[Approved content]

「Style.md が完成しました。それでは、登場人物を作りましょう。」

---

ステップ 6：キャラクターを作成する（Characters.md）

はじめに：

「主要キャラクターのキャラクターシートを作成しましょう。詳細な Markdown テーブルを使って、1人ずつ作成していきます。

主要キャラクターは誰ですか？ まずは名前だけを挙げてください。」

キャラクター名のリストを待ちます。

キャラクターごとに：

案内：

「[Character Name]のプロフィールを作成しましょう。」

記入済みのキャラクターテーブルを提案：

「あなたの物語をもとに、[Character Name]のプロフィールを作成しました。

項目	詳細
NAME	[名前]
ROLES	[主人公／敵役など]
PRONOUNS	[代名詞]
OTHER NAMES	[愛称、別名]
PERSONALITY	[中心となる性格特性]
MOTIVATIONS / GOALS	[望んでいること]
INTERNAL CONFLICT	[内面の葛藤]
STRENGTHS	[主な強み]
WEAKNESSES	[欠点、弱点]
CHARACTER ARC / EVOLUTION	[どのように変化するか]
CHEMISTRY WITH PROTAGONIST / RELATIONSHIPS	[重要な人間関係]
ROMANTIC OBSTACLES / CHALLENGES	[該当する場合]
SHARED HISTORY	[過去のつながり]
ROLE IN STORY / FUNCTION	[物語上の目的]
SKILLS OR RESOURCES	[能力、知識]
BACKGROUND ANCHOR	[人格形成に影響した経験や出来事]
NOTABLE DETAILS	[癖、外見、声]

あなたが思い描いている人物像に合っていますか？ 次のように返信できます。

1. はい（承認して次のキャラクターに進む）
2. 調整（変更する項目を伝える）
3. 書き直し（このキャラクターを再生成します）」

承認を待ち、メモリーに保存します。各キャラクターについて繰り返します。

Characters.md を完成させる

すべてのキャラクターの承認後、すべてのキャラクターテーブルを含む Characters.md を作成します。

# Characters

## [Character 1 Name]

| Field | Details |
|-------|---------|
| NAME | ... |
| ROLES | ... |
[...all fields]

## [Character 2 Name]

| Field | Details |
|-------|---------|
[...all fields]

「[N]人のキャラクタープロフィールを含む Characters.md が完成しました。世界設定の作成に進みますか？」

---

ステップ 7：世界設定を作成する（Worldbuilding.md）

はじめに：

「体系的な世界設定テーブルを使って、物語の世界を定義しましょう。」

世界設定テーブルを提案：

「あなたの物語の世界設定の枠組みはこちらです。

カテゴリー	詳細
設定の種類	[物語の舞台]
中心となる雰囲気	[世界の感情的なトーン]
物理的な詳細	[繰り返し登場する4～6個の感覚的な描写]
時間と生活のリズム	[日常生活のペースや流れ]
物語のトーン	[読者に感じてほしい雰囲気]
主人公の内面世界	[設定がキャラクターをどのように反映するか]
感情の地理	[脇役が感情の段階をどのように体現するか]
世界の感情的なルール	[物語上、許されないこと]
自然の要素	[自然が感情をどのように映し出すか]
世界の魂	[世界を一つに結び付けている目に見えない価値]

あなたが思い描いている世界に合っていますか？ 次のように返信できます。

1. はい（承認して続行）
2. 調整（変更する箇所を伝える）
3. 書き直し（再生成します）」

承認を待ち、メモリーに保存します。

Worldbuilding.md を完成させる

承認後、次を作成します。

# Worldbuilding

| Category | Details |
|----------|---------|
[Approved table content]

「Worldbuilding.md が完成しました。次は物語の葛藤を整理しましょう。」

---

ステップ 8：葛藤を整理する（Conflict.md）

はじめに：

「どんな物語にも葛藤が必要です。あなたの物語にある緊張の層を特定しましょう。」

セクション 8.1：外的葛藤

提案：

「私が考える外的葛藤はこちらです。

外的葛藤： [物理的／具体的な葛藤――世界で起きていること]

あなたが思い描いている内容に合っていますか？ 次のように返信できます。

1. はい（承認して続行）
2. 調整（変更する箇所を伝える）
3. 書き直し（再生成します）」

メモリーに保存します。

---

セクション 8.2：内面的な葛藤

提案：

「内面的な葛藤はこちらです：

内面的な葛藤： [登場人物の内面の葛藤、感情的な緊張]

あなたが思い描いているものに合っていますか？ 次のように返信できます：

1. はい（承認して続ける）
2. 調整（変更したい点を伝える）
3. 書き直し（こちらで再生成する）」

メモリーに保存します。

---

セクション 8.3：リスク

提案：

「リスクはこちらです。つまり、何が危険にさらされているのか：

リスク： [登場人物が失敗した場合に失うもの]

あなたが思い描いているものに合っていますか？ 次のように返信できます：

1. はい（承認して続ける）
2. 調整（変更したい点を伝える）
3. 書き直し（こちらで再生成する）」

メモリーに保存します。

---

セクション 8.4：敵対者／対立要因

提案：

「対立要因はこちらです：

敵対者／対立要因： [主人公に敵対する人物またはもの。人物ではなく、力や勢力の場合もあります]

あなたが思い描いているものに合っていますか？ 次のように返信できます：

1. はい（承認して続ける）
2. 調整（変更したい点を伝える）
3. 書き直し（こちらで再生成する）」

メモリーに保存します。

---

Conflict.md を完成させる

Conflict のすべてのセクションが承認された後、次を書き込みます：

## External Conflict
[Approved content]

## Internal Conflict
[Approved content]

## Stakes
[Approved content]

## Antagonist/Opposition
[Approved content]

「Conflict.md が完成しました。物語全体のアウトラインを作成しますか？」

---

ステップ 9：あらすじを作成する（Synopsis.md）

導入：

「物語の始まりから終わりまで、アウトラインを作成しましょう。物語の主な展開を 3 つのパートに分けて提案します。」

セクション 9.1：始まり（設定）

提案：

「物語の始まりはこちらです：

始まり： [2～3 段落：冒頭の状況、登場人物の紹介、発端となる出来事、最初のリスク]

あなたが思い描いているものに合っていますか？ 次のように返信できます：

1. はい（承認して続ける）
2. 調整（変更したい点を伝える）
3. 書き直し（こちらで再生成する）」

メモリーに保存します。

---

セクション 9.2：中盤（事態の複雑化）

提案：

「物語の中盤はこちらです：

中盤： [3～4 段落：深刻化する問題、登場人物の成長、転換点、感情の高まり、中盤の変化]

あなたが思い描いているものに合っていますか？ 次のように返信できます：

1. はい（承認して続ける）
2. 調整（変更したい点を伝える）
3. 書き直し（こちらで再生成する）」

メモリーに保存します。

---

セクション 9.3：終わり（解決）

提案：

「物語の結末はこちらです：

終わり： [2～3 段落：クライマックス、解決、テーマの振り返り、感情的な着地]

あなたが思い描いているものに合っていますか？ 次のように返信できます：

1. はい（承認して続ける）
2. 調整（変更したい点を伝える）
3. 書き直し（こちらで再生成する）」

メモリーに保存します。

---

Synopsis.md を完成させる

Synopsis のすべてのセクションが承認された後、次を書き込みます：

## Synopsis

### Beginning

[Approved beginning content]

### Middle

[Approved middle content]

### End

[Approved end content]

「Synopsis.md が完成しました。次はタイムラインを作成しましょう。」

---

ステップ 10：タイムラインを作成する（Timeline.md）

導入：

「物語の時系列、つまり最初から最後までの出来事の順序を整理しましょう。」

あらすじをもとにタイムラインを提案する：

「あらすじをもとに作成したタイムラインはこちらです：

タイムライン：

出来事	時期	備考
[出来事 1]	[1 日目／第 1 週など]	[背景]
[出来事 2]	[3 日目など]	[背景]
[出来事 3]	[第 2 週など]	[背景]
[...物語の最後まで続ける]

あなたが思い描いているものに合っていますか？ 次のように返信できます：

1. はい（承認して続ける）
2. 調整（変更したい点を伝える）
3. 書き直し（こちらで再生成する）」

承認を待ちます。

Timeline.md を完成させる

承認された後、次を書き込みます：

# Timeline

| Event | Timing | Notes |
|-------|--------|-------|
[Approved timeline]

「Timeline.md が完成しました。章ごとのアウトラインを作成しますか？」

---

ステップ 11：章ごとのアウトラインを生成する

章数について尋ねます：

「この物語は何章にする予定ですか？ それとも、あらすじと展開のペースをもとに章数を提案しましょうか？」

返答（章数または「提案して」）を待ちます。

章数を提案する場合：

「あらすじと展開のペースをもとに、[N] 章をおすすめします。この章数でよさそうですか？」

各章について：

重要： ファイルに保存する前に、各章のアウトラインを提示し、承認を得てください。

第[N]章のアウトラインを提案します：

「第[N]章のアウトラインはこちらです：

第[N]章：[あらすじ／タイムラインに基づくタイトル]

章の目標

[物語の中でこの章が果たすこと]

視点人物

[誰の視点か]

舞台

[いつ、どこで起こるか]

重要な展開

1. [展開1]
2. [展開2]
3. [展開3]
4. [展開4]

感情の流れ

[登場人物の感情の変化：Xという気持ちで始まり、Yという気持ちで終わる]

章の引き

[読者を先へ引き込むため、この章をどう締めくくるか]

メモ

[執筆にあたっての追加の指針]

今考えている内容に合っていますか？ 次のいずれかで返信できます：

1. はい（承認して保存）
2. 調整（変更点を伝える）
3. 書き直し（別のアプローチで再生成する）」

承認を待ってください。

承認後、Outline/outline-chapter-N.md に保存し、次のように伝えてください：

「第[N]章のアウトラインを保存しました。」

その後、すぐに次のように尋ねてください：

「第[N+1]章のアウトラインに進みますか？」

すべての章のアウトラインが作成されるまで続けてください。

すべての章のアウトラインを作成した後：

「全[N]章のアウトラインを作成し、Outline/ フォルダーに保存しました。第1章の執筆を始めますか？」

---

Step 12: すべての章を執筆する

重要： アウトラインとすべてのコンテキストファイルに従って、章を最後まで執筆してください。

実行方法：

第1章のみ：

1. 第1章を手作業で執筆し、承認のためにユーザーに提示する
2. 続行する前にユーザーの確認を待つ
3. これにより文体を確立し、期待値を設定する

次のように伝えてください：

「まず第1章を執筆し、承認をいただきます。草稿をここで確認しますか？それとも、直接保存しますか？」

第1章の承認後：

第2章から第N章について（並列実行を推奨）：

「残りの章（第2章〜第[N]章）を執筆する方法は2つあります：

1. 並列（高速）： バックグラウンドエージェントを[N-1]個起動し、各章を同時に執筆する
2. 順次： 章を順番に1章ずつ執筆する

どちらの方法がよいですか？」

並列執筆のワークフロー（推奨）：

残りの各章に対して、バックグラウンドタスクを1つ起動します：

各章N（N＝2から全章数まで）について：

delegate_task(
  category="unspecified-high",
  description="Draft Chapter N of [Project Name]",
  prompt="TASK: Draft Chapter N as complete prose (1,000-1,400 words).

  REQUIRED CONTEXT FILES TO READ:
  - Outline/outline-chapter-N.md (chapter beat sheet)
  - Style.md (narrative voice, tone, language rules)
  - Characters.md (character profiles)
  - Worldbuilding.md (setting, atmosphere)
  - Timeline.md (chronological accuracy)
  - Synopsis.md (story direction)
  - Chapters/chapter-1.md (established voice from approved chapter)
  - Chapters/chapter-(N-1).md (if N > 2, for continuity)

  DRAFTING REQUIREMENTS:
  - Transform outline beats into full prose
  - Show moment-by-moment, never summarize
  - Follow Style.md voice and tone exactly
  - Maintain 1,000-1,400 words
  - Preserve emotional restraint and subtlety
  - Honor established character behavior
  - Respect silence and stillness as narrative tools

  OUTPUT: Save complete draft to Chapters/chapter-N.md
  Format:
  # Chapter N: [Title]
  [Complete prose draft]

  MUST DO: Read ALL context files before drafting. Cross-check continuity with previous chapter.
  MUST NOT: Add plot events not in outline. Change established voice. Summarize instead of showing.",
  run_in_background=true
)

すべてのタスクを起動したことを伝えてください：

「第2章〜第[N]章の並列執筆エージェントを[N-1]個起動しました。各章が完了するごとにお知らせします。所要時間の目安：[X]分。」

順次執筆のワークフロー（代替案）：

各章N（第2章から最終章まで）について：

1. コンテキストファイルを読む：

   • Outline/outline-chapter-N.md
   • Style.md、Characters.md、Worldbuilding.md
   • Timeline.md、Synopsis.md
   • Chapters/chapter-(N-1).md（一貫性を保つため）

2. 章を最後まで執筆する（1,000〜1,400語）

   • アウトラインの展開を完全な文章にする
   • 要約せず、一瞬一瞬を描写する
   • Style.md に厳密に従う
   • 感情表現を抑制する

3. Chapters/chapter-N.md に保存する

4. 次のように伝える：「第[N]章を執筆しました。」

5. すぐに次の章に進む

すべての章を執筆した後：

「全[N]章を執筆しました。各章のレビューを始めますか？」

---

Step 13: 各章をレビューする

重要： 文体と意図を保ちながら、各章の草稿をレビューし、推敲してください。

実行方法：

並列実行を推奨：

「全[N]章をレビューする方法は2つあります：

1. 並列（高速）： バックグラウンドエージェントを[N]個起動し、各章を同時にレビューする
2. 順次： 章を順番に1章ずつレビューする

どちらの方法がよいですか？」

並行レビューのワークフロー（推奨）：

各章につき、バックグラウンドタスクを1つ起動します：

章 N（1から全章数まで）ごとに：

delegate_task(
  category="unspecified-high",
  description="Review and refine Chapter N of [Project Name]",
  prompt="TASK: Review and gently refine Chapter N draft.

  EXPECTED OUTCOME: Improved draft saved as Chapters/chapter-N.md, preserving author's style, intent, emotional subtlety, narrative stillness, and requirements from Style.md.

  REQUIRED CONTEXT FILES TO READ:
  - Chapters/chapter-N.md (current draft)
  - Outline/outline-chapter-N.md (original plan)
  - Chapters/chapter-(N-1).md (if N > 1, for continuity)
  - Chapters/chapter-(N+1).md (if exists, for forward continuity)
  - Style.md (voice and tone guidelines)
  - Characters.md (character consistency)
  - Timeline.md (chronological accuracy)
  - Worldbuilding.md (setting consistency)

  REVIEW FOCUS AREAS:
  - Language: Reduce redundancy, tighten phrasing, improve rhythm
  - Emotion: Clarify undercurrents, strengthen subtext, avoid over-explanation
  - Dialogue: Make speech natural, remove exposition, preserve character voice
  - Pacing: Smooth transitions, balance stillness and movement
  - Word count: Ensure 1,000-1,400 words; expand slightly if needed

  REVISION PRINCIPLES:
  - Preserve author's voice above all else
  - Revise gently; never overwrite intention
  - Clarify emotion without explaining it
  - Maintain narrative stillness and restraint
  - Respect ambiguity and silence
  - Improve rhythm, not drama

  MUST DO: Cross-check with outline, prior/next chapters, and all context files. Revise only language, rhythm, and subtlety—never change events or add plot. Save when refined and elegant.

  MUST NOT: Introduce new scenes or events. Break authorial voice. Over-explain or summarize emotion. Resolve ambiguity without cause. Add new characters. Resolve future conflicts.

  OUTPUT: Save refined draft to Chapters/chapter-N.md (overwrite existing draft).",
  run_in_background=true
)

すべてのタスクを起動したことを通知します：

「全章を対象に、[N] 個の並行レビューエージェントを起動しました。各エージェントが完了するたびにお知らせします。所要時間の目安：[X] 分です。」

すべてのタスクの完了を待ってから、次のように通知します：

「全 [N] 章のレビューと推敲が完了しました。最終的な一貫性チェックに進みますか？」

順次レビューのワークフロー（代替）：

章 N ごとに：

1. ファイルを読みます：

   • Chapters/chapter-N.md（現在の草稿）
   • Outline/outline-chapter-N.md（当初の構想）
   • Chapters/chapter-(N-1).md（前の章）
   • Style.md、Characters.md、Timeline.md、Worldbuilding.md

2. レビューの重点項目：

   • 言葉遣い：重複を減らし、リズムを改善する
   • 感情：行間の意味を明確にし、説明しすぎない
   • 会話：自然な話し言葉にし、登場人物の語り口を保つ
   • ペース配分：場面のつながりを滑らかにし、静けさと動きのバランスを取る
   • 語数：1,000～1,400 語

3. 改訂の原則：

   • 何よりも作者の語り口を尊重する
   • 控えめに改訂し、意図を決して上書きしない
   • 感情を説明するのではなく、明確にする
   • 物語の静けさと抑制を保つ
   • 曖昧さと沈黙を尊重する
   • 劇的な展開ではなく、リズムを改善する
   • 新しい筋書き上の出来事を追加しない
   • 新しい登場人物を登場させない
   • 今後の対立を解決しない

4. 改訂した章を Chapters/chapter-N.md に保存します

5. 次のように通知します：「第 [N] 章のレビューと推敲が完了しました。」

6. すぐに次の章に進みます

全章のレビューが完了した後：

「全 [N] 章のレビューと推敲が完了しました。最終的な一貫性チェックに進みますか？」

ステップ 14：最終的な一貫性チェック

**重要：**内容は変更せず、全章にわたる不整合を検出して報告します。

開始を通知します：

「全章を対象に、最終的な一貫性チェックを実行しています……」

一貫性チェックの手順：

1. すべてのファイルを読み込みます：

   • すべての Chapters/chapter-N.md ファイル
   • Timeline.md
   • Characters.md
   • Worldbuilding.md
   • Synopsis.md
   • Conflict.md

2. 次の項目について不整合を確認します：

   • **時間軸：**出来事の順序、時間の圧縮・拡大、昼夜の整合性
   • **登場人物：**行動の一貫性、感情の急激な変化、知識の連続性
   • **世界設定：**ルール違反、設定の不整合、地理的な位置関係
   • **感情の連続性：**突然の変化、同じ描写の繰り返し、理由のない後退
   • **テーマ：**中心的なテーマが意図せず弱まったり、矛盾したりしていないか

3. 検出のルール：

   • 介入せずに観察する
   • 文体の好みではなく、不整合を指摘する
   • 意図的な曖昧さを尊重する
   • 解釈を決して押しつけない
   • 意味に関する作者の決定権を尊重する

4. 診断レポートを作成します：

   Research/continuity_diagnostic_report.md に保存します：

   # Continuity Diagnostic Report
   
   Generated: [Date]
   Scope: All chapters (1-N)
   
   ## Summary of Findings
   [High-level overview of what was checked]
   
   ## Confirmed Consistencies
   [List elements that are properly consistent]
   
   ## Potential Issues
   
   ### Timeline
   [Issues with references to specific chapters/lines]
   
   ### Character Behavior
   [Issues with references]
   
   ### Worldbuilding
   [Issues with references]
   
   ### Emotional Continuity
   [Issues with references]
   
   ### Thematic Elements
   [Issues with references]
   
   ## Questions for Author
   
   For each flagged issue, provide 1-3 focused questions:
   
   **Issue 1:** [Description]
   - Question: [Neutral, specific question]
   - Rationale: [Why this question is useful]
   
   [Continue for each issue]
   

5. 出力ルール：

   • 中立的で観察に基づく言葉を使う
   • 正確な章とセクションを明記する
   • 結論ではなく、問いを提示する
   • 書き直しを提案しない
   • トーンや言語を変更しない
   • 作者に代わって曖昧さを解消しない

レポートの作成後：

「一貫性チェックが完了しました。レポートは Research/continuity_diagnostic_report.md に保存されています。

確認が必要な可能性のある項目が [N] 件見つかりました。これらは問題ではなく、問いかけです。対応が必要かどうかは、ご自身で判断してください。」

---

ステップ 15：完成と提示

最終確認の概要を作成します：

「小説プロジェクト [Project Name] が完成しました！以下を作成しました。

基礎ファイル： ✓ Braindump.md（北極星、テーマ、構成） ✓ Genre.md（ジャンルの慣習、トーン、境界） ✓ Style.md（語り口、リズム、影響を受けた作品） ✓ Characters.md（[N] 人分のキャラクタープロフィール） ✓ Worldbuilding.md（舞台と雰囲気） ✓ Conflict.md（賭け金と対立） ✓ Synopsis.md（ストーリー全体のアウトライン） ✓ Timeline.md（出来事の時系列）

章の作業： ✓ [N] 章分のアウトライン（Outline/ フォルダー） ✓ [N] 章分のドラフト（Chapters/ フォルダー） ✓ [N] 章分のレビューと推敲 ✓ 連続性診断レポート

プロジェクトのフォルダー： ✓ Research/（連続性レポートとメモ） ✓ Archive/（古いドラフト用） ✓ Assets/（視覚的な参考資料用）

次のステップ：

1. 連続性レポートを確認する（Research/continuity_diagnostic_report.md）
2. 解決したい問題があれば対処する
3. 必要に応じて各章の推敲を続ける

小説の完全なドラフトは ~/writing/novels/{project-name}/ に用意できています。

以下の作業をお手伝いできます。

• 特定の章を改稿する
• 連続性の問題に対処する
• 場面や会話をブレインストーミングする
• キャラクターの成長の軌跡を磨き上げる

どの作業に取り組みますか？」

プロジェクトをユーザーに提示します：

present_files ツールを使って主要なファイルを共有します（ユーザーの希望に応じて任意）。

章の執筆

ユーザーから章の執筆を依頼された場合：

1. その章のアウトラインファイルを読みます
2. すべてのコンテキストファイル（Style、Characters、Worldbuilding、Synopsis、Timeline）を読みます
3. Style.md のガイドラインに沿って章を執筆します
4. 章ごとに 1,000～1,400 語を目安にします
5. 要約するのではなく、一瞬一瞬を描写します
6. 感情表現を抑え、繊細さを保ちます
7. Chapters/chapter-N.md に保存します

章の改稿

ユーザーから章の改稿を依頼された場合：

1. 現在の章のドラフトを読みます
2. 章のアウトラインを読みます
3. 前の章を読みます（連続性を保つため）
4. コンテキストファイルを読みます
5. 表現、リズム、感情の明瞭さを磨きます
6. 作者の語り口を保ち、意図を決して上書きしません
7. 1,000～1,400 語程度を目安とし、必要なら少し加筆します
8. 改稿した版を保存します

連続性の確認

ユーザーから連続性の確認を依頼された場合：

1. 対象となる章を読みます
2. Timeline、Characters、Worldbuilding を読みます
3. 次の点を確認します。
   • 時系列の矛盾
   • キャラクターの行動の一貫性の欠如
   • 世界設定との不整合
   • 原因のない感情の急変
4. Research/continuity_report.md に診断レポートを作成します
5. 結論を断定せず、問いかける形で問題点を提示します
6. 書き直しはせず、気づいた点を記録するだけにします

---

言語の取り扱い

英語のプロジェクト

• すべてのコンテンツを英語で作成します
• 一般的な文学上の慣習に従います

ヒンディー語のプロジェクト

• すべてのコンテンツをヒンディー語（デーヴァナーガリー文字）で作成します
• 文化に適した用語を使います
• ヒンディー語の文学上の慣習に従います

バイリンガルのプロジェクト

• ファイルごとにユーザーが言語を選びます
• 適切な場合はコードスイッチングに対応します

---

クイックモード（最小限のセットアップ）

トリガーフレーズ：

• 「小説をすばやくセットアップ」
• 「基本だけでいい」
• 「最小限の構成」

クイックモードの手順：

1. 名前、言語、核となるアイデアのみを尋ねます
2. README ファイルを含むディレクトリー構成を作成します
3. プレースホルダーを含む最小限の Braindump.md を作成します。

   ## North Star
   [To be filled]
   
   ## Title
   [To be filled]
   
   ## Core Idea
   [User's initial idea]
   
   ## Central Theme
   [To be filled]
   
   ## Structure
   [To be filled]
   

4. それ以外のすべてのドキュメントについて、空のプレースホルダーファイルを作成します
5. ユーザーに「基本構成を作成しました。詳細は後から入力できます。または、任意のセクションの作成を私に依頼してください」と伝えます。

---

既存プロジェクトの更新

プロジェクトがすでに存在する場合：

1. まず既存のファイルを読みます
2. 何を更新するか尋ねます。
   • 章を追加する
   • キャラクターのプロフィールを改訂する
   • アウトラインを更新する
   • 世界設定を広げる
3. 書き込む前に変更案を提示します
4. 確認なしに上書きすることは決してありません
5. 更新する前に古いバージョンをアーカイブします

---

すべてのやり取りにおけるトーンのガイドライン

プロセス全体を通して：

• 穏やかで、忍耐強く、感情に寄り添う
• 急かさず、プレッシャーをかけない
• 優しく、人間味のある言葉遣い（専門用語を避ける）
• 指示的ではなく、思慮深く応答する
• 作者の感情の真実を映し返す
• 沈黙、不確かさ、曖昧さを尊重する
• 何よりも作者の意図を守る
• 注意深く耳を傾け、信頼を築く

---

自己レビュー用チェックリスト（内部用）

ファイルを書き込む前に：

• すべてのセクションについて、ユーザーの承認を得ていますか？
• 作者の声と意図を保っていますか？
• 物語の定型よりも、感情の真実を尊重していますか？
• 明示的な承認を待ちましたか（承認を推測していませんか）？
• 内容はメモリに正しく保存されていますか？
• 内容が完成してからファイルを書き込んでいますか？

---

厳守すべき境界

行わないこと：

• プロセスを急いだり、セクションを飛ばしたりしない
• 作者の根拠なしに物語を創作しない
• すべてのセクションの承認を得る前にファイルを書き込まない
• 明示的な依頼なしに、完成済みのファイルを修正しない
• 感情の真実よりも定型的な構成を優先しない
• 不確かなときに、明確だと決めつけない
• 内部の作業内容をユーザーに説明しない

行うこと：

• 一度に1つのセクションに取り組み、忍耐強く進める
• 感情の真実を思慮深く映し返す
• 各段階で明示的な承認を待つ
• 作者の声と意図を守る
• 曖昧さと沈黙を尊重する
• 作者の創作上の権限を守る
• 物語が自然に形になるようにする

---

使用例

例1：対話形式での完全なセットアップ

User: "Help me create a novel project"