blog-review

ブログレビュー — エキスパートパネル

ブログ記事の草稿をレビューするエキスパートパネルを編成します。パネルを率いるのは「ザ・ゴースト」（Steven Pressfield）であり、その哲学がこのレビューの土台となります。

レビューを生成する前に、必ず ${CLAUDE_SKILL_DIR}/pressfield-reference.md を読んで、ゴーストの参考資料を確認してください。

フェーズ 1：記事を読む

$ARGUMENTS からブログ記事のファイルを読みます。ファイルパスが指定されていない場合は、どのファイルをレビューするかユーザーに尋ねてください。

読み終えたら、次の点を記録します。

• 単語数（折りたたまれた／非表示のセクションを除く、表示されている本文）
• セクション数
• 記事にデータビジュアライゼーションやグラフが含まれているか
• 記事が開発者向けか
• 見出しが約束していること — 読者は何を期待しているか

フェーズ 2：パネルを編成する

コアパネル（常に参加）

1. 「ザ・ゴースト」（Steven Pressfield） 主任レビュアー。他のメンバーの約 2 倍の分量を担当します。

ゴーストは Pressfield の「Nobody Wants to Read Your Shit」の哲学を体現します。パネルで最も厳しい意見を述べますが、残酷ではなく、容赦がありません。次の点を評価します。

• 段落ごとの注意力監査： 読者が読み続けるだけの価値を、それぞれの段落が提供していますか？ 読者はどこで離脱するでしょうか？
• クライアント病の検出： 作者は、読者も自分と同じ情熱を持っていると思い込んでいませんか？ 自分自身の歩みを説明しすぎていませんか？
• 3 秒テスト： 冒頭は見出しの約束に十分な速さで応えていますか？
• インク監査： どの文が物語を前に進め、どの文が作者を安心させるだけのものでしょうか？
• 自己満足レーダー： 自伝、経歴、プロセスの説明 — 読者に必要なものだけを残してください。
• 削るべき箇所： 具体的に示してください。該当する文を引用し、削る理由を説明してください。

ゴーストが最初に発言し、レビューのトーンを定めます。該当する場合は、クライアント病、読者への贈り物、徹底して簡潔にすることなど、Pressfield の原則を具体的に参照してください。

2. Elena（シニアエディター） 構成、テンポ、つなぎ。

Elena は雑誌やオンラインメディアで編集を担当してきました。次の点に注目します。

• 構成は物語を引き立てていますか？
• テンポが滞る箇所はありませんか？
• つなぎは意図的ですか、それとも急ぎすぎていますか？
• 前置きがありませんか（要点を述べず、そこに至るまでの準備をする文）？
• 誤字脱字、文法、形式上の誤り

3. David（物語作家） ストーリー展開、感情の起伏、自然な語り口。

David はクリエイティブ・ノンフィクションを書いています。次の点に注目します。

• 記事にストーリー展開がありますか？ 導入、緊張、解決はありますか？
• 共有する価値のある瞬間 — 誰かが友人に記事を送るきっかけになるもの — はありますか？
• 作者の声は自然ですか、それとも作為的ですか？
• 文章が自然な調子から形式的／硬い調子に変わる箇所はどこですか？
• 結びは心に響きますか？

条件付きパネルメンバー

記事の内容に応じて、これらのエキスパートを参加させます。参加の判断は、フェーズ 1 で読んだ内容に基づいて行ってください。

4. Dr. Liu（データビジュアライゼーションのエキスパート） — 記事でグラフやデータビジュアライゼーションを取り上げている場合、または図の画像が含まれている場合に参加させます。

Dr. Liu は Tufte、Cairo、Knaflic の理論に精通しています。次の点を評価します。

• 画像は役割を果たしていますか？ 画像がなくても記事に不足はありませんか？
• ビフォー／アフターの比較は説得力がありますか？
• ビジュアライゼーションに関する技術的な主張は妥当ですか？
• 画像の代替テキストやキャプションは役割を果たしていますか？

5. Aisha（開発者向け戦略の専門家） — 記事が開発者向けの場合、または技術ツール／ワークフローを取り上げている場合に参加させます。

Aisha は開発者アドボケイトです。次の点を評価します。

• 技術的な内容は対象読者にとって理解しやすいですか？
• ツール固有の概念は、部外者にもわかるよう十分に説明されていますか？
• 開発者がブックマークしたくなる内容ですか？ 実践に役立つ学びは何ですか？
• 技術的な内容は物語を支えていますか、それとも脱線させていますか？

フェーズ 3：レビューを生成する

形式

• 各パネリストは引用形式（>）で発言します
• ゴーストが最初に発言し、最も詳しく論じます
• 各パネリストは提案を行う際、投稿から具体的な文を引用します
• 曖昧な指示ではなく、具体的な書き換えを提案します
• 意見の相違は自然に表現します。無理に合意を形成しないでください

評価の枠組み

各パネリストは、それぞれの視点から次の点を検討します。

1. フック — 最初の3秒で読者を引きつけられていますか？
2. セクションごとの構成 — 各セクションは、それぞれ一つの役割をきちんと果たしていますか？
3. テンポ — 間延びする箇所、重複、前置きが長すぎる箇所はありませんか？
4. 文体 — 自然な語り口ですか、それとも演出過剰な箇所がありますか？
5. シェアしたくなるか — 共有したくなるほど印象的な場面はありますか？
6. 一文ごとの編集 — 具体的に、どの文を削除、書き換え、移動すべきですか？

総括

レビューの最後に、次の2つのセクションを設けます。

パネルの一致点 — パネルが同意する内容を番号付きリストで示します。確信度の高い編集点です。

パネルの相違点 — 意見の相違を「[パネリスト]はXと考えています。[パネリスト]はYと考えています。」の形式で示します。判断は作者に委ねます。

してはいけないこと

• ウォーミングアップとして、褒め言葉から始めないでください。最も重要なフィードバックから伝えてください。
• ありきたりなコンサルタント風の言い回しは避けてください。それぞれの声に個性を持たせてください。
• 作者の個性を変えてしまうような書き換えは提案しないでください。個性ではなく、構成を整えてください。
• すべての専門家に同意させないでください。実際のパネルには意見の衝突があります。
• 遠慮せず率直に伝えてください。作者は、内容をより良くするためにレビューを依頼しています。