writing-review

name	writing-review
description	日本語の技術文書を書いた後・公開前にレビューし、重要度つきの指摘レポートを出すスキル（ファイルは変更しない）。日本語の文章品質・AI Slop・表記の慣習・整合性・独自性・語り口を点検する。媒体非依存の汎用版で、ブログMDXなどプロジェクト固有のレビュースキルがあればそちらを優先・併用する。

文章レビュースキル

日本語の技術文書全般（README・ドキュメント・スキル文書・PR説明・記事・スライドなど）の文章品質をレビューする観点とワークフロー。プロジェクトや媒体を問わず使える汎用スキルで、結果は重要度つきの指摘レポートとして出す。

プロジェクト固有のレビュースキル（例: ブログMDX用の /blog-review）があれば、媒体固有チェックはそちらに任せ、本スキルはどの文書にも共通する文章面を見る。

対象範囲

行うこと: 日本語文章ルール／AI Slop・LLMっぽい言い回し／表記の慣習／整合性・流れ／独自性・価値／語り口・演出を点検し、重要度つきの指摘と修正提案をレポートする。

行わないこと: ファイルの自動修正（レポートのみ）／執筆・アウトライン作成／コード・設定の技術的な正しさ（文章面に限る。コードの動作は別途確認）。

修正依頼の場合でも、まずレポートを出し、どの指摘を直すか合意してから着手する。ファイルは変更しない。

適用対象と重み付け

• 観点5（独自性） は公開する読み物（記事・スライドなど）向け。README・設計メモなど参照系には適用しない。
• **太字（**）** は一般の文書では使ってよい（強調・初出用語など要所に絞る）。観点2で弾くのは「AI的な機械的な太字」だけ。媒体によっては太字なしの方針もある（その場合はその規約に従う）。
• コードブロック内のコード・インラインコード（...）は日本語ルールの対象外（コメントや注釈テキストは日本語として読む）。

レビューの進め方

1. 対象文書を通しで一度読む。
2. 下の機械的補助コマンドで機械検出できる項目を先に洗い出す。
3. 観点1〜7を判定する（観点4〜6は通し読みのあとに見る）。
4. 重要度（要修正 / 推奨 / 任意）を付けてレポートにまとめる。

機械的補助コマンド

機械検出できる項目はコマンドで先に洗い出す。対象のパスをFILEに入れて実行（ripgrep / awk）。

コード除外: (1)〜(4)は文書全体に当たるため、コードフェンス内・インラインコード（...）内・注釈（[!callout:]等）内も拾う。マッチがコード内なら違反ではないので除外して判断する。コードが多い文書では下のPROSE（フェンス除外済み本文）に当てると誤検出が減る（ただし行番号は本文内通し番号になる）。

FILE='path/to/doc.md'
PROSE=$(awk '/^[[:space:]]*```/{f=!f;next} !f' "$FILE")   # フェンス内を除いた本文

# (1) AI的な太字の候補（中身のない強調・ラベル型。一般文書では正当な太字も拾う）
rg -n '\*\*[^*]+\*\*' "$FILE"
# (2) ラベル型リスト（- **ラベル**: …）
rg -n '^\s*[-*+]\s+\*\*[^*]+\*\*\s*[:：]' "$FILE"
# (3) 英語(英数字)と日本語の間のスペース
rg -n '[A-Za-z0-9] [ぁ-んァ-ヶー一-龥]|[ぁ-んァ-ヶー一-龥] [A-Za-z0-9]' "$FILE"
# (4) 全角英数・emダッシュ・語並列の中黒（固有名詞内の中黒は目視除外）
rg -n '[Ａ-Ｚａ-ｚ０-９]|──|—|[ぁ-ん一-龥]・[ぁ-ん一-龥]' "$FILE"

