doc-consistency

ドキュメント横断の整合性レビュー（重複・矛盾の検出）を実行してください。ファイルパスは空白区切りで複数渡せます。渡した各ファイルをそれぞれ起点として扱います。 通常開発の Issue の実装フローに入れないのは、Issue ごとに docs/ 全体を横断すると、週次チェックと同じファイルを毎回二重に見ることになるためです。文書の分割・統合・規定の移動そのものが作業の Issue だけは、重複・矛盾が生まれていないことの確認が完了確認になるので、実装フローに入れてかまいません。 ## レビュー結果の起票 レビュー結果を出力したら、続けて `gh issue create` で GitHub Issue を起票してください。**ユーザーへの確認は行いません**（CLAUDE.md の boy-scout ルール）。指摘が1件も無ければ起票しません。 | 起票対象 | 粒度 | タイトル | なぜ | | ------------------ | ------------------- | ------------------------------------- | ---------------------------------------------------------------------------------------- | | 矛盾（優先度: 高） | 1件ごとに1 Issue | `[矛盾] <事柄>: <文書A> と <文書B>` | どちらを正とするかを1件ずつ決めて直す。束ねると片方だけ直った状態が残る | | 重複（優先度: 中） | 全件まとめて1 Issue | `[重複] ドキュメント横断の重複まとめ` | SSOT をどこに置くかの判断は並べて見た方がぶれない。件数分に割ると矛盾の Issue が埋もれる | タイトルの先頭ラベルは省略しないでください——本文を開かないと指摘の重さが分からない状態を避けるためです。タイトルの先頭には段番号を付けてください（例：`1. [矛盾] …`）。振り方は Issueの階層ガイド（`docs/reference/issue-hierarchy.md`）の「段番号（着手順）」に従います。 本文の書き方・ラベル・起票前セルフチェックは `.claude/skills/quick-issue/SKILL.md` が正典です。Read して従ってください。重複確認（`gh issue list --state all` で既存 Issue を検索する）もこのセルフチェックに従います。 Issue 本文の「現状」には、レビュー結果の**出典（ファイルパスと行番号）・食い違いの中身・推奨**を書き写してください（レビュー結果を読み返さずに着手できるように）。 ### `[重複]` のまとめ Issue は指摘ごとに確認する `/quick-issue` の重複確認は Issue 単位の検索なので、まとめ Issue の中に並ぶ指摘1件ずつの重なりまでは見えません。まとめ Issue を組み立てる前に、**指摘ごとに** `gh issue list --state all --search "<事柄>"` を実行し、open または `NOT_PLANNED`（却下済み）の既存 Issue に同じ指摘が載っていたら、その指摘はまとめから外してください。 ### 完了済みと同じ指摘は再発として起票する `[矛盾]`・`[重複]` とも、`state reason: COMPLETED` で閉じられた Issue に載っていたのと同じ指摘（**同じ2文書・同じ事柄**で判定する）が再び見つかったら、重複扱いで捨てずに再発として新しい Issue を起票してください。直ったはずのものが再び壊れているのは、既存の指摘を積み増すのとは別の新しい問題だからです（この「同じ指摘」の判定基準は #583 の結論が出たらそちらに合わせます）。 引数: $ARGUMENTS