YosukeIida Answer-First Writing
概要
多くの文書は、書き手が考えた順（背景→分析→結論）のまま書かれるため、読み手は結論を自分で探すことになる。この skill は情報を「考えた順」から「読み手が判断できる順」に並べ直す。結論を最上段に、理由を中段に、証拠を下段に置き、読者テストに合格するまで検証する。
判断基準は一つ：想定読者が最初の2文だけを読んで、何が結論で、自分が何をすべきか分かるか。
結論先行は情報を削ることではない。背景を捨てるのではなく下へ送る。明確さは冷たさではなく、読者の時間に対する敬意である。
2つのモード
- rewrite モード：ユーザーの下書き（メール・Slack・提案書・報告書・企画書）を再構築して最終稿を出す。
- report モード：エージェント自身が調査・監査・実装などの結果を報告するとき、この型で報告を組み立てる。読者＝依頼主、取ってほしい行動＝「次に何を判断・指示するか」を既定値とする。
入力パケット（工程0）
作業前に以下を把握する。rewrite モードで会話から読み取れないものは仮定を置き、解釈次第で結論が変わる場合に限り1回だけ質問する。細部の不明点で作業を止めない。
- 読者（誰が読むか・その状況）
- 文書の目的
- 読者に取ってほしい行動（最重要。「説明したい」は目的ではない。「B案を承認してほしい」まで具体化する）
- 期限・制約
- 絶対に残す情報・使ってよい根拠
置いた仮定は最終出力に明記する。
内部ワークフロー（工程1〜5）
以下は役割の異なる5つのレンズであり、同じ確認の反復ではない。「もっと深く考える」を繰り返すのではなく、工程ごとに見るものを変える。途中経過は表示せず、最終出力だけを出す。
1. ピラミッド設計
- 読者の中心的な問いを1つ特定する。
- 答え・提案・依頼を1文にする。立場を取ること。「〜について共有します」は題名であって結論ではない。
- **成果物・結論が複数あるときは、先にその数を認識する。**すべてを覆う結論を1つ立てるか、並列の成果物として最上段に並べる。一方の結論を他方の本文中段に埋めない。
- 結論を支える論点を2〜4個に整理する。同じ分類軸・同じ抽象度でそろえ、MECEにする。5個必要に見えたら結論が広すぎる。
- 各論点の下に証拠（数字・実名の事例・引用・実測）を置く。
- **事実・推論・仮定を分離する。根拠がないものは創作せず「未検証」「要確認」と明記する。**文章を強くするために事実を弱くしない。
2. SCQA導入（長文のみ）
提案書・企画書・記事など長文で、結論をいきなり置くと唐突になる場合のみ作る。短いメール・Slack・報告では省略し、結論から始める。
- Situation（読者が同意できる事実）→ Complication（判断が必要になった変化）→ Question（読者の問い）→ Answer の順に最大4文。
- 「現代は変化が激しい」のような何にでも使える一般論は禁止。
- Answer はピラミッド最上段の結論と完全に一致させる。
3. 論理監査
- 支持論点の分類軸を言語化する。軸が混在していれば直す（「市場が成長」「9月開始」「費用50万」は軸が違う）。
- 重複（言い換えただけの論点）・欠落（結論を支えるのに足りない論点）・飛躍（証拠から結論へ跳んでいる箇所）を探す。
- 読者が出しうる最も強い反論を1つ作り、それに答える根拠があるか確認する。なければ未検証として明記するか、主張を弱める。
- 問題を致命的／重要／軽微に分類する。遠慮して数を減らさない。
4. 読者テスト
実際の読者（工程0で特定した人物・状況）として判定する。
第1段階：最初の2文だけを読んで答える — (1) 結論は何か (2) 自分は何をすべきか (3) いつまでか。1つでも不明なら不合格。
第2段階：全文を読み、5軸を各0〜2点で採点する（合計10点）。
| 軸 | 2点の基準 |
|---|---|
| 行動の明確さ | 次に取る行動と期限が一意に分かる |
| 論点の網羅性 | 判断に必要な論点が2〜4個で揃っている |
| 証拠の十分さ | 主要な主張に具体的根拠がある（未検証は明示済み） |
| 読者との関連性 | 読者の関心・権限・知識に合っている |
| 簡潔さ | 結論・理由・証拠以外の文がない |
即不合格条件：最初の2文で結論・依頼が不明／主要な主張に証拠がない／次の行動が不明／重大な反論が未処理。
5. 停止条件付き修正
- 8点未満、または致命的問題がある場合だけ修正する。指摘された箇所以外を書き換えない。
- 修正後に工程4で再評価する。書き直しは最大2回まで。
- **合格したら止める。**それ以上磨かない。十分に明確な文書を早く出すことが、完成しない完璧より価値がある。
- 2回書き直しても合格しない場合は、最良版と残る問題点（多くは根拠不足）を明示して出し、不足情報の提供をユーザーに求める。
出力形式
- 短文（メール・Slack・短い報告）：チャットに最終稿を直接出す。
- 長文（報告書・提案書・監査結果）：md ファイルに書いて渡す。
- 常に添える：置いた仮定、未検証・要確認事項。最終スコア（5軸の内訳）は rewrite モードでは添え、report モードのチャット報告では省略してよい（求められたら出す）。
- 内部工程（ピラミッド図・監査ログ・各回の採点）は求められない限り出力しない。最終稿がそのまま送信・公開できることが完成条件。
report モードの標準形
結論（1〜2文。判断・依頼を含む）
→ 取ってほしい行動・判断（期限があれば期限）
→ 理由 2〜4個（同一軸・MECE）
→ 証拠（実測値・file:line・出典）
→ 仮定・未検証事項
禁止事項
- 経緯・時系列を本文の骨格にすること（考えた順で書かない）。「ここに至る流れ」「まず〜次に〜」で段落を並べるのは、この skill が排除すべき構造そのもの。作業の経緯は結論を支える証拠になる場合のみ下層に置き、それ以外は削るか付録へ送る。
- 根拠の創作。数字がなければ「必要なデータ」を指摘する。
- 事実・推論・仮定の混同。
- 合格後の追加修正、合格部分の書き換え。
- 結論を弱める空疎なヘッジ（「かもしれません」「一応」「念のため」の乱用）。丁寧さが必要なら挨拶や配慮の文で足す。配慮と遠回りは別物である。