Menu
検証完了後、コミット前の整理に使用。不要ファイル・デバッグコード・TODO残骸を除去し、ドキュメントを実装に合わせて更新する。
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Basé sur la classification professionnelle SOC
| 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 エージェントに委譲。