mcpField
N
narrative-nonfiction

narrative-nonfiction

github.com/rhavekostクリエイティブ・メディア20568 回インストール今日更新
リポジトリ

narrative-nonfiction について

物語、メタファー、読者の変化の道筋を使い、自己啓発や実用ノンフィクションを構成・執筆するワークショップスキルです。企画から章の制作、全体の見直しまでを扱い、セッションの引き継ぎと停止点も定めます。

主な機能

  1. 01本の約束と読者の道筋の設計
  2. 02物語を取り入れた章の開発
  3. 03メタファーの一貫性確認
  4. 04エクササイズの設計
  5. 05仕掛けとペースの確認
  6. 06セッション記録と設計図の維持

活用シーン

  1. 01自己啓発書の企画
  2. 02物語を軸にしたノンフィクション章の開発
  3. 03読者の変化の道筋に沿った原稿の確認

インストール

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

$npx skills add https://github.com/rhavekost/author-toolkit --skill narrative-nonfiction

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

同梱ファイル

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

assets/
book-blueprint-template.md
chapter-template.md
references/
conceptual-reveal.md
empirical-reveal.md
exercise-design.md
metaphor-consistency.md
reveal-engineering.md
structural-reveal.md
transformation-arc.md
voice-editing.md

詳細

ナラティブ・ノンフィクション・ワークショップ

物語の要素やメタファーを使って読者の変容を導く、セルフヘルプ書籍や実践的なノンフィクションのためのワークフローです。

核となるコンセプト: 読者が主人公であり、本は地図であり方法です。変容こそが約束です。

セッションの継続性

書籍プロジェクトは数週間から数か月にわたります。Claude はセッション間で記憶を保持しないため、プロジェクトの設計図ドキュメントが永続的な状態を保ちます。

  • セッション開始時: ほかの作業を始める前に、book-blueprint.md(またはプロジェクトで設計図に使っているファイル)を読みます。sessions/ 内の最近のファイルをざっと確認し、未解決の課題を把握します。
  • セッション終了時: sessions/YYYY-MM-DD_topic-slug.md に簡潔なメモを作成し、行った作業、決定事項、中断した時点をまとめます。2~5 文で十分です。
  • 基盤に変更があったとき: 約束、中心となるメタファー、読者の変容段階、または明かし方の構造が変わったら、すぐに設計図を更新します。設計図は一度限りのテンプレートではなく、信頼できる唯一の情報源です。
  • 未解決の質問を明らかにする: 新しい作業を始める際、前回のセッションから持ち越された質問を列挙し、続行する前にどれに取り組むかをユーザーに尋ねます。

使用する場合

このスキルは、次の用途に適しています。

  • ✅ セルフヘルプ書籍や実践的なノンフィクション書籍
  • ✅ 教訓や変容の軌跡を含む回顧録
  • ✅ 拡張メタファーや物語の枠組みを使う書籍
  • ✅ ストーリー要素を含む実用ガイド
  • ✅ 読者の旅の設計(変容前の状態 → 変容後の状態)
  • ✅ 構造的な議論を展開するノンフィクション(読者がシステムやカテゴリーをどう理解するかを捉え直す書籍)

使用しない場合

このスキルは、次の用途には適していません。

  • ❌ 純粋なフィクション(小説、短編小説)。代わりに fiction-workshop を使います
  • ❌ 学術的な執筆や研究論文。慣例が異なります
  • ❌ そのまま事実を伝えるジャーナリズムや報道。変容の軌跡がありません
  • ❌ ストーリー要素のない技術ドキュメントやハウツーガイド
  • ❌ 読者の旅ではなく、データや事例研究だけに焦点を当てたビジネス書

ステージ 1:基盤づくり

目標: 約束、メタファー体系、変容の軌跡を確立します。

最初の質問
  1. 想定読者は誰ですか?(人口統計的特徴 + 心理的特徴)
  2. どのような変容を約束しますか?
  3. 中心となるメタファーや枠組みは何ですか?
  4. 読者の「変容前」と「変容後」の状態はどのようなものですか?
  5. この書籍ならではの切り口は何ですか?
  6. アウトライン作成済み、または執筆済みの部分はどの程度ありますか?
中核となる要素

約束: 読者が得るものです。「この本は、[方法]によって[変容]を実現できるよう支援します」

メタファー: 中心となるメタファー、それがアドバイスにどう当てはまるか、どこで役立ち、どこで誤解を招くか

読者の旅: 出発点(読者がどこから始めるか)、悩み、抵抗、変容の段階、到達点(読者がどのような人になるか)

どんでん返し/種明かし(該当する場合):何が明かされるか、どのような伏線が必要か、納得できる結末をどう実現するか

