mcpField
N
novel-writing

novel-writing

github.com/wgwtestクリエイティブ・メディア54107 回インストール5 週間前に更新
リポジトリ

novel-writing について

Novel Writing は、小説の構成、執筆、続きの作成、レビューを支援するスキルです。物語の因果関係、登場人物の認識、場面の行動、作者の文体を重視し、原稿の版とフィードバックの管理も扱います。

主な機能

  1. 01章、場面、物語の構成案作成
  2. 02小説の執筆、続きの作成、書き直し
  3. 03構成と登場人物の導入確認
  4. 04具体的な指摘による作品レビュー
  5. 05原稿の版と作者フィードバックの調整
  6. 06作者の文体と物語の細部の保持

活用シーン

  1. 01章の葛藤と物語の展開を計画
  2. 02既存の章の続きを執筆または改稿
  3. 03場面の情報と行動の論理を確認
  4. 04作者の修正版を比較してフィードバックを整理

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/wgwtest/novel-writing --skill novel-writing

インストール後、Claude Code で/novel-writingを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

agents/
openai.yaml
references/
character-introductions.md
cognition-layers-and-language.md
dialogue-and-behavior.md
manuscript-lifecycle-and-feedback.md
planning.md
realism-constraints.md
revision-checklist.md
scene-and-structure.md
scene-causality-and-agency.md
story-outline-and-causal-summary.md
style-fidelity.md
scripts/
check_manuscript_text.py

詳細

小説執筆

概要

文章単位の手直しだけでなく、物語を構成する技術が求められるフィクションの執筆にこのスキルを使用します。構想、文章の執筆や続きを書く作業、完成したフィクションのレビューに対応します。章のバージョンをまたぐ作業では、プロジェクトの原稿の引き継ぎや、著者からのフィードバックの学習も調整します。

使用する場面

次のような依頼があった場合に、このスキルを使用します。

  • 章、シーン、物語の展開、巻、物語全体のアウトライン、あらすじ、設定資料、または種明かしの順序を考える
  • 正式な章、作業中の改稿、著者からのフィードバックをセッションをまたいで管理するフィクションプロジェクトを立ち上げる
  • フィクションの文章の続きを書く、または書き直す
  • 章の構成が適切か確認する
  • 登場人物がわかりやすく紹介されているかレビューする
  • 改稿しながら、著者本来の文体を保つ
  • 著者が手作業で編集した章と実際の納品物を比較し、根拠のあるフィードバックを後の作業に反映する
  • 既存プロジェクトの原稿やアーカイブのルールに沿って改稿を納品する
  • 視認性、手順、年齢、能力など、現実世界の制約にシーンが従っているか検証する

次のような依頼には、このスキルを使用しないでください。

  • 詩のみの依頼
  • 脚本の書式設定作業
  • 物語上の判断が不要な、純粋なコピーエディット
  • ノンフィクションの執筆

ステージの選択

プロジェクトの立ち上げや原稿のバージョンをまたぐ作業では、以下の指示に従ってライフサイクルのリファレンスを読み込みます。文章作成の依頼では、該当するステージを判断します。

1. 構想

文章を書く前に、シーン、章、物語の展開、巻、または物語全体で何を描くかを決める場合に使用します。

以下を読みます。

  • シーンまたは章単位の構想には references/planning.md
  • 物語の展開、巻、または物語全体のアウトライン、あらすじ、単独の設定・理論資料には references/story-outline-and-causal-summary.md
  • 知識、動機、または情報開示が判断を左右する場合は references/cognition-layers-and-language.md
  • 対立、責任、行動の順序、または章同士の接続には references/scene-causality-and-agency.md
  • 計画中の会合、面談、相談、調査、または技術的なシーンが、順番に説明するだけの展開になりうる場合は references/dialogue-and-behavior.md
  • 章の流れが主な懸念事項である場合は references/scene-and-structure.md
  • 章が現実世界の制約に依存する場合は references/realism-constraints.md
2. 執筆または続きを書く

新しいフィクションの文章、既存の文章の書き直し、または既存の章の続きを求められた場合に使用します。

以下を読みます。

  • references/character-introductions.md
  • 判断や台詞が知識、判断、動機の差異に左右される場合は references/cognition-layers-and-language.md
  • 対立、動き、権限、または連続性には references/scene-causality-and-agency.md
  • 続く会話、会議、面談、尋問、家庭内の対立、または実験室や研究のシーンには references/dialogue-and-behavior.md
  • references/scene-and-structure.md
  • references/style-fidelity.md
  • シーンが現実世界の制約に依存する場合は references/realism-constraints.md
