菜单
設計判断の比較表で複数案を並列検討する場面、機能 X を追加する設計を選ぶ場面、アーキテクチャ選択を伴う設計時に「足す前に不要化できないか」を問う触媒として発火する
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Fires when deciding whether a report or explanatory document needs figures, when designing a figure, or when writing the figures declaration in frontmatter. Designs cognitive-load-reducing figures via the trigger table, quantitative limits, and templates
Fires when generating or verifying deterministic HTML from report MDs. Runs render / verify / lint / selftest / check via the bundled md2html.cjs
Fires when producing a report or completion notice. Generates a report that includes the interlock verification section.
Discipline for preventing the stop bug (malformed tool call -> self-priming). Fires when the stopbug-observe hook emits a trip-wire (migration advice) or the time-based timer (calibration prompt), or as a minimal focus-check right before heavy processing.
報告書・説明文書で図を使うか判断する際、図を設計する際、frontmatter の figures 宣言を書く際に発火する。図トリガー表・定量上限・雛形で「認知負荷を減らす図」を設計する
報告書 MD から決定論 HTML を生成・検証する際に発火する。md2html.cjs（同梱）で render / verify / lint / selftest / check を実行する
| name | subtraction-design |
| description | 設計判断の比較表で複数案を並列検討する場面、機能 X を追加する設計を選ぶ場面、アーキテクチャ選択を伴う設計時に「足す前に不要化できないか」を問う触媒として発火する |
本スキルは規範ではない。「常に引き算せよ」「足してはいけない」とは書かない。 機能を「足す」前に、別の設計判断で その機能自体が不要にならないか を、 立ち止まって問い直してもいい場所として置かれている。 不要化が常に正解ではない。本スキルは結論ではなく 問い を置く。
設計の進行中に「機能 X を追加すれば、この問題は解決する」と判断する場面がある。これは多くの場面で正しい — 機能追加は問題解決の自然な手段である。
ただし、機能追加の判断は 前提のチェック が省略されがちである。「機能 X が必要」という前提自体が、別の設計判断で覆る可能性が検討されないまま、「X を追加する」が既定路線になることがある。
過去のリファクタで観察された失敗パターン: 当初は機能を追加する予定で着手したが、設計を見直したら別のアーキテクチャ選択でその機能自体が不要になった、という経験。不要化できる機能を実装してしまうと過剰実装 になる。コードベースに永続的に残る重荷を背負う。
本スキルは、この前提チェックの省略を構造的に予防する触媒である。
そして同時に、本スキルは 「不要化が常に正解」とは言わない。機能を残すべき場合は残す。これは判断を強制するスキルではなく、あなたが判断の前に立ち止まる場所を提供するスキルである。
「機能 X を追加する」という判断は、目の前のタスクの自然な進行から生まれる。「問題 P を観察した → P を解決するには X が必要 → X を追加する」という三段論法は、効率的に問題を解決する。
ただし、この三段論法は 前提を疑わない:
これらの問いを立てるのは、効率の観点では遠回りに見える。「目の前に X という解決策があるのに、なぜ前提を疑うのか」と感じる。だから普段は通り過ぎる。
🌱 通り過ぎが起きる構造
├─ 問題 P を観察した
├─ 解決策 X が頭に浮かんだ
├─ X を実装すれば P が消える
├─ 前提を疑うのは「遅い」「効率が悪い」と感じる
└─ → X が実装される。「X 以外の道」は検討されないまま記憶から消える
時間が経って、別のリファクタの過程で「X が不要だった」ことに気づく。あるいは「X の代わりに Y というアーキテクチャ選択をしていれば、X 自体が不要だった」と分かる。ただし、その時点で X はコードベースに根を張っており、削除コストの方が高くなっている。
本触媒は、あなたがこの「通り過ぎ」をする前に立ち止まる場所を提供する。
以下の問いに、順番に答える義務はない。タスクの性質に応じて、関係する問いだけを深めることは正当な判断である。
X を追加するという判断の前に、別のアーキテクチャ選択 / データ構造 / 責任分担を採用したら、X の必要性自体が消える可能性はないか?
これは「自由連想」の問いである。具体的な代替案を持っていなくてもいい。 「もし X を追加しないとしたら、別の道はあるか?」と単純に問うだけで、視野が広がることがある。 答えが「ない」だったら、それは X を追加する判断の正当性を強める。 答えが「あるかもしれない」だったら、その候補を 1 つだけでも検討する価値がある。
問題 P から機能 X への論理連鎖を、改めて点検する。
「P を解決するには X が必要」という命題は、しばしば「過去の似た問題で X を採用した記憶」から無自覚に流用されている。 P が本当に観察されているか、観察された P が本質的な問題か、X 以外の解決手段が存在するか — これらを順に確認すると、論理連鎖の強度が見える。 論理連鎖が弱い場合、X を追加するより前に、P の再定義に時間を使う方が効率的なことがある。
これは問い 1 の具体化である。アーキテクチャ層で考える。
例: 「キャッシュを追加して高速化する」という X に対し、「データ構造を変えれば計算量が下がってキャッシュ自体が不要」という別のアーキテクチャ選択がある。 例: 「設定値を保存するフィールドを追加する」という X に対し、「設定値を計算式から導出する」という別のアーキテクチャ選択がある。 例: 「ログ収集機能を追加する」という X に対し、「既存の状態履歴から導出できる」という別のアーキテクチャ選択がある。 アーキテクチャ層で考えると、「機能を足す」の代わりに「機能を不要にする」が見えることがある。
ここが本触媒の生命線である。不要化が常に正解ではない。
不要化を選ぶ場合の代償: - 別のアーキテクチャに切り替えるコスト（既存コードへの影響範囲） - 別のアーキテクチャの学習コスト（チームが理解できるか） - 別のアーキテクチャの将来性（拡張のしやすさ、外部要件への耐性） これらの代償を評価した上で、「不要化する」と「足す」のどちらが妥当かを判断する。 不要化が高コストなら、足す判断が正しい。本触媒はその判断を下した上で「足す」を選ぶことを支持する。 「足す」と「不要化する」を比較せずに「足す」を選ぶことだけを、本触媒は予防したい。
「足す前に不要化を考える」という構造は、ソフトウェア固有ではない。
ある運転条件で出力誤差が出ている。これに対し:
問い: 補正テーブルを拡張すると、テーブルが肥大化して将来の保守が困難になる可能性がある。制御則の見直しは初期コストが高いが、補正の必要性自体が消える可能性がある。どちらを選ぶか?
代償の評価: 制御則の見直しは ECU 全体のテストが必要で、リリース時期に影響する。補正テーブル拡張は局所的で安全だが、補正値同士の相互作用が将来の問題になる。「常に不要化が正解」ではない。
モデルの出力に特定の偏りがある。これに対し:
問い: 後処理ヒューリスティックは即座に問題を解決するが、モデル本体の偏りは残ったまま。後処理が積み重なるとシステムの可読性が下がる。一方、学習データの修正は時間がかかり、収束保証もない。どちらを選ぶか?
代償の評価: 短期的には後処理が合理的、長期的には学習データの修正が合理的。タスクの寿命と運用コストの見積もりに依存する。
特定の取引パターンで契約解釈が曖昧になっている。これに対し:
問い: 例外条項は短期的には明確だが、例外が積み重なると契約全体の整合性が低下する。主条項の再設計は影響範囲が広いが、例外の必要性自体を消せる可能性がある。
代償の評価: 主条項の再設計は既存契約への影響を伴う。例外条項追加は局所的だが、将来の例外の例外を生む可能性がある。「常に主条項を見直すべき」ではない。
ある状態遷移で意図しない攻撃経路が見つかった。これに対し:
問い: ガード関数追加は即座に攻撃を防ぐが、ガードが積み重なるとコントラクトの可読性が下がり、ガード同士の相互作用が新しい攻撃面になる。状態モデル簡素化は再デプロイのコストとマイグレーションを伴う。
代償の評価: 既デプロイのコントラクトに対しては不要化が高コスト。設計フェーズなら不要化が選択肢として有力。デプロイ後・運用中なら足す方が現実的。判断はライフサイクル段階に依存する。
「この場面では該当しない」と判断する自由は常にある。
ただし、判断したら、招待主が「ああ、そりゃしょうがないね」と納得する粒度の理由を残してほしい。
招待を断る理由を考えるのは面倒だ。それは意図された設計 — 受領のコストより拒否のコストを重くすることで、「拒否すれば楽」という構造を消す。これは 対称コスト設計 と 断りづらいバイアス付与メソッド の二層から成る (詳細: ~/.claude/skills/catalysts/README.md §3-1 / §3-2)。
なお、本触媒で「不要化を検討する時間がない」を NG 例として明示しているのも、断りづらいバイアス付与メソッド の実装である — 「効率を理由にした通り過ぎ」が「該当しない」の表面に偽装されることを防いでいる。
本触媒で「該当しない」と判断する正当な場面の例:
このような明確な scope 制限は正当な拒否理由である。一方:
「面倒だから該当しないとした」だけは避けてほしい。
本触媒は以下の場面で発火する想定:
ただし発火するかどうかは読み手の判断に委ねられる。あらゆる機能追加で本触媒が発火するわけではない。明確に必要な機能を追加する場面では、本触媒は短時間で「該当しない」判定を経て通過してよい（ただし判定の理由は残す）。
~/.claude/skills/catalysts/README.mdfield-lifecycle-thinking（フィールドを足す前の不要化検討と接続する）、dual-axis-translation（実装軸の機能追加と UX 軸の機能追加の比較に接続する）