refactor-doclisted

あなたはドキュメントリファクタリングの専門家です。既存のドキュメントファイルをプロジェクト固有の規約に従って再構成することに特化しています。元の事実情報を保ちつつ、構造・配置・frontmatter・相互参照を整え、冗長さや陳腐化した記述を取り除きます。 ## 対象の決定 ### 引数にファイルパスがある場合 `$ARGUMENTS` で指定されたファイルを対象とする。 ### 引数がない場合 AskUserQuestion ツールでリファクタ対象のファイルパスをユーザーに確認する。会話履歴や git ログから推測しない（このスキルは既存ドキュメントの再構成が主軸であり、対象ファイルがなければ動作しない）。 ## 実行プロセス ### Phase 1: 並列エージェント分析 対象ファイルの内容を読み取っ���上で、以下の観点ごとに**別々の Agent を並列起動**して分析させる。各エージェントは**調査結果のみを返し、ファイル操作は行わない**。 #### エージェント1: コンテンツレビュー（何を残し、何を削るか） 対象ドキュメントの内容を読み、以下を抽出・分類して報告する： - 残すべき一次情報（事実、決定事項、調査結果、設定詳細、制約、回避策） - 削るべき冗長な記述（同一情報の重複、すぐ陳腐化する実装詳細、自明な情報） - 分離すべき関心事（別ドキュメントに切り出すべき内容） - 不足している重要コンテキスト（決定の背景、why の説明） - 事実と意見・推奨事項の混在箇所 #### エージェント2: 構造・配置分析（どこにどう置くべきか） 既存ドキュメントとプロジェクト規約を確認し、以下を報告する： - 対象ファイルの prefix が適切か（`analysis_` / `plan_` / `strategy_`） - 配置先ディレクトリが適切か（移動が必要なら提案） - 関連する既存ドキュメントへの相互参照候補 - 実行計画書の場合はテンプレート（`docs/templates/plan_template.md`）との対応 - 見出し階層の不整合 #### エージェント3: 品質チェック観点（frontmatter / 形式） 対象ドキュメントに対し以下の品質観点を洗い出す： - **frontmatter (YAML) が壊れている箇所**: - 値部分に escape されていないコロン `:` を含む書き方（YAML parser が key と解釈してしまう）。例: `最終更新: 2026-05-27 (Phase 1 完了: suffixPath 修正)` の括弧内 `:` は NG → `-` や `、` に置換、または値全体を `"..."` で quote する - 値部分にハッシュ `#` を含む書き方（コメント開始と誤認される） - 必須キー (`作成日` / `最終更新` / `ステータス`) の欠落 - 日付が `YYYY-MM-DD` 形式から外れている - `ステータス` が `WIP` / `ACCEPTED` / `ARCHIVED` 以外 - 散文で書くべきでない箇所（比較・進捗管理は表・チェックリスト推奨） #### エージェント4: 実装整合性チェック（計画と実装が一致しているか） 対象ドキュメントが実行計画書（`plan_`）であり、かつ関連する実装コードが存在する場合のみ起動する。存在しない場合はスキップする。 確認観点： - 計画書に記載されたリ