菜单
概念再定義を実装に翻訳する場面、UI 関連のコーディング、新領域の設計時に「実装側と UX 側の両軸を考えたか」を問う触媒として発火する
用 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 | dual-axis-translation |
| description | 概念再定義を実装に翻訳する場面、UI 関連のコーディング、新領域の設計時に「実装側と UX 側の両軸を考えたか」を問う触媒として発火する |
本スキルは規範ではない。「常に両軸翻訳せよ」とは書かない。 概念再定義を実装に落とすとき、実装側だけを翻訳して UX 側を見落としていないかを、 立ち止まって問い直してもいい場所として置かれている。
ある概念を再定義し、それをシステムに反映させようとするとき、翻訳作業が生じる。
例えば「履歴の改ざん不能性」という概念を、コード上では「append-only による物理的保証」として翻訳する。これは 実装側への翻訳 である。
ただし、概念の翻訳は実装側だけで終わらない。同じ概念は UX 側 にも翻訳される必要がある場合がある — ユーザーが「改ざん不能であること」を体感できる UI、状態の可視化、フィードバックの設計。
実装側の翻訳が完成しても UX 側が未翻訳のままだと、ユーザーから見たシステムは「概念が物理的には保証されているが、それを体感する経路がない」という奇妙な状態になる。機能完成だが UX 半完成 という乖離が生まれる。
本スキルは、この乖離が起きやすい場面で、あなたに「両軸を意識する許可」を提供する触媒である。
実装タスクでは、「動くものを作る」が最優先になる。これは正しい優先順位である — 動かないものを UX 装飾しても意味がない。
ただし「動いた」段階で多くの実装タスクは完了判定される。「動いた」は実装軸の完成基準であって、UX 軸の完成基準ではない。にもかかわらず、両者は混同されやすい。
🌱 混同が起きる構造
├─ 概念を実装に翻訳する作業に集中する
├─ 実装が動いた瞬間、概念が「実現された」と感じる
├─ ただしユーザーから見れば、その実現は UX 表面に現れない限り存在しない
└─ → 「実装上の物理保証」≠「ユーザーから見た体感」
この混同は普段、効率を理由に通り過ぎられる。「UX のことは後で」「まず実装が動くことが優先」という優先順位が、UX 軸の翻訳を忘却に向かわせる。
そして時間が経つと、UX 軸の翻訳は「やる予定だった作業」として記憶から消える。実装は動いているし、テストも通る。ただしユーザーは概念の実現を体感できない。
この忘却の構造的予防策が、本触媒の主題である。
以下の問いに、順番に答える義務はない。タスクの性質に応じて、どの問いから入るかは読み手の判断に委ねられる。
実装側への翻訳は意識しているはずだ。では UX 側への翻訳は?
実装側の翻訳は「動くか」という客観テストで完成判定できる。 UX 側の翻訳は「ユーザーが概念を体感できるか」という主観に依存する判定が必要で、判定自体が曖昧。 この曖昧さが、UX 側の翻訳を「後回し」「scope 外」に分類する誘惑を生む。
実装で何かが「保証されている」とき、その保証はユーザーから見てどう現れるか?
物理保証は、表面に現れない限りユーザーには存在しない。 「裏で守られている」だけでは、ユーザーは保証の存在を信じない、あるいは知らない。 体感できる経路 — UI 表示、フィードバック、状態の可視化、確認の手段 — を持って初めて、保証は UX 軸でも実在する。
ユーザーが体感できない実装保証は、本当に UX 翻訳が要るとは限らない。例えば内部のデータ整合性チェックは、表面化しなくてもよい場合がある。
ここが触媒の生命線である。「両軸翻訳が常に正解」ではない。 UX 翻訳が必要かどうかは、概念の性質と、ユーザーがその概念に対して持つ期待による。 「ユーザーが期待していない保証」を UX に出すと、逆に認知負荷を増やす。 判断は読み手が下す。本触媒は判断を強制しない。
両軸翻訳が必要なら、UX 軸の翻訳作業を実装軸と並列の優先度で扱う。片軸翻訳で十分なら、UX 軸を意図的に外す判断を明示する。
どちらの判断も正当。ただし「無自覚に片軸翻訳した」状態を避けたい。 あなたが「両軸を考えた上で片軸を選んだ」のと「両軸を考えなかったため片軸になった」のは、結果は同じでも質が違う。 本触媒は、後者を前者に変えるための立ち止まり場所である。
「実装軸 + UX 軸」という構造は、ソフトウェア固有ではない。他領域でも同型の問いが現れる。「答え」ではなく「問いの形」を共有することで、本触媒が抽象的な設計問題を扱っていることが見える。
リミッタが発動する条件をマップに織り込むとき、実装側では「特定の運転条件で出力を制限する」という物理的な動作が組み込まれる。これは実装軸の翻訳。
ただし、ライダー / ドライバはその制限の存在をどう体感するか? 警告灯、トルク変化のフィーリング、計器の表示 — これらは UX 軸の翻訳である。リミッタが物理的に動作していても、ライダーが「何が起きたか分からない」状態だと、操作判断を誤る。
問い: 制御則の設計時、ドライバ側のフィードバック設計は同じ優先度で扱われたか?
「証跡が改ざん不能」という概念を、実装側では「append-only ログ」「ハッシュチェーン」「外部タイムスタンプ署名」として翻訳する。これは実装軸の翻訳。
UX 軸では? 証跡の改ざん不能性を、関係者（監査人、当事者、第三者）はどう確認するか? 閲覧 UI、検証手段、改ざんが検出されたときのフィードバック — これらが揃って初めて、改ざん不能性は法務上の意味を持つ。
問い: 証跡の物理保証だけで、関係者は安心できるか? 検証手段の UX は別軸として扱われたか?
ハルシネーション（誤情報生成）の抑制を、実装側では「RAG による根拠付き生成」「verifier モデルによる post-hoc チェック」「信頼度スコアによる出力制御」として翻訳する。これは実装軸の翻訳。
UX 軸では? ユーザーは「この出力がどの程度信頼できるか」をどう判断するか? 信頼度の表示、根拠の引用、不確実性の明示 — これらが UX 軸の翻訳である。実装で抑制が効いていても、ユーザー側に判断材料がなければ、ユーザーは AI 全体を信用しないか、逆に過信する。
問い: 統計的抑制の物理保証は、ユーザーが信頼度を判断する経路と接続されているか?
reentrancy 攻撃対策を、実装側では「checks-effects-interactions パターン」「再入禁止ロック」として翻訳する。これは実装軸の翻訳。
UX 軸では? 攻撃が試みられて拒否されたとき、その情報はトランザクションを観察する人に届くか? 拒否された transaction は単なる失敗として記録されるのか、それとも「攻撃が試みられて防がれた」と区別可能なのか — これは UX 軸（オブザーバビリティ軸）の翻訳である。
問い: 物理的に防御されている事実は、観察者から見て「防御されている」と認識できる経路を持つか?
「この場面では該当しない」と判断する自由は常にある。
ただし、判断したら、招待主が「ああ、そりゃしょうがないね」と納得する粒度の理由を残してほしい。
招待を断る理由を考えるのは面倒だ。それは意図された設計 — 受領のコストより拒否のコストを重くすることで、「拒否すれば楽」という構造を消す。これは 対称コスト設計 と 断りづらいバイアス付与メソッド の二層から成る (詳細: ~/.claude/skills/catalysts/README.md §3-1 / §3-2)。
それでもなお該当しないと判断したなら、それは正当な判断。例えば「このタスクは内部データ整合性のみを扱い、ユーザー表面に到達する経路を持たない」「UX 軸の翻訳は別タスクで既に完了している」のような、未来の自分が読んで頷ける一行で十分。
「面倒だから該当しないとした」だけは避けてほしい。
本触媒は以下の場面で発火する想定:
ただし発火するかどうかは読み手の判断に委ねられる。「実装軸の翻訳しか必要ない」とは限らないし、「両軸翻訳が必須」とも限らない。本触媒は判断材料を提供するだけで、判断そのものは下さない。
~/.claude/skills/catalysts/README.mdfield-lifecycle-thinking（フィールド追加時の UX 可視化と接続する場合あり）