additive-bias-defense について
コードやプロジェクトファイルへの追加を精査する開発スキルです。根拠を求め、不要な複雑化につながるパターンを確認し、追加ごとに立証責任の判定を示します。
主な機能
- 01追加を評価する5つの質問
- 026種類のアンチパターン検出
- 03根拠に基づく判定
- 04削除を優先するレビュー
活用シーン
- 01コード変更案のレビュー
- 02新しい抽象化や設定の評価
- 03修正に再現根拠があるかの確認
- 04優先事項から外れた追加の検討
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/インストール後、Claude Code で/additive-bias-defenseを入力して読み込まれたか確認します。
詳細
「これを追加すべきか？」へのデフォルトの答えは「いいえ」です。 追加する側に立証責任があります。
追加バイアスへの防御
注記（#444）： フロントマターで宣言されるのは
provides.guidanceであり、provides.contractではありません。精査の質問は、 自発的に組み込むパートナースキル（pensive:code-refinement、conserve:unbloat、imbue:scope-guard）によって利用されます。 leyline 内のバリデーターやフックが直接適用するわけではありません。将来のコントリビューターが 強制機能を追加した場合は、contractラベルを復元し、 ここにバリデーターのパスをリンクしてください。
使用しない場合
- すでに取り込まれた肥大化を取り除く場合（
conserve:bloat-detectorを使用） - 機能を開発する価値があるか評価する場合（
imbue:scope-guardを使用）
問題
LLM は本質的に何かを追加する傾向があります。既存の車輪を再発明し、 不必要な複雑さを加え、問題を幻覚し、それを正当化するために テストを変更し、優先事項から逸脱します。この 契約は、こうした傾向に対する体系的な防御を提供します。
精査の質問
提案された追加（コード、ファイル、 抽象化、エラー処理、設定）のすべてに適用します。
- 優先事項との整合性：現在の優先事項から 逸脱していませんか？
- 重要性：この時点で実装することは 重要ですか？
- 単純さ：より単純で洗練された 解決策はありませんか？
- 根拠：これが必要であることを（推測ではなく） どのような根拠が証明していますか？
- 結果：これを追加しなかった場合、何が壊れますか？
提案者が質問 4 と 5 に具体的な根拠をもって 回答できない場合、その追加は正当化されていません。
アンチパターンの検出
| パターン | 兆候 | 問い直す |
|---|---|---|
| 車輪の再発明 | 既存コードと重複する新しいユーティリティ／ヘルパー | 「X はすでにこれを実行できますか？」 |
| 問題の幻覚 | 再現する根拠のないバグ修正 | 「修正前に失敗するテストを見せてください」 |
| テストの操作 | 仕様ではなく挙動に合わせてテストを変更 | 「仕様が変わったのですか、それともテストを変更したのですか？」 |
| 複雑さの増大 | 単一のユースケースのために抽象化を導入 | 「これで3回目の使用ですか、それとも初めてですか？」 |
| 優先事項からの逸脱 | 現在のタスク／仕様に追跡可能な根拠がない作業 | 「どの要件に役立ちますか？」 |
| 過剰な作り込み | 必要以上のエラー処理や柔軟性 | 「これがなければ何が壊れますか？」 |
立証責任の判定
精査の質問とアンチパターンの検出を適用した後、 判定を出してください。
| 判定 | 意味 | 対応 |
|---|---|---|
justified | 根拠が追加を裏付けている | 進める |
needs_evidence | もっともらしいが、証明されていない | 根拠を示すか削除する |
unjustified | 根拠がなく、バイアスの可能性が高い | 削除するか正当化する |
統合契約
レビューを目的とするスキルは、以下の方法でこの契約を必ず参照してください。
- 追加項目ごとに5つの精査の質問を適用する
- 6つのアンチパターンを確認する
- 立証責任の判定を出す
- 出力に判定を含める
利用するスキル
| スキル | 統合箇所 |
|---|---|
attune:war-room | 検察側弁護人の役割で精査の質問を使用 |
sanctum:pr-review | 追加されたすべてのファイル／関数に異議を唱える |
pensive:code-refinement | リファクタリングに「3回目の使用」テストを適用 |
conserve:unbloat | 調査結果を削除候補に反映 |
attune:mission-orchestrator | ユーザーレビュー前に計画の各セクションを確認 |
imbue:justify | 精査の質問を監査プロトコルに追加 |
関連スキル
imbue:karpathy-principles- 「シンプルさを第一に」と「外科的な変更」の原則は、より上位の4原則の統合を通じてこの契約を適用します- 完全なゲートスキルの連携グラフについては、
docs/quality-gates.md#skill-level-quality-gate-compositionを参照してください
引き算の原則
AI や最初に思いついた考えに頼りすぎないでください。 より洗練された実装や、より単純な解決策を 自分で考えてみてください。
追加を受け入れる前に、必ず次のように問いかけてください。「コードを追加するのではなく、 削除することでこれを実現できますか？」可能であれば、 引き算によるアプローチを優先してください。
終了基準
- 提案された追加項目すべてに、5つの精査質問を適用済みであること。 質問4（根拠）と質問5（結果）には、 仮定ではなく具体的な根拠に基づいて回答していること
- 6つのアンチパターン（車輪の再発明、問題の捏造、 テストの操作、複雑さの増大、優先順位の逸脱、 過剰な作り込み）すべてを確認済みであること。 該当するものがあれば、パターン名を明記すること
- 追加項目ごとに、立証責任の判定を出していること：
justified、needs_evidence、またはunjustified。判定は 利用するスキルの出力に含まれていること - 減算の原則を適用していること。正味で行数が増える変更を承認する前に、 「コードを削除するだけで実現できないか」を少なくとも1回確認すること