Obsidian Flavored Markdown Skill
Create and edit Obsidian Flavored Markdown with wikilinks, embeds, callouts, properties, and other Obsidian-specific syntax. Use when working with .md files in Obsidian, or when the user mentions wikilinks, callouts, frontmatter, tags, embeds, or Obsidian notes.
npx skills add github:pantheon-org/tekhne --skill documentation--obsidian--obsidian-markdownCreate and edit valid Obsidian Flavored Markdown. Obsidian extends CommonMark and GFM with wikilinks, embeds, callouts, properties, comments, and other syntax. This skill covers only Obsidian-specific extensions – standard Markdown (headings, bold, italic, lists, quotes, code blocks, tables) is assumed knowledge.
Mindset
Obsidian’s core principle: use vault-native syntax (wikilinks, embeds, callouts) for anything that lives inside the vault, and standard Markdown only for external references or content that must render outside Obsidian.
When to apply: Working with .md files in an Obsidian vault, creating notes with wikilinks, using callouts, defining frontmatter properties, or embedding content from other notes.
When NOT to apply: Plain Markdown files outside a vault, GitHub READMEs, or documentation sites — Obsidian-specific syntax renders as raw text outside Obsidian.
Workflow: Creating an Obsidian Note
- Add frontmatter with properties (title, tags, aliases) at the top of the file. See PROPERTIES.md for all property types.
- Write content using standard Markdown for structure, plus Obsidian-specific syntax below.
- Link related notes using wikilinks (
[[Note]]) for internal vault connections, or standard Markdown links for external URLs. - Embed content from other notes, images, or PDFs using the
![[embed]]syntax. See EMBEDS.md for all embed types. - Add callouts for highlighted information using
> [!type]syntax. See CALLOUTS.md for all callout types. - Verify the note renders correctly in Obsidian’s reading view.
When choosing between wikilinks and Markdown links: use
[[wikilinks]]for notes within the vault (Obsidian tracks renames automatically) and[text](url)for external URLs only.
Internal Links (Wikilinks)
[[Note Name]] Link to note
[[Note Name|Display Text]] Custom display text
[[Note Name#Heading]] Link to heading
[[Note Name#^block-id]] Link to block
[[#Heading in same note]] Same-note heading link
Define a block ID by appending ^block-id to any paragraph:
This paragraph can be linked to. ^my-block-id
For lists and quotes, place the block ID on a separate line after the block:
> A quote block
^quote-id
Embeds
Prefix any wikilink with ! to embed its content inline:
![[Note Name]] Embed full note
![[Note Name#Heading]] Embed section
![[image.png]] Embed image
![[image.png|300]] Embed image with width
![[document.pdf#page=3]] Embed PDF page
See EMBEDS.md for audio, video, search embeds, and external images.
Callouts
> [!note]
> Basic callout.
> [!warning] Custom Title
> Callout with a custom title.
> [!faq]- Collapsed by default
> Foldable callout (- collapsed, + expanded).
Common types: note, tip, warning, info, example, quote, bug, danger, success, failure, question, abstract, todo.
See CALLOUTS.md for the full list with aliases, nesting, and custom CSS callouts.
Properties (Frontmatter)
---
title: My Note
date: 2024-01-15
tags:
- project
- active
aliases:
- Alternative Name
cssclasses:
- custom-class
---
Default properties: tags (searchable labels), aliases (alternative note names for link suggestions), cssclasses (CSS classes for styling).
See PROPERTIES.md for all property types, tag syntax rules, and advanced usage.
Tags
#tag Inline tag
#nested/tag Nested tag with hierarchy
Tags can contain letters, numbers (not first character), underscores, hyphens, and forward slashes. Tags can also be defined in frontmatter under the tags property.
Comments
This is visible %%but this is hidden%% text.
%%
This entire block is hidden in reading view.
%%
Obsidian-Specific Formatting
==Highlighted text== Highlight syntax
Math (LaTeX)
Inline: $e^{i\pi} + 1 = 0$
Block:
$$
\frac{a}{b} = c
$$
Diagrams (Mermaid)
```mermaid
graph TD
A[Start] --> B{Decision}
B -->|Yes| C[Do this]
B -->|No| D[Do that]
```
To link Mermaid nodes to Obsidian notes, add class NodeName internal-link;.
Footnotes
Text with a footnote[^1].
[^1]: Footnote content.
Inline footnote.^[This is inline.]
Complete Example
See EXAMPLES.md for a full annotated note combining all Obsidian-specific syntax.
Common Mistakes
NEVER use standard Markdown links ([text](file.md)) for notes inside the vault — renames silently break them. Use [[wikilinks]] instead.
NEVER wrap external URLs in [[...]] wikilink syntax — creates unresolvable vault references instead of hyperlinks.
NEVER place block IDs on the same line as list items or quotes — they require a separate trailing line after the block.
NEVER embed full notes with ![[Note]] when only a section is relevant — use ![[Note#Heading]].
NEVER include spaces in tag names — a space terminates the tag and the rest becomes unindexed plain text.
NEVER place YAML frontmatter anywhere except the very first line of the file.
WHY: Obsidian-specific syntax fails silently — broken wikilinks, unindexed tags, and ignored properties produce no errors but corrupt the vault graph invisibly.
See COMMON-MISTAKES.md for full BAD/GOOD examples.
References
Explicit NEVER/WHY/consequence triplets with side-by-side bad/good examples. Generic warnings score low — concrete failure modes with real impact (security, correctness, performance) score high.
Runtime validation via eval scenarios proving the skill actually changes agent behaviour. Requires evals/ directory, instructions.json, ≥3 scenarios, and ≥80% instruction coverage in summary.json.
Appropriate rigidity for the skill type: strict rules for critical/security skills, balanced steps for process skills, flexible options for tool skills. Mismatched calibration (too rigid or too loose) reduces score.
Expert-only knowledge the AI couldn't derive on its own — domain-specific patterns, production gotchas, decision frameworks, and non-obvious tool behaviour. High scores mean <5% redundancy with what the model already knows.
A clear philosophy plus numbered step-by-step workflows with explicit entry/exit points. Should answer: what is the core principle, how to execute it, and when (and when not) to apply it.
Rich activation keywords and trigger scenarios in the description so the skill fires when needed. Best descriptions read like an exhaustive list of the tasks and concepts that should invoke this skill.
Copy-paste-ready code, complete runnable examples, real file paths and commands. Pseudocode and abstract descriptions score low — concrete, executable content scores high.
SKILL.md as a <100-line navigation hub pointing to focused references/ files. Content should be lazy-loaded on demand, not front-loaded. Includes actionable 'When to Use' conditions per reference.
Proper frontmatter, single-task focus, activation keywords, and cross-harness portability. Skills must work across 40+ agentic harnesses without hardcoded paths or agent-specific references.
Expert-only knowledge the AI couldn't derive on its own — domain-specific patterns, production gotchas, decision frameworks, and non-obvious tool behaviour. High scores mean <5% redundancy with what the model already knows.
A clear philosophy plus numbered step-by-step workflows with explicit entry/exit points. Should answer: what is the core principle, how to execute it, and when (and when not) to apply it.
Explicit NEVER/WHY/consequence triplets with side-by-side bad/good examples. Generic warnings score low — concrete failure modes with real impact (security, correctness, performance) score high.
Proper frontmatter, single-task focus, activation keywords, and cross-harness portability. Skills must work across 40+ agentic harnesses without hardcoded paths or agent-specific references.
SKILL.md as a <100-line navigation hub pointing to focused references/ files. Content should be lazy-loaded on demand, not front-loaded. Includes actionable 'When to Use' conditions per reference.
Appropriate rigidity for the skill type: strict rules for critical/security skills, balanced steps for process skills, flexible options for tool skills. Mismatched calibration (too rigid or too loose) reduces score.
Rich activation keywords and trigger scenarios in the description so the skill fires when needed. Best descriptions read like an exhaustive list of the tasks and concepts that should invoke this skill.
Copy-paste-ready code, complete runnable examples, real file paths and commands. Pseudocode and abstract descriptions score low — concrete, executable content scores high.
Runtime validation via eval scenarios proving the skill actually changes agent behaviour. Requires evals/ directory, instructions.json, ≥3 scenarios, and ≥80% instruction coverage in summary.json.
No eval scenarios available.
Callouts Reference
Basic Callout
> [!note]
> This is a note callout.
> [!info] Custom Title
> This callout has a custom title.
> [!tip] Title Only
Foldable Callouts
> [!faq]- Collapsed by default
> This content is hidden until expanded.
> [!faq]+ Expanded by default
> This content is visible but can be collapsed.
Nested Callouts
> [!question] Outer callout
> > [!note] Inner callout
> > Nested content
Supported Callout Types
| Type | Aliases | Color / Icon |
|---|---|---|
note |
- | Blue, pencil |
abstract |
summary, tldr |
Teal, clipboard |
info |
- | Blue, info |
todo |
- | Blue, checkbox |
tip |
hint, important |
Cyan, flame |
success |
check, done |
Green, checkmark |
question |
help, faq |
Yellow, question mark |
warning |
caution, attention |
Orange, warning |
failure |
fail, missing |
Red, X |
danger |
error |
Red, zap |
bug |
- | Red, bug |
example |
- | Purple, list |
quote |
cite |
Gray, quote |
Custom Callouts (CSS)
.callout[data-callout="custom-type"] {
--callout-color: 255, 0, 0;
--callout-icon: lucide-alert-circle;
}
Obsidian Markdown Common Mistakes
1. Using Markdown links for internal vault notes
NEVER use standard Markdown links for notes inside the vault. Obsidian will not update them on rename, and they break if the file moves.
WHY: Markdown links bypass Obsidian’s link graph entirely, so renamed or moved notes silently break without any warning in the UI.
<!-- BAD -->
[Meeting Notes](meeting-notes.md)
<!-- GOOD -->
[[Meeting Notes]]
Use [[wikilinks]] for all notes within the vault. Reserve [text](url) for external URLs only.
2. Using wikilink syntax for external URLs
NEVER wrap an external URL in [[...]] wikilink syntax. Obsidian resolves wikilinks against vault notes and will create a broken internal link instead of a hyperlink.
WHY: The URL becomes an unresolvable note reference in the graph, producing a dead link that cannot be opened in a browser.
<!-- BAD -->
[[https://obsidian.md]]
<!-- GOOD -->
[Obsidian](https://obsidian.md)
3. Placing block IDs inline on list items
NEVER place a block ID on the same line as a list item or quote block. Obsidian requires block IDs for lists and quote blocks to appear on a separate line after the block, or the ID will not be recognised.
WHY: An inline block ID on a list item is parsed as plain text, so any [[Note#^block-id]] link targeting it will silently fail to resolve.
<!-- BAD -->
- First item ^item-one
- Second item ^item-two
<!-- GOOD -->
- First item
- Second item
^list-block-id
4. Embedding an entire note when only a section is needed
NEVER embed a full note with ![[Note]] when only a specific section is relevant. This pulls in every heading and paragraph of the target note, flooding the reading view with unwanted content.
WHY: Embedding an entire large note makes the host note hard to read and causes unnecessary re-rendering whenever any part of the source note changes.
<!-- BAD -->
![[Architecture Diagram]]
<!-- GOOD -->
![[Architecture Diagram#Overview]]
5. Using spaces in tags
NEVER include spaces in tag names. A space terminates the tag; the rest of the text becomes plain content and is not indexed.
WHY: The partial tag appears in search results under the wrong name, and the trailing words are indexed as free text rather than as part of the tag hierarchy.
<!-- BAD -->
#project alpha
#my tag
<!-- GOOD -->
#project-alpha
#my-tag
6. Placing frontmatter after content
NEVER place YAML frontmatter anywhere other than the very start of the file. It must appear before any headings, text, or blank lines. Frontmatter placed anywhere else is treated as a fenced code block and the properties are ignored.
WHY: Obsidian only parses the opening --- block as properties; a misplaced block renders as a visible code fence and all defined properties are lost.
<!-- BAD -->
# My Note
---
title: My Note
tags:
- project
---
<!-- GOOD -->
---
title: My Note
tags:
- project
---
# My Note
Embeds Reference
Embed Notes
![[Note Name]]
![[Note Name#Heading]]
![[Note Name#^block-id]]
Embed Images
![[image.png]]
![[image.png|640x480]] Width x Height
![[image.png|300]] Width only (maintains aspect ratio)
External Images


Embed Audio
![[audio.mp3]]
![[audio.ogg]]
Embed PDF
![[document.pdf]]
![[document.pdf#page=3]]
![[document.pdf#height=400]]
Embed Lists
![[Note#^list-id]]
Where the list has a block ID:
- Item 1
- Item 2
- Item 3
^list-id
Embed Search Results
```query
tag:#project status:done
```
Obsidian Markdown Examples
Complete Note Example
A full note combining frontmatter properties, wikilinks, callouts, embeds, tasks, math, and tags.
---
title: Project Alpha
date: 2024-01-15
tags:
- project
- active
status: in-progress
---
# Project Alpha
This project aims to [[improve workflow]] using modern techniques.
> [!important] Key Deadline
> The first milestone is due on ==January 30th==.
## Tasks
- [x] Initial planning
- [ ] Development phase
- [ ] Backend implementation
- [ ] Frontend design
## Notes
The algorithm uses $O(n \log n)$ sorting. See [[Algorithm Notes#Sorting]] for details.
![[Architecture Diagram.png|600]]
Reviewed in [[Meeting Notes 2024-01-10#Decisions]].
What this example demonstrates
| Element | Syntax used |
|---|---|
| Frontmatter properties | --- YAML block with title, date, tags, status |
| Wikilink | [[improve workflow]] |
| Callout | > [!important] Key Deadline |
| Highlight | ==January 30th== |
| Task list | - [x] and - [ ] |
| Wikilink to heading | [[Algorithm Notes#Sorting]] |
| Image embed with width | ![[Architecture Diagram.png|600]] |
| Wikilink to block in note | [[Meeting Notes 2024-01-10#Decisions]] |
| Inline math | $O(n \log n)$ |
Properties (Frontmatter) Reference
Properties use YAML frontmatter at the start of a note:
---
title: My Note Title
date: 2024-01-15
tags:
- project
- important
aliases:
- My Note
- Alternative Name
cssclasses:
- custom-class
status: in-progress
rating: 4.5
completed: false
due: 2024-02-01T14:30:00
---
Property Types
| Type | Example |
|---|---|
| Text | title: My Title |
| Number | rating: 4.5 |
| Checkbox | completed: true |
| Date | date: 2024-01-15 |
| Date & Time | due: 2024-01-15T14:30:00 |
| List | tags: [one, two] or YAML list |
| Links | related: "[[Other Note]]" |
Default Properties
tags- Note tags (searchable, shown in graph view)aliases- Alternative names for the note (used in link suggestions)cssclasses- CSS classes applied to the note in reading/editing view
Tags
#tag
#nested/tag
#tag-with-dashes
#tag_with_underscores
Tags can contain: letters (any language), numbers (not first character), underscores _, hyphens -, forward slashes / (for nesting).
In frontmatter:
---
tags:
- tag1
- nested/tag2
---