技術ブログレビュースキルの設計パターン
技術ブログの公開前レビューをClaude Codeスキル化した際の設計知見
レビュー観点の優先順位
6観点を以下の順で評価するのが効果的だった：
- セキュリティ・情報漏洩 — 最優先。1件でも公開ブロック
- 事実の正確性 — 数値はgit logなどで裏取り可能なものは実際に検証する
- ターゲット適合性 — 複数ターゲット（エンジニア/非エンジニア）がいる場合、セクション分けで対応
- 構成・読みやすさ — プラットフォーム別の最適文字数を基準にする
- ブランディング・採用効果 — 宣伝色と信頼性のバランス
- プラットフォーム固有 — ハッシュタグ、アイキャッチ等
数値検証の重要性
ブログ内の「5日で34件」という記述を gh pr list で検証したら実際は32件だった。素材メモの段階で概数を使っていたものが、記事本文でそのまま「事実」として書かれてしまうパターン。
対策: レビュースキルに「git log / GitHub APIで裏取りできる数値は実際に確認する」をルール化した。
素材整理→体裁検討→執筆の3フェーズが有効
- 素材整理: git履歴・ドキュメントから事実を正確にMDに書き出す（ファクトシート）
- 体裁検討: ターゲット・プラットフォーム・切り口を決める
- 執筆: 素材を元に書く
素材フェーズで数値を正確に記録しておくと、執筆時の事実誤認が減る。
S/A/B/C/D の総合評価スケール
レビュー結果を5段階で示すと、筆者が「どこまで直すべきか」の判断がしやすい：
- S: 公開OK（指摘なし）
- A: 公開OK（軽微な改善提案）
- B: 改善推奨（公開可だが品質向上余地あり）
- C: 要修正（指摘解消後に公開）
- D: 公開ブロック（セキュリティ・事実誤認）