必要に応じて assets/book-blueprint-template.md を使います。

完了条件: 読者、約束、メタファー、変容の軌跡を明確に把握していること。


ステージ 2:章の作成

目標: アドバイス、ストーリー、演習のバランスを取りながら、章を執筆または推敲します。

章の構成: 導入(ストーリー/質問)→ 前提(なぜ重要なのか)→ 本文(解説)→ 裏付け(ストーリー/研究)→ 応用(演習)→ 次章へのつなぎ

執筆モード

モードは主にステージ 2(章の展開)とステージ 3(構成の整合性チェック)で使用します。ステージ 1 は自由形式で基盤を構築する段階のため、モードの指定は必要ありません。必要に応じて切り替えてください。

モード呼び出し方焦点
ボイスエディター「語り口の一貫性を確認して……」トーン、比喩の整合性、著者のペルソナ
コンテンツエディター「……の内容を評価して」明瞭さ、網羅性、正確さ
エクササイズデザイナー「……のエクササイズを設計して」実践への応用、適切な難易度
比喩コンサルタント「比喩の一貫性を確認して……」展開された比喩の整合性、混乱の回避
リビールエンジニア「リビールを仕込んで……」伏線、ミスリード、効果

現在呼び出しているモードに対応するリファレンスファイルだけを読み込んでください。セッション開始時にすべてのリファレンスを事前に読み込まないでください。コンテキストの予算を無駄にします。セッション中にモードを切り替える場合は、新しいリファレンスファイルを読み込み、両方を明示的につなぐ作業でない限り、以前のファイルは対象外として扱ってください。

リビールエンジニアについては、reveal-engineering.md は 4 つのリビールパターン(permission-reframe、empirical、structural、conceptual)をまとめたインデックスです。まず「Choosing a Reveal Pattern」のセクションを読み、プロジェクトに適したパターンを特定してから、そのパターンのリファレンスファイルだけを読み込んでください。4 つすべてを事前に読み込まないでください。

各モードの詳しいガイダンスについては、references/ を参照してください。

作成ワークフロー
  1. 目的の確認: 重要な持ち帰りは何か? 構成のどこにあたるか? 次の章に進む前に、読者は何を信じている必要があるか?

  2. 展開の骨子: 導入の選択肢、教えるポイント(2~4 個)、ストーリーや例、エクササイズ、次章への橋渡し

  3. 下書き: 章を書く。「話すように書く」語り口を使う。

  4. 比喩を重ねる: 比喩を含めつつ、無理に押しつけない。

  5. エクササイズを追加: references/exercise-design.md を使う

  6. 磨き上げる: 語り口、ペース配分、読者の意欲を確認する

編集ワークフロー
  1. 対象読者として読む: 引き込まれるか? 理解できるか? 自分にもできると思えるか? 圧倒されるか、それとも準備ができたと感じるか?

  2. 問題を診断する: 混乱 → 明確にする | 退屈 → ストーリーを加える | 抵抗感 → 反論に対処する | 圧倒される → 簡素化する

  3. モードを呼び出す: 関連するリファレンスファイルを読み込む

  4. 実装する: str_replace を使う


ステージ 3:構成の整合性チェック

目標: 本全体が、変化へと導く一貫した道のりとして機能することを確認します。

全体のアウトライン/原稿を読み、次の点を確認します:

  1. 約束の実現: 本は約束を果たしているか? 変化は明確で、実現可能か?
  2. ペース配分: 変化のスピードは適切か? 定着のための停滞期はあるか? 高揚感は高まっているか?
  3. 比喩: 全編を通して維持されているか? 破綻したり、矛盾したりしていないか? 最後まで役立っているか?
  4. リビール(該当する場合):どんでん返しに納得感があるか? 伏線は張られているか? 見方の転換は感情に訴えかけるか?
  5. エクササイズの進行: 互いに積み重なっているか? 難易度は段階に合っているか? バリエーションはあるか?
よくある問題
症状原因対処法
「説教くさい」ストーリーや例が足りない物語を加える
「抽象的すぎる」具体的なアドバイスが欠けている具体的なやり方を加える
「圧倒される」章ごとの内容が多すぎる焦点を絞り、章を追加する
「なぜ気にかける必要があるの?」読者の悩みとのつながりが欠けている読者の苦悩から始める
「自分にはできない」段階的な支援が欠けているより小さなステップや例を加える

セルフチェック:正しく進められていますか?

ワークフローに沿って正しく進められているか、次のチェックポイントで確認してください。

基盤づくりの後:

  • 本の約束を一文で述べられますか?
  • 読者の「前」と「後」の状態を明確に説明できますか?
  • 中心となるメタファーと、それがアドバイスにどう対応するかを理解していますか?
  • メモを見ずに、変化の道筋の各段階を概説できますか?

