deslop

Deslop

ブランチで変更されたコードから AI 生成の不要なコードを取り除き、動作は変えないようにします。すべてのコミットの前、および /deslop、「deslop it」、「clean the diff」、「strip the slop」と指示されたときに使用します。コードのみを対象にします。文章は unslop スキルが担当し、コメントのレビューは no-comments スキルが担当します。

対象範囲

呼び出し元から指定されたファイルまたは差分を使用します。指定がない場合は、作業ツリーと未追跡ファイル（git status --short）も含め、このブランチの基点となるブランチとの差分を対象にします。プルリクエストが開かれている場合はそのベース（origin の fetch URL から取得した <host>/<owner>/<repo> を使った gh pr view <branch> -R <host>/<owner>/<repo> --json baseRefName）、そうでない場合は分岐元のブランチ（git branch -vv または git reflog show <branch>）、それもなければ main を対象にします。積み重ねたブランチでは、main を基点にすると親ブランチのコミットも差分に含まれてしまいます。ブランチで追加または変更されたハンク内だけを編集してください。判断に必要な情報として、呼び出し元、型、既存のヘルパー、ファイルの残りの部分を確認してください。それ以外の場所で気づいた不要なコードはレポートに記載し、手を加えないでください。

各コミットの前に

テストのみ、失敗するテスト、修正ラウンド、WIP のコミットを含め、すべてのコミットまたは amend の前に、このチェックを完了してください。

1. コミットを行うエージェントで、このスキルを読み込みます。各パスの前に、すべてのルールと Report セクションを含む SKILL.md 全文を読んでください。ファイル全体をカバーする単独の読み取り、または範囲を区切った複数回の読み取りで構いません。返却内容が途中で切れている場合は、続きの内容を取得してから先に進んでください。カタログ項目、読み取りコマンドの成功、部分的な読み取り、または別のエージェントによる要約だけでは、全文を読んだことになりません。
2. 対象となるコミット、その親、対象パスを正確に特定します。ステージ済みの内容と新規ファイルを含む、すべてのハンクを確認してください。amend の場合は、既存コミットのハンクとステージ済みの変更の両方を含めます。その対象範囲に以下の Process を適用してください。ブランチ末尾での確認だけでは、それ以前のコミットを確認したことになりません。コメントを追加していなくても、コードが他のルールの対象外になるわけではありません。
3. コミット前に証拠を記録してください。全文を読み取った際のツール参照、親コミット、レビュー対象を特定するステージ済みツリー ID または保存済みパッチを記録します。削除内容はルール ID とファイル名で示してください。変更がない場合は、該当するルールによって削除が不要である理由を、具体的なパスと関連する呼び出し元、型、または境界条件を挙げて説明します。文章のみの対象範囲であれば、確認したパスを記載したうえで no code として構いません。スキルを読み込んだことや「問題なし」と述べるだけでは不十分です。
4. クリーンアップ後に実行した検証コマンドと、その実際の結果を記録してください。取り消した安全でない削除と未解決の問題も含めます。意図的に失敗するテストを含むコミットでは、想定される失敗を維持し、クリーンアップ後もそれが維持されていることを示してください。フックや後続の編集によってコミット対象が変わった場合は、変更された内容をレビューし、再試行の前に証拠を更新してください。コンパクション後は、スキル全文を再読み込みし、コミット前に対象範囲をあらためて確定してください。
5. パスと証拠の記録が完了してからコミットしてください。成功後、コミットの親とツリーをレビュー済みスナップショットと照合し、コミット SHA を記録します。一致しない場合は、コミット前チェック漏れを報告して承認を保留します。変更内容をレビューし、許可された修正を新たなパスで行ってください。不一致の記録は履歴に残します。後からのレビューで、以前のコミット前パスを証明することはできません。各コミットにつき証拠参照を 1 件、親に返してください。必要な読み取り、レビュー、検証のいずれかが未完了の場合は、コミットを保留し、不足事項を報告してください。

プロセス

1. 差分をハンクごとに読み、各ハンクが担うタスクを明確にします。どのタスクも担わないハンクはルール17に該当します。
2. 以下のルールを順に適用します。編集は最小限にします。書き換える前に削除します。
3. 新たな構造（型、ヘルパー、状態モデルなど）が必要になる箇所で止め、リファクタリングのプレイブックに引き継ぎます。Deslop は、不要なコードを取り除くために抽象化を追加しません。
4. 実際の成果物で動作が変わっていないことを確認します。差分が触れるテストと型チェックを実行します。テストを通すために変更する必要があるなら、動作が変わっています。その箇所は元に戻します。
5. 残りを隣接する担当者に引き継ぎます。ルール1〜3で判断できないコメントは、報告する前にコメントレビューが必要です。そのコメントには no-comments スキルを使います。レビューでコードを変更した場合は、手順4を再度実行します。その後、名前、メッセージ、残すコメントに unslop スキルを使います。
6. 以下の形式で報告します。

ルール

ルール番号は、他のスキルが参照する固定の ID です。ルールが削除されても、番号は欠番のまま残します。各ルールでは対象、該当する兆候、修正方法を示します。

コメント

1. 内容を語るコメント。 コメントが直下の行を言い換えている場合や、フェーズ名（// increment count、// Phase 1: add cards など）を示している場合は削除します。
2. コメントアウトされたコードと削除マーカー。 コメント記号で囲まれたコードや、// removed という注記は削除します。
3. 残すもの。 ライセンスヘッダー。形を変更できない外部依存関係、プラットフォーム、ベンダー、プロトコルに起因する、見落としやすい動作に関するコメント。prettier-ignore。公開 API の契約を定義するドキュメントコメント。コードでは表現できない制約を説明する Issue または RFC へのリンク。残すコメントも文章であるため、手順5で unslop スキルに引き継ぎます。

