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.

2.56x

Quality

83%

Does it follow best practices?

Impact

82%

2.56x

Average score across 3 eval scenarios

Securityby

Passed

No findings from the security scan

Quality

Content

72%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.

The body is a highly actionable, accurate syntax reference with excellent executable examples, but it is a monolithic single-file dump. It lacks a creation workflow with a validation checkpoint, and the function/property reference should be split into a bundle file to keep SKILL.md as an overview.

Suggestions

Add a short step-by-step creation workflow with a validation checkpoint (e.g., confirm the YAML parses and the view renders in Obsidian) before considering a .base file done.

Move the Functions Reference, File Properties, and Default Summary tables into a references/ file (e.g., references/functions.md) and keep SKILL.md to the schema, filter syntax, and one or two examples, with clearly signaled links.

Trim or drop the "Common Patterns" section, which repeats filter combinations already demonstrated in the Filter Syntax section and the complete examples.

Dimension	Reasoning	Score
Conciseness	The body is dense domain-specific reference (schema, operator tables, function tables, examples) with almost no explanation of concepts Claude already knows. Not 5 because the "Common Patterns" section repeats filter syntax already demonstrated, and four full multi-view example bases inflate the token budget; not 3 because there is no padded or redundant conceptual explanation.	4 / 5
Actionability	Everything is executable: a complete YAML schema, concrete filter/formula syntax with quoting rules, per-view-type templates, and four copy-paste-ready full example .base files (task tracker, reading list, project notes, daily notes) covering common cases.	5 / 5
Workflow Clarity	There is no explicit creation sequence (the filters -> formulas -> views order is only implied by the schema) and no validation checkpoint such as confirming the YAML parses before saving or embedding. Per the rubric, missing validation steps cap this dimension at 3 even though the reference material itself is clear.	3 / 5
Progressive Disclosure	No bundle files exist (references/, scripts/, assets/ are absent), so everything lives in a ~600-line monolithic SKILL.md. The ~200 lines of function/property API reference tables clearly belong in a separate reference file; structure and section headers are good, but content that should be separate is inline, matching the anchor-3 example.	3 / 5
	Total	15 / 20 Passed

Description

95%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.

The description is a strong example: it pairs a concrete capability statement with an explicit, keyword-rich trigger clause covering natural synonyms and the file extension. It closely matches the rubric's good-overall examples with no fluff or over-claims.

Dimension	Reasoning	Score
Specificity	"Create and edit Obsidian Bases (.base files) with views, filters, formulas, and summaries" names the domain plus several concrete actions and feature areas. Not 5 because coverage of capabilities is not comprehensive (no mention of editing existing bases' configurations beyond the generic 'edit', or troubleshooting); not 3 because more than 1-2 concrete actions are listed.	4 / 5
Completeness	The description explicitly answers both: what ("Create and edit Obsidian Bases (.base files) with views, filters, formulas, and summaries") and 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"). Concrete trigger phrases are present, mirroring the anchor-5 example structure.	5 / 5
Trigger Term Quality	Triggers include natural synonyms and the file extension: ".base files", "Bases", "table views", "card views", "filters", "formulas", "database-like views", and "Obsidian". This matches the anchor's comprehensive synonym-plus-extension coverage.	5 / 5
Distinctiveness Conflict Risk	"Obsidian Bases (.base files)" is a clear product-specific niche with distinct triggers scoped by "in Obsidian". Terms like "table views" or "card views" alone would carry minor overlap risk, but the Obsidian scoping keeps conflict risk minimal.	5 / 5
	Total	19 / 20 Passed

Validation

87%

Warnings & errors only

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

Validation — 14 / 16 Passed

Validation for skill structure

Criteria	Description	Result
skill_md_line_count	SKILL.md is long (603 lines); consider splitting into references/ and linking	Warning
frontmatter_unknown_keys	Unknown frontmatter key(s) found; consider removing or moving to metadata	Warning

	Total	14 / 16 Passed

Repository: davepoon/buildwithclaude
Path: plugins/all-skills/skills/obsidian-bases/SKILL.md
Commit: b90e2de

Reviewed: 3 days ago

Table of Contents

Discovery Implementation Validation

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.