| name | idea-pipeline:write |
| description | 確定した記事構成をもとに、note/Zennの本文を見出しごとに執筆する。 ユーザーが「本文を書いて」「記事を書いて」「執筆して」「この構成で書いて」と言ったとき、 またはidea-pipeline:structureの出力を受け取って次に進む場面では必ずこのスキルを使え。 これはidea-pipelineの第3工程。第2工程（structure）の後に実行する。
|
工程③：執筆（Write）
確定した記事構成を受け取り、本文を見出しごとに執筆する。
構成（骨格）に肉を付けて、読者が読める状態の本文を作ることがゴール。
手順
1. 条件を確認する
以下が会話から判明していなければ確認する（わかっていれば省略）：
- 媒体（note / Zenn）
- トーン（です・ます調 / やわらかい話し言葉まじり / 技術的で簡潔 など）
- 1見出しあたりの目安文字数（指定なければ note は400〜600字、Zenn は300〜500字）
- 特に入れてほしい具体例・体験談
2. 見出しを1つずつ書く
見出し1つ分の本文を書いて出力し、「次の見出し〈○○〉を書きますか？」と確認してから次に進め。
一度に全部書こうとしないこと。見出しをまたぐと文脈の一貫性が落ち、ユーザーが途中で方向修正できなくなる。
ユーザーから「全部まとめて書いて」と言われても、品質を保つため分割して書くことを伝えて進める。
3. 媒体別の文体を適用する
note向け：
- 「私も〜」「あなたも〜」と読者を引き込む一文から導入を始める
- 体験・感情・失敗談を織り交ぜる。AIが書いた優等生な文章にしない。
- 一文を短く（20〜30字を目安）、改行を多めにする。スマホで読まれるため。
- 専門用語を使ったら必ず一言で説明する
- 読後に「気づき」「行動」「共感」のどれかが残るように書く
Zenn向け：
- 「誰が・何の環境で・何を解決するか」を最初の段落に入れる
- コードは最小で動く例を示す（コードブロック形式）
- 技術選定の「なぜそうしたか」の理由を書く
- 不確かな点は「未検証」「要確認」と明記する
- バージョン・日付・動作環境を明示する
4. 次の形式で出力する
### [見出し名]
本文〜〜〜
（コードブロック・箇条書き・改行など、媒体に合わせた形式で）
5. 全見出しが揃ったら通知する
「全見出しの本文が揃いました。推敲（工程④）に進みますか？」と聞け。
注意事項
ユーザーのアイデア・視点を活かすこと。「表現を整える」のがこの工程の役割であり、全部書き換えない。
事実・数値・固有名詞は断定せず「要確認」とタグを付ける。
次の工程
全見出しの本文が揃ったら idea-pipeline:review（推敲）を呼び出し、全文をそのまま渡せ。
出力例
入力：「H2：確認作業が増えるという構造（note向け、です・ます調、500字程度）」
出力：
### 確認作業が増えるという構造
AIに仕事を頼んだのに、なぜ疲れるのか。
最初は気のせいだと思っていた。でも繰り返すうち、パターンが見えてきた。
AIが答えを出してくれるたびに、「これは本当に正しいか？」という確認が発生する。
頼んだ数だけ、確認が増える。
これは「決断疲れ」に近い現象だ。選択肢が増えるほど認知の負荷が上がり、
最終的には判断すること自体がしんどくなる。AIを使えば使うほど、この確認ループが加速する。
