obsidian-markdown
Obsidian 独自の記法だけを扱う。保管庫の中はウィキリンク、外は通常のリンク
npx skills add kepano/obsidian-skills/obsidian-markdown入れる前にこのスキルがすること・注意点・SKILL.md の原文を確かめてください。解析は安全性の判定ではありません。
- インストール
- 94,080
- 実用度
- 56
- GitHub star
- 50,894
- 最終更新
- 2026/9/15
頼み方の例
そのままコピーして使えますobsidian-markdownを使って、この内容を Obsidian のノートにしてください。保管庫の中の参照はウィキリンクで、外部の URL は通常のリンクにしてください。注意書きはコールアウトで出してください。
対象のファイルや状況は、ご自身の作業に合わせて置き換えてください。
このスキルがすること
SKILL.md の記述から機械的に抽出- 外部通信・シェル実行・ファイル操作の記述は見つかりませんでした
これは安全性の判定ではありません。 SKILL.md にそう書かれているという事実だけを並べています。実際に問題があるかは使い方と文脈で決まるため、当サイトでは断定しません。導入前に SKILL.md の原文を確認してください。
SKILL.md の規模
コードブロックの言語: markdown、yaml
いつ使うか
Obsidian のノートを書く・直すときです。
説明文の範囲が明確です。ウィキリンク、埋め込み、コールアウト、属性、その他の Obsidian 固有の記法。
★標準の Markdown は扱わない
本文が範囲を絞っています。
Obsidian は CommonMark と GFM を、ウィキリンク・埋め込み・コールアウト・属性・コメントなどの記法で拡張している。このスキルが扱うのは Obsidian 固有の拡張だけである。標準の Markdown(見出し、太字、斜体、一覧、引用、コードブロック、表)は既知として扱う。
範囲を宣言しているのが良い設計です。 Markdown の書き方を教え直さないので、本文が小さく収まります(5,367 バイト。2026-10-09 確認)。
★保管庫の中と外でリンクを書き分ける
本文に引用として置かれた判断の基準があります。
ウィキリンクと Markdown のリンクで迷ったら—— 保管庫の中のノートには
[[ウィキリンク]](Obsidian が名前の変更を自動で追う)、外部の URL には[文字](url)だけを使え。
理由が「名前の変更を追う」なのが的確です。保管庫の中でノートの名前を変えると、ウィキリンクなら Obsidian が書き換えてくれます。Markdown のリンクだと切れます。
ウィキリンクの形が 5 つ
| 書き方 | 何を指すか |
|---|---|
[[Note Name]] | ノート |
[[Note Name|表示]] | 表示を変える |
[[Note Name#見出し]] | 見出し |
[[Note Name#^block-id]] | 段落(ブロック) |
[[#同じノートの見出し]] | 同じノートの中 |
段落を直接指せるのが Obsidian の特徴です。段落の末尾に ^block-id を付けると、そこに ID が付きます。一覧や引用のときは、塊の後ろの別の行に置きます。
ほかにタグ(#tag、#nested/tag)、%% で囲むコメント、== の強調表示、数式、Mermaid の図、脚注の書き方も本文に載っています。
ノートを作る流れが 6 段
- 属性を先頭に属性(frontmatter)を先頭に(題・タグ・別名)
- 構造を書く標準の Markdown で構造を書く
- 関連を繋ぐウィキリンクで関連を繋ぐ
- 埋め込む
![[埋め込み]]で他のノート・画像・PDF を埋める - コールアウトを足す
> [!type]でコールアウトを足す - 閲覧ビューで確かめるObsidian の閲覧ビューで描かれることを確かめる
1 段目が属性なのが順序として正しいです。あとから足すと、ファイルの先頭に挿入する作業になります。
6 段目が入っているのが丁寧です。書式として正しくても、Obsidian が描くとは限りません。
詳細は同梱の 3 ファイルに分かれている
references/PROPERTIES.md属性の型すべてreferences/EMBEDS.md埋め込みの種類すべてreferences/CALLOUTS.mdコールアウトの種類すべて
本文は入口で、種類の列挙は資料の側です(スキルを入れすぎて重くなる仕組み)。
同じリポジトリの 5 件の組み方と入れ方は、Obsidian の地図にまとめています。
使わないほうがいいとき
Obsidian を使っていないなら要らない
ウィキリンクも ![[埋め込み]] も Obsidian 固有です。他の Markdown ではただの文字列として表示されます。
表として引く定義を作るなら別物
そちらは
obsidian-bases で、.base ファイル(YAML)を書きます。
文章の構成そのものを詰めたいなら別物
writing-shape は「読者がまだ知らない概念に寄りかからせない」という軸を持っています。このスキルは記法だけを扱います。
Word の文書にするなら別
docx の側です。
標準の Markdown の書き方は教えてくれない
範囲外と明記されています。
注意点
解析では外部通信・シェル実行・書き換えの記述は見つかっていない
SKILL.md の解析では、外部通信・シェル実行・ファイル書き換えの記述は見つかっていません。同梱ファイルは 3 件です(2026-10-09 確認)。
ただし実際には保管庫の中にファイルを書く
ただし実際には保管庫の中にファイルを書きます。解析が拾っていないのは、記法の例として書かれているためです(スキルを入れる前に確認すること)。
既存のノートを直させる場合は控えを取る
既存のノートを直させる場合は控えを取ってください。保管庫のファイルを直接書き換えます。
ウィキリンクは外に持ち出せない
GitHub や普通の Markdown の道具では [[...]] がそのまま文字として表示されます。
属性の型は Obsidian の版に依存する
references/PROPERTIES.md に列挙されていますが、手元の版で使えるかは確かめてください。
外部への通信はない
外部への通信はありません。保管庫の中で完結します。
ライセンスは MIT
ライセンス: MIT。再配布や商用利用の前に公開元の表記を確認してください。
インストール数の推移
日次で記録9月18日 〜 11月7日(49日分)
インストール数と 1 日あたりの増加は Skillselion が に集計した値です。上流の更新は数日おきなので、前日比ではありません。GitHub star と最終更新は に GitHub から取得しました。
併用すると強いスキル
docx
Word 文書を書式ごと作らせる。変更履歴とコメントに対応し、既存ファイルは XML 直編集で壊さない
obsidian-bases
Obsidian のノートを表として引ける .base ファイルを書かせる。中身は YAML
obsidian-cli
動いている Obsidian を、エージェントに obsidian コマンドで操作させる。ノートの読み書き・検索・タスク・属性に加え、プラグインやテーマの再読み込みとエラーの確認まで
writing-shape
材料の山から記事を 1 段落ずつ育てる。読者がまだ知らない概念に寄りかからせない
よくある質問
標準の Markdown も書いてもらえますか
このスキルの範囲外です。見出し・太字・一覧・表などは既知として扱われます。
扱うのは Obsidian 固有の拡張だけです。
ウィキリンクと通常のリンクはどう使い分けますか
保管庫の中はウィキリンク、外部の URL は通常のリンクです。
理由は名前の変更です。ウィキリンクなら Obsidian がノート名の変更を追って書き換えます。
段落を直接リンクできますか
できます。段落の末尾に ^block-id を付けると ID が付き、[[Note Name#^block-id]] で指せます。
コールアウトの種類はどこにありますか
同梱の references/CALLOUTS.md です。本文は > [!type] の形と主な 13 種(note・tip・warning など)を示し、別名・入れ子・CSS で作る独自の種類を含む全体は資料の側にあります。
属性と埋め込みも同じ作りです。
書いたあと何を確かめますか
Obsidian の閲覧ビューです。流れの 6 段目に入っています。
書式として正しくても、描かれるとは限りません。
他の Markdown の道具でも読めますか
ウィキリンクと埋め込みは読めません。[[...]] がそのまま文字として表示されます。
外部に公開する予定があるなら、リンクの書き方を先に決めてください。
対応しているエージェントはどれですか
Claude Code と Codex です。公開元の README が Claude Code と Codex それぞれへの入れ方を節に分けて案内しています(2026-10-09 確認)。当サイトは公開元が明記しているものだけを「対応」として表示する方針なので、このスキルのページには両方が対応として出ます(指標の意味と限界)。
同じ分類のスキル
◇ ノート・知識管理domain-modeling
「その言葉、どっちの意味?」を毎回聞かせる。用語集と決定記録をその場で書かせる
doc-coauthoring
仕様書・提案書・判断の記録を、3 段で一緒に書かせる。まず背景を全部吐き出させ、節ごとに候補を出して選ばせ、最後に「何も知らない Claude」に読ませて伝わるかを試す
design-doc-mermaid
設計書やコードの説明に載せる図を Mermaid で描かせる。依頼の中身から図の種類と読む手引きを選び、mermaid-cli で描けるかを確かめてから文書に入れる。GitHub の wiki は図の記法のまま、Confluence は画像も添える