mcpField
S
story-decisions

story-decisions

github.com/haowjyクリエイティブ・メディア54944 回インストール1 日前に更新
リポジトリ

story-decisions について

story-decisions は、物語の選択、その理由、代替案、制約を関連するナレッジベース項目に記録する方法を案内します。決定時の記録を重視し、過去のセッション記録からの抽出方法も扱います。

主な機能

  1. 01決定とその理由を記録
  2. 02却下した代替案を明記
  3. 03関連項目に注釈を配置
  4. 04制約と決定の変更を記録
  5. 05過去のセッションから抽出

活用シーン

  1. 01ブレインストーミングの創作上の選択を保存
  2. 02キャラクターや時系列の決定理由を説明
  3. 03新しい章の前に過去の決定を集約

インストール

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

$npx skills add https://github.com/haowjy/creative-writing-skills --skill story-decisions

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

詳細

ストーリー上の決定事項

ストーリー上の決定事項は、コード上の決定事項よりも早く忘れられてしまいます。キャラクターの年齢、会議シーンの雰囲気、時系列の順序、却下されたプロットの筋についての判断理由は、要約されたブレインストーミング、終わってしまった会話、執筆セッションの合間の作者の頭の中に残されています。1か月後、また疑問が浮かびます。「なぜキャラクターを10歳ではなく8歳にしたんだっけ?」――そして判断理由は消えています。さらに悪いことに、判断が記録されていないため、ライターエージェントが決定事項に矛盾するシーンを書いてしまうこともあります。

判断の理由が新鮮なうちに、選択したその場で記録してください。後から遡って記録するのではありません。長いブレインストーミングのあとに記憶を頼りに記録すると、細かなニュアンスが失われます。選択肢の違いが曖昧になり、制約の具体性が薄れ、理由が後付けの正当化になってしまいます。

記録する内容

各決定事項の記録では、3つの問いに答えます。何を決定したか、なぜそれを選んだか、ほかに何を検討したかです。

  • 選択した内容。 具体的に記載し、影響を受けるキャラクター、シーン、仕組み、または世界の要素を挙げてください。「より軽い雰囲気にすることにした」では曖昧です。「ルート1の会合では、脅威を共有する状況ではなく、コミカルな誤解を使う」と記せば、決定事項になります。
  • 判断理由。 どのような制約、目標、創作上の直感がこの選択を後押ししたのでしょうか。物語のテンポでしょうか。キャラクターの声でしょうか。テーマの一貫性でしょうか。具体性のない理由は単なる意見です。「しっくりきた」では、6回のセッション後にこの決定を実行する必要があるライターの助けにはなりません。
  • 却下した選択肢。 その内容と、却下した理由を記してください。「戦闘から始まる出会いも検討しましたが、キャラクターにはまだ戦闘経験がなく、その能力を説明する必要が生じるため却下しました」は、ストーリー上の決定事項の記録で最も価値のある一文です。次のブレインストーミングで、却下済みの案が再び提案されるのを防げます。
  • 判明した制約。 多くの場合、決定そのものより、それを強いた制約のほうが重要です。「ルート1に割ける日数は2日まで」という説明は、「ルート1の展開を短縮した」より多くの情報を伝えます。
  • 変更内容。 この決定が以前の決定を改めるものなら、何に取って代わるのか、また状況が変化した理由を参照してください。ストーリーの方向性は変化していくものです。それ自体は問題ありませんが、その変化を追跡できるようにしてください。

決定事項の記録場所 — 別ファイルではなく、関連項目に追記

決定事項は、別の決定事項ファイルやマスターログではなく、関連する成果物の中に追記します(kb の meridian context kb)。

キャラクターの年齢に関する決定は、該当するキャラクターファイルに、年齢が記載されている箇所への注記として残します。時系列の順序に関する決定は、タイムラインの該当する出来事の並びに注記します。世界の仕組みに関する決定は、該当する世界設定の項目にある関連システムの説明へ注記します。

これにより、決定事項を、それが規定する事実と同じ場所に保てます。ライターがキャラクターファイルを読み込むと、現在の設定だけでなく、なぜそうなっているのかも確認できます。継続性チェッカーがタイムラインの問題を指摘した場合も、その順序にした理由をすぐに確認できます。

注記の形式
Character is 8 years old at story start.

決定事項の注記には HTML コメントを使用してください。レンダリングされた Markdown では表示されませんが、ソースには保持されます。必要に応じて meridian session から詳しい議論を確認できるよう、セッションへの参照を含めてください。

記録すべき場合と省略すべき場合

誰かが別の選択をするのも妥当で、その理由がストーリー自体からは明らかでない場合は、決定を記録してください。判断基準は、ライターエージェントがシーンを正しく書くために、この背景情報を必要とするかどうかです。

特に重要なのは、次のような場合です。

  • ブレインストーミングの選択肢を絞り込む場合(却下した案も、選んだ案と同じくらい価値があります)
  • 今後のシーンを制約するキャラクターの特性を確立する場合
  • 順序がプロットの論理に影響するタイムライン上の出来事を並べる場合
  • 重要なシーンのトーンやアプローチを選ぶ場合
  • クリティックの指摘を覆す場合(オーケストレーターが同意しなかった理由を記録してください)
  • 以前の決定を見直す場合(何が変わり、なぜ変わったのか)

確立済みの正史やプロジェクトの慣例から自然に導かれる決定は省略してください。キャラクターがまだ戦闘できないことがストーリーですでに確立されているなら、戦闘を避けるシーンの概要は記録する価値のある決定ではなく、制約です。

その場での記録と過去セッションからの抽出

その場で記録する

ストーリーオーケストレーターとナレッジオーケストレーターは、ブレインストーミングで選択肢を絞り込み、方向性が固まるにつれて、決定をリアルタイムで記録します。これが最も質の高い方法です。その場で記録された決定には、文脈が十分に残ります。

選択肢を検討し、作者が方向性を決めたブレインストーミングセッションの後は、すぐに session-miner を呼び出し、決定を抽出して kb にインラインで書き込んでください。後回しにしないでください。会話の直後が、セッションの文脈を最も豊富に保てるタイミングです。

過去のセッションから抽出する

その場で決定が記録されていなかった場合(記録されないことはよくあります)、session-miner は meridian session を使って、過去のセッションのトランスクリプトから決定を抽出できます。これにより、失われるはずだった情報を復元できますが、質は低くなります。圧縮されたセッションでは細かなニュアンスが失われていることがあり、session-miner は理由を記録するのではなく再構成するためです。

次のような場合は、過去のセッションから抽出してください。

  • ライターまたはクリティックが、理由の記録されていない事実に遭遇した場合
  • 新しいアークに取り組み始める際、それを制約する過去の決定をすべて集める必要がある場合
  • 既存の履歴はあるものの決定の注釈がないプロジェクトに参加する場合

session-miner はトランスクリプトを読み取り、追跡可能性を確保するため、ソースセッションをタグ付けした決定の注釈を、該当する kb エントリーにインラインで書き込みます。

コメント