Menu
検証完了後、コミット前の整理に使用。不要ファイル・デバッグコード・TODO残骸を除去し、ドキュメントを実装に合わせて更新する。
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
| name | cleanup |
| description | 検証完了後、コミット前の整理に使用。不要ファイル・デバッグコード・TODO残骸を除去し、ドキュメントを実装に合わせて更新する。 |
コミットする前に、ワーキングツリーを整理する。 実装中に残った不要物を除去し、ドキュメントを実装の最終状態に合わせて更新する。
入力: REQ パス（例: requirements/REQ-001/）+ 検証完了済みの実装コード + テストコード + 検証報告書
出力: 整理済みのワーキングツリー + 更新済みドキュメント
原則: コミットは「完成品の記録」だ。作業の残骸を含めるな。
不要ファイルを残したままコミットするな
デバッグコード、一時ファイル、対応済み TODO、使われていない import ——これらは実装の副産物であり、成果物ではない。
常に:
例外（人間パートナーに確認すること）:
digraph cleanup {
rankdir=TB;
input [label="検証完了", shape=ellipse];
subgraph cluster_parallel {
label="並列実行";
style=dashed;
code_cleanup [label="コード整理\n(cleanup-agent)", shape=box, style=filled, fillcolor="#ccffcc"];
doc_update [label="ドキュメント更新\n(doc-maintainer)", shape=box, style=filled, fillcolor="#cce5ff"];
}
test [label="テスト実行\n全GREEN確認", shape=box, style=filled, fillcolor="#ffffcc"];
review [label="人間パートナーに\n変更一覧を提示", shape=box, style=filled, fillcolor="#e6ccff"];
done [label="整理完了", shape=ellipse];
input -> code_cleanup;
input -> doc_update;
code_cleanup -> test;
doc_update -> test;
test -> review;
review -> done;
}
lint/formatter では対応できない不要物をワーキングツリーから除去する。 未使用 import・変数、console.log、debugger 等は lint の責務。cleanup-agent は扱わない。
| 対象 | アクション |
|---|---|
| 一時ファイル | .tmp, .bak, .orig, テスト用の一時出力等を削除 |
| 対応済み TODO/FIXME | 削除（対応済みであることを検証報告書で確認） |
| コメントアウトされたコードブロック | 削除（Git に履歴がある。文脈を見て判断） |
| 空ディレクトリ | 削除 |
削除しないもの:
.gitkeep（空ディレクトリの保持用）.env.example 等）実装の最終状態に合わせてドキュメントを更新する。
| 対象 | アクション |
|---|---|
| README | 新機能の使い方・設定項目を追記 |
| API ドキュメント | エンドポイント・パラメータの変更を反映 |
| CHANGELOG | 変更内容を記録（プロジェクトにある場合） |
| 設定ファイルの例 | .env.example 等に新しい環境変数を追記 |
| requirements.md の status | status: verified → status: done に更新 |
更新しないもの:
整理後にテストスイート全体を実行し、整理が何も壊していないことを確認する。
整理内容を人間パートナーに提示する。
## 整理内容
### コード整理
- 削除: [ファイル名:行番号] console.log 3箇所
- 削除: [ファイル名] 未使用の import 2件
- 削除: [ファイル名:行番号] 対応済み TODO 1件
### ドキュメント更新
- 更新: README.md — 新機能の使い方を追記
- 更新: .env.example — 新しい環境変数を追記
### テスト結果
- 全 GREEN（N件）
| 言い訳 | 現実 |
|---|---|
| 「コメントアウトしたコードは参考になる」 | Git の履歴を見ろ。コメントアウトは読む人を混乱させる |
| 「TODO は後で対応する」 | 対応済みの TODO は嘘のコメント。未対応なら Issue にしろ |
| 「ドキュメントは後で書く」 | 後で書くドキュメントは永遠に書かれない |
| 「小さい変更だから整理不要」 | 小さい変更の積み重ねがゴミ屋敷を作る |
以下のどれかに当てはまったら、やり方を見直せ。
整理完了前に確認:
| 問題 | 解決策 |
|---|---|
| 削除していいか判断できない | 人間パートナーに聞く。迷ったら残す |
| 整理後にテストが RED になった | 整理が振る舞いを変えている。変更を元に戻して原因を特定 |
| ドキュメントの更新範囲がわからない | 変更した機能に関連するドキュメントだけ。無関係なドキュメントは触らない |
| TODO が対応済みか判断できない | 検証報告書の FR/AC 充足状況と突き合わせる |
あなたはこのスキルのプロセスを自分で実行しない。以下のエージェントにディスパッチする。
前提: 対応する REQ を特定する。 ディスパッチ前に、このタスクに対応する requirements/REQ-*/requirements.md を特定しろ。タスクのコンテキスト（plan、直前のステップの出力）に REQ パスが含まれていればそれを使う。見つからなければ requirements/ を確認し、候補を人間パートナーに AskUserQuestion で提示して選択してもらう。推測で REQ を決めるな。必ず人間に確認しろ。
メタループ駆動の場合の例外: requirements/ が存在しない環境（workspace/ec-sample 等）では、progress.txt のストーリー定義を requirements の代替として使用する。
cleanup-agent と doc-maintainer を並列ディスパッチする
cleanup-agent: プロンプトに REQ パス + 変更対象ファイル一覧 + 検証報告書を含めるdoc-maintainer: プロンプトに REQ パス + requirements.md 全文 + 変更対象ファイル一覧 + 検証報告書を含めるtest-runner エージェントをディスパッチしてテスト全体実行
あなたが結果を判断し、人間パートナーに変更一覧を提示する
前提スキル:
必須ルール:
次のステップ:
実装完了後のコードレビューに使用。仕様準拠・コード品質・セキュリティの3観点を並列レビューし、指摘を依存解決して修正する。
セッション完了後の振り返りに使用。ワークフロー遵守の検証、ユーザ指摘の収集と自己改善提案、改善後のリグレッション確認を行う。
ワークフローを開始する。ユースケースを選択し、適切なステップを順に実行する
設計確定後、実装前に使用。設計をタスクに分解し、実装順序と依存関係を明確にする。
大規模プロジェクト（複数機能・フェーズ分割が必要）で使用。全体をフェーズに分割し、マイルストーンとリスクを定義する。各フェーズは planning スキルに渡す。
機能開発・バグ修正の着手前に使用。メインセッションで人間パートナーと対話し、要件を構造化する。コード調査は Explore エージェントに委譲。