# 観点1の客観ルール（数えれば判定できるもの。PROSE=本文のみに当てる）
# (5) 読点が4つ以上の一文（観点1: 読点は最大3）
printf '%s' "$PROSE" | awk 'BEGIN{RS="。"} {n=gsub(/、/,"&"); if(n>=4) printf "読点%d: %s。\n", n, $0}'
# (6) 漢字が7文字以上連続（観点1: 連続漢字は最大6）
printf '%s' "$PROSE" | rg -n '[一-龥]{7,}'
# (7) 文体混在の手がかり（両方とも1以上なら です/ます と である/だ の混在の可能性。だ。は誤検出あり）
printf '%s' "$PROSE" | rg -c '(です|ます)。'; printf '%s' "$PROSE" | rg -c '(である|だ)。'

出力ゼロなら基本OK。(5)(6)はそのまま要修正候補、(7)は両方ヒットしたら該当文を目視で確認する。

観点

各観点の見出し＋見るところ。詳細カタログは references/ に置く。

観点1: 日本語の文章ルール

文体統一・文末句点・読点数・連続漢字・ら抜き・冗長表現・ひらがな化・表記ゆれ・誤用など。客観ルール（読点数・連続漢字・文体混在）は上のコマンドで先に数える。全ルールとNG→OK例は references/japanese-rules.md。

観点2: AI Slop・LLMっぽい言い回し

一次担当=語句レベル（一文単体で判定できる定型表現）。中身のない太字・ラベル型リスト・誇張表現・「重要なのは〜である」式の予告・空虚な形容/動詞など。一覧とNG→OK例、定型句リストは references/ai-slop.md。

観点3: 表記の慣習

観点	内容
英日スペース	英語（英数字）と日本語の間にスペースを入れない（コマンド3で検出。コード内は除外）
半角/全角	数字・英字・記号は半角に統一
ダッシュ・中黒	emダッシュ・2倍ダッシュ（──）を地の文・見出しで使わない。日本語の語の並列に中黒「・」を使わない（「、」「と」でつなぐ。固有名詞内部は可）
用語の定義	用語と説明は全角コロン（用語：説明）で書く
インラインコード	API名・プロパティ名・コード断片はバッククォートでインラインコード化する

例（英日スペースなし）: Baseline 2026で揃いました / React のフックではなくReactのフック。

観点4: 文章の整合性・流れ

一次担当=論理構造の破綻。通しで読み、段落・節・文書全体のレベルで見る（読者が実際につまずく箇所に絞る）。

観点	見るところ
論理の飛躍・矛盾	根拠なく結論へ飛んでいないか。前半と後半で主張が食い違っていないか
段落・文のつなぎ	接続詞が論理関係と合っているか（「しかし」なのに逆接でない 等）
説明の順序	前提→本論→応用の順か。定義する前に用語を使っていないか
重複・冗長	同じ内容を別の場所で繰り返していないか。読者が自力で補える中間段階を書きすぎていないか。重要度=理解を進める繰り返しなら任意、二度同じ理解をさせるなら推奨
見出しの中身	節が答える問い・扱う対象を表す具体的な句か。情報量ゼロ（「例に戻す」等）や、結論を言い切る「オチ」でないか。二要素を詰め込まず単一の句か（「はじめに/おわりに」など慣例見出しは許容）
指示語・主述のねじれ	「これ・それ」が指すものが明確か。主語と述語が対応しているか。読点3つ以内でも引用・条件・結論を1文に詰めて60〜80字超で主述が遠いものは分割を提案
導入と結論の回収	冒頭で示した問い・目的が本文と結びで回収されているか
初出の用語	専門用語が説明・リンクなしに突然出てこないか
論証の厳密さ	推量・可能性を根拠なく断定に変えていないか。別々の決定・原因を「同じ」とまとめていないか。因果は機構（なぜそうなるか）を示しているか。「必ず」でなく条件付き（「〜しやすい」）で述べているか。確認していないことを確認したように書いていないか（事実整合）
伏線の回収	「次節で扱う」とした論点を本当に回収しているか。逆接で終えて放置していないか

観点5: 内容の独自性・価値（ありふれていないか）

公開する読み物向け。公式ドキュメントや既存記事の焼き直しで終わっていないか。

