// ソフトウェアエンジニア向けの技術書・原稿をレビューし、構成・技術的正確性・読者体験の観点から改善提案を行うスキル。ユーザーが技術書の原稿、章のドラフト、チュートリアル記事、技術ドキュメントのレビューを依頼したときに使う。「原稿をレビューして」「この章を見てほしい」「技術書を書いている」「コードサンプルをチェックして」「構成についてアドバイスがほしい」といった依頼で発動する。技術書の執筆支援、編集フィードバック、構成改善、コードレビュー（書籍内のコード）、読者レベルの調整など、技術書制作に関わるあらゆるレビュー作業に対応する。
引数で指定した記事のレビューを行います。記事スラッグを引数に渡すと、textlint による自動校正と誤字脱字・文法的な誤りの指摘を行います。/article-review [スラッグ] の形式で呼び出してください。記事を書いた後のチェック、公開前の校正、文章の品質確認にも使用してください。
技術記事の内容から読者の理解度をチェックする4択クイズを指定のYAML形式で生成するスキル。ユーザーが「この記事のクイズを作って」「理解度チェックを作成して」「記事を読んだ人向けの問題を作って」「selfAssessment形式でクイズを作って」と依頼したときに必ず使う。ブログ記事、技術ドキュメント、チュートリアル、解説記事、技術書の章など、読者の学習内容を確認する問題を作る必要があるあらゆる場面で使う。記事のURL・マークダウン・テキスト・ファイルパスのいずれを渡されても動作する。
記事を英語に翻訳する。記事スラッグを引数に渡すと、日本語の記事を英語に翻訳して contents/blogPost/en/ に出力する。/translate [スラッグ] の形式で呼び出す。
| name | tech-review |
| description | ソフトウェアエンジニア向けの技術書・原稿をレビューし、構成・技術的正確性・読者体験の観点から改善提案を行うスキル。ユーザーが技術書の原稿、章のドラフト、チュートリアル記事、技術ドキュメントのレビューを依頼したときに使う。「原稿をレビューして」「この章を見てほしい」「技術書を書いている」「コードサンプルをチェックして」「構成についてアドバイスがほしい」といった依頼で発動する。技術書の執筆支援、編集フィードバック、構成改善、コードレビュー（書籍内のコード）、読者レベルの調整など、技術書制作に関わるあらゆるレビュー作業に対応する。 |
ソフトウェアエンジニア向けの技術書・チュートリアル・技術記事の原稿を、プロの編集者の視点でレビューし、具体的な改善提案を行う。
原稿を受け取ったら、以下の順序でレビューを進める。
原稿を読む前に、以下を確認または推定する：
ユーザーがこれらを明示していない場合は、原稿の内容から推定し、「〇〇向けの中級者向けチュートリアルとしてレビューしますが、認識は合っていますか？」のように確認する。
最初に大きな視点から見る。細かい文法やtypoは後回し。
構成の論理性を確認する観点：
スコープの適切さ：
これが最も重要。技術書の信頼性に直結する。
コードが実際に動作するかどうかを可能な範囲で検証する。コンテナ環境で実行可能なコードであれば、実際に動かしてみる。
コードブロック自動検証の手順：
原稿ファイル（.md, .rst, .txt）が提供された場合、同梱の scripts/extract_and_run.py を使ってコードブロックを自動検証できる。
# 基本的な使い方（全言語を検証）
python <skill-path>/scripts/extract_and_run.py <原稿ファイル> --json report.json
# Python のみ検証
python <skill-path>/scripts/extract_and_run.py <原稿ファイル> --lang python --json report.json
# タイムアウトを変更（デフォルト30秒）
python <skill-path>/scripts/extract_and_run.py <原稿ファイル> --timeout 60 --json report.json
スクリプトは以下を自動的に行う：
検証結果を確認したら、失敗したブロックについてレビューレポートの「コードレビュー」セクションに以下を記載する：
スクリプトが対応していない言語（Go, Rust, Java等）のコードは、目視で構文チェックを行う。
注意点：
pip install が必要なライブラリは、事前にインストールしてから再実行する技術書のコードは「動く」だけでは不十分。読者が学ぶためのものなので：
x, tmp のような意味のない名前を避ける）書籍全体の統一感を確認する：
レビュー結果は以下の構造で出力する：
# 原稿レビューレポート
## 概要
- 対象: [原稿タイトル/章番号]
- 想定読者: [レベル]
- 全体評価: [ひとことの総合評価]
## 良い点
[原稿の強みを具体的に挙げる。改善点だけでなく、うまくいっている部分を伝えることで著者のモチベーションを保つ]
## 重要な改善提案（優先度: 高）
[技術的な誤り、構成上の大きな問題など、出版前に必ず直すべき点]
## 改善提案（優先度: 中）
[読者体験の向上、説明の明確化など、直すとより良くなる点]
## 細かい指摘（優先度: 低）
[typo、表現の微調整、好みレベルの提案]
## コードレビュー
[コードサンプルごとの具体的なフィードバック。修正案のコードも示す]
## 次のステップ
[著者が次に取り組むべきアクション]
1章分や1節分だけのレビューを依頼された場合も、可能な限り全体の文脈を聞く。「この章の前には何を説明していますか？」「読者はこの時点でどの概念を知っている前提ですか？」と確認する。
書籍に掲載するコードだけをレビューする場合は、通常のコードレビューに加えて「教育目的のコードとして適切か」の観点を加える。本番向けの最適化よりも読みやすさと学習効果を優先する。
まだ本文がなく、目次や構成案だけの段階では：