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.
76
71%
Does it follow best practices?
Impact
82%
2.56xAverage score across 3 eval scenarios
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./plugins/all-skills/skills/obsidian-bases/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 follows best practices closely. It uses third person voice, lists specific capabilities, includes a clear 'Use when' clause with multiple natural trigger terms, and targets a distinct niche (Obsidian Bases) that is unlikely to conflict with other skills.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Lists multiple specific concrete actions: 'Create and edit Obsidian Bases', '.base files', 'views, filters, formulas, and summaries'. These are concrete, actionable capabilities. | 3 / 3 |
Completeness | Clearly answers both 'what' (create and edit Obsidian Bases with views, filters, formulas, and summaries) and 'when' (explicit 'Use when' clause covering .base files, database-like views, and multiple trigger terms). | 3 / 3 |
Trigger Term Quality | Excellent coverage of natural terms users would say: '.base files', 'Bases', 'table views', 'card views', 'filters', 'formulas', 'Obsidian', 'database-like views of notes'. These are terms users would naturally use when needing this skill. | 3 / 3 |
Distinctiveness Conflict Risk | Highly distinctive with a clear niche: Obsidian Bases and .base files are very specific. The mention of Obsidian context plus the specific file extension and feature set (Bases, table views, card views) makes it unlikely to conflict with other 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.
This skill is a comprehensive and highly actionable reference for Obsidian Bases with excellent concrete examples, but it severely suffers from being a monolithic document that tries to be both a quick-start guide and a complete API reference. The ~450+ lines include extensive function tables and property references that should be in separate files, and the skill lacks workflow guidance for the actual process of creating/editing .base files safely.
Suggestions
Extract the function reference tables (Global, Date, String, Number, List, File functions) into a separate REFERENCE.md file and link to it from the main SKILL.md
Remove the 'When to Use This Skill' and 'Overview' sections — this information belongs in the YAML frontmatter description, not the body
Add an explicit workflow section at the top: 1) Determine view requirements, 2) Write the YAML, 3) Validate YAML syntax, 4) Verify property names exist in vault frontmatter
Trim the main SKILL.md to schema + one complete example + common patterns, keeping it under 150 lines with references to detailed docs
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is extremely verbose at ~450+ lines, functioning as a comprehensive reference manual rather than a concise skill. It includes exhaustive function reference tables (string, number, list, date functions), operator tables, and property listings that Claude already knows or could infer. The 'When to Use This Skill' section and 'Overview' are unnecessary padding. Much of this content (especially the full function reference) should be in separate reference files. | 1 / 3 |
Actionability | The skill provides fully executable YAML examples throughout, including complete base files for task trackers, reading lists, project notes, and daily notes. Filter syntax, formula syntax, and view configurations are all copy-paste ready with concrete, working examples. | 3 / 3 |
Workflow Clarity | The skill clearly documents the schema and syntax but lacks an explicit workflow for creating or editing a .base file (e.g., steps like: read existing file, validate YAML, check property names against vault). There are no validation checkpoints or error recovery guidance for when YAML is malformed or properties don't exist in the vault. | 2 / 3 |
Progressive Disclosure | The entire content is a monolithic wall of reference material in a single file with no bundle files. The exhaustive function reference tables, operator tables, and property listings should be split into separate reference files. The SKILL.md should be a concise overview pointing to detailed references, but instead it inlines everything. | 1 / 3 |
Total | 7 / 12 Passed |
Validation
81%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 9 / 11 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 | 9 / 11 Passed | |
857fe3a
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.