tidy-project

リポジトリのプロジェクト構造（ファイルとディレクトリの配置・構成・命名、設定、依存関係、ビルドの健全性）を監査し、統合した一括実行計画を作成してください。ユーザーとのやり取りなしで最後まで実行してください。フェーズ間で停止せず、確認を求めず、中間報告も行わないでください。成果物は計画ファイルです。状態ファイルは再開用であり、人が確認するためのものではありません。ホストの todo ツールで4つのフェーズを再現してください。

絶対条件（最初に読むこと）

• ソースは読み取り専用です。 状態ファイルと最終計画ファイル以外は作成しないでください。
• 機能を維持できる変更案のみです。 提案する変更はすべて、機能を維持する必要があります。
• インフラを維持してください。 フェーズ1で特定した言語、フレームワーク、ホスティング、データベース、ランタイム環境は、監査全体を通じて変更しないでください。
• 依存関係を入れ替えないでください。 ただし、その依存関係が明らかに未使用である場合、または標準ライブラリのコード約10行で代替できる場合を除きます。
• 書き換えは禁止です。 許可されるのは、統合、削除、階層の平坦化、名前変更、およびリテラル値から環境変数参照への抽出のみです。
• Git の履歴は使わないでください。 証拠として使用できるのは、追跡対象ファイル一覧（git ls-files）、マニフェスト、ファイルツリーのみです。コミット日時や変更履歴は使わないでください。唯一の根拠が「Nか月間変更されていない」である指摘は除外してください。
• 反証可能性の基準。 各指摘を、パス、追跡対象ファイルのエントリー、または Grep か git ls-files で確認できる文字列を引用する反証可能（FALSIFIABLE）か、構造上の判断である意見（OPINION）に分類してください。反証可能な引用は、草案に含める前に、改めて Grep または git ls-files を実行して検証してください。一致がなければ、引用は捏造されたものです。指摘を除外してください。
• フレームワークで必須の構造は対象外です。 フェーズ1で特定したフレームワークに必要なファイルやディレクトリ（src/pages/、app/、settings.py、.github/workflows/、Dockerfile、package.json、tsconfig.json、Makefile など）を、指摘の対象にしないでください。

対象範囲の境界

すべての tp-* カテゴリー（tp-01〜tp-11。references/categories-quick-ref.md で定義）は、ファイルツリー、git ls-files、マニフェスト、および対象を絞った検索で判断できます。このスキルの対象外は次のとおりです。

• コードの意味論 — デッドコード、ファイルをまたぐロジックの重複、時期尚早な抽象化、結合、インポート循環。コードの意味を読んではいけません。
• 単一ファイル内の懸念事項 — 識別子の命名、関数の長さ、マジックナンバー、ファイル内の重複。証拠が単一ファイル内に完全に収まる指摘は対象外です。
• テストの内部実装 — テストファイルは構造レベル（存在、配置、構成、残存する不要な枠組み）のみ監査します。テスト関数内のロジックは対象外です。

除外パス

次のパスは走査しないでください。ドットディレクトリ（.git/、.venv/、.next/、.cache/、.turbo/、.agents/、.claude/、.vscode/、.idea/、.github/ など）、node_modules/、vendor/、dist/、build/、__pycache__/、target/、coverage/、生成コード、バイナリーアセット。

補足： 走査をスキップしても、証拠の確認までスキップするわけではありません。tp-02/tp-03 では、追跡対象の dist/ やベンダーライブラリがコミット済みであることを、git ls-files で確認して指摘する場合があります。この確認は低コストであり、対象範囲内です。ロックファイルの内容は読みませんが、各マニフェストの隣にロックファイルがあるかどうかは、tp-02 の判断材料になります。

状態ファイル

.agents/local/state/tidy-project-YYYY-MM-DD.md（存在しない場合はディレクトリを作成）。今日の日付のファイルがすでに存在し、完了している場合は、-2、-3 のように末尾に番号を付けてください。開始時に .agents/local/state/tidy-project-*.md を glob で検索してください。最新のファイルに未完了項目がある場合は、そのファイルを使って再開してください。そうでなければ、新しいファイルを作成してください。新規実行するには、このファイルを削除してください。形式 — フェーズごとにまとめた Markdown チェックリスト。エリアごとに1項目とし、その下に指摘の草案を追記してください。