3. レビュー

既存のフィクションについて、批評、問題の診断、または改稿の助言を求められた場合に使用します。

以下を読みます。

  • references/revision-checklist.md
  • 台詞が議事録のように読める、登場人物が順番に話す、または人間の反応に乏しく動きだけがあるシーンでは references/dialogue-and-behavior.md
  • 次に、見つかった問題に対応する特定のリファレンスファイルを読み込みます

長編フィクションのコンテキスト戦略

フィクションプロジェクトが、正式な草稿全体を読み込むのが非効率なほど長い場合は、全文を最初に読むのではなく、コンテキスト LOD を使用します。

読み込み順序
  • L0 Task:直ちに行う執筆またはレビューの作業

  • L1 Hard constraints:アウトライン、時系列、設定、課題記録、プロジェクト固有のルール

  • L2 Near-field full text:忠実さが重要な場合の現行章、隣接する章、リンクされた原稿の各レイヤー

  • L3 Far-field structure:章カード、時系列の抜粋、アウトラインの抜粋

  • L4 Cold zone:無関係な後続章や離れた箇所の全文。デフォルトでは対象外

  • 章を直接改稿する場合は、その章の全文を読みます。

  • 会話のリズム、心理描写、曖昧さ、いちゃつく様子、または身体の描写が重要な場合は、要約資料に頼らず、該当箇所の全文を読みます。

  • 構成カードがプロジェクトで正式な本文と矛盾する場合は、その食い違いを指摘し、この作業では本文を根拠として使います。カードを更新するのは、プロジェクトのルールと現在の承認が許す場合に限ります。未レビューの作者による編集が、自動的に正史として受け入れられるわけではありません。

  • 利用可能な構造化コンテキストが不十分な場合は、小説全体を読み込まず、対象を絞って全文を読みます。

  • 確認済みの連続性上の依存関係が必要とする場合を除き、後続章の本文はデフォルトで対象外です。

原稿と作者フィードバックの管理

小説プロジェクトの作成時、または章の各バージョン、手作業で編集・注釈された作者の草稿、納品物、セッションをまたぐ復旧を扱う際は、原稿のライフサイクルと作者フィードバックを読みます。このスキルは、現行の原稿、作業中の改稿、凍結された証拠、再利用可能な作者フィードバック間の準備や引き継ぎを調整します。それぞれのパスと権限は、プロジェクト独自のルールで決まります。別のバージョン管理システムを作成したり、執筆ツールやレビュー用ツールがプロジェクトの正式な原稿を管理していると想定したりしないでください。章を並行して担当する場合は、現在のプロジェクトで明示されているワークフローに従います。

厳守事項

読者の知識と作者の知識は別です

読者がすでに以下を知っていると想定してはいけません。

  • 登場人物が誰か
  • 人々がどのような関係にあるか
  • 場所がどのように見えるか
  • ある行動がなぜ重要なのか

作者が知っていても本文で示されていないことは、情報が欠けているものとして扱います。

重要な登場人物を、何の説明もなく登場させてはいけません

重要な登場人物を物語に効果的な形で初登場させる際は、読者が人物像をつかめるだけの情報を本文に含めます。

  • 身元または役割
  • 現在の出来事や視点人物との関係
  • 第一印象

その人物が悪役、恋愛対象、ライバル、または中核となる味方である場合は、さらに以下のような認識しやすい特徴を少なくとも1つ含めます。

  • 外見
  • 服装
  • 姿勢
  • 声
  • 癖になっている仕草
  • 他の人物の反応
シーンの情報は、アクセスできる範囲に従わなければなりません

登場人物が知り得るのは、そのシーンで把握できることに限られます。

以下を必ず区別します。

  • 見えること
  • 聞こえること
  • 物理的に手が届くこと
  • 正しく推論できること

何かを見ることと、それを理解することは同じではありません。一度近づけたことと、時間をかけて調べられたことも同じではありません。

認知は選択と言葉に影響しなければなりません

重大な決断や会話の前に、情報の分布と認識上の位置づけを分けて考えます。何が共有され、専門的で、個人的な情報なのかを把握し、そのうえで観察、報告、判断、意図、誤認を区別します。

共有された理解は、冗長な説明を避けながらシーンに制約を与えるために使います。専門的な理解は、リスクや利用できる手段を変えるために使います。個人の認知は、登場人物が何を選び、隠し、歪め、試し、または口にするかを決めるために使います。そのすべてを、現在の登場人物、時点、聞き手に照らして分類します。

