writing-staffing

執筆の人員配置

委任された各エージェントは、それぞれの定義から中核となるスキルを読み込みます。このスキルでは、追加で割り当てるスキル、渡すファイル、参照するリソースについて説明します。

モデルの選択

エージェントのデフォルト設定は、通常は適切です。追加のレーンでモデルを上書きしたり選択したりする場合は、作業内容に合わせてモデルを選んでください。創造的なセンスや重大な局面での批評には判断力が必要です。アウトライン作成や複数ドキュメントにまたがる確認には、構造化された統合力が必要です。後続の統合作業で漏れを補えるなら、大量の情報収集や機械的なチェックには、より低コストのモデルを使えます。

モデルの異なる複数のエージェントに作業を振り分ける場合は、盲点の異なる利用可能なモデルファミリーを2つ選んでください。どのモデルやルートを利用できるかを決めつけず、ディスパッチ時に最新のモデルカタログとモデル固有のプロンプトガイドを確認してください。

ファンアウトでは、同じ質問とファイルを異なるモデルファミリーに渡し、それぞれ独立した判断を得ます。モデルの多様性によって異なる盲点が明らかになる可能性がある、重大な判断に限って使用してください。並列レーンでは、異なるプロンプトや重点領域を使います。レーンに不足している能力が必要でない限り、各エージェントのデフォルトモデルを使用してください。

ディスパッチのリファレンス

@writer

声の忠実さには /character-sim を、プロジェクト内の語彙には /shared-dao を追加します。

/creative-writing-modes → resources/prose-modes.md から制作モード（新規執筆、改稿、つなぎ、別案、文章の磨き上げ）を指定します。必要に応じて、/creative-writing-craft → resources/prose-writing.md または resources/scene-construction.md を参照してください。登場するすべての人物について、スタイルファイルとキャラクター状態ファイルに加え、連続性の基準となる情報を渡します。

1つのシーンにつきライターは1人にします。複数のライターが隣接する内容を担当すると、声の一貫性が損なわれます。

@critic

文章や声に重点を置く場合は /creative-writing-craft を、語彙を確認する場合は /shared-dao を追加します。

重点領域（構成、キャラクター、声、文章、連続性）を割り当てます。声の批評にはスタイルファイルを、キャラクターや連続性に重点を置く場合はキャラクター状態ファイルを渡します。

異なる重点領域を並列レーンで実行します。重要度に応じて規模を調整してください。重要度が低い場合は1～2人、標準的な章では3人、重要な次第を担うシーンでは、重要な観点を重複して確認する4～5人を割り当てます。

重要なシーンや判断が分かれる場合は、同じ重点領域の批評を、優れた異なるモデルファミリー2つに振り分けて、意見の相違を統合します。

@editor

編集レベル（編集レビュー、構成編集、ライン編集、コピー編集、校正）を指定します。全体的な確認には /story-review → resources/editorial-review.md を参照し、それ以外の場合は該当する編集レベルのリソースを参照してください。

複数の課題に優先順位をつける必要がある原稿に使用します。1つの観点を深く掘り下げる場合は、@critic を使用してください。

@continuity-checker

原稿に加え、設定の正史、年表、キャラクター状態、語彙の各ファイルを渡します。このエージェントはプロジェクト全体を幅広く読むため、連続性に重点を置くクリティックよりコストがかかります。日常的な確認にはクリティックを、プロジェクト全体にまたがる詳細な検証には連続性チェッカーを使用してください。

@brainstormer

キャラクターのアークには /character-sim を、現実世界に即した設定には /creative-research を追加します。

同じ観点ではなく、異なる切り口で並列レーンを実行します。1つの切り口を5人で検討するより、3つの視点で検討するほうが有効です。

@outliner

アウトラインの作成は方向性を決めてから始めます。まず @brainstormer を使用してください。アウトライナーの出力はライターに渡します。

@style-creator

サンプルの章または既存のスタイルファイルを渡します。/creative-writing-craft → resources/style-analysis.md を参照してください。

@reader-sim

読者のペルソナが特定のキャラクタータイプである場合は、/character-sim を追加します。読者のペルソナと知識の境界、つまりこの読者がすでに読んだ内容を指定してください。原稿を渡します。

執筆と批評のループが収束した後、著者に提示する前に実行します。シーンが技術的には問題なくても、読者の心を動かさないことがあります。

@character-sim

キャラクターの状態ファイルとスタイルファイルを渡します。検討するシナリオまたは関係性を指定します。個別に検討する場合は、キャラクターまたは視点ごとに並列レーンを1つ使用します。キャラクター間のやり取りをテストする場合は、共有シミュレーションを1つ使用します。

@web-researcher

質問、ストーリーの背景、そしてストーリーが現時点で前提としていることを指定すると、調査担当者が矛盾点を指摘できます。

@kb-lead

フィクション固有の事実カテゴリと成果物の構成を利用するために、/story-memory を添付します。きっかけとなった出来事が落ち着いてから委任します。たとえば、章が完成したとき、ブレインストーミングが終わったとき、または作者が決断を下したときです。

労力の調整

重要度に応じて批評の範囲を調整します。方針や章が固まるまでは、ナレッジのメンテナンスを待ちます。執筆と批評のループが収束した後に、読者シミュレーションを実行します。