obsidian-layout-adjustment について
obsidian-layout-adjustmentは、ユーザーのデザイン方針に沿ってCSSスニペットでObsidianの外観を調整するスキルです。画面要素を担当レイヤーに対応付け、編集前にチェックポイントを保存し、スクリーンショットで変更を確認します。
主な機能
- 01画面要素をObsidianのUIレイヤーに対応付け
- 02有効なCSSスニペットを確認して安全に編集
- 03見た目の変更前にチェックポイントを保存
- 04CSSを整形しスクリーンショットで検証
- 05フィードバックを基に編集または復元
活用シーン
- 01タブヘッダー、サイドドック、ノート面の調整
- 02アイコンのコントラストと画面の可読性向上
- 03スタイル変更が反映されない原因の調査
- 04外観を確認しながら確定済みスニペットを整理
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ ar9av/ obsidian-wiki --skill obsidian-layout-adjustmentインストール後、Claude Code で/obsidian-layout-adjustmentを入力して読み込まれたか確認します。
同梱ファイルevals/evals.jsonreferences/workflow-reference.md
詳細
Obsidian のレイアウト調整
このスキルは、ユーザーのビジュアルスタイルに合わせながら、CSS ファイルで Obsidian の見た目を変更するためのものです。
Obsidian の環境は常に同じ種類の要素で構成されています。アプリのフレーム、タブヘッダー、サイドドック、ビューのヘッダー、ペインの外枠、ノートの表示面、プロパティ、ファイルエクスプローラー、バックリンク、グラフ、レンダリングされた Markdown、ステータスバーです。ボルト、テーマ、スニペット、求めるテイストは変わっても、キャンバスは Obsidian のままです。
中核となる動作は、ユーザーの表現を対応付けることです。
ユーザーが Obsidian 上で見えるオブジェクトを指定したら、その表現を安定した Obsidian のレイヤー/バックエンドオブジェクトに対応付け、アクティブなスニペットを安全に編集し、結果をスクリーンショットで確認し、良好な状態を失わずに反復します。
これは一般的な CSS のワークフローでも、固定テーマを生成するものでもありません。
通常の出力モード
このスキルは、スタイリング作業を素早く進めるためのものであり、小さな依頼のたびに報告書を作るためのものではありません。
通常の使い方は次のとおりです。
- あいまいさを防ぐ必要があるときだけ、対応付けを伝えます。
- 対応付けは簡潔にします。通常は一文で十分です。
- その後、作業を進めます。アクティブなスニペットを確認し、チェックポイントを作成してから、修正、整形、再読み込み、スクリーンショットの撮影を行います。
- 変更したファイル、チェックポイント、スクリーンショットの状況を簡潔に報告します。
通常の適切な進捗報告の例:
「『ノートの上にあるタブ』は、矢印/ブック/ドットがあるビューのヘッダーではなく、ワークスペースのタブヘッダーとして扱います。アクティブなスニペットのチェックポイントを作成し、そのセレクター群だけを修正して、タブ部分のスクリーンショットを撮ります。」
次の場合を除き、長いワークフロー報告は書かないでください。
- ユーザーが計画、監査、レビュー、または説明を求めている場合。
- 評価を実行している場合、またはこのスキルを構築している場合。
- 見た目を変更せずにリファクタリングしている場合。
- 先に作業するとリスクが生じるほど、依頼があいまいな場合。
大切なのは、作業の速さを保ちながら、誤った CSS の修正を繰り返さないようにすることです。
リファレンスを使う
次の場合は references/workflow-reference.md を読んでください。
- ユーザーが Obsidian 上で見えるオブジェクトを自然言語で指定した場合。
- 対象が複数の Obsidian レイヤーに該当する可能性がある場合。
- スクリーンショットで「何も変わっていない」「まだ折り返されている」「持ち上がっていない」、端が不ぞろい、表面の色が薄い、アイコンが読めないなどの状態が見られる場合。
- 見た目を変えずにアクティブなスニペットをリファクタリングする場合。
- Obsidian のサーフェスマップ、変更種別マップ、または失敗パターンの一覧が必要な場合。
このリファレンスは Obsidian に特化しています。UI を未知のウェブページとして扱う前に使用してください。
作業ループ
- 稼働中のボルトから始めます。
<vault>/.obsidian/appearance.jsonを読みます。enabledCssSnippetsを、アクティブなスタイル設定の信頼できる情報源として扱います。- アーカイブ、バックアップ、古い試作より先に、アクティブなスニペットを読みます。
- ユーザーの表現を Obsidian のオブジェクトと、それを所有するレイヤーに対応付けます。
- 変更の種類を分類します。色、可読性、浮き上がり、形状、構造、密度、簡素化、ワークフロー、リファクタリングのいずれかです。
- 主観的な編集を行う前に、名前付きチェックポイントを保存します。アクティブなスニペットを
.obsidian/snippet-archive/にコピーしてください。スニペットピッカーを整理された状態に保つため、.obsidian/snippetsには保存しないでください。 - 現在の該当ブロックを再度読み込んでから、所有するレイヤーを一つだけ編集します。ステージ、外枠、ヘッダー、ラッパー、子要素のいずれかです。整形によってファイルの形が変わるため、記憶している状態を基にパッチを書くと、機械的に一致しません。
- CSS を整形します。
- Obsidian を再読み込みしてフォーカスし、影響を受ける領域を正確にスクリーンショットで撮影します。
- スクリーンショットとユーザーの修正指示を根拠として使います。
- 失敗した場合は、所有関係を確認するか元に戻します。同じ誤った対象に CSS を継ぎ足し続けないでください。
- 見た目の状態がユーザーに受け入れられてから、リファクタリングします。
編集前に対象を特定する
ユーザーは通常、セレクターではなく、目に見えるものを指して説明します。
- 「ノートの上のタブ」
- 「ノートの上の矢印/本/点」
- 「ノートの左側にあるボタン」
- 「右サイドバー」
- 「小さな領域にあるリンク」
- 「ノートの周りにあるもの」
- 「選択中のアイコン」
- 「左上の白い角」
編集する前に、その表現が何を指すのか確認してください。
user phrase -> visible object -> Obsidian layer -> likely selector/settings surface -> change type -> owning layer
曖昧な可能性がある場合は、対応関係をユーザーに伝えてください。
「ノートの上のタブという表現は、ノートペイン内の矢印/本/点の列ではなく、ワークスペースのタブヘッダーを指すものとして扱います。」
これは、間違いを防ぐための重要な手順です。最も不満の大きかった失敗の多くは、ユーザーの意図とは異なる、もっともらしい要素を変更したり、見た目を決めているのがラッパー/ヘッダー/ステージなのに、その子要素を変更したりしたことが原因でした。
安定したレイヤー構成
まずこの簡潔な対応表を使い、実際のボルトで正確なセレクターを確認してください。
| ユーザーが指しているもの | 通常、意味するもの |
|---|---|
| 左上の白い領域/ネイティブ領域 | タイトルバー/ネイティブのクローム、または隣接するアプリヘッダー |
| ノートの上のタブ | ワークスペースのタブヘッダー |
| タブの横のプラス | 新しいタブのコントロール |
| 緑色のバー/上部のバー | アプリのフレーム、またはタブヘッダーのコンテナー |
| 一番左のアイコン | リボン/サイドドック |
| 選択中のサイドアイコン | アクティブなサイドドックのタブヘッダーとアイコンの状態 |
| ファイル一覧の上のボタン | ファイルエクスプローラーのナビゲーションコントロール |
| ノート/フォルダーの左側のボタン | ファイルエクスプローラーのツリー行 |
| ボルト名/フッター | サイドドックのプロフィール/フッター |
| ノートの上の矢印/本/点 | Markdown ビューのヘッダー |
| ノート/ページ/紙 | Markdown のリーフ、エディター、または閲覧可能な領域 |
| ノートの影/浮き上がり/縁 | ステージ、シェル、ガター、オーバーフロー、または疑似要素の関係 |
| プロパティ | メタデータコンテナー、または Properties View のワークフロー |
| リンク | 閲覧モード/編集モードの内部リンクのスパン |
| 右サイドバー | 右側のワークスペース分割とユーティリティリーフ |
| リンクされた言及/バックリンク | バックリンクプラグインの結果グループ |
| グラフ | グラフプラグインのリーフ/キャンバス |
| 下部の統計情報 | ステータスバー |
Obsidian の作業では、見えているオブジェクトと、それを構成するバックエンドのレイヤーは安定したものとして扱ってください。正確なクラス名はテーマ/プラグイン/アプリのバージョンによって異なることがあるため、変更を適用する前に実際のボルトで確認してください。
変更の種類を分ける
同じオブジェクトでも、依頼内容によって必要な作業は異なります。
- 色/アクセント:背景、テキスト、境界線、アイコンの線/塗り、アクティブ/ホバー/フォーカス状態をまとめて更新します。
- 読みやすさ:特に色付きツールバー上のアイコンについて、レンダリング後のコントラストを確認します。
- 浮き上がり/奥行き:前景、ステージ、シェル、ガター、オーバーフロー、外側の影を決めます。浮き上がりは単なる
box-shadowではなく、要素間の関係です。 - 角丸:親シェル、子要素の角丸、オーバーフロー、隣接する背景を確認します。
- 構造:見た目を決めているラッパー/ヘッダー/シェルをスタイルします。
- 簡素化:装飾を追加する前に、ラッパー、境界線、グラデーション、影、疑似要素を取り除きます。
- プロパティ/ワークフロー:メタデータを CSS で圧縮する前に、Obsidian の Properties View や表示設定を検討します。
- リファクタリング:カスケード順序を保ち、スクリーンショットが変わらないことを確認します。
対象に2種類の変更が必要な場合は、2段階に分けて作業してください。たとえば、まずサイドドックのアイコンを読みやすくしてから、選択状態の色を調整します。
最初に変更するもの
まず、次の項目から始めます。
appearance.jsonのアクティブな CSS スニペット- 問題がワークスペースの動作に関する場合は、Obsidian の設定
- 変更を後から調整できる状態にしておく場合は、Style Settings またはテーマ変数
- 安定した Obsidian のラッパー:タブヘッダー、ビューのヘッダー、ペインのシェル、サイドドック、ファイル行、ノートの表示領域、バックリンクのグループ
まず次の項目を変更するのは避けます。
- Obsidian アプリのバンドルファイル
- コミュニティプラグインのソースファイル
- インストール済みテーマのソースファイル
- 見た目を強制的に変えるためだけの保管庫コンテンツ
- アクティブなスニペットとテーマ CSS を除外する前のアプリ内部や圧縮済みコード
次の操作を行う前に、明示的な確認を求めます。
- テーマの切り替え
- スニペットやプラグインの無効化
- ワークフローの変更としてのプロパティの非表示/移動
- 全体のタイポグラフィやエディターの密度を大幅に変更すること
- アーカイブ済みの試行版の削除
.obsidian/snippetsまたは Obsidian の設定以外のファイルの変更
スクリーンショットの必須確認
CSS が有効であることは、見た目が成功したことを意味しません。製品の実際の状態を示すのはスクリーンショットです。
見た目に影響する作業を行うたびに、次の手順を実行します。
- チェックポイントを保存します。
- パッチを適用します。
- CSS をフォーマットします。
- Obsidian を再読み込みするか、前面に表示します。
- 影響を受けた領域のスクリーンショットを撮ります。
- スクリーンショットを問題の内容と比較します。
別のウィンドウが Obsidian を覆っている場合は、スクリーンショットを撮り直します。確認手段自体が適切かも確認します。キャプチャを信頼する前に、Obsidian が実際に最前面にあることを確認してください(AppleScript で最前面のプロセスを確認できます)。問題がごく小さい場合は、端、アイコン、タブ、行、ペインの周辺だけを screencapture -R<x,y,w,h> out.png でキャプチャします。
スクリーンショットで修正が確認できなければ、作業を続けるか、元に戻すか、失敗したと伝えてください。フォーマットしただけで成功したかのように作業を終えてはいけません。
失敗の兆候
ユーザーからの修正指示は、セレクターを特定する手がかりです。
- 「何も変わっていない」は、セレクター、レイヤー、クリッピング、適用範囲、または上書きの指定が間違っていることを意味します。
- 「まだ折り返される」は通常、ラッパーと子要素の両方にスタイルが適用されていることを意味します。
- 「浮き上がっていない」は、ステージ/シェル/ガターの関係が間違っているか、変化が微妙すぎることを意味します。
- 「右側が明るくなった」は、ノートの上にオーバーレイまたは疑似要素があることを示します。
- 「アイコンが見えない」は、アクティブ/非アクティブのボタンの塗りとアイコンの色を併せて調整する必要があることを意味します。
- 「やりすぎ」は、多くの場合、別の処理を追加する前に、まず処理を取り除くべきことを意味します。
ある方向性を 2 回試してもうまくいかなかった場合は、最後に正常だったチェックポイントに戻し、スタイルの適用先を見直してください。
リファクタリングのルール
見た目を試行錯誤している最中は、リファクタリングを行わないでください。
ユーザーが見た目を気に入ったら、次の手順を実行します。
- ベースラインのチェックポイントを保存します。
- ファイルマップとセクション見出しを追加または更新します。
- 意図的に変更する場合を除き、セレクターの順序を維持します。
- CSS をフォーマットします。
- 意図しない見た目の変更がないか差分を確認します。
- Obsidian のスクリーンショットを撮ります。
- 使用していない試行版を
.obsidian/snippetsの外にアーカイブします。
CSS のサイズよりも、カスケードの混乱やアクティブなスニペット選択画面の散らかりの方が、通常は問題になります。
完了報告
作業が完了したら、締めくくりは簡潔にします。次の内容を報告してください。
- 変更したアクティブなスニペットファイル
- 保存したチェックポイントのパス
- ユーザーのどの表現が Obsidian のどのレイヤーに対応したか
- スクリーンショットで確認した内容
- 確認できなかったこと、または意図的に保留したこと
小さな変更を行うたびに、ワークフロー全体を説明するのは避けてください。チェックポイントの保存、範囲を絞った編集、スクリーンショット、証拠に基づく次の手順によって、ワークフローを行動で示してください。