WriteStory

🚨 必須：音声通知（アクションを起こす前に必須）

このスキルが呼び出されたら、何よりも先にこの通知を送信する必要があります。

1. 音声通知を送信する：

   curl -s -X POST http://localhost:31337/notify \
     -H "Content-Type: application/json" \
     -d '{"message": "Running the WORKFLOWNAME workflow in the WriteStory skill to ACTION"}' \
     > /dev/null 2>&1 &
   

2. テキスト通知を出力する：

   Running the **WorkflowName** workflow in the **WriteStory** skill to ACTION...
   

これは任意ではありません。スキルの呼び出しと同時に、この curl コマンドをただちに実行してください。

WriteStory

概要

WriteStory は、フィクション執筆のための足場を提供します。すでにあるもの――一文、メモのフォルダー、書きかけの章――をもとに、プロの作家が意図的に活用する手法を使って、物語の残りを一層ずつ組み立てる手助けをします。創造力を発揮するのはあなたです。不足している要素を補うのが WriteStory の役割です。物語そのものを代わりに書くことはありません。

課題

物語を書きたいと思っている人の多くは、最後まで書き上げられません。心を離れない登場人物、思い描けるけれど地図にできない世界、背筋がぞくっとする結末――そのひらめきはあります。しかし、ひらめきから完成した草稿までの間には、構成、登場人物の隠れた傷、感じ取れるのに言葉にできないテーマ、読者の心に響くはずなのに響かない文章といった難題があります。一般的なツールは、こうした空白をそのままにするか、物語を代わりに書いて、自分のものとは思えない作品を返してきます。WriteStory は、物語をあなたから奪うことなく、その空白を埋めます。

仕組み

作業は7つの物語レイヤーを通して進み、執筆する各書籍は、システムが後から戻って作業を続けられる状態を保持するプロジェクトになります。

7つのレイヤー

ここでは、どの物語も次の7つのレイヤーを通して組み立てます。

1. 意味 — テーマ、物語が示す主張、物語が投げかける問い
2. キャラクターの変化 — 聖なる欠点／誤った信念 → 変容（Storr、Cron）
3. プロット — 出来事の因果関係の連鎖
4. 謎 — 読者が知っていることと知らないこと、そしてそのタイミング
5. 世界 — 舞台、政治、ルール、世界が人々に与える圧力
6. 人間関係 — 重要な絆がどのように変化し、登場人物を追い詰めるか
7. 文章表現 — 修辞技法、声、審美性、文体

レイヤーは目指す到達点です。そこに至る順序を決めるのは作家であり、システムではありません。詳しくは「レイヤー・インタビュー」をご覧ください。

ワークフローの振り分け

ワークフロー	起動条件	ファイル
Interview	「interview me」「I have notes/an idea for a story」「help me plan a story」「layer my story」	Workflows/Interview.md
BuildBible	「build story bible」「create story plan」「map the story」	Workflows/BuildBible.md
Explore	「explore ideas」「brainstorm」「I'm stuck」「what if」	Workflows/Explore.md
WriteChapter	「write chapter」「write scene」「draft this」	Workflows/WriteChapter.md
Revise	「revise」「edit」「improve」「polish」	Workflows/Revise.md

一般的な進め方は、Interviewで手元にあるものを読み込み、あなたと一緒に物語の骨格を作る → BuildBibleでそれをストーリーバイブル（プロジェクト ISA）にまとめる → WriteChapterでそのバイブルをもとに草稿を書く → Reviseでレイヤーを重ね、磨き上げる、という流れです。レイヤーが本当に空白のときは、アイデアを生み出すExploreを活用します。

プロジェクトと状態

各書籍は、LIFEOS/USER/CUSTOMIZATIONS/SKILLS/WriteStory/projects/<book-slug>/ の下にプロジェクトとして保存されます。

• interview.md — 保存されたインタビュー結果（骨格、レイヤー、確認済みの内容）
• ISA.md — プロジェクト ISA としてのストーリーバイブル。完了した内容と残作業を追跡し、セッションを重ねるごとに成長する、生きた計画です。

書籍の執筆を途中で止めても、後から再開できます。Interview は保存された状態を読み直し、最初からやり直すのではなく、中断したところから再開します。

背後にあるフレームワーク

リファレンス	ファイル	目的
レイヤーアーキテクチャ	StoryLayers.md	7 層システム
ストーリー・フレームワーク	StorrFramework.md	致命的な欠点、支配の理論、ドラマ上の問い、ステータス争い
プレスフィールド・フレームワーク	PressfieldFramework.md	コンセプト、フック、テーマ、Foolscap の 1 ページ手法
導出レンズ	DerivationLenses.md	複数のレンズを用いる背骨エンジン（Storr、Cron、Pressfield/Truby、Egri）
フェーズとイベント	PhasesAndEvents.md	三幕構成、ビート、必須イベント
修辞技法	RhetoricalFigures.md	修辞技法のツールベルト（Forsyth）
クリシェ対策システム	AntiCliche.md	新鮮さの徹底、禁止パターン
ストーリー構成	StoryStructures.md	Dramatica、Story Grid、Sanderson、Hero's Journey
美的プロファイル	AestheticProfiles.md	ジャンルとスタイルの設定
批評家プロファイル	Critics.md	散文の複数回レビュー