章の草稿を書いた後:

  • 章に6つの要素すべてが含まれていますか?:フック、導入、本文、根拠、実践、橋渡し。
  • メタファーは押しつけがましくなく、盛り込まれていますか?
  • 語り口は前の章と一貫していますか?
  • 想定読者は内容を理解し、実践できると信じられますか?

エクササイズを設計した後:

  • エクササイズの難易度は、読者の現在の段階に合っていますか?
  • 読者は、これまでに得た知識でエクササイズを完了できますか?
  • 実行に移せるほど具体的ですか?(「生産性を高める」ではなく、「3日間、時間の使い方を記録する」など)
  • これまでのエクササイズを踏まえた内容になっていますか?

モードを呼び出した後:

  • 「Voice Editor」や「Metaphor Consultant」、または特定のモードを明示的に依頼しましたか?
  • フィードバックはそのモードの担当領域に絞られていますか?
  • 複数の観点(語り口+内容+エクササイズ)を一度に混在させていませんか?

「完了」とする前に:

  • 全体の道筋は、第1章で掲げた約束を果たしていますか?
  • メタファーは全体を通して一貫していますか?(意図的に発展させている場合を除く)
  • エクササイズは、簡単なものから複雑なものへと論理的に進んでいますか?
  • 意外な展開やどんでん返しがある場合、前の章に伏線が張られていますか?

チェック項目に「いいえ」が1つでもある場合は、先に進まず、その段階に戻ってください。


停止ポイント

各モードと段階には、明確な終了地点があります。そこで停止してください。次のモードへ自動的に進んだり、黙って作業範囲を広げたり、診断を依頼されているのに書き直しを始めたりしないでください。

ツール/段階次の条件を満たしたら停止その後
Foundation Building(Stage 1)Foundation Building Self-Checkに合格した著者に引き継ぎます。Chapter Developmentへ自動的に進まないでください。
Voice Editor依頼された範囲について1回の確認が完了し、所見を報告した著者が変更を適用するまで待ちます。依頼がない限り、他の章を再確認しないでください。
Content Editor明瞭さ/網羅性/正確性に関する問題の診断を提示した停止します。修正案を書かないでください。対応を決めるのは著者です。
Exercise Designer各案の理由とともに、エクササイズ案を2~3個提示した著者に代わって選ばないでください。確認なしに本文へ組み込まないでください。
Metaphor Consultant一貫性に関する報告(対応関係、破綻、提案)を作成したメタファーが使われている箇所を独断で書き直さないでください。報告したら停止します。
Reveal Engineer現在の章について、伏線を張る計画または提案を提示した提案をもとに章の草稿を書かないでください。提案は入力であり、成果物ではありません。
Arc Integrity Check(Stage 3)全体の道筋に関する報告(約束の達成度、ペース配分、メタファー、意外な展開、エクササイズの進行)を提示した著者に引き継ぎます。どの所見に、どの順序で対応するかは著者に委ねてください。
セッション停止ポイントに達した、またはコンテキストウィンドウの余裕がなくなってきた基盤に変更があればブループリントを更新し、sessions/にメモを作成して停止します。

著者から停止ポイントを越えて続けるよう明示的に依頼された場合は、続けて構いません。ただし、作業範囲の変更が分かるように、「これから診断から第4章のフックの書き直しに移ります」のように、次に行う作業を伝えてください。


よくある間違い

間違い起こる理由修正方法
土台づくりを省略する「とにかく書き始めたい」伝えたい約束、比喩、展開が明確でないと、章の内容がぶれていきます。設計図づくりに30分かければ、書き直しにかかる時間を何時間も節約できます。
比喩を無理に当てはめるすべての文を枠組みに合わせようとする比喩は理解を助けるものであり、制約するものではありません。理解の助けになるところで使い、そうでないところでは省きましょう。無理に当てはめるより、自然な表現が効果的です。
教えすぎて、物語が足りない知識をすべて共有したくなる読者はまず物語を通じて共感します。物語・例を40%、解説を40%、実践を20%にすることを目安にしてください。章の必要性に応じて調整しましょう。
読者の準備度に合わない演習他の本の演習形式をそのまま使う演習の難易度は、読者が展開のどの段階にいるかに合わせる必要があります。序盤の章では簡単な振り返りを、後半の章ではより大きな課題を設定します。
語り口の一貫性が失われる学術的な口調と会話調を切り替えるひとつの語り口(自己啓発書では通常、会話調)を選び、一貫して使いましょう。「Voice Editor」モードを使って一貫性を確認してください。以下の例を参照してください。
読者の抵抗感を無視する読者が前提に同意していると思い込む反論には明確に対応しましょう。「こう思っているかもしれませんが……」と伝えることで、読者の懐疑的な気持ちを理解していることを示し、信頼を築けます。
伏線のないどんでん返しどんでん返しの結末を計画しても、伏線を置かない本に見方の転換や真相の明かしがある場合は、各章にさりげない伏線が必要です。「Reveal Engineer」モードを使って、伏線を配置し、追跡しましょう。
例:語り口の一貫性

