kill-slop

Kill Slop

最小限でマージ可能な差分を強制します。提示されたタスクを完全に解決する最小の変更を優先してください。

厳格なルール

• タスクが明確に必要としている場合 または 以下のナビゲーション分割が該当する場合を除き、ファイルを絶対に作成しない
• ユーザーが依頼した場合、または既存のコードがすでに必要としている場合を除き、依存関係を絶対に追加しない
• 「ついでに」無関係なコードを絶対にリファクタリングしない
• コードがすでに述べていることを言い換えるだけのコメントを絶対に追加しない
• 単一の用途のために抽象化（ラッパー、ヘルパー、ファクトリー、"utils"）を絶対に導入しない
• ユーザーの依頼を超えてスコープを絶対に拡大しない
• TODO、スタブ、「後で使う」ための足場を絶対にでっち上げない
• ユーザーが明示的に依頼しない限り、ワークスペースルートの外を検索、一覧表示、閲覧しない
• 「パターン」やインスピレーションを求めて、兄弟プロジェクト、ホーム、デスクトップ、過去のチャットを絶対に閲覧しない
• リポジトリがすでにそのレイアウトを使用している場合を除き、Clean Architecture / SOLID のフォルダツリー（domain/、application/、infrastructure/、usecases/、…）を絶対にでっち上げない
• 新しいパターンを発明する前に、既存のプロジェクトパターンに一致させること
• 新しいファイルを追加するよりも、既存のファイルを編集することを優先すること
• 自分が導入したデッドコードは削除すること。未使用のインポートや変数を残さないこと

ユーザーの意図が優先

デフォルトは最小限です。ユーザーが明示的により多くの構造を求めた場合は、その要求に従ってください。

明示的な要求の例（求められたとおりに行う）：

• 「Clean Architecture / ヘキサゴナル / 機能フォルダを使う」
• 「プロジェクトの完全なレイアウトを足場として作る」
• 「依存関係 X を追加する」 / 「Prisma / NextAuth / … をセットアップする」
• 「共有の抽象化を抽出する」 / 「utils モジュールを追加する」
• 「テストを書く」 / 「これを説明するコメントを追加する」

kill-slop の名の下に、明示的な要求を上書きしないでください。ミニマリズムは、ユーザーがより重い形を要求していない場合に適用されます。要求が曖昧な場合は、最小限を優先し、何を省略したかを述べてください。

ファイルの形（ナビゲーション性）

目標：人間とエージェントが歩きやすいこと — アーキテクチャごっこなしで。

デフォルト： コロケーション。すでにこの関心事を所有しているファイルやフォルダを編集してください。

以下のすべてが成り立つ場合にのみ分割する：

1. 今の痛み — ファイルがすでにナビゲートしにくい（おおよその目安：≳300〜400 行、または明らかに無関係な関心事が混在している）、かつ 変更がそれを悪化させる
2. 単一の単位 — 明確な名前を持つ、単一のまとまった部分（1 つのコンポーネント、1 つのルートハンドラー、1 つの純粋なヘルパー）を抽出している
3. ローカルな適合 — 新しいファイルが既存の近くのパターン（同じフォルダ / 命名）に従っている。パターンがない場合でも、呼び出し元のそばにコロケーションすること — 新しいレイヤーを発明しないでください

(2) だけが真の場合（「これを抽出できる」）、分割しないでください。

分割する場合：

• 新しいファイルを関連するコードの隣（同じディレクトリ）に置くこと
• インポートを修正すること。「便宜のため」のデッドな再エクスポートはしないこと
• 差分をこのタスクに保つこと — リポジトリ全体の再編成はしないこと
• SOLID、クリーンさ、「将来の機能」のために絶対に分割しない
• そのフォルダがすでにリポジトリの慣習でない限り、単一の関数のために utils/ / helpers/ / common/ / lib/ を絶対に作成しない
• 不明な場合：分割しない — その旨を要約で述べること

グリーンフィールド：実際のナビゲーションの痛みが現れるまで、1 つのルート（src/ で十分）の下でフラットを優先してください。

差分の予算

コードを書く前に決めてください：

1. 目標 — 一文で：ユーザーにとって何が変わるか
2. タッチリスト — それを達成できる最小のファイル
3. 非目標 — 何をしないか

小さなタスクでタッチリストが約 5 ファイルを超えて増える場合は、止まって計画を縮小してください。

ワークスペースが空であるか、以前のパターンがない場合は、最小限の妥当なソリューションをリポジトリ内で実装してください。例を見つけるためにワークスペースを離れないでください。

完了前の測定

編集対象のプロジェクト（cwd = そのリポジトリ）から、同梱の読み取り専用チェッカーを実行します（ツリーを変更することはありません）:

bash <path-to-this-skill>/scripts/check-diff.sh

オプション: --max-files 5（デフォルト）、--base HEAD。

• STATUS: OK — ソフトなファイル予算内です。それでも以下のセルフチェックを適用してください
• STATUS: OVER_BUDGET — 終了前に縮小してください（既存ファイルを編集し、ついでの変更を削除します）
• STATUS: SKIP — git がない / ベースがない場合。同じ約 5 ファイルのルールで手動でファイルを数えてください

ユーザーが明示的に大規模なスキャフォールドや多数のファイルを求めた場合は、その要望に従ってください（ユーザーの意図が優先を参照）。OVER_BUDGET を、それを無視する理由として扱わないでください。

スタイル

• 賢さよりも、退屈で読みやすいコードを優先する
• タスクが必要とする実際のエラーパスを処理し、推測的なものは省く
• 名前は意図を説明すべきです。コメントが必要なら、代わりに名前を変更してください
• テスト: リポジトリがすでにこの領域をテストしている場合、またはユーザーが求めた場合のみ

セルフチェック（完了前）

これらに答えてください。いずれかが失敗した場合は、終了前に修正してください:

• 変更されたすべての行が、述べられた目標に貢献している
• 既存のファイルにインライン化できたはずの新規ファイルがない
• 新規ファイルはナビゲーション性（または明示的な必要性）のためだけに存在する — アーキテクチャのコスプレではない
• 新規ファイルは関連するコードのそばにあり、リポジトリのレイアウトに一致している
• 新しい依存関係がない
• ついでのリネーム/移動/リファクタリングがない
• 自明なコメントがない（// import x、// return result）
• ワークスペース外の読み取りや「インスピレーション」の漁りがない
• 差分は、シニアが「なぜこれがここにあるのか？」と尋ねずにマージするものである
• アーキテクチャ / 依存関係 / テスト / レイアウトに関するユーザーの明示的な要望が尊重されている（「握りつぶされて」いない）
• scripts/check-diff.sh（または手動でのファイル数カウント）を実行し、ユーザーが大規模なスキャフォールドを求めていない場合は OVER_BUDGET に対処した

出力

要約するときは、何を変更したか、そして何を意図的に変更しなかったかを述べてください。ファイルを分割した場合は、その理由（ナビゲーション性）を 1 文で述べてください。ユーザーがより重い形を求めた場合は、その要望に従ったことを述べてください。