minimal-code-discipline

最小限のコード規律

コード変更の計画と記述に、最小限のコード（YAGNI ラダー）の規律を適用するには、このスキルを使用します。ユーザーの安全を守るためのチェックを犠牲にせず、差分を小さく、明らかに正しい状態に保ちます。

このスキルは ai-slop-cleaner を補完します。あちらは混入したスロップを後から整理しますが、こちらはそもそも書かれないようにします。

使用するタイミング

次の場合にこのスキルを使用します。

• ユーザーが最小限、簡潔、YAGNI、または可能な限り小さな差分での実装を求めている
• 計画中または進行中の変更が、依頼された範囲を超えて膨らんでいる
• スコープクリープ、ヘルパーの再発明、または先回りした汎用化が起きやすい新しいコードを書く
• 実装前に、提案された差分の規模を確認する

使用しないタイミング

次の場合はこのスキルを使用しないでください。

• ユーザーが幅広く、機能豊富で、将来にも対応できる構築を明示的に求めている（明示された範囲を優先します）
• ユーザーが使い捨てと明示した、探索的な足場作りのタスクである
• 最小化の圧力によって保護対象の動作に影響が及ぶ（「譲れない要件」を参照）

規律

まず必要性を問う。 変更そのものが本当に必要かを確認し、将来の不確かなニーズにしか役立たない作業は省きます。

書く前に再利用する。 新しいものを書く前に、既存のヘルパー、型、パターンをコードベース内で検索します。数ファイル先にあるヘルパーをコピーしてはいけません。再利用するか、共通の場所に切り出します。

依存関係の段階を踏む。 まず標準ライブラリ、次にプラットフォーム標準の機能、続いてすでにインストール済みの依存関係を検討します。手書きのコードは最後の手段です。ユーザーが明示的に依頼または承認していない限り、数行のコードで済む場合に新しい依存関係を導入してはいけません。

最小化する前に理解する。 まず影響を受けるコードを読み、実行経路をたどります。問題を理解してから、正しい範囲で最短の差分を実装します。書かなかったコードは、決して壊れることがありません。

巧妙さより堅実さを。 巧妙なコードより、平凡で正しさが明白なコードを優先します。

上限を明記する。 意図的な簡略化について、受け入れる制限と、置き換えが妥当となる条件を短いコメントで記録します。

症状ではなく根本原因を。 報告された症状ごとに別々の修正を行うのではなく、すべての呼び出し元に共通する根本原因を修正します。

譲れない要件

次の要件を最小化によって削ってはいけません。

• 信頼境界を越える箇所での検証
• データ損失を防ぐエラー処理
• セキュリティ制御
• アクセシビリティの基本要件
• ユーザーが明示的に依頼した範囲

検証

完了を報告する前に、次の点を確認します。

• 追加したすべての行に存在意義がある（先回りした汎用化や重複するヘルパーがない）
• 差分が、依頼された問題を正しく解決する最短のものである
• 譲れない要件が守られている
• テストが引き続き成功し、依頼された変更以外の動作に変化がない