ガード

4. あり得ない状態へのガード。 型や境界処理によって null にならない値への null チェック、すでに型が絞り込まれている型への instanceof、タプルの長さチェック、すべての呼び出し元が渡す引数へのデフォルト値は削除します。型を信頼してください。
5. 信頼できる経路での防御的なラップ。 ハンドラーが想定する形では失敗しない内部呼び出しを囲む try/catch やフォールバック、またはエラーを握りつぶすハンドラーは削除します。ラップを取り除くか、エラーをそのまま送出します。不明瞭な不変条件を隠すサイレントフォールバックはルール4に該当し、レポートにはその不変条件を記載します。
6. 検証の重複。 境界ですでに解析済みのデータを再解析または再検証するチェックは、内側の重複分を削除します。

システム境界（ユーザー入力、ネットワーク、ファイル、環境、外部 API）にあるガードは残します。テストで必要とされるガードも残し、そのテストを根拠とします。

不要な経路

7. 互換性シム。 新しい経路と併存する古い経路、呼び出し元がないのに「呼び出し元のために」残されたエイリアスや再エクスポート、このブランチで置き換えたコードに対する非推奨通知は削除します。呼び出し元のないシムは削除します。すべての呼び出し元がブランチのハンク内にある場合は、同じ変更で移行してシムを削除します。ハンクの外に呼び出し元があるシムは残し、報告に記載します。その呼び出し元の移行はスコープ外の編集になるためです。
8. 未使用のパラメーター、エクスポート、フラグ。 何も渡されないパラメーター、何もインポートされないエクスポート、値が1つしかないオプション、到達可能な分岐が1つしかないフラグ、一時的と明記された分岐は削除します。
9. デバッグの残骸。 タグの有無を問わず、デバッグ用ログや出力、使い捨てのプロトタイプ、バリエーション切り替え用コードは削除します。

パッケージの公開インターフェースに含まれるシンボル（エントリーポイントのエクスポート、文書化された API）は、リポジトリ内に呼び出し元がなくても残します。呼び出し元がリポジトリの外にあるためです。タスクで公開 API から削除する場合に限り、そのシンボルを削除します。それ以外の場合は「変更しなかった項目」に記載します。

型

10. 型チェッカーを黙らせるもの。 型チェッカーを通すことだけが目的の any または unknown へのキャスト、as アサーション、抑制コメントは、型を修正するかキャストを削除します。

形状

11. 呼び出し元が1つのラッパー。 引数をそのまま渡すだけで、呼び出し元が1つの関数、ヘルパー、またはアダプター。インライン化してください。
12. 時期尚早な汎用化。 タスク内で実装が1つしかなく、2つ目の用途もない抽象化、パラメーター、フック、または拡張ポイント。実際に必要になるまでインライン化してください。
13. ヘルパーの再実装。 コードベース内の既存のヘルパーと同じ処理をするコード。既存のヘルパーを呼び出してください。
14. 早期リターンでネストをフラット化。 関数の残りすべてを本体とするガード節。早期にリターンして、インデントを浅くしてください。
15. バリエーションのあるコピー＆ペースト。 差分内に、小さな違いだけで同じ形のコードが2つあるケース。コードベースですでに共通の形として名前が付いている場合に限り、抽出してください。それ以外は、似た行が3つあってもそのままにします。
16. 差分だけでは修正できない構造。 無関係なフローに付け足された条件分岐、単発のブール値または nullable モード、同じ形に対する条件分岐の繰り返し。Refactoring プレイブックの principle-model-the-domain に引き継いでください。ここでは修正しないでください。

スコープ

17. 無関係な編集。 タスクで触れる必要のなかったコードにおける、フォーマットの変更、名前変更、インポートの並べ替え、構文の現代化。git で復元できるハンク、つまりブランチにコミットされたものと、このセッションで自分が書いたものを元に戻してください。自分が書いていない未コミットのハンクはそのまま残し、コミットで保持されていない作業を壊すことになるため、そのことをレポートに記載してください。コミット済みのハンクは git diff <base>...HEAD、未コミットのハンクは git diff HEAD で確認できます。ハンク単位で元に戻し、ファイル全体を復元してはいけません。同じファイルにある未コミットのハンクを残すためです。コミット済みのハンクを元に戻すには、該当行を手作業で戻すか、git diff <base>...HEAD -- <file> からそのハンクだけを逆適用してください。その差分全体を逆適用すると、ファイルに対するタスクの作業も元に戻ります。また、git diff <base> -- <file> には、そのファイルの未コミットのハンクも含まれます。
18. クリーンアップ内の動作変更。 クリーンアップのラベルが付いた変更の中で、コードの動作を変えるハンク。分けて、レポートに記載してください。
19. ファイルのスタイルに合わない。 周囲のファイルで使われていないパターン。ファイルのスタイルに合わせてください。

レポート

1〜3文で述べた後、以下を記載してください。

• ルール ID ごとの件数と、変更したファイル。
• ルール17に基づいて元に戻したハンク、およびそのまま残した無関係な未コミットのハンク。
• Refactoring プレイブックに引き継いだ指摘（ステップ3、ルール16）。
• コメントのステップ5で no-comments スキルに引き継いだ内容と、それぞれに対して実施したこと。
• スコープ外の問題点の「変更せず」リスト。
• テストおよび型チェックのコマンドとその結果。

CREDITS.md には、このスキルが参考にした情報源と、引き継いだ文章が記載されています。