wording-check

name	wording-check
description	指定したドキュメントの文言をチェックし、日本語としてわかりづらい表現（難解な用語・造語・英語直訳調・論理のねじれ・用語のゆれ・曖昧な指示語）を検出して、修正案を重要度順に報告する。「文言チェック」「言葉遣いのチェック」「わかりやすさのレビュー」「用語のゆれを確認」などの依頼や、スキル・README・ガイド文書の文章レビューを指示されたら読み込む。

文言チェック

指定されたドキュメントの「日本語としてのわかりやすさ」をレビューする手順とチェック観点です。技術的な正しさのレビューではなく、文章表現のレビューを行います。

対象の決め方

• ユーザーが指定したファイル・ディレクトリ・PR番号・コミット範囲だけを対象にする。指定範囲を勝手に広げない。
• PR番号やブランチ差分が指定された場合は差分を取得し、新規に書かれた・書き換えられた文章を中心にチェックする。ファイル分割やテーブル書式変更などで移動しただけの文は対象外（ただし移動時に文言も書き換えられていれば対象）。
• 対象が読み取れない場合は、チェックを始める前にユーザーに確認する。

手順

1. 対象の文章を全て読む（差分の場合は差分全体）。断片だけ読んで判断しない。
2. 「チェック観点」に沿って問題箇所を検出する。用語のゆれは対象ファイルを横断して突き合わせる。
3. grep等で各問題語の全出現箇所を洗い出し、file:lineを確定する。
4. まず報告だけ行い、修正はしない。修正するかどうか・どこまで直すかはユーザーが決める。
5. 修正の指示を受けたら「修正時のルール」に従って直し、修正後に残存ゼロをgrepで確認する。

チェック観点

重要度の高い順。例は過去に実際へ検出・修正したもの（#473の文言調整）。

1. 論理のねじれ・視点のずれ（高）

文の構造が、伝えたい事実と合っていないもの。読んだ人（人間・AIエージェント）が挙動や意図を誤解する。

• 例: 「例外の自己承認を見逃しやすくなる」→ 見逃すのは第三者の視点。本人の話なら「例外を自己承認してしまいやすくなる」。
• 例: 「修正→再評価ループを終了条件にする」→ 終了条件はループではなく「違反ゼロ」。「違反ゼロを終了条件にする」。

2. 難解な用語の流用（高）

数学・心理学などの専門用語を、一般の説明文に持ち込んでいるもの。

• 例: 「閉集合」→「ここに挙げたものだけ」。
• 例: 「一貫性バイアス」→「自分で立てたプランを疑いにくくなる心理」。

3. 造語・内輪語（高〜中）

書き手が発明した言葉で、初見では意味が取れないもの。

• 例: 「固定窓読み」→「ファイル先頭の一定行数しか読まないこと」。
• 例: 「補助検出器」→「grepによる補助チェック」。「会話出力」→「チャットの返答」。

4. 用語のゆれ（中）

同じ概念に複数の名前が使われているもの。対象ファイル間の横断チェックが必要。

• 例: 同じファイルを「検収報告」と「評価報告」で呼ぶ。同じ概念を「スケール前提」と「倍率前提」で呼ぶ。
• 統一先は、より多く使われている・用語定義がある・関連する識別子（YAMLキー名等）と整合する側に寄せる。

5. 英語直訳調（中）

英語の言い回しをそのまま日本語化した不自然な表現。

• 例: 「観測可能な」（observable）→「後から確認できる」。
• 例: 「プランに焼き込まれた」（baked in）→「プラン段階で確定してしまった」。
• 例: 「本人が直列実行する」（serial execution）→「本人が順に自分で実行する」。

6. 曖昧・誤読しやすい文（低）

• 指示語の指す先が曖昧（前の文の書き換えで「この仮定」の指す先が消えている等）。
• 別の意味に読める文。例: 「検証済みかも確認する」→「かもしれない」に読めるので「検証済みかどうかも確認する」。
• 同じ内容の重複記述、冗長な言い回し。

指摘しないもの

• プロジェクトで定義され、一貫して使われている専門用語（例: このリポジトリの「照合」「トークン」「Primitive」「正本」等）。定義済みで一貫していれば難しめの語でも許容する。
• コード・クラス名・識別子・コマンド、引用やNG例として意図的に書かれた文言。
• 完全に好みの範囲の言い換え。指摘する場合は「低優先・好みの範囲」と明示する。

報告書式

重要度順に番号を振り、各項目に以下を含める。

• 現状の文言（引用）と file:line
• 何が問題か（どう誤読・誤解されるか）
• 修正案（具体的な文で示す）

最後に「高優先だけ直すか、全部直すか」など修正範囲の選択肢を添えてユーザーに確認する。

修正時のルール

• 意味を変えない最小限の書き換えにする。文章の構成・トーン・敬体/常体は元のまま。
• 用語を統一した場合は、どちらに寄せたかと理由を完了報告に書く。
• 見出しを変更した場合は、他ファイルからの参照・アンカーリンクをgrepで確認して追従する。
• テーブルはパディング揃えにせず| --- | --- |形式を維持する。
• 対象ファイル固有の制約（例: skills/lism-css-guide/の各ファイル260行以下ルールなど、CLAUDE.mdに記載の制約）を修正後も満たしているか確認する。
• 修正後、指摘した語句をgrepして残存ゼロを確認する。コミットはユーザーの指示があるまでしない。