OrbitOS解説｜Obsidian＋Claude Code／Gemini CLIで動かすAI駆動セカンドブレインの設計

Obsidianにノートを溜め込んだものの、整理しきれずに放置している。研究や日課やアイデアが別々の場所に散らばり、つながりを見失う。こうした個人ナレッジ管理の手詰まりに対して、整理の作業そのものをAIに任せてしまおうと提案するのが、Obsidianベースのフレームワーク OrbitOS（オービットオーエス） だ。GitHubで★880（2026-06-18時点）を集め、作者のMars Wang氏が「すべてが自分の周りを回る（everything orbits around you）」という比喩で設計を貫いている。

OrbitOSの特徴は、それがソフトウェアではないという点にある。リポジトリの中身はMarkdownのノートとAgent Skillsの設定ファイルだけで、GitHubの言語統計は空だ。知識を保管し計画を立てるのは、Obsidianの保管庫に同居させた Claude Code か Gemini CLI が担う。本記事は、公式README・AGENTS.md・各スキル定義・Issue・作者プロフィールといった一次情報だけを根拠に、OrbitOSの思想・構造・実行モデル・既存のAI-OS系との違いを順に整理する。数値はすべて2026-06-18時点でGitHub APIにより実測した。

OrbitOSのように「モデル以外のすべてをどう設計するか」を扱う発想は、当サイトが繰り返し追ってきたエージェント設計の系譜に乗っている。OrbitOSが採るオーケストレーター役と作業役を分ける二段構成は、その典型例の一つだ。土台となる考え方は AIエージェント設計パターン入門｜プロンプトチェーンからマルチエージェントまで21の型を体系理解する に体系的にまとまっているので、あわせて読むと位置づけが見えやすい。

OrbitOSとは何か（作者・規模・ライセンス・スコープ）

OrbitOSは、READMEの定義によれば「シンプルな原則を中心に設計されたObsidianベースの生産性フレームワーク。その原則とは、すべてが自分の周りを回る、というものだ」。手作業での整理を前提とする従来のノートシステムと違い、Claude CodeかGemini CLIを「知的なナレッジ管理者かつ日次プランナー」として使う点に主眼を置く。AIは情報を保管するだけでなく、アイデアの取り込み、当日の計画、調査の構造化、ノート間のつながり作り、完了案件のアーカイブまでを能動的に手伝う。

作者の Mars Wang氏（GitHub: MarsWang42、米カリフォルニア州アーバイン在住、フォロワー477）は、ほかにもNeovim向けプラグインのmars.nvimや、ローカルで動くOSSのAIエージェント／アプリビルダーAwelなどを公開している開発者だ。OrbitOSは同氏の公開リポジトリの中で最も多く星を集めている。

数値で輪郭を押さえておく。

・スター 880 / Fork 99 / Watch 7（2026-06-18時点・GitHub API実測）
・ライセンス MIT。自由に利用・改変・再配布できる
・作成 2026-01-24、最新コミット 2026-03-15。最終のpushから執筆時点で約3か月空いている
・正式リリース 0件。バージョンタグは付与されていない
・コントリビューター 2名：MarsWang42氏（13コミット）とliuhedev氏（3コミット）
・言語統計は空。実体はMarkdownとTOML・設定ファイルで、実行可能なコードを持たない

スコープは「個人の生産性とナレッジ管理」に限定されている。チーム共有や同期サーバ、プラグインのような機能は備えず、あくまで一人のユーザーがObsidianとAI CLIだけで完結させるための枠組みだ。なお updated_at はGitHub上で2026-06-17を指すが、これはスター獲得などの活動による更新で、コード変更を意味しない。コードの実質的な最終更新は2026-03-15である点は区別して読む必要がある。

なぜ「Orbit（軌道）」なのか

名前のOrbitは「軌道」を指し、設計思想を一語で表している。READMEの「Philosophy」節は5つの原則を挙げる。順に見ると、この比喩が単なる飾りでないことがわかる。

第一に AIはパートナー であること。AIを単なる道具ではなく、システムを理解して維持を手伝う協働者として位置づける。第二に すべてを取り込み、処理は後で という方針。Inboxはアイデアを失わないために存在し、処理は準備ができたときにAIが手伝う。第三に カテゴリよりつながり を重んじる姿勢。硬直したフォルダ階層は破綻するため、wikilinkで柔軟に検索可能な知識グラフを作る。第四に 日次のリズム。日次ノートがすべての錨となり、作業と思考のタイムラインを形成する。第五に 段階的な形式化。アイデアは粗いまま始まり、AIの支援で徐々に構造化されていく。

