メニュー
Obsidian Vault 向けに Markdown を変換するスキル。article-summarizer の出力など、プレーン Markdown を Obsidian 独自記法（YAML プロパティ、wikilink、embed、ハッシュタグ、コールアウト、ブロック参照）に最適化する。ユーザーが既存 Markdown を Obsidian 向けに整形・最適化したいとき、または article-summarizer 出力を Vault に取り込むときに使用する。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Codexの計画・実装内容・差分・検証結果をClaude Codeに渡して、読み取り中心のセカンドレビューを受けるスキル。トリガー: ユーザが「Claudeにレビューして」「Claude Codeに見てもらって」「セカンドオピニオンを得て」「計画や実装をレビューして」と依頼したとき、または大きめの変更前後に別モデルの観点で設計・バグ・テスト不足を確認したいとき。
Read academic papers from local raw/papers entries, arXiv/HTML/PDF sources, or provided URLs; create detailed Japanese Markdown explanations with formulas, figures, experimental results, limitations, and Obsidian/MathJax compatibility checks. Use when the user asks to read, explain, summarize, or turn a paper into an Obsidian-ready Markdown note.
漠然とした初期段階のアイデアを「発散→収束」の 2 サイクルで洗練するスキル。Double Diamond 思考フレームに沿って、対象ユーザ・成功条件の明確化、複数案の発散、批判的評価、HMW（How Might We）形式の問題定義への収束までを対話形式で進める。トリガー条件: ユーザが「アイデアを洗練したい」「ブレストしたい」「How Might We を作りたい」「アイデアを練りたい」「企画を考えたい」「サービスのアイデアを発散したい」と依頼したとき。
Kaggle コンペ参加期間中（序盤の戦略立案・中盤の追加実験・終盤の取捨選択いずれも）の実験投資判断スキル。次に試す仮説の発散と、優先度付けした実験バックログ生成を行う。Kaggle／コンペ／LB／CV／public notebook／discussion／submission／leaderboard／QWK／MAP@K／adversarial validation／pseudo labeling 等のキーワード、または『何から始めるべきか』『次に何の実験をやるべきか』『LB が伸びない』『仮説を整理したい』『リーク疑いがある』『submission 何回残してる時に何をやるべきか』のような発話で必ず使う。良い案を出すだけでなく『今やるべきでない仮説を殺す』ことも目的。一般的なブレスト・新規事業アイデア・プロダクト企画は対象外（その場合は idea-refinement を使う）。HPO（ハイパーパラ最適化の体系的探索）は対象外。
URLで指定されたWebページ（ブログ記事、X/Twitterポスト、技術記事、論文ページ等）の内容を調査・要約し、マークダウンファイルとしてまとめるスキル。記事内で引用・参照されている外部リンクの内容も追跡して含める。ページ内の画像も元URLから直接ダウンロードしてJPEG圧縮して保存する。トリガー: ユーザがURLを提示して「まとめて」「要約して」「内容を調査して」「ファイルに保存して」と依頼したとき。
作業中に行き詰まったとき、OpenAI Codex CLIをセカンドオピニオンとして呼び出すスキル。現在の問題・コード・エラーをCodexに渡し、別の視点からのアドバイスや解決策を得る。トリガー: ユーザが「Codexに聞いて」「セカンドオピニオンを得て」「Codexの意見を聞かせて」と依頼したとき。
| name | obsidian-formatter |
| description | Obsidian Vault 向けに Markdown を変換するスキル。article-summarizer の出力など、プレーン Markdown を Obsidian 独自記法（YAML プロパティ、wikilink、embed、ハッシュタグ、コールアウト、ブロック参照）に最適化する。ユーザーが既存 Markdown を Obsidian 向けに整形・最適化したいとき、または article-summarizer 出力を Vault に取り込むときに使用する。 |
プレーン Markdown を Obsidian Vault 向けの独自記法に変換する。article-summarizer の生成物のような構造化された記事 Markdown を、Properties / Wikilink / Embed / Callout / Tag に最適化された Obsidian ネイティブ表現へ整形する。
article-summarizer の出力フォーマットを主対象とする。入力 Markdown を読み込み、以下の構造要素を抽出する。
# タイトル 行- 情報源: ..., - 著者: ..., - 日付: ..., - 引用: ... 等の箇条書き）## 見出し）と本文 の位置と alt テキスト> ...）の有無$...$, $$...$$）の有無ユーザーが明示的に保存先や追加要件（タグ追加、特定見出しの callout 化等）を指定している場合はメモする。
冒頭の箇条書きメタデータブロックを YAML frontmatter に変換する。マッピング規則と Properties の型は references/conversion-rules.md と references/obsidian-syntax.md を参照。
最低限のフィールド: title, source, date, tags。author, aliases, created は元 Markdown に存在すれば追加する。
frontmatter 化したメタデータは本文側からは削除する（重複させない）。# タイトル 見出しは frontmatter の直後に 1 度だけ残す（Obsidian は H1 を本文として表示するため）。
 → ![[path|alt]]。alt が空の場合は ![[path]]。外部 URL（http://, https://）の場合はそのまま標準 Markdown 形式を維持する（Obsidian の embed は Vault 内パスのみ対応）。[[note]] または [[note#heading]] 化する。元 Markdown に内部リンクが無い場合は何もしない。以下は Claude の判断で適用する。references/conversion-rules.md の判断指針に従う。
tags: リストに入れる。Obsidian の慣習に従い area/topic 形式のネストタグも検討する。[[キー概念]] でリンク化する。一般語や代名詞には適用しない。> [!summary]、「注意／警告」は > [!warning]、「補足／メモ」は > [!note]、引用元情報は > [!cite] に変換する。元見出しの意味と一致しない場合は変換しない。変換後の Markdown について、references/conversion-rules.md 末尾の「自己検証チェックリスト」（7 項目）を一通り確認する。未充足項目があれば該当箇所を再修正する。
数式（$...$, $$...$$）は Obsidian の KaTeX で互換のため変更不要。ただし $$ ... $$ ブロックの前後に空行が無い場合は空行を追加する。
foo.md に対し foo.obsidian.md を同じディレクトリに作成する。元ファイルは上書きしない（差分確認できるようにする）。![[]] の中身に流し込む。references/obsidian-syntax.md — Obsidian 固有記法のチートシート。Properties 型、Wikilink、Embed、Callout 種別、ブロック参照、数式の書式を網羅。references/conversion-rules.md — article-summarizer 出力 → Obsidian 表現のマッピング表と自己検証チェックリスト。references/examples.md — before/after の具体例。標準的な技術記事とエッジケース（数式・引用多め）の 2 シナリオ。references/validation.md — /empirical-prompt-tuning を起動する際のシナリオ・チェックリスト・収束基準。スキル設計を改善・反復するときに使用する。スキル設計を改善・反復するときは /empirical-prompt-tuning を起動し、references/validation.md のシナリオ 3 件とロック済みチェックリストを評価者に渡す。連続 2 イテレーションで「新規 unclear ゼロ」かつ「精度改善 +3 ポイント以下」になったら収束とみなす。