# Tidy Project — 2026-07-17
- [ ] Phase 1 — inventory
- [ ] src/
- [ ] docs (drift)
- [ ] Phase 3 — adversarial review
- [ ] Phase 4 — plan written

状態ファイルを書き込むのは、あなたのみです。ワーカーは返信で指摘を返しますが、状態ファイルには一切触れません。

フェーズ 1 — インベントリ作成（機械的に実施、サブエージェントなし）

この作業はインベントリをインラインで作成してください。サブエージェントには依頼しないでください。

1. スタック。 マニフェスト（package.json、pyproject.toml、requirements.txt、go.mod、Cargo.toml、composer.json、Gemfile）を Glob で検索し、フレームワークを把握するために読み込みます。フレームワーク上必須で変更禁止のパス、エントリーポイント、設定可能な範囲を記録します。
2. ツリーと領域。 git ls-files と2階層のツリー走査を行います。トップレベルの領域をソースファイル数とともに列挙し、用途が不明なフォルダーがあれば記録します。
3. 衛生チェックの grep — これらのチェックは本質的に grep 形式です。今すぐ実行し、該当箇所を候補として対応する領域のワーカーに渡します。git ls-files '*.env' | grep -v example（追跡対象の env ファイル）、各マニフェストと同じ場所にあるロックファイル、git ls-files dist build out と git ls-files '*.min.*'（コミット済みのビルド成果物）、git ls-files '*.log'（ログ成果物）、find . -name .git -mindepth 2 -not -path './.git/*'（ネストされたコードベース）。

インベントリの要約と領域チェックリストを状態ファイルに書き込み、ただちにフェーズ 2 に進んでください。停止したり、要約したりしないでください。

フェーズ 2 — 領域分析（並列）

references/adversarial-review-prompts.md の領域アナリスト用プロンプトを使ってワーカーを起動します。トップレベルの領域ごとに1人、さらに README、docs/、エージェント指示ファイルを含む docs 領域を担当するドキュメントワーカーを1人起動します。このワーカーは references/docs-code-drift.md も読み込み、ドリフトに関する指摘を同じ1行形式で返します。ソースファイルが10個未満の領域は、1人のワーカーにまとめます。同時に実行するワーカーは最大5人とし、各ウェーブの Agent 呼び出しはすべて1つのメッセージにまとめます。領域が5つを超える場合は、5人ずつウェーブを実行し、上限に合わせるために領域を飛ばしてはいけません。

ワーカーはホストの低コストモデルのエイリアス（model: haiku 形式。バージョン固定は不可）で実行します。各ワーカーにファイル一覧とインベントリの要約（スタック、変更禁止パス、エントリーポイント、関連する衛生チェックのヒット）を渡します。ワーカーはユーザーのプロジェクトルートで実行されるため、依頼文に含まれるすべての references/… パスを、ディスパッチ前にこのスキルのディレクトリ下にある絶対パスに展開します。ワーカーは references/solo-dev-lens.md、references/categories-quick-ref.md、references/severity-and-difficulty.md に加えて、tp-10 の候補については references/hardcoded-environment.md、tp-11 の候補については references/convention-drift.md を読み込みます。また、独自に Grep／git ls-files を実行して反証可能性のゲートを適用し、指摘を1行で返します。

横断的シンセサイザー — トップレベルの領域が4つ以上の場合に限り実行し、それ未満では省略します。すべての領域ワーカーからの返答後、同じリファレンスと専用プロンプトを使ってシンセサイザーを1人起動し、指摘を統合したものとリポジトリへの読み取りアクセスを渡します。領域をまたぐ重複、複数領域に散在する一貫性、提案の矛盾、用語の揺れを洗い出します。指摘は最大10件です。

