agentleFS
ntaffziintaffzii/Skill-Agents/skills/obsidian/obsidian-markdown/SKILL.md

obsidian-markdown

Skill4 starsChanged 2 months agoMITView on GitHub

Create and edit Obsidian flavored Markdown notes with wikilinks, embeds, callouts, properties, tags, comments, highlights, footnotes, Mermaid, and Obsidian-specific syntax. Use when working with Obsidian .md notes, vault content, wikilinks, callouts, frontmatter, tags, or embeds.

85 other projects use a version of this, 1 of them edited.

Adopted by

Most recently taken up by

Used with

Projects with it also use defuddle, knap and 10 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • HK-hubSkill

    defuddle

    Extract clean markdown content from web pages using Defuddle CLI, removing clutter and navigation to save tokens. Use instead of WebFetch when the user provides a URL to read or analyze, for online documentation, articles, blog posts, or any standard web page.

    Also in 29 projects that use this

  • lucasmaher-hashSkill

    knap

    Render Markdown from templates and structured data using Knap CLI. Use when the user asks to apply a Knap template, turn JSON or CSV data into notes, batch-generate Markdown files, or format Defuddle output into a note.

    Also in 4 projects that use this

  • jykimSkill

    obsidian-cli

    Interact with Obsidian using the official CLI to read, search, create, and manage notes, daily notes, tasks, properties, and more. Use when the user wants to query or manipulate vault content via the obsidian command.

    Also in 38 projects that use this

  • BCS1037Skill

    mermaid-visualizer

    Transform text content into professional Mermaid diagrams for presentations and documentation. Use when users ask to visualize concepts, create flowcharts, or make diagrams from text. Supports process flows, system architectures, comparisons, mindmaps, and more with built-in syntax error prevention.

    Also in 4 projects that use this

  • 0xHoneyJarSkill

    qmd

    Local markdown search engine for knowledge bases, notes, and documentation. Combines BM25 full-text search, vector semantic search, and LLM re-ranking. Use when searching through markdown notes, retrieving documents, or managing knowledge collections.

    Also in 3 projects that use this

  • MicrosoftSkill

    excalidraw-diagram

    Create Excalidraw diagram JSON files that make visual arguments. Use when the user wants to visualize workflows, architectures, or concepts.

    Also in 4 projects that use this

The file

Show its rules and text

We split this skill into the rules it gives an agent

16 rules. 0 are common, 12 are distinctive, and 4 are very specific to this project.

  • 0

    Common

    Most of the 80 edited versions we read keep these.

  • 12

    Distinctive

    This author's own choices. Worth a look.

  • 4

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Use this skill to create valid Obsidian notes.

    line 8
  2. Distinctive:

    Put YAML frontmatter at the top when the note needs metadata.

    line 13
  3. Very specific:

    Use title, tags, aliases, status, date, or project-specific properties when appropriate.

    line 14
  4. Distinctive:

    Use standard Markdown headings and lists.

    line 17
  5. Distinctive:

    Keep headings linkable and specific.

    line 18
  6. Distinctive:

    Use task checkboxes for actionable items.

    line 19
  7. Very specific:

    Use [[Note Name]] for internal notes.

    line 22
  8. Very specific:

    Use [[Note Name|Display Text]] when the note title is not natural in prose.

    line 23
  9. Distinctive:

    Use normal Markdown links only for external URLs.

    line 24
  10. Distinctive:

    Add Obsidian syntax when useful

    line 26
  11. Distinctive:

    Check frontmatter is valid YAML.

    line 34
  12. Distinctive:

    Check wikilinks point to intended note names.

    line 35
  13. Very specific:

    Check callout syntax has > on each line.

    line 36
  14. Distinctive:

    Prefer wikilinks for vault-internal references.

    line 64
  15. Distinctive:

    Do not use external URL syntax for internal notes.

    line 65
  16. Distinctive:

    Keep tags lowercase unless the vault already uses another convention.

    line 66

“Common” is measured: kept by at least 6 in 10 of the 80 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Obsidian Markdown

Use this skill to create valid Obsidian notes.

Workflow

  1. Add properties
    • Put YAML frontmatter at the top when the note needs metadata.
    • Use title, tags, aliases, status, date, or project-specific properties when appropriate.
  2. Structure the note
    • Use standard Markdown headings and lists.
    • Keep headings linkable and specific.
    • Use task checkboxes for actionable items.
  3. Link the vault
    • Use [[Note Name]] for internal notes.
    • Use [[Note Name|Display Text]] when the note title is not natural in prose.
    • Use normal Markdown links only for external URLs.
  4. Add Obsidian syntax when useful
    • Embeds: ![[Note Name]], ![[image.png|300]]
    • Callouts: > [!note], > [!warning] Custom Title
    • Tags: #tag or #nested/tag
    • Comments: %% hidden comment %%
    • Highlights: ==highlighted text==
  5. Verify
    • Check frontmatter is valid YAML.
    • Check wikilinks point to intended note names.
    • Check callout syntax has > on each line.

Common Patterns

---
title: Project Alpha
tags:
  - project
  - active
status: in-progress
---

# Project Alpha

Related: [[Project Index]]

> [!important] Decision
> Use the existing sync pipeline for the first release.

## Tasks

- [ ] Confirm owner
- [ ] Draft implementation plan

Rules

  • Prefer wikilinks for vault-internal references.
  • Do not use external URL syntax for internal notes.
  • Keep tags lowercase unless the vault already uses another convention.

Output Format

End with:

  • Notes created or changed
  • Properties, tags, and links added
  • Obsidian syntax used
  • Validation performed

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.