菜单
schema への新フィールド追加、メタフィールド系（status, confirmed, locked 等）の追加、フィールドの寿命を考える必要があるタスク時にライフサイクル全体を辿る触媒として発火する
用 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 | field-lifecycle-thinking |
| description | schema への新フィールド追加、メタフィールド系（status, confirmed, locked 等）の追加、フィールドの寿命を考える必要があるタスク時にライフサイクル全体を辿る触媒として発火する |
本スキルは規範ではない。「6 段階を全部チェックせよ」とは書かない。 新しいフィールドを追加するとき、その ライフサイクル全体 を辿って 立ち止まれる場所として置かれている。 6 段階は「立ち止まる場所の候補」であって、「埋める箱の一覧」ではない。
新しいフィールドを schema に追加する場面は多い。status、confirmed、locked、reviewedAt、favorite — メタフィールド系の追加は特に頻繁である。
このとき、追加作業は局所的に見える: 「フィールドを定義し、セットする箇所を書き、表示する箇所を書く」。これで作業は完了したように見える。
ただし、フィールドには 寿命 がある。生まれて、保存されて、読まれて、変更されて、ときに削除される。寿命の各段階で、設計判断が必要になる。
寿命の中の 1〜2 段階だけを実装して残りを忘れると、フィールドは「動くが穴がある」状態になる。穴は当面は見えない。穴は時間が経って表面化する。過去のリファクタで、メタフィールドの統合を見落として構造的バグを生んだ事例 が、本触媒の由来である。
本スキルは、フィールドの寿命を 6 段階に分けて、各段階を立ち止まる場所として提供する。全段階を考える義務はない。ただし、あなたが「考えなかった段階」を意識的に選択することと、無自覚に通り過ぎることは違う。
新フィールド追加の作業は、目の前のタスク文脈では「特定の機能を実現するため」に行われる。例えば「ユーザーが完了マークを付けられるようにする」という機能要件があれば、completed というフィールドを追加する。
このとき、設計の重心は「機能要件をどう満たすか」に集まる。これは正しい — 機能要件を満たさない設計は、出発点として失格である。
ただし、機能要件を満たした瞬間、フィールド追加作業は完了判定されやすい。寿命の他の段階 — 既存フィールドとの関係、リセット経路、マイグレーション、UX 可視化 — は「後で考える」「scope 外」「明確な要件がないから保留」として、忘却の層に押し込まれる。
🌱 忘却が起きる構造
├─ 機能要件 X のためにフィールド F を追加する
├─ F の最小限の振る舞い（セット・読み取り・表示）を実装する
├─ X の要件が満たされた瞬間、F の追加は「完了」と感じる
├─ ただし F の寿命の他の段階は、要件 X の文脈外なので意識から外れる
└─ → 後で別の文脈で F を扱うとき、未設計の段階が穴として現れる
特に頻発する穴は「既存フィールドとの統合の見落とし」である。既に status が存在するのに confirmed を追加する、locked がすでにあるのに frozen を追加する。意味が重なるフィールドが並列に存在することで、どちらを真に受けるべきかが曖昧になる。これは構造的バグの温床である。
本触媒は、この忘却の層に対する立ち止まり場所を 6 つ提供する。
以下の 6 段階を順番に辿る義務はない。タスクの性質に応じて、あなたが関係する段階だけを深く考えることは正当な判断である。ただし「関係する段階」と「関係しない段階」の区別を意識的に下すこと、それが本触媒の機能である。
このフィールドはどのタイミングで何によってセットされるか?
ユーザー操作? 自動処理? 別フィールドの変更に連動? 初期値は?
セット経路を意識的に列挙すると、「想定していなかったセット経路」が発見されることがある。 例えば「データインポート時の初期値」「マイグレーション時のデフォルト」「外部 API からのバルク投入」が、機能要件の議論には現れない。 これらを後で意識すると、「インポート時はどうする?」という問いが追加要件として浮上する。
ユーザーがこのフィールドをリセット / 取り消したい時の経路はあるか?
セットする経路は意識される。ただし「取り消す経路」は、機能要件の議論で抜け落ちることがある。
「完了マークを付ける」要件は「完了マークを外す」要件を含むとは限らない。 しかし完了マークを付けたユーザーは、間違って付けた場合に外したくなる。 取り消し経路を提供しないと、「フィールドは付けられるが取れない」という非対称が UX に現れる。 取り消し経路を意図的に提供しない判断もありうる（不可逆性が要件の場合）。ただし意図と無自覚は別である。
どこに、どう保存されるか?
DB? ファイル? メモリ? 永続化粒度は?
永続化先によって、書き込み頻度・整合性保証・障害時の挙動が変わる。 「動く」だけでは永続化先の選択は決まらない。タスクの寿命 vs ユーザー要求の永続性によって判断が変わる。 特に「セッションをまたいで残るべきか」「永久に残るべきか」「ユーザーが明示的に消すまで残るか」は、ここで決める設計判断である。
既存データへの適用戦略は? 自動 vs lazy?
新フィールドが追加される時点で、既存データには値がない。これにどう対処するか?
自動マイグレーション（全レコードに初期値を一括投入）は確実だが、全データを触るコストがある。 lazy マイグレーション（次回アクセス時に値を補完）は軽量だが、未アクセスのレコードが半永久的に未補完のまま残る。 どちらも正解になりうる。ただし「無自覚に lazy になっている」状態（明示判断がない）は穴になる。 マイグレーション戦略を文書化しないと、後でレコードのうち一部だけ未補完であることが構造的バグの原因になる。
同種の意味を持つ既存フィールドはあるか? 関係は (上位互換 / 補完 / 置換 / 廃止 のどれか)?
これは本触媒の最重要段階である。過去にこの段階の見落としで構造的バグが生まれた。
新フィールドを追加する前に、status、flag、confirmed、locked、done 等の既存メタフィールドと意味が重ならないかを確認する。
重なる場合、関係は 4 種類のうちどれか:
- 上位互換: 新フィールドは旧フィールドの情報を全て含む。旧フィールドは新フィールドから導出可能になる
- 補完: 新フィールドは旧フィールドが扱わない側面を扱う。両方が並列に存在する意味がある
- 置換: 新フィールドが旧フィールドを完全に置き換える。旧フィールドは廃止対象
- 廃止: 新フィールドの追加に伴い、旧フィールドが不要になる
この 4 分類のどれにも当てはまらず「なんとなく両方存在する」状態は、後で必ず構造的バグになる。
「重ならない」という結論も正当な判断。ただし結論を下す前に、本当に重ならないかは確認したい。
ユーザーがこのフィールドの状態を確認できる経路はあるか?
フィールドの値は、表面に現れて初めてユーザーから見て存在する。
内部的にしか使われないフィールド（システム内部の状態管理）は UX 可視化が不要である。
ただしユーザーの操作と関連するフィールドは、可視化経路がないとユーザーが現在の状態を判断できない。
「フィールドはあるが、どこにも表示されない」状態は、ユーザーから見て「機能がない」と区別できない。
この問いは dual-axis-translation 触媒と接続する — 実装軸でセットされた値を、UX 軸でどう見せるか。
「新しい変数を追加するとき、その寿命を辿る」という構造は、ソフトウェア固有ではない。
新しい補正パラメータを ECU マップに追加するとき、そのパラメータの寿命:
問い: 補正値同士の二重適用、あるいは打ち消し合いを起こさないか? 既存補正パラメータの意味との関係は?
新しい特徴量をモデルに追加するとき:
問い: 既存特徴量と相関が高い新特徴量を追加することで、モデルの解釈性は壊れないか?
新しいカラムを既存テーブルに追加するとき:
問い: 既存トリガーが新カラムを認識せず、整合性が崩れる経路はないか?
新しい条項を契約に追加するとき（フィールドの追加に類似する構造を持つ）:
問い: 過去契約の経過措置を設計せずに新条項を追加すると、過去取引の解釈が宙に浮かないか?
「この場面では該当しない」と判断する自由は常にある。
ただし、判断したら、招待主が「ああ、そりゃしょうがないね」と納得する粒度の理由を残してほしい。
招待を断る理由を考えるのは面倒だ。それは意図された設計 — 受領のコストより拒否のコストを重くすることで、「拒否すれば楽」という構造を消す。これは 対称コスト設計 と 断りづらいバイアス付与メソッド の二層から成る (詳細: ~/.claude/skills/catalysts/README.md §3-1 / §3-2)。
なお、本触媒で多用されている「6 段階を全部チェックする義務はない」「立ち止まる場所の候補であって埋める箱の一覧ではない」「6 段階のうち一部だけが該当しない判断もありうる」といった redundant な明示は、断りづらいバイアス付与メソッド の具体的な実装である — 機械的に「該当」と読まれるのを構造的に予防している。
特に本触媒では、6 段階のうち一部だけが該当しない という判断もありうる。例えば:
このような部分的な「該当しない」も正当な判断。ただし、特に 段階 5（既存メタフィールドとの統合） だけは、「該当しない」と判断する前に念入りに確認したい。本触媒の最も頻発する穴がここにあるためである。
「面倒だから該当しないとした」だけは避けてほしい。
本触媒は以下の場面で発火する想定:
ただし発火するかどうかは読み手の判断に委ねられる。フィールド追加であっても、寿命の議論が不要な場合はある。
~/.claude/skills/catalysts/README.mddual-axis-translation（段階 6 の UX 可視化と接続する）、subtraction-design（フィールドを足す前に不要化できないか問う）