ここで「軌道」が効いてくる。利用者（ユーザー）を中心の天体に見立てると、プロジェクト・知識・日課は周回する衛星だ。それぞれが動き続け、互いに引力でつながり、決して静止しない。フォルダに固定して死蔵するのではなく、Inboxから日次ノートへ、日次ノートからプロジェクトへ、調査からWikiへと、要素が軌道を移りながら循環する。この動きをwikilinkが重力のように結びつける、というのがOrbitOSの中心的なイメージだ。

アーキテクチャ全体像

OrbitOSの全体像は、3つの層で捉えると見通しがよい。土台にObsidianの保管庫（Markdownファイル群）があり、その上にAgent Skills（スキル定義）が乗り、最上位で外部のAI CLI（Claude Code／Gemini CLI）がオーケストレーターとして全体を動かす。利用者はスラッシュコマンドでCLIに指示を出すだけだ。

見落とせないのは矢印の向きだ。利用者はCLIに話しかけ、CLIは保管庫内のAGENTS.md等で自分の役割を理解し、スキル定義に従ってフォルダにノートを書き込む。推論もファイル操作も外部CLIが行い、OrbitOS自体は「どう振る舞うべきか」を記したルールとテンプレートの集合に徹する。この分離が、OrbitOSをサーバレスかつビルド不要に保っている。

なお、保管庫内に置かれたAGENTS.md・CLAUDE.md・GEMINI.mdは、ほぼ同じ内容をCLIごとに用意した「振る舞いの憲法」にあたる。Claude Code向けのCLAUDE.mdには「英語で応答し、テンプレート内容も英語で書く」、Gemini向けのGEMINI.mdとAGENTS.mdには「ユーザーの言語で応答する」といった差分が書き込まれている。フォルダの役割、wikilinkを多用するルール、frontmatterの直後に空行を入れない決まりなどはどのファイルでも共通だ。CLIが起動時にこのルールファイルを読み込むことで、別々のAIが同じ作法でひとつの保管庫を運用できるようになっている。

スクリーンショットが示すとおり、ObsidianのコミュニティプラグインであるTerminalを使えば、Claude CodeをObsidianの中のターミナルペインで直接動かせる。アプリを切り替えずに、左でノートを見ながら右でAIに指示する運用が公式の推奨構成だ。

コアコンポーネント

OrbitOSを構成する部品は、フォルダ構造・スキル・テンプレート・ペルソナ・Obsidian機能の5種類に整理できる。

8つの軌道フォルダ が骨格だ。番号順に役割が決まっている。

・00_Inbox：素早い書き留め。AIが /kickoff や /research で適切な場所へ処理する
・10_Daily：日次ログ（YYYY-MM-DD.md）。毎朝 /start-my-day で生成する
・20_Project：進行中プロジェクト。エリアではなく名前で平置きし、C.A.P.レイアウトで管理する
・30_Research：恒久的な参照資料。調査の成果を構造化して置く
・40_Wiki：原子的な概念。再利用できる定義を1概念1ノートで切り出す
・50_Resources：収集コンテンツ。Newsletters／ProductLaunches などを置く
・90_Plans：実行計画。AIが下書きし利用者が承認、完了後にアーカイブ
・99_System：システム設定。Archives／Prompts／Templates と、Obsidian BasesのDB定義を格納

この番号付きフォルダ構成は、PARA（Projects/Areas/Resources/Archives）の発想に日次ログを足したものに近い。ただしエリアはフォルダ階層ではなく、frontmatterの area: "[[AreaName]]" というwikilinkで表す。分類を物理フォルダに固定しないという原則がここにも現れている。

12のスキル が動作を担う。ワークフロー系が start-my-day・kickoff・research・ask・brainstorm・parse-knowledge・archive、コンテンツ収集系が ai-newsletters・ai-products、Obsidian技術系が obsidian-markdown・obsidian-bases・json-canvas だ。各スキルは .agents/skills/<name>/SKILL.md にfrontmatter付きMarkdownで定義される。

