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.
80
71%
Does it follow best practices?
Impact
100%
1.06xAverage score across 3 eval scenarios
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./plugins/all-skills/skills/obsidian-markdown/SKILL.mdQuality
Discovery
100%Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.
This is an excellent skill description that hits all the marks. It uses third person voice, lists specific concrete capabilities, includes a comprehensive 'Use when...' clause with natural trigger terms, and carves out a clear niche that distinguishes it from generic Markdown or note-taking skills. It closely mirrors the good examples provided in the rubric.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Lists multiple specific concrete actions and features: 'Create and edit Obsidian Flavored Markdown with wikilinks, embeds, callouts, properties, and other Obsidian-specific syntax.' This names the domain clearly and enumerates specific capabilities. | 3 / 3 |
Completeness | Clearly answers both 'what' (create and edit Obsidian Flavored Markdown with specific syntax features) and 'when' (explicit 'Use when...' clause listing file types and trigger terms like wikilinks, callouts, frontmatter, tags, embeds, Obsidian notes). | 3 / 3 |
Trigger Term Quality | Excellent coverage of natural terms users would say: 'Obsidian', '.md files', 'wikilinks', 'callouts', 'frontmatter', 'tags', 'embeds', 'Obsidian notes'. These are all terms a user working with Obsidian would naturally use. | 3 / 3 |
Distinctiveness Conflict Risk | Highly distinctive with a clear niche: Obsidian-specific Markdown. The mention of Obsidian-specific features like wikilinks, callouts, and embeds clearly distinguishes this from a generic Markdown skill or other document editing skills. | 3 / 3 |
Total | 12 / 12 Passed |
Implementation
42%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
The skill provides comprehensive, concrete syntax examples for Obsidian Flavored Markdown, making it highly actionable. However, it is severely bloated by including standard Markdown syntax that Claude already knows (headings, bold, lists, code blocks, tables, footnotes, LaTeX), roughly doubling its length unnecessarily. The monolithic structure with no progressive disclosure makes it an inefficient use of context window.
Suggestions
Remove all standard Markdown syntax sections (Basic Formatting, Lists, Code Blocks, Tables, Math, Footnotes, Diagrams) and focus only on Obsidian-specific extensions: wikilinks, embeds, callouts, properties, block references, comments, tags, and ==highlights==.
Split the callout types reference table and the complete example into separate bundle files (e.g., CALLOUT_TYPES.md, EXAMPLE.md) and reference them from the main skill.
Add a brief pitfalls/gotchas section covering common errors: YAML frontmatter must be first in file with no preceding whitespace, special characters in note names, wikilink vs standard markdown link tradeoffs.
Condense the Properties section by combining the type table and examples into a single compact reference rather than showing them separately.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Extremely verbose — much of this is standard Markdown syntax (headings, bold, italic, lists, code blocks, tables, footnotes) that Claude already knows. The skill should focus only on Obsidian-specific extensions (wikilinks, embeds, callouts, properties, block references, comments). Basic formatting, ordered/unordered lists, fenced code blocks, and LaTeX math are not Obsidian-specific and waste significant token budget. | 1 / 3 |
Actionability | Every syntax feature includes concrete, copy-paste-ready markdown examples. The complete example at the end demonstrates how all features combine in a real note. The examples are executable and specific. | 3 / 3 |
Workflow Clarity | This is primarily a reference/syntax skill rather than a multi-step workflow, so explicit validation steps are less critical. However, there's no guidance on common pitfalls (e.g., YAML frontmatter must be the very first thing in the file, wikilink escaping, how to handle special characters in note names), which would help prevent errors. | 2 / 3 |
Progressive Disclosure | This is a monolithic wall of text at ~350+ lines with no bundle files to offload content. The callout types table, supported code languages list, HTML support section, and basic formatting sections could all be in separate reference files. Everything is inline with no layered structure. | 1 / 3 |
Total | 7 / 12 Passed |
Validation
90%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 10 / 11 Passed
Validation for skill structure
| Criteria | Description | Result |
|---|---|---|
frontmatter_unknown_keys | Unknown frontmatter key(s) found; consider removing or moving to metadata | Warning |
Total | 10 / 11 Passed | |
c911a92
Table of Contents
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.