基本姿勢

WriteStory は創作者を支援します。創作者に取って代わることはありません。このスキル全体は、次のルールを基盤としています。

• 背骨を創作せず、書き手の背骨を膨らませます。 書き手が持ち込んだものから始めます。
• 導き出した要素はすべて、システムが断定する事実ではなく、書き手が承認する提案です。 それぞれの出どころを明記します。「あなたの種から推測」か、「新しい選択肢として提案」のどちらかです。
• 答えではなく、選択肢を提示します。 承認する改稿案を一つだけ示すのではなく、選べる方向性をいくつか提示します。
• 提案は文やビートのレベルにとどめます。章全体を引き受けてはいけません。
• 書き手自身の声に基づきます。お気に入りの作品、サンプル、文体のリズムを参考にします。
• 書き手の言葉が常に優先されます。 書き手が方向を変えたら、その方向が正解です。
• 散文を出力するのは WriteChapter だけです。それも書き手が確認したバイブルに基づき、書き手自身の所有物として修正可能な草稿の形でのみ出力します。

カスタマイズ

実行前に、次の場所にユーザーのカスタマイズがあるか確認します。 ~/.claude/LIFEOS/USER/CUSTOMIZATIONS/SKILLS/WriteStory/

このディレクトリが存在する場合は、以下を読み込んで適用します。

• PREFERENCES.md — デフォルトのジャンル、美的傾向、声
• projects/<book-slug>/ — 執筆中の各書籍について保存されたインタビューと Story Bible ISA

例

例 1：すでに多くの素材を持っている書き手

User: "I've got a folder of notes for a novel — a few character sketches,
       a rough world, and two draft scenes. Help me build it out."
→ Interview workflow points at the folder and reads ALL of it first
→ Reflects back the story it sees, asks what excites them most
→ Picks a derivation lens that fits what they brought
→ Derives the spine (flaw, dramatic question, theme) as proposals they confirm or redirect
→ Layers outward one dimension at a time, only where they're blank
→ Saves it as a project; hands off to BuildBible

例 2：ストーリーの計画全体を組み立てる

User: "Build the story bible for my novel"
→ BuildBible workflow turns the interview spine into a project ISA
→ Maps all seven layers start to finish, tracks done-vs-remaining
→ Outputs a living bible that guides every chapter

例 3：実際の散文を書く

User: "Write chapter 3 based on the story bible"
→ WriteChapter reads the bible ISA for chapter 3's beats across all layers
→ Deploys rhetorical figures at key moments, in the writer's aesthetic
→ Produces a fresh, anti-cliche draft the writer owns and revises

注意点

• 支援に徹し、決して代替しません。 背骨を創作せず、書き手の背骨を膨らませます。導き出した要素はすべて、出どころを明記したうえで書き手が承認する提案です。これがこのスキルの要点です。書き手と一緒に組み立てるのではなく、物語を自分で生成していることに気づいたら、作業を止めてください。
• 一つのストーリー理論を押しつけないでください。 致命的な欠点を最初に置く方法は一つのレンズであり、絶対的なルールではありません。文学作品、プロット主導のジャンル作品、群像劇、雰囲気を重視する作品には、それぞれ異なる背骨が必要です。書き手が持ち込んだものに合ったレンズを選んでください（DerivationLenses.md を参照）。
• 素材が薄い、または雰囲気だけの種には、導出ではなく聞き取りが必要です。 書き手が雰囲気やイメージだけを持ち込んだ場合、因果構造を導き出す前に質問して素材を引き出してください。欠点を捏造して、それを承認されたものとして扱ってはいけません。
• 質問する前に、書き手の素材を読んでください。 すでに提供された内容を無視する一般的な質問票は、この再設計がなくそうとしている失敗パターンです。
• シリーズの連続性を保つための正本はストーリーバイブルです。 新しい内容を書く前に、必ずプロジェクト ISA を読んでください。
• 修辞技法は具体的な技法です。 装飾として使うのではなく、影響の大きい場面で正確に使ってください。
• キャラクターアークは、欠点 → 危機 → 変容というモデル（Storr）に従います。「キャラクターが成長する」ではありません。

実行ログ

ワークフローを完了したら、JSONL エントリーを 1 件追加します。

echo '{"ts":"'$(date -u +%Y-%m-%dT%H:%M:%SZ)'","skill":"WriteStory","workflow":"WORKFLOW_USED","input":"8_WORD_SUMMARY","status":"ok|error","duration_s":SECONDS}' >> ~/.claude/LIFEOS/MEMORY/SKILLS/execution.jsonl

WORKFLOW_USED を実行したワークフローに、8_WORD_SUMMARY を入力内容の簡潔な説明に、SECONDS をおおよその実時間に置き換えてください。ワークフローが失敗した場合は、status: "error" を記録してください。