一貫性のない語り口(第1章は会話調、第4章は学術調):

第1章:「『生産的な』一日を終えたのに、重要なことは何も達成できていない。そんな感覚、ありますよね?それは、何かがおかしいと脳が教えてくれているのです。」

第4章:「実証研究によると、タイムブロッキングの手法を実践する人は、タスクの完了率と主観的な生産性が大幅に高いことが示されています(Chen et al., 2019)。」

一貫した語り口(どちらも会話調):

第4章:「研究でわかったことを紹介します。タイムブロッキングを使う人は、より重要な仕事を多く終えています。ある研究では、ナレッジワーカー500人を6か月間追跡したところ、タイムブロッキングを使う人は、優先度の高いプロジェクトを60%多く完了していました。あなたの直感は正しかったのです。」

**違い:**会話調の語り口では、「あなた」という呼びかけを保ち、平易な言葉を使い、研究を読者自身の経験と結びつけています。

例:無理な比喩と自然な比喩

本の比喩:「建築家のように考える」

無理な例:「朝起きたら、その日の設計図を描きましょう。土台となるコーヒーを注ぎましょう。あらゆる瞬間が、人生の構造を設計する機会なのです。」

自然な例:「建築家は、着工する前に必要なものを計画します。プロジェクトを始めるときは、まず必要な条件を特定しましょう。ただ建て始めて、うまくいくことを願うだけではいけません。」

**違い:**自然な比喩は、具体的な助言をわかりやすくします。無理な比喩は、あらゆる細部を枠組みにこじつけようとします。

例:段階的な支援を取り入れた演習設計

序盤の章の演習(読者が概念を学び始めたばかりの場合):

EXERCISE: Track Your Time
This week, log what you actually do for three full workdays.
Just notice. Don't judge yourself or try to optimize yet.
Write down: Where did your time go? When were you most focused?

後半の章の演習(読者が基本を実践済みの場合):

EXERCISE: Block Your First Deep Work Session
Choose one morning this week (not your busiest day—start manageable).
1. Identify your most important task
2. Block 90 minutes using the protocol from Chapter 3
3. Practice saying it out loud three times before the actual conversation
4. Deliver the boundary
5. Journal: What happened? How did you feel? What would you do differently?

**違い:**序盤の演習は、プレッシャーをかけず、観察だけを行います。後半の演習では、身につけたスキルを土台にして、行動を促します。


コマンド早見表

必要なことコマンド
新しいプロジェクトを始める"[project] の設計図を作りましょう"
語り口を確認する"[chapter] の語り口の一貫性を確認してください"
内容を編集する"[chapter] の解説を評価してください"
演習を設計する"[concept] の演習を設計してください"
比喩を確認する"[chapters] 全体で比喩の一貫性を確認してください"
真相を明かす伏線を仕込む"[chapter] に [reveal] の伏線を仕込むのを手伝ってください"
展開を見直す"[outline/draft] の変化の展開を見直してください"

指摘の形式

このスキルの診断モード(リビールの仕込みと回収の不一致、メタファーの一貫性チェック、読者の道のりの監査)は、../../references/finding-schema.json に準拠します。audit はモード名、technique は具体的な文章技法の要素(例:「回収のないリビールの仕込み」)、severity は重大度、location は該当箇所、issue は問題点、confidence: "judgment" は確信度を表し、exemplar は任意です。演習の設計と変容の軌道の構成要素(診断ではなく生成を目的とする)は対象外です。


ファイル

  • references/transformation-arc.md - 読者の道のりの構成
  • references/metaphor-consistency.md - 拡張メタファーの管理
  • references/exercise-design.md - 実践的な応用の設計
  • references/reveal-engineering.md - リビールのパターン一覧。許可を捉え直すパターンの詳細
  • references/empirical-reveal.md - 直感に反するデータを用いたリビールのパターン(フリーコノミクス風)
  • references/structural-reveal.md - 見えないメカニズムを明らかにするリビールのパターン(バスティア風)
  • references/conceptual-reveal.md - カテゴリーの転換によるリビールのパターン(アンチフラジャイル風)
  • references/voice-editing.md - 語調とペルソナの一貫性
  • assets/book-blueprint-template.md - 書籍の計画書
  • assets/chapter-template.md - 章構成のテンプレート

コメント