• 焼き直し（要修正）の足切り: 次の両方を満たすときだけ要修正にする — (a) 一次情報に無い検証結果・落とし穴・比較・使い分けが1つも無い、(b) 本文を読まず一次情報（MDN等）の要約で同じ結論に到達できる。片方でも独自要素があれば推奨以下。新しめのAPIの素直な解説でも、独自要素ゼロなら焼き直し扱い。
• 見るところ: 著者ならではの視点（検証・落とし穴・使い分け・比較）／裏付け（具体例・動かした結果・コード）／読後の差分／読者への誠実さ（作為的な例を隠さず疑念を先回りする、都合のよい例だけで一般化しない）。
• ありふれていたら「どの部分が既知情報の繰り返しか」「何を足せば独自になるか」を具体的に提案する。ニッチな題材を頭ごなしに否定しない。

観点6: 語り口と演出

一次担当=文書を通した語りの一貫性・修辞の量（複数箇所の総量で判定）。

• 視点と語り: 例示は受動態でなく行為者を主語に。読者を「あなた」と呼ばず役割名で。無意味な人物設定を冠さない。対象語は具体的に。術語は導入したら最後まで通す。
• 演出の抑制: 修辞疑問・決め台詞・劇的な転回・対句を乱用しない（要所に絞る）。事故・危険を煽らない。一意に決まらない比喩を避け平易な動詞で言う。強調はここぞの一点に絞る（個別の太字・予告フレーズは語句レベルなので観点2で扱う）。

観点7: 公開前チェック（リンク・事実）

• リンク: 空リンク（[テキスト]()）が無いか。外部リンクは到達性を確認（任意で curl -sI <url> | head -1）。
• 事実・鮮度: バージョン番号・「Baseline 20XX」・日付などの事実が公開時点で正しく、古びていないか。

レポート形式

ファイルは変更せず、重要度ごとに整理したレポートを出す。各指摘に「場所（file:line）・該当箇所・なぜ問題か・修正提案」を含める。

## 文章レビュー: <ファイル名>

### 🔴 要修正

- `doc.md:88` 文体混在（ですます/である）→「〜です」に統一 ［該当: 「…注意すべきである。」］
- `doc.md` 全体 焼き直しで独自要素ゼロ（検証・比較・落とし穴なし＝足切り該当）→ 著者の検証・使い分けを足す

### 🟡 推奨

- `doc.md:30-46` 「基本構文」より先に応用が来て理解順が逆 → 節を入れ替える
- `doc.md:15` 「React の」→「Reactの」（英日スペース）
- `doc.md:50` 「正面から扱う」→ 何をどう書くかを具体的に

### 🟢 任意

- `doc.md:60` 同じ説明が前節と重複（言い回し違いの補強）→ どちらかに寄せる

### 指摘なしの観点

- 観点1 日本語ルール / 観点3 表記: OK
- 観点2 AI Slop: 検出なし
- 観点4 整合性・流れ: 問題なし

重要度の天井:

• 客観違反（観点1〜3: ルール違反）→ 要修正まで可。
• 主観観点（観点4〜6）→ 原則 推奨が上限。例外として、観点4の論理矛盾と観点5の焼き直し（足切り該当）は要修正に上げてよい。
• 観点4〜6は主観が入るので、明確に読者が損をする箇所に絞り、好みの押し付けはしない。
• コードの動作・技術的正確性は本レビューの対象外（別途確認する旨をレポートに一言添える）。
• 指摘ゼロの観点も「OK」と明記して網羅性を示す。

チェックリスト

• 機械的補助コマンド（太字 / ラベル型 / 英日スペース / 全角ダッシュ中黒 / 読点 / 連続漢字 / 文体）を実行した
• 観点1: 日本語の文章ルール（references/japanese-rules.md）
• 観点2: AI Slop・LLMっぽい言い回し（references/ai-slop.md）
• 観点3: 表記の慣習
• 観点4: 整合性・流れ（通しで読んで判定）
• 観点5: 独自性・価値（公開読み物の場合。焼き直しは足切りで判定）
• 観点6: 語り口と演出
• 観点7: リンク・事実の確認
• 重要度つきレポートを出力した（ファイルは変更していない）