mcpField
F
factory-clean

factory-clean

github.com/tikalk開発143138 回インストール今日更新
リポジトリ

factory-clean について

factory-cleanは、並行実行後の後片付けを行うプロジェクト管理者向けに、ソフトウェアファクトリーのリソースを調査・回収するスキルです。稼働中の作業や未保存の変更を保護し、安全性を確認できた古いリソースだけを削除候補にします。

主な機能

  1. 01ワークツリー、クローン、ビルド成果物の調査
  2. 02稼働状態に基づくリソース分類
  3. 03未コミット・未プッシュ作業の保護
  4. 04古いロック、リース、成果物の整理
  5. 05削除直前の再確認と個別実行

活用シーン

  1. 01並行実行後にディスク容量を回収
  2. 02安全に削除できるワークツリーの特定
  3. 03期限切れのロックやリースの整理
  4. 04未保存作業を失わないことの確認

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/tikalk/adlc-team-skills --skill factory-clean

インストール後、Claude Code で/factory-cleanを入力して読み込まれたか確認します。

詳細

factory-clean

このスキルの機能

factory-clean は、ソフトウェアファクトリーのリソース回収エンジンです。次の2つの問いに答え、2つ目の問いに基づいて処理を実行します。このプロジェクトは今、このマシンにどれだけの負荷をかけているか、そして作業を破棄したり、まだ実行中のエージェントを中断したりせずに、何を回収できるかです。

このスキルは、実行レジストリを読み取り、アクティブなワークツリーを特定して、破棄済みまたは古くなったアーティファクトをクリーンアップする Kind-B のコントロールプレーンスキルとして動作します。


使用するタイミング

  • 複数の並列実行の後、安全に削除できるワークツリーを確認し、ディスク領域を回収するとき。
  • 放置された、または古くなったロックやリースをクリーンアップするとき。
  • 未コミットまたは未プッシュの作業が誤って失われないことを確認するとき。

使用しない場合:

  • 通常のコード開発や PR レビューには使用しません(factory-mission または factory-review を使用してください)。
  • 未プッシュの git コミットや未コミットのファイルを強制削除する場合には使用しません(このスキルは安全でない作業を削除することはありません)。

操作手順

1. プロジェクトの取り込み

対象プロジェクトを特定します(デフォルトは現在のリポジトリです)。その状態ルート、実行レジストリ、ワークツリールート(.adlc/worktrees/)を特定します。

2. 実行中の作業の分類

削除候補を表示する前に、ローカルの状態ファイルとコメントバスを読み取ります(トラッカーと統合されている場合は、コメントバスとリースマーカーを使用します)。各リソースを、次の5つの稼働状態のいずれかに分類します。

  • in use — リースが有効な実行(heartbeat_ts + ttl_seconds > now)が所有しているか、アクティブなプロセスがそのパスを開いています。**保護対象です。**削除候補として提示しないでください。
  • holds work — 未コミットの変更やリモートにないコミットがあるワークツリー、またはレジストリエントリに retained のマークが付いています。**保護対象です。**保持している内容を正確に表示してください。削除しないでください。
  • stale — 登録済みで、リースの TTL が期限切れであり、未保存のものがなく、かつ実行中のプロセスがそのパスを保持しておらず、作業ディレクトリにもしていません。削除候補です。
  • orphan — レジストリエントリはありませんが、正規の包含関係と決定的なプロジェクト、スキル、実行の所有権ラベルによって、このスキルファミリーが作成したことが証明されています。削除候補です。
  • unknown — 所有権または稼働状態を特定できません。**保護対象です。**ユーザーには表示しますが、削除候補として提示しないでください。

注:稼働状態の分類は、このスキルファミリー独自のレジストリから読み取ります。レポートには、他のローカルプロセスや IDE のチェックアウトは認識できず、unknown として保護されることを明記してください。

3. インベントリの範囲

次の項目をスキャンし、サイズや数を測定します。

  1. スキルのワークツリーとクローン:.adlc/worktrees/ 配下のワークツリー、.adlc/clones/ 配下の管理対象クローン。
  2. Git アーティファクト:古くなったワークツリー登録、ルーズオブジェクトとパックのサイズ。(ローカルユーザーブランチとグローバル Git キャッシュは対象外とし、保護します)。
  3. プロジェクトの依存関係とビルド出力:依存関係ディレクトリ(node_modules、.venv)、ビルドおよび配布用出力、カバレッジおよびテストアーティファクト。
  4. スキルの状態、スクラッチ、ログ:実行ごとの一時ディレクトリ、スナップショット、ログファイル。(保存済みの ID マッピング、プロジェクト規約、スキーマ、設定は常に保護されます)。
  5. プロセスとポート:このプロジェクトのポートまたはファイルを保持している開発サーバー、ポートフォワード、バックグラウンドワーカー。
4. レポートと承認
  1. インベントリをグループごとにまとめ、各グループ内では回収可能なサイズ順に並べ、グループごとの合計と全体の合計を示します。何がどの理由で保護されているかを明確に記載します。
  2. 各グループ内の候補について、ユーザーに正確な識別子を選択してもらいます。デフォルトでは何も選択しません。
  3. 実行するコマンドを正確に提示します。
  4. 削除の直前に、稼働状態を再確認します。インベントリ作成後に実行が開始された場合や未保存の作業が追加された場合は、その項目をスキップして競合を報告します。
  5. 1つずつ削除し、最初のエラーが発生した時点で停止します。前提が崩れたまま処理を続けないでください。
  6. 回収したもの、スキップしたもの、実際に回収した容量(推定ではなく再測定した値)を報告します。

コメント