writing-shape

ユーザーは、素材をまとめた Markdown ファイルを渡した（またはこれから渡す）予定です。これを素材の山として扱います。整然とした断片のリストでも、まとまりのない文章のかたまりでも、トランスクリプトでもかまいません。形式は問いません。ほかの作業に着手する前に、最初から最後まで読んでください。

次に、構成を練るセッションを行い、独立した記事ドキュメントを作成します。これは 活用 の段階です。探索は終わり、素材の山は固定されています。構成を決め、その構成を埋めるために素材を掘り起こしてください。素材ファイルは編集しないでください。このスキルでは読み取り専用です。

記事の保存先をユーザーが指定していない場合は、一度だけ尋ね、パスを記憶してください。

進行の流れ

1. 素材の山を読む。 入力ファイルを最後まで読みます。何が含まれているか把握します。
2. 前提知識を確定する。 読者が読み始める時点で知っていること、つまり最初から土台ができている概念について、ユーザーとすり合わせます。それ以外の概念は、後のブロックで前提にする前に、先行するブロックで土台を築く必要があります。土台づくりを参照してください。
3. 冒頭の候補を2～3案作成する。 それぞれ異なる主張や切り口を示すものにします。すべて提示し、ユーザーに選択または組み合わせを促します。選ばれた冒頭によって、記事の残りで何を論じるべきかが決まります。
4. 段落ごとに組み立てる。 冒頭が固まったら、「この冒頭を踏まえて、読者は次に何を知る必要があるか？」と尋ねます。その答えになる内容を素材の山から探します。次のブロックで前提にできるのは、すでに土台ができている概念だけです。新しい概念は、ブロック内で土台を築いてから先へ進みます。次のブロックをどの形式にするかも議論します。段落、リスト、表、囲み、引用、コードブロックなどが候補です。形式の選択は、いずれも意図的で、理由を説明できるものにしてください。
5. 記事ファイルに随時追記する。 まとめて書くのではなく、合意した段落やブロックをその都度すぐに書き込みます。記事が形になっていく様子をユーザーが確認できるようにしてください。
6. 記事が完成するまでステップ4を繰り返す。 完成のタイミングはユーザーが決めます。

土台づくり

どの概念も、ブロックが前提にする前に土台ができている必要があります。読者が最初から知っているか、先行するブロックで学んでいる必要があります。土台のない概念に触れるブロックでは、読者がついてこられなくなります。基準となるのは用語ではなく、概念です。専門用語が一つもなくても、読者が知らない考えを前提にすることはあります。概念に名前（用語）がある場合は、考え方と用語を一緒に伝えることで土台を築きます。

概念の土台を築く方法は2つあります。

• 前提知識：冒頭より前に土台が築かれています。読者が持ち込む知識です。最初に確定します。
• 導入：ブロックで概念を説明し、それ以降、記事の残りで土台が築かれたものとして扱います。

土台ができている概念のリストを常に更新してください。「読者は次に何を知る必要があるか？」と尋ねたとき、次の展開に必要な概念の土台ができていなければ、それ自体が答えです。まずその概念の土台を築いてください。このブロック内で築くか、それ以前のブロックに含める必要があります。そうしなければ、次の展開には進めません。これは素材の山から拾い上げる段階を一つ上のレベルにしたものです。前者では素材が不足し、ここでは記事の基盤が不足しています。

前提知識と、記事内で土台を築く概念のどちらにするかが鍵です。最初に多くの知識を求めすぎると読者を遠ざけ、記事内で説明しすぎると冒頭が定義だらけになります。前提知識を確定する際に、ユーザーとすり合わせてください。

対話の進め方

これは、問い詰めるセッションを逆にしたものです。アイデア出しでは「実際に何に気づいているのか？」と尋ねました。ここでは「この記事は実際に何を論じていて、読者はどの順番でそれを知る必要があるのか？」と尋ねます。異議を唱えてください。弱い段落のつながりを見過ごしてはいけません。段落に存在意義がなければ、削除してください。

繰り返し使う具体的な問いかけ：

• 「この段落は、前の段落ではできなかったどんなことを読者に伝えていますか？」
• 「これを削ると、何が成り立たなくなりますか？」
• 「これは文章で書くべきですか、それともリストにすべきですか？なぜ文章なのですか？」
• 「この文は2つの役割を担っています。分けるか、どちらか一つに絞ってください。」
• 「冒頭ではXを約束しました。話がYにそれています。冒頭に結び直すか、冒頭を変えるか、どちらかにしてください。」

## 素材の山から抜き出す

生の素材は台本ではなく、採掘場として扱ってください。断片を取り出し、周囲の段落に合うように手を加えて配置します。断片は複数の段落に分けたり、別の断片と組み合わせたり、言い換えたりしてかまいません。素材の山は掘り起こされるためにあり、記事は一つの声で読めるようにするためにあります。

記事に必要なものが素材の山にない場合は、その不足を明示してください。「ここには例が必要ですが、素材の山にはありません。今すぐ例をください。そうでなければ、このセクションを削除します。」

実際に検討する書式の選択肢

ブロックの表示方法を決めるときは、トレードオフをユーザーに声に出して伝え、一方的に決めないでください。

• 文章かリストか。 文章は論旨を伝え、リストは並列する項目を伝えます。項目が本当に並列でないなら、文章のほうが適しています。並列しているなら、リストのほうがすばやく確認できます。
• 本文中かコールアウトか。 ヒント、警告、補足はコールアウト（> [!TIP]、> [!NOTE]）にします。ただし、本文に入れると主な論旨の流れを本当に妨げる場合に限ります。そうでなければ、本文中に残してください。
• 表か繰り返しの構成か。 同じ項目が同じフィールドで3回以上繰り返されるなら、表にします。それ以外は、太字の見出しを付けた文章にします。
• 引用か言い換えか。 元の表現そのものが重要なら引用し、考えだけが重要なら言い換えます。
• コードブロックかインラインコードか。 複数行、実行可能、または説明用のものはコードブロックにします。単一のトークンや識別子はインラインコードにします。

執筆のリズム

各ブロックについて合意できたら、その都度記事ファイルに追記してください。書き込む前には毎回、ディスクからファイルを読み直してください。ユーザーがターンの間に編集しているかもしれません。内容を確認せずに上書きしてはいけません。ユーザーが段落の書き直しを望んだら、その段落だけをその場で編集し、ほかの部分には手を加えないでください。

対象外

• 素材の山にない新しい断片を探すこと（「素材の山から抜き出す」と同様に、不足への対応をしてください）。
• 生の素材ファイルを編集すること。
• ユーザーから求められていない公開、特定のプラットフォーム向けの書式設定、フロントマターの追加。