writing-shape

ユーザーは、素材をまとめた Markdown ファイルを渡しています（またはこれから渡します）。これを入力素材として扱ってください。きれいに整理された断片のリストから、構成のない長文や文字起こしまで、形式は問いません。ほかのことを始める前に、最初から最後まで読んでください。

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

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

進め方

1. 素材を読む。 入力ファイルを最後まで読みます。何が書かれているか把握してください。
2. 前提知識を確定する。 読者がどのような知識を持って読み始めるか、つまり最初から 基礎として扱う 概念についてユーザーと合意します。それ以外の概念は、後のブロックで前提にする前に、いずれかのブロックで基礎を固める必要があります。基礎固めを参照してください。
3. 冒頭案を2～3案作る。 それぞれ異なる主張や切り口を記事で示唆する案にします。すべて提示してください。ユーザーに案を選んでもらうか、組み合わせてもらいます。選ばれた冒頭によって、記事の残りの部分で何を示す必要があるかが決まります。
4. 段落ごとに組み立てる。 冒頭が決まったら、「この冒頭を踏まえて、次に読者が知るべきことは何か？」と尋ねます。素材から必要な内容を取り出して答えてください。次のブロックで前提にできるのは、すでに基礎が固まっている概念だけです。新しい概念は、そのブロックで基礎を固めます。次のブロックをどの形式にするか、段落、リスト、表、コールアウト、引用、コードブロックなどを検討してください。形式の選択には、いずれも明確な意図と妥当な理由が必要です。
5. 記事ファイルに都度追記する。 まとめて書かないでください。合意した段落やブロックは、その都度すぐに書き込み、記事が形になっていく様子をユーザーが確認できるようにします。
6. 記事が完成するまで手順4を繰り返す。 完成の判断はユーザーに委ねます。

基礎固め

ブロックで前提にする概念は、すべて事前に基礎を固めておく必要があります。読者が最初から知っているか、前のブロックですでに触れていることが条件です。基礎の固まっていない概念を持ち出すブロックは、読者を置き去りにします。基準となるのは用語ではなく概念です。専門用語がなくても、読者が理解していない考えを前提にすることがあります。概念に名前、つまり用語がある場合、基礎を固めるには、概念と用語を一緒に定着させます。

概念の基礎を固める方法は、次の2つです。

• 前提知識 — 冒頭より前に基礎を固めます。読者がすでに持っている知識です。最初に決めて、以降は変更しません。
• 導入 — ブロックで概念を確立します。それ以降、記事の最後まで基礎が固まった概念として扱えます。

基礎が固まった概念の一覧を随時更新してください。「次に読者が知るべきことは何か？」と尋ねたとき、次の展開に必要な概念の基礎が固まっていなければ、それ自体が答えになります。まずその概念の基礎をここ、または前のブロックで固めなければ、その展開には進めません。これは、素材から掘り起こすを一段上のレベルにしたものです。あちらでは素材に内容が足りませんが、こちらでは記事の土台が不足しています。

重要なのは、何を前提知識にし、何を記事の中で基礎固めするかです。最初に求める知識が多すぎると読者を締め出し、記事内で説明しすぎると冒頭が定義だらけになります。前提知識を確定するときに、ユーザーと合意してください。

対話の進め方

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

次のような問いかけを繰り返し使ってください。

• 「この段落は、前の段落ではできなかったどんなことを読者に伝えていますか？」
• 「これを削ると、何が崩れますか？」
• 「これは文章にすべきですか、それともリストにすべきですか？ なぜ文章なのですか？」
• 「この文は2つの役割を果たしています。分けるか、どちらかに絞ってください。」
• 「冒頭でXを約束しました。今はYにずれています。冒頭に沿って軌道を戻すか、冒頭を変えてください。」

## 素材の山から掘り出す

生の素材は台本ではなく、採石場だと考えてください。断片を取り出し、前後の段落に合うように手を加えて、配置します。断片は複数の段落に分けたり、別の断片と組み合わせたり、言い換えたりできます。素材の山は掘り出すためにあり、記事は一貫した語り口で読めることが大切です。

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

形式の選択では、実際に議論する

ブロックの表現形式を選ぶときは、黙って判断せず、ユーザーと声に出して次のトレードオフを検討してください。

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

文章のリズム

各ブロックについて合意が取れたら、その都度記事ファイルに追加してください。書き込む前には毎回、ディスクからファイルを読み直してください。ユーザーがやり取りの合間に編集している可能性があります。確認せずに上書きしてはいけません。段落の書き直しを求められたら、その段落だけを編集し、ほかの部分はそのままにしてください。

対象外

• 素材の山にない新しい断片を探すこと（「素材の山から掘り出す」の説明に従って不足に対処してください）。
• 生の素材ファイルを編集すること。
• 公開すること、特定のプラットフォーム向けに書式を整えること、またはユーザーが求めていないフロントマターを追加すること。