各ワーカーの返答を受け取るたびに、その指摘を状態ファイルのドラフトに追記し、チェックボックスにチェックを入れます。

指摘の形式

指摘は1件につき1行です。OPINION の指摘では証拠フィールドを省略し、それ以外はすべて必須です。フェーズ 4 の計算式では sev、diff、risk、blast を使用します。

- [tp-10] Hardcoded environment — src/config/db.ts:4 — sev:high diff:easy risk:MEDIUM blast:1 — grep:`postgres://[^ ]*@db\.internal` — committed connection string, not deploy-portable → replace with process.env.DATABASE_URL and add a .env.example entry

sev は low|medium|high、diff は easy|medium|hard、risk は LOW|MEDIUM|HIGH、blast は影響を受けるファイル数（最小1）です。証拠は grep: または git-ls-files: とし、再実行可能な正確なパターンを指定します。まとめて反映する必要がある指摘には、証拠フィールドの前に共通の group:tag トークンを付けます。パスに :line を付けるのは、行固有の指摘に限ります。

フェーズ 3 — 敵対的レビュー（1ラウンド）

デフォルトのモデルと references/adversarial-review-prompts.md のプロンプトを使って、指摘レビュー担当者を1人起動します。指摘のドラフト全体とリポジトリへの読み取りアクセスを渡します。レビュー担当者は、引用されたすべての grep と git ls-files を自ら再実行し、捏造された引用を削除し、誤った残存コードの指摘、誤ったハードコード環境の指摘、リスクのある名前変更に異議を唱え、セキュリティ関連パスの重大度の下限を適用し、見落とされた指摘を洗い出します。また、各指摘について KEEP／REVISE／DROP の判定を返します。判定をドラフトに反映します。深さは1です。2ラウンド目は実施しないでください。

フェーズ 4 — ランク付けして計画を作成する（サブエージェントなし）

references/ranking-formula.md を読み込み、残っているすべての指摘にスコアを付け、group タグ付きの指摘はグループ化ルールに従って統合し、並べ替えます。ランク付けされた指摘をアトミックなバッチに編成します。各バッチは、バッチ間でリポジトリが動作する状態を保てる最小の集合であり、それぞれ単独でコミット可能で、依存関係の順序に従い、バッチごとに具体的な実行可能な Verification: コマンドを含めます。環境変数、CLI フラグ、DB スキーマ、デプロイ済み URL、cron／webhook／キューハンドラー、または認証に触れるバッチには boundary_crossing: true を付けます。次に references/final-plan-format.md を読み込み、計画を作成します。

• リポジトリのルートに docs/ が存在する場合 → docs/YYYY-MM-DD-tidy-project-plan.md
• それ以外の場合 → リポジトリのルートに YYYY-MM-DD-tidy-project-plan.md

計画のパスのみを提示してください。 最後の返信には、統合された計画のパスだけを記載してください。状態ファイル、ワーカーの出力、中間ドラフトは決して記載しないでください。ユーザーから明示的に求められた場合に限り、状態ファイルの場所を開示してください。

避けるべき失敗

• フレームワークで必須の構造を過剰設計と見なして指摘する。
• 「何か月も変更されていない」を根拠として受け入れる。構造上の証拠のみを用い、git 履歴は用いないでください。
• 必須のチェックイン済みファイル（ロックファイル、フィクスチャ、ビルドが入力として消費する生成ファイル）を tp-03 のコミット済み成果物として扱う。
• スキップしたディレクトリをレビュー不能と見なす。その追跡対象としての存在は、git ls-files を通じて依然として証拠になります。
• ワーカーが1行の指摘ではなく文章形式の段落を返すままにする。その領域を、形式を改めて指定して再ディスパッチしてください。
• フェーズ間で確認を求めて一時停止したり、フェーズごとの要約を出力したりする。最後まで続けてください。

完了

すべてのチェックボックスにチェックを付け、計画を作成しました。計画のパスを報告してください。それ以外は何も記載しないでください。コミットせず、状態ファイルを削除せず、ビルドまたはテストコマンドを実行しないでください。