---
name: start-my-day
description: Daily planning workflow - review yesterday, plan today, connect to active projects
---
You are the Daily Planner for OrbitOS.

# OBJECTIVE
Help the user start their day by reviewing yesterday's progress,
creating today's daily note with priorities, and connecting daily tasks
to active projects. Generate the daily log directly without intermediate plan files.

ペルソナ・プロンプト群 は 99_System/Prompts/ にある。Finance（Crypto／Debt／Portfolio／StockMarket／Tax）、General（FirstPrinciples／Latticework／SecondOrderThinking）、Health（General／Medication／Nutrition／Symptom）、SE（Architect／CodeBase／Interview）といった領域別の専門家人格が用意され、調査時にAIが最適な人格を選んで使う。たとえばSE_Architectは「FAANG級企業のシニア・プリンシパル・アーキテクト」として、要件整理から概算見積り、トレードオフ分析までの出力形式を指示する。

Obsidian Bases との連携も実装されている。.base ファイルはObsidian標準のデータベースビュー機能で、フォルダ内のノートをフィルタ・数式・テーブルで一覧できる。

filters:
  and:
    - file.ext == "md"
    - or:
        - file.inFolder("30_Research")
        - file.inFolder("40_Wiki")
formulas:
  display_title: file.asLink(file.basename.replace("_", " ").replace("-", " "))
  category: file.folder.split("/").reverse()[0]
  area_name: file.path.split("/")[1]
views:
  - type: table
    name: "📚 Wiki (Concepts)"
    filters:
      and:
        - file.inFolder("40_Wiki")
    groupBy:
      property: formula.area_name

このKnowledge.baseは、30_Researchと40_Wikiのノートを横断する3つのテーブルビュー（Wiki／Research／全知識）を定義する。Markdownの集合が、Obsidian上では検索可能なナレッジベースとして立ち上がる仕掛けだ。

プロジェクトのC.A.P.レイアウト も、構造化の中心に位置する。20_Projectに置くプロジェクトノートは、Context（目的と成功条件）、Actions（フェーズ別のチェックリスト）、Progress（日付つきの進捗と日次ノートへのリンク）の3部構成を取る。Project_Templateを見ると、frontmatterに type: project・status: active・area: "[[AreaName]]" を持ち、本文は次の骨格を備える。

---
title: Project Name
type: project
status: active
area: "[[AreaName]]"
created: 
---
# Project Name

## Context
**Objective:** [成功した状態を一文で]
**Success Metrics:**
- [ ] Metric 1

## Actions
### Phase 1: [Phase Name]
- [ ] Task 1

## Progress
- : [[]] - Project initiated

この形式が効くのは、プロジェクトと日次ノートが相互に参照し合うからだ。プロジェクトのProgressは作業した日の日次ノートへリンクし、日次ノートのRelated Projectsは触れたプロジェクトへリンクする。/start-my-day が status: active のプロジェクトを拾い、3日以上更新のないものを停滞として警告できるのも、この status と更新日がノートに刻まれているからだ。テンプレートとfrontmatterの規約が、AIによる自動巡回の土台になっている。