視点人物がすべての決定権を持つわけではありません

体験の中心人物、問題の当事者、決定権を持つ人物、領域の担い手、実行責任者を区別してください。POVは、どのような圧力が読者に最初に届くかを決めますが、それだけで権限、専門知識、恒久的な支配権が与えられるわけではありません。

重要な場面は、知覚または誤解、選択肢の絞り込み、決断、行動、結果、再評価として、筋道がわかるようにしてください。この流れは診断のための足場として扱い、必須の定型や、全知視点・複数視点のフィクションを禁じる規則として扱わないでください。

対話は行動を通じて展開させる

長く続く対話は、常に身体性を伴い、結果をもたらすものにしてください。登場人物が小道具や器具を扱っているだけで、場面が動いているとは限りません。戦略を明らかにしたり、次の展開を変えたりする機能的な行動と、装飾的な行動や手順上の行動を区別してください。

すべての台詞に感情を示すラベルや恣意的な身振りを添えて、議事録のような文章を修正しないでください。行動の密度は品質の目標ではなく、ビートを均等に配置する必要もありません。声と緊張感が明確なら、テンポの速い対話にはタグを付けなくてもかまいません。情報が届く場面、嘘が試される場面、力関係が変わる場面、自制が崩れる場面、決断が変わる場面では、行動のビートを加えてください。

因果関係と反応の確認は、作者側で行う診断であり、文ごとの語りのテンプレートではありません。文脈、対話、行動、間にやり取りを担わせてください。沈黙を直接述べる表現も有効です。発言に返答があったかどうかを常に説明するのではなく、Dialogue and Behaviorの区別を使ってください。

すべての場面のまとまりに存在意義を持たせる

各章または機能上のまとまりについて、次の問いに答えられるようにしてください。

  • このまとまりでは、どの問題に対処していますか?
  • ここで誰が変わりますか?
  • 終わりまでに何が前進しますか?

状況を変えずに内容を積み重ねるだけの文章は、構成上弱いものとして扱ってください。

文体を形作る要素を守る

原則として、作者の次の要素を維持してください。

  • 対話
  • 内面の思考
  • 脱線の味わい
  • 観察の細部
  • いちゃついた雰囲気や曖昧さ
  • リズムを生み出す反復

言葉遣い、句読点、書き起こしのノイズ、段落の区切りは修正してかまいません。具体的な内容を、黙って要約に圧縮しないでください。

レビュー結果は具体的にする

フィクションをレビューする際は、次の情報を添えて具体的な問題点を報告してください。

  • 該当箇所
  • 問題の種類
  • うまくいかない理由
  • 修正方法

「少し硬い」や「改善できるかもしれない」といった曖昧なコメントは避けてください。

プロジェクトのルールはこのスキルより優先される

フィクションのプロジェクトにすでにローカルルール、文体規約、原稿レイヤーのルールがある場合は、まずそれらに従ってください。このスキルは一般的なフィクションの手法を示すものであり、プロジェクト固有の規則ではありません。

作業手順

  1. タスクがプロジェクトのセットアップ、文章作成の段階、または原稿の複数バージョンや作者からのフィードバックにまたがる作業のいずれに当たるかを確認してください。該当する場合は、プロジェクトフォルダーや原稿ファイルを編集する前に、ライフサイクルのリファレンスを読み込んでください。
  2. タスクに必要な最小限のコンテキスト層を特定してください。
  3. その段階で必要なリファレンスファイルだけを読み込んでください。
  4. 追加の文章を取り込む前に、プロジェクト固有のアウトライン、タイムライン、設定、問題点のファイルを読み込んでください。
  5. 言葉遣い、文体、章の連続性を修正する場合は、対象箇所の前後に当たる文章を全文読み込んでください。
  6. 文章の変更を提案する前に、必須ルールを適用してください。
  7. レビューを行う場合は、要約の前に構造化された問題点を提示してください。
  8. プレーンテキストの原稿ファイルを納品する場合は、同梱チェッカーを python <skill-directory>/scripts/check_manuscript_text.py <file-or-directory> として実行してください。警告は確認の対象とし、自動的に文章の欠陥と見なさないでください。
  9. 繊細なリアリティに関する制約を扱う際に確信が持てない場合は、知ったかぶりをせず、何を確認する必要があるかを伝えてください。

参考資料

コメント