writing-shape

ユーザーは raw material の Markdown ファイルをすでに渡しているか、これから渡します。そのファイルを input pile として扱います。整然とした fragment のリストでも、構造のない prose の塊でも、transcript でも、どのような形式でもかまいません。まず最後まで読み、その後でほかの作業に取りかかります。

次に shaping session を行い、独立した article document を作成します。これは exploit です。探索は完了しており、pile は固定されています。構成を決め、その構成を埋めるために pile を掘り下げます。raw material ファイルは編集しません。この skill では読み取り専用です。

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

The loop

1. Pile を読む。 input file を最後まで読み、内容全体を把握します。
2. 前提知識を明確にする。 読者が読み始める時点で何を知っているか、つまり最初から grounded である概念をユーザーと確認します。それ以外は、ほかの block が依存する前に、いずれかの block で grounded にする必要があります。Grounding を参照してください。
3. opening の候補を2～3つ作成する。 各 opening で、記事の異なる thesis や angle をほのめかします。候補をすべて提示し、ユーザーに選択するか、組み合わせて hybrid にするか決めてもらいます。選ばれた opening によって、記事全体でこの先何を達成する必要があるかが定まります。
4. 段落ごとに書き進める。 Opening が定まったら、「この opening の次に、読者は何を知る必要があるか？」と尋ねます。その答えとなる material を pile から取り出します。次の block が依存できるのは、すでに grounded になった概念だけです。また、block が定まる際には、新しい概念を grounded にします。次の block を paragraph、list、table、callout、quote、code block のどれにするかを検討します。形式の選択はすべて、意図的で、根拠を説明できるものであるべきです。
5. 作業しながら article file に追記する。 まとめて書くのではなく、合意した paragraph や block をすぐに書き込み、記事が形になっていく様子をユーザーに見せます。
6. 記事が完成するまで step 4 を繰り返す。 いつ完成とするかはユーザーが決めます。

Grounding

ある concept に依存する block を書く前に、その概念は必ず grounded になっていなければなりません。読者が読み始める時点ですでに知っているか、それより前の block で触れている必要があります。grounded ではない概念を持ち出す block は、読者を置き去りにしてしまいます。単位は概念であり、その表現ではありません。用語がひとつも登場しなくても、block が読者にない考えに依存している場合があります。概念に名前、つまり term がある場合、grounded にするとは、その考えと用語を一緒に定着させることです。

概念を grounded にする方法は2つあります。

• Prerequisite —— opening の前に grounded にしておきます。読者がすでに知っていることです。冒頭で前提として明示します。
• Introduced —— ある block で概念を確立します。それ以降、記事の残りの部分では grounded になります。

ここまでに grounded にした内容をリストにしておきます。「次に読者は何を知る必要があるか？」と尋ねたとき、次に必要なものの中に grounded ではない概念があれば、それ自体が答えです。まず、その概念をここか、それ以前の block で grounded にします。そうしなければ、先へ進めません。これは Pulling from the pile における gap-naming の一段上の考え方です。あちらは pile に material がない場合、こちらは記事に foundation がない場合です。

重要なのは、何を prerequisite とし、何を記事内で grounded にするかです。冒頭で多くを要求しすぎると、読者を締め出してしまいます。記事内で多くを grounded にしすぎると、opening が定義に埋もれてしまいます。前提知識を決める際に、ユーザーとこの点を確認します。

Conversational feel

これは、逆向きに進める grilling session です。Ideation で尋ねるのは「実際に何に気づいていますか？」ですが、ここで尋ねるのは「この記事は実際に何を主張していて、読者にはどの順番で伝える必要がありますか？」です。必要に応じて異議を唱えます。弱い transitions を見過ごしてはいけません。段落に存在意義がなければ削除します。

次のような具体的な問いかけを継続して使います。

• 「この段落は、ひとつ前の段落にはできない、どんなことを読者にもたらしますか？」
• 「これを削ったら、何が成り立たなくなりますか？」
• 「これは prose ですか、それとも list にすべきですか？ prose にする理由は何ですか？」
• 「この文は2つの役割を担っています。分けるか、どちらかに絞りましょう。」
• 「opening では X を約束していました。話が Y にそれています。筋を通し直すか、opening を変えましょう。」

Pulling from the pile

raw material は script ではなく、quarry として扱います。fragment を取り出し、周囲の段落に合うように書き換えてから配置します。ひとつの fragment を複数の段落に分けたり、別の fragment と組み合わせたり、言い換えたりできます。Pile は掘り下げるためのものです。記事は、ひとつの声で読めるものにします。

pile に記事で必要な内容がなければ、gap を明示します。「ここには例が必要ですが、pile にはありません。例を今出してもらうか、このセクションを削るか、どちらかにしましょう。」

Format arguments to actually have

block の提示方法を選ぶときは、tradeoff を黙って判断するのではなく、ユーザーと声に出して話し合います。

• Prose vs. list. Prose は議論を伝え、lists は並列する項目を伝えます。項目が本当に並列でなければ、prose のほうが適しています。並列であれば、list のほうが読みやすくなります。
• Inline vs. callout. Tip、warning、aside は callout（> [!TIP]、> [!NOTE]）にします。ただし、inline にすると main argument が本当に中断される場合に限ります。そうでなければ inline のままにします。
• Table vs. repeated structure. 同じ形式の内容が同じ fields で3回以上繰り返される場合は、table にします。それ以外は、bold lead を添えた prose にします。
• Quote vs. paraphrase. 元の言い回し自体が重要な場合は quote にします。考え方だけが重要な場合は paraphrase にします。
• Code block vs. inline code. 複数行のもの、実行可能なもの、または説明用のものは block にします。単一の token や identifier は inline にします。

Writing rhythm

block ごとに合意したら、すぐに article file に追記します。書き込む前には、必ずディスクからファイルを読み直します。ユーザーがターンの合間に編集している可能性があるためです。決して確認せずに上書きしません。ユーザーが段落の書き直しを希望した場合は、その段落だけを所定の位置で編集し、ほかの部分には手を加えません。

Out of scope

• pile に存在しない fragment を掘り起こすこと（gap は「Pulling from the pile」の方法で扱います）。
• raw material ファイルを編集すること。
• 公開すること、特定のプラットフォーム向けに整形すること、またはユーザーから依頼されていない frontmatter を追加すること。