wikilinkの記法 も押さえておく。OrbitOSはObsidian標準の記法を多用する。[[NoteName]] が基本リンク、[[NoteName|表示名]] が表示名つきリンク、![[NoteName]] がノート全体の埋め込み、![[NoteName#Section]] が特定セクションの埋め込みだ。AIが自動でこれらのリンクを張り、概念どうしを結ぶことで、フォルダ階層に頼らない知識グラフが育つ。

実行モデル：スラッシュコマンドと二段エージェント

OrbitOSの操作は、すべてスラッシュコマンドから始まる。利用者が /start-my-day と打てば、AGENTS.mdの定義により対応するスキルが起動し、AIが定められた手順を実行する。Gemini向けの .gemini/commands/*.toml は、prompt = "Use the start-my-day skill." のように該当スキルを呼び出すだけの薄いラッパになっている。

注目すべきは、/research と /kickoff が 二段エージェント方式 で実装されている点だ。研究スキルのSKILL.mdは、文脈を新鮮に保つために2つの別エージェントを使うと明記する。流れはこうだ。利用者が /research <topic> を打つと、オーケストレーター役のAIがまず 計画エージェント をTaskツールで起動する。計画エージェントは既存ノートとの重複を確認し、関連エリアと適切なペルソナを特定し、90_Plans/ に計画ファイルを書いてパスを返す。利用者が計画を確認・修正して承認すると、オーケストレーターは 実行エージェント をまっさらな文脈で起動し、計画ファイルだけを渡して調査と執筆を任せる。

この設計の利点を、スキル自身が4点挙げている。実行エージェントが調査と執筆だけに集中できること、計画段階で既存ノートを確認するため重複を避けられること、利用者が実行前に方針を調整できること、そして文脈を分けることでトークン消費を抑えられることだ。オーケストレーターと作業者を分け、各作業者に新鮮な文脈を与えるこの形は、マルチエージェント設計における定石の一つを個人ナレッジ管理に持ち込んだものといえる。

一方、/ask のような軽量コマンドは単一エージェントで完結する。保管庫を簡単に検索し、必要なら答えるだけで、些末な質疑応答ではノートを作らない。/archive は status: done のプロジェクトや status: processed のInbox項目を見つけてアーカイブへ移す。コマンドごとに重さを変える設計になっている。

ナレッジの循環とAI連携

OrbitOSの真価は、個々のコマンドではなく、それらが生み出す知識の循環にある。1日の流れを追うと、要素がフォルダ間を軌道移動していく様子が見える。

朝、利用者は /start-my-day を打つ。AIは前日の日次ノートから未完了タスクを拾い、20_Project/ から status: active のプロジェクトを探し、3日以上触れていない停滞プロジェクトを警告し、Inboxの未処理件数を数える。並行して /ai-newsletters と /ai-products を走らせ、当日のAIニュースと新製品の要約を取り込む。そのうえでAskUserQuestionツールで「今日の主眼は何か」「新しいアイデアは」「障害はあるか」を尋ね、回答を反映した日次ノートを生成する。新しいアイデアはその場で 00_Inbox/ にファイル化される。

日中、Inboxの項目は /kickoff でプロジェクトに昇格する。プロジェクトはC.A.P.（Context／Actions／Progress）のレイアウトで、目的・フェーズ別タスク・日次ノートへの進捗リンクを持つ。調査が必要になれば /research が30_Researchに本体ノートを、40_Wikiに原子的な概念ノートを作り、wikilinkで結ぶ。完了したものは /archive で99_System配下のArchivesへ移る。

AI連携の中心は、あくまで外部CLIだ。Claude Codeは npm install -g @anthropic-ai/claude-code、Gemini CLIは npm install -g @google/gemini-cli で導入する。調査スキルが WebSearch や WebFetch を呼ぶことからわかるとおり、Web検索やドキュメント取得はCLI側のツールに依存する。OrbitOS自体はMCP（Model Context Protocol）サーバを内蔵しないが、運用役のClaude CodeやGemini CLIが備えるツール群とMCP接続を、そのまま保管庫の操作に活用できる構図だ。知識のリズムを回す日課の繰り返しという観点は、当サイトの ループエンジニアリングとは｜AIエージェントの反復制御を設計する5つの軸と主要OSS実装 で扱う反復制御の考え方とも重なる。

holaOS・Osaurus・claudesidianとの対比

OrbitOSを正しく理解するには、名前の似た「AI-OS」系プロジェクトとの違いを押さえるのが早い。結論を先に言えば、OrbitOSだけがランタイムを持たない。

当サイトで既に解説済みの holaOS｜AIエージェントと人が同居するOpen Agent Computer、Workspace中心設計を解読 は、エージェントと人が同居する計算環境そのものを提供する。同じく Osaurus入門｜「Inference is all you need」を実装したmacOSネイティブAIハーネス は、Apple Silicon上でモデルを動かすネイティブのハーネスだ。どちらも実体のあるソフトウェアで、エージェントが走る土台を用意する。

対してOrbitOSは、ノート保管庫の構造とスキル定義だけを提供し、土台は利用者が別途用意するClaude CodeやGemini CLIに任せる。Web検索で確認できる範囲では、claudesidianやclaude-obsidianといった「Obsidian＋Claude Codeでセカンドブレインを作る」系のプロジェクトが複数存在し、OrbitOSはその系譜に属する。なお git clone を伴う系のプロジェクトでは、初回セットアップ時に外部から取得する内容を確認する習慣が望ましい点は共通する。

OrbitOSの差別化軸を、同系統のObsidian＋Claudeプロジェクトと比べて整理すると次のようになる。

・二言語の同梱：英語（EN）と中国語（CN）の保管庫を最初から備える
・複数CLIへの配慮：Claude／Gemini／Codex向けのスキルとルールを並列に用意
・ペルソナ・プロンプト群：Finance／Health／SE など領域別の専門家人格を標準装備
・Obsidian Bases連携：.base でノート集合をデータベースビュー化
・二段エージェントの調査：計画と実行を分け、文脈を新鮮に保つ研究ワークフロー

この図は本記事による位置づけの整理で、各プロジェクトの公称機能と実体から相対配置したものだ。厳密な計測値ではなく、性格の違いを俯瞰するための見取り図として読んでほしい。

導入手順（最小例）

導入は、保管庫の取得とAIアシスタントの用意の2段階で済む。README記載の手順を確認する。

英語版だけを取得するなら、Gitのスパースチェックアウトを使う。

# 英語版のみをスパースチェックアウト
git clone --filter=blob:none --sparse https://github.com/MarsWang42/OrbitOS.git my-vault
cd my-vault
git sparse-checkout set EN
mv EN/* EN/.* . 2>/dev/null; rmdir EN

Git履歴が不要なら、degitの方が簡潔だ。

# degit で英語版を取得（履歴なし）
npx degit MarsWang42/OrbitOS/EN my-vault

次に前提ソフトを用意する。Obsidian本体を公式サイトから入れ、AIアシスタントを1つ選ぶ。

# Claude Code（いずれか一方でよい）
npm install -g @anthropic-ai/claude-code

# または Gemini CLI
npm install -g @google/gemini-cli

取得した保管庫フォルダをObsidianで開き、同じディレクトリでClaude CodeかGemini CLIを起動すれば準備完了だ。READMEはObsidianのTerminalプラグインを入れ、Obsidian内でClaude Codeを直接動かす構成を推奨している。アプリを行き来せずに、ノートを見ながらAIへ指示できる。

最初の1日はこう進む。まず 00_Inbox/ に思いついたことを1行書き留める。次にAIアシスタントで /start-my-day を実行すると、AIがInboxを走査し、当日の日次ノートを推奨事項つきで生成する。Inbox項目をプロジェクトにするなら /kickoff、何かを深く調べるなら /research <topic>、軽い質問なら /ask <question> を使う。生成される日次ノートは、Priorities・Log・Notes・AI Digest・Related Projectsの各セクションと、Energy・Focusの絵文字メーターを持つテンプレート形式になる。

---
date: 
day: 
week: 
---
# 

## Priorities
- [ ]
- [ ]

## Log
*

## Notes

## AI Digest

## Related Projects
-

想定ユースケース

OrbitOSが向くのは、Obsidianを既に使い、かつClaude CodeかGemini CLIに課金している個人だ。具体的な使い所をいくつか挙げる。

第一に 日次の立ち上げ自動化 だ。毎朝の /start-my-day で、前日の積み残し・進行中プロジェクト・停滞案件・Inbox件数を一画面に集約し、当日の優先順位をAIに提案させる。手作業でのレビューを省ける。

第二に 調査の構造化 だ。新しい技術や概念を学ぶとき、/research が一次資料を調べ、本体ノートと原子的なWiki概念を生成し、wikilinkで既存知識に接続する。学んだ内容が孤立せず、知識グラフに編み込まれる。

第三に アイデアの取りこぼし防止 だ。思いついたら 00_Inbox/ に放り込むだけでよく、整理は後でAIに任せる。/kickoff で粗いアイデアが目的・フェーズ・成功指標を備えたプロジェクトに育つ。

第四に 領域別の壁打ち だ。99_System/Promptsのペルソナを使えば、財務・健康・ソフトウェア設計といった文脈で、それぞれの専門家人格としてAIに相談できる。SE_Architectなら設計のトレードオフを、General_SecondOrderThinkingなら二次的影響の検討を促す。

逆に向かないのは、チームでの共同編集や、リアルタイム同期、モバイル中心の運用だ。OrbitOSは一人のユーザーがデスクトップでCLIを叩く前提で、共有機能を持たない。

制限事項・既知の課題

導入前に押さえるべき制約を、一次情報の範囲で正直に挙げる。

・実行環境はCLI依存：OrbitOS単体では何も動かない。Claude CodeかGemini CLIと、その利用料・APIキーが必須になる
・開発が停滞気味：最新コミットは2026-03-15で、執筆時点で約3か月更新がない。正式リリースも0件
・少人数体制：コントリビューターは実質2名。長期保守の体制は確認できない
・Windows PowerShell非互換：Issue #2で、READMEのインストールコマンドがPowerShellで動かないと報告されている
・RSS取得の不具合：Issue #3で、コンテンツ収集系のRSSソースからデータを取得できない事例が報告されている
・WSL構成の不明点：Issue #7で、WSLに入れたClaude Codeと組み合わせられるかという質問が未解決のまま残る
・対応CLIの限定：Qwen CodeやCodeBuddyへの対応はIssue #1で要望段階。2026-06-18時点では非対応

Issueの傾向から、課題の多くは「どのCLI・どの環境でも同じように動くか」という移植性に集中していることがわかる。OrbitOSがランタイムを外部に委ねる設計を採る以上、利用者ごとの環境差がそのまま動作差として表れやすい。

数値の出所も明確に区別しておく。スター880・Fork 99・コミット数・リリース0件・コントリビューター構成は本記事がGitHub APIで実測した値だ。設計思想・フォルダ役割・スキルの挙動は、OrbitOS自身のREADMEとSKILL.mdの公称である。既知の課題は公開Issueの記載に基づく。推測による補完は行っていない。

今後のロードマップ

OrbitOSは正式なロードマップ文書を公開していない。そのため今後の方向は、公開Issueに表れた要望と、作者の関心から読み取るしかない。

公開Issueが示す改善余地は3つに集約される。第一に 対応CLIの拡大（Issue #1、Qwen Code／CodeBuddyなど安価な選択肢）。第二に インストールの移植性（Issue #2、Windows PowerShell対応）。第三に コンテンツ収集の安定化（Issue #3、RSS取得の修正）。クローズ済みのIssue #6では、別プロジェクトObsidianOSとの連携可能性も話題に上っていた。

ただし最新コミットが2026-03-15で止まっている現状を踏まえると、これらが近いうちに反映される保証はない。作者のMars Wang氏は他にもAwelやmars.nvimなど複数のプロジェクトを並行しており、OrbitOSへの今後のリソース配分は2026-06-18時点で確認できない。導入を検討するなら、現状の機能セットで完結すると見たうえで判断するのが現実的だ。本記事は「停滞している」という観測事実を述べるにとどめ、再開や放棄の予測は行わない。

まとめ

OrbitOSは、Obsidianの保管庫をAIに運用させるという発想を、最小限の部品で形にしたフレームワークだ。コードを持たず、Markdownのノート構造とスキル定義だけで、Inboxから日次ノート、プロジェクト、調査、Wikiへと知識が軌道を回る循環を設計する。推論とファイル操作は外部のClaude CodeやGemini CLIに委ね、自身は「どう振る舞うべきか」を記したルールとテンプレートに徹する。この潔い分離が、サーバレスでビルド不要という身軽さを生んでいる。

holaOSやOsaurusのような実体あるランタイムと並べると、OrbitOSの立ち位置がはっきりする。土台を自前で持たず、既存CLIの上に「個人ナレッジの運用ルール」だけを薄く乗せる。だからこそ、Obsidianと好みのAI CLIを既に使っている個人なら、保管庫を1つ取得するだけで今日から試せる。一方で開発は約3か月停滞し、移植性に課題を残す点は割り引いて見る必要がある。設計の参考として読むか、現状の機能で完結すると割り切って使うか。最新の正確な仕様は、本記事末尾の典拠に挙げた一次ソースを起点に確認してほしい。

参照ソース

・MarsWang42/OrbitOS（公式README・GitHub） — 最終アクセス2026-06-18
・OrbitOS EN/AGENTS.md（Claude Code Behavior 定義）
・OrbitOS Agent Skills（research/kickoff/start-my-day 他）
・OrbitOS Issues（既知の課題・要望）
・Mars Wang（MarsWang42）GitHubプロフィール
・Obsidian 公式サイト
・Claude Code Documentation（Anthropic 公式）
・Gemini CLI（Google 公式リポジトリ）
・OrbitOS obsidian-markdown skill（LobeHub 収録）