readable-writing-workflow

name	readable-writing-workflow
description	読まれない前提で設計し、クリックから読了・反応までを書き手の責務とみなす。フィード型Web向けのタイトル比重、読者メリット、圧縮、一晩寝かせ、インプット比率、読者リサーチ、構成の割合を手順化する。ブログ・ニュースレター・プラットフォーム長文の発信品質向上に使う。契約書の定型、IMRAD固定の学術査読原稿、編集意図のない自動生成のみには使わない。

読まれる文章ワークフロー

Web 上で長文を公開するとき、選ばれて・読まれて・反応されるまでを一連の仕事として扱う。詳細な論点整理は必要に応じてスキル同梱の references/mindset-and-tactics.md を読む。

手順

ステップ1: 前提を固定する

1. 「誰も自分の文章を読みたいと思わない」前提で設計する。読まれる努力をしていない原稿は埋もれるのが自然、と受け入れる。
2. 仕事の終端を「公開」ではなく 読者に届いた状態 に置く。クリックされない Web 原稿は本文が存在しないのに等しい、というフィード文脈を確認する。
3. 反応（コメント・いいね等）をコミュニケーションの信号として扱い、ゼロに近いときは独り言化を疑う。

ステップ2: クリック以前と以後を分ける

1. タイトルに最大の推敲リソースを寄せる。クリック動機が弱いと本文は読まれない。
2. クリック後は 読者にとってのメリット を各段落で確認する。書き手の書きたいことだけでは成立しない場面が多い、とみなす。
3. 「何を書くか」を読者の疑問・状況から導く。題材が同じでも想定読者が変われば答えるべきことが変わる、と仮説を置く。

ステップ3: インプットと読者リサーチ

1. 下書きが薄いときは インプット不足 を第一原因として疑う。材料がない料理と同じ比喩で扱う。
2. 参照読書では、著者が読者をどう 説得（一緒に考えてもらう） しているかを観察する。
3. 誰に向けて書くか を一人に絞り、その人の疑問・状況・用語レベルをリサーチする。「誰に」が「何を」を決める、という順序を守る。

ステップ4: 構成と執筆

1. 目安として リサーチ7・構成2・執筆1 の配分を検討する。数字は厳密でなくてよい。
2. 構成案では次の2点だけを埋める: (1) 誰に、何を伝えるか (2) 伝えた結果どうなってほしいか。必要ならスキル同梱の assets/outline-two-questions.md をコピーして使う。PREP 等の型に合わないなら無理に当てはめない。
3. 必要なら「旅行の計画」のように ゆるい構成 にし、筆が進む区間で面白さを出す余地を残す。
4. 完成を優先する。永遠に磨くより、線引きして終わらせる。

ステップ5: 圧縮・寝かせ・公開判断

1. 初稿後に 圧縮する。長さは読了率や末尾までの到達を下げる要因になりうる、とチェックする。
2. 一晩寝かせ、自分を最初の読者として通読し、拙い箇所を直す。
3. 可能なら第三者に添削してもらい、「伝わっていない」箇所を特定する。

ステップ6: テーマの芯（任意の最終チェック）

1. 技法だけでは伸びない原稿がある、という自己分析を踏まえ、書かずにはいられない主題があるかを問う。
2. 熱量とさらけ出しはリスクを伴うため、文脈（職場・ブランド・法務）に合わせて調整する。

補助コマンド

• 既定フローの箇条書きを stdout に出す: スキル同梱の scripts/print-workflow.py を python3 scripts/print-workflow.py で実行する。

エラー処理

• 学術 IMRAD・契約条文など 型が固定 の文書では、タイトル比重や「読者メリット」の語り方をドメイン規範に合わせて置き換える。
• 権威・著名性 でクリックが担保される場合は、タイトル最適化の優先度を下げてよい。
• スキル同梱の references/mindset-and-tactics.md の数値（9割・7-2-1 等) は 比喩 として扱い、ジャンルに応じて再配分する。