doc-consistency

ドキュメント横断の整合性レビュー（重複・矛盾の検出）を実行してください。ファイルパスは空白区切りで複数渡せます。渡した各ファイルをそれぞれ起点として扱います。

通常開発の Issue の実装フローに入れないのは、Issue ごとに docs/ 全体を横断すると、週次チェックと同じファイルを毎回二重に見ることになるためです。文書の分割・統合・規定の移動そのものが作業の Issue だけは、重複・矛盾が生まれていないことの確認が完了確認になるので、実装フローに入れてかまいません。

レビュー結果の起票

レビュー結果を出力したら、続けて gh issue create で GitHub Issue を起票してください。ユーザーへの確認は行いません（CLAUDE.md の boy-scout ルール）。指摘が1件も無ければ起票しません。

タイトルの先頭ラベルは省略しないでください——本文を開かないと指摘の重さが分からない状態を避けるためです。タイトルの先頭には段番号を付けてください（例：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