CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

obsidian-bases

Create and edit Obsidian Bases (.base files) with views, filters, formulas, and summaries. Use when working with .base files, creating database-like views of notes, or when the user mentions Bases, table views, card views, filters, or formulas in Obsidian.

Quality

90%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide
SecuritybySnyk

Passed

No findings from the security scan

The canonical home for this skill is obsidian-bases in kepano/obsidian-skills

SKILL.md
Quality
Evals
Security

Quality

Content

88%Weight 40%Scale 1-5

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

An excellent, highly actionable reference: every section is executable YAML with real gotchas (Duration typing, quoting, null guards) that Claude would not reliably know, and the workflow includes explicit validation and error-recovery steps. The main improvements are trimming duplication between the Schema, View Types, and Complete Examples sections, and moving more of the long tail (full examples, exhaustive tables) into reference files.

Suggestions

Consolidate the View Types section into the Schema section or the examples — the four short per-view snippets repeat information already shown in the schema and complete examples.

Move one or two of the three complete example bases into a references/ file (e.g., references/EXAMPLES.md), keeping one representative example inline in SKILL.md.

Trim the trailing "References" list of four help.obsidian.md links to the single canonical syntax page, since the functions link duplicates the FUNCTIONS_REFERENCE.md pointer.

DimensionReasoningScore

Conciseness

The body is dense with non-obvious, skill-specific knowledge (Duration does not support .round(), YAML quoting rules, the "this" keyword scoping) and contains no padding or explanation of concepts Claude already knows. It falls short of anchor 5 because the four view-type snippets, the summaries table, and the third complete example partially duplicate what the Schema section and the first two examples already demonstrate, and could be trimmed or consolidated.

4 / 5

Actionability

Everything is executable: a full annotated schema, complete copy-paste-ready .base files for three common cases (task tracker, reading list, daily notes), and explicit WRONG/CORRECT pairs in Troubleshooting for quoting, Duration math, null guards, and undefined formulas. This matches anchor 5's copy-paste-ready coverage of common cases.

5 / 5

Workflow Clarity

The six-step workflow has an explicit validation step ("Verify the file is valid YAML with no syntax errors. Check that all referenced properties and formulas exist") and a test-with-feedback-loop step ("Open the .base file in Obsidian... If it shows a YAML error, check quoting rules below"), reinforced by a dedicated Troubleshooting section with fixes. This matches anchor 5's sequence with explicit validation and error recovery; the operation is non-destructive so the batch/destructive cap does not apply.

5 / 5

Progressive Disclosure

Structure is good: the most common functions are inline while the complete per-type reference is correctly split into references/FUNCTIONS_REFERENCE.md (verified to exist), clearly signaled ("For the complete reference of all types... see [FUNCTIONS_REFERENCE.md]") and only one level deep. It falls short of anchor 5 because the ~500-line body inlines substantial material — three full example bases and complete file-property/summary tables — that could live in reference files, leaving SKILL.md as a leaner overview.

4 / 5

Total

18

/

20

Passed

Description

87%Weight 40%Scale 1-5

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

A strong description that clearly states what the skill does and when to use it, with an explicit and richly keyworded trigger clause covering the file extension, product name, and view types. The only gaps are a couple of missing natural trigger terms (list views, map views) and a verb list that could enumerate more distinct actions.

Suggestions

Add "list views" and "map views" to the trigger clause alongside "table views, card views" so users naming those view types also match.

Consider naming one more concrete action (e.g., "group and summarize notes" or "embed bases in notes") to round out the capability list beyond create/edit.

DimensionReasoningScore

Specificity

"Create and edit Obsidian Bases (.base files) with views, filters, formulas, and summaries" names the domain with two concrete actions plus an enumeration of capability objects. It is above anchor 3 (which expects only 1-2 actions with no scope detail) because the feature list clarifies coverage, but below anchor 5, which expects multiple distinct concrete actions.

4 / 5

Completeness

It explicitly answers both questions: the "what" ("Create and edit Obsidian Bases (.base files) with views, filters, formulas, and summaries") and a concrete "when" ("Use when working with .base files, creating database-like views of notes, or when the user mentions Bases, table views, card views, filters, or formulas in Obsidian"). This matches the anchor 5 example's structure of explicit trigger phrases.

5 / 5

Trigger Term Quality

The trigger list covers ".base files", "Bases", "table views", "card views", "filters", "formulas", "database-like views", and "Obsidian" — including the file extension and synonyms. It falls between anchors 4 and 5 because natural terms like "list views" and "map views" are missing even though overall coverage is good.

4 / 5

Distinctiveness Conflict Risk

"Obsidian Bases" and ".base files" form a clear niche with distinct triggers and minimal conflict risk. Potentially generic words like "filters" and "formulas" are qualified by "in Obsidian", keeping overlap with non-Obsidian skills negligible.

5 / 5

Total

18

/

20

Passed

Validation

100%

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository

valeriibeck-star/claude-skills

Path

skills/obsidian-bases/SKILL.md

Reviewed

Table of Contents

Is this your skill?

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.