Obsidian bases

Skill arch3rPro/ark-space/plugins/ark-space/skills/obsidian-bases

ArkSpace is a creative workspace for orchestrating agent skills, roles, and workflows across Claude Code and Code

Install

npx -y skills add arch3rPro/ark-space --skill obsidian-bases

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

2 stars2 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

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.

SKILL.md

4.2 KB, 951 tokens by cl100k_base, as published. Nobody here has run it

Obsidian Bases Skill

Workflow

Create or open the target .base file and keep it valid YAML.
Define scope with the smallest useful filters.
Prefer existing file metadata and note properties before inventing new schema.
Add formulas only when the requested view cannot be expressed with raw properties.
Add one or more views with a clear order and optional grouping or summaries.
Validate YAML syntax, formula references, and quoted strings before finishing.

Property Discipline

Prefer Obsidian-native file properties and existing note properties before introducing new frontmatter fields.

Use file.name, file.basename, file.folder, file.path, file.ext, file.ctime, file.mtime, file.tags, file.links, file.backlinks, file.embeds, and file.properties when they satisfy the request.
Prefer file.hasTag(...), file.inFolder(...), and file.hasLink(...) for scope filters instead of adding duplicate custom metadata.
Do not add custom properties such as status, priority, due, category, type, author, pages, or cover unless the user asks for them, the vault already uses them, or the requested view cannot be built from native metadata.
When custom note properties are needed, keep them minimal and make the Base consume the existing schema rather than inventing extra fields.

Minimal Schema

Base files use the .base extension and contain valid YAML.

filters:
  and: []

formulas:
  age_days: '(now() - file.ctime).days'

properties:
  formula.age_days:
    displayName: "Age (days)"

views:
  - type: table
    name: "All Notes"
    order:
      - file.name
      - formula.age_days

Filters

Use string expressions for simple cases and nested and / or / not objects when the logic needs structure.

filters:
  and:
    - 'file.ext == "md"'
    - file.hasTag("project")

filters:
  or:
    - file.hasTag("book")
    - and:
        - file.inFolder("Reading")
        - 'status != "done"'

Prefer global filters for the overall dataset and per-view filters only when one view needs a narrower slice.

Formulas

Formulas are shared computed properties. Keep them null-safe and easy to read.

formulas:
  days_until_due: 'if(due_date, (date(due_date) - today()).days, "")'
  day_of_week: 'date(file.basename).format("dddd")'

Common rules:

Date subtraction returns a Duration, so access .days, .hours, or another numeric field before rounding.
Guard optional properties with if() instead of assuming every note has the field.
Every formula.X used in properties, order, or summaries must exist in formulas.

Views

Supported view types are table, cards, list, and map.

Use table for sortable indexes and status views.
Use cards for gallery-style browsing with cover or summary fields.
Use list for compact navigation.
Use map only when the vault already has latitude and longitude style properties and the Maps plugin is relevant.

Example:

views:
  - type: table
    name: "Active Tasks"
    filters:
      and:
        - 'status != "done"'
    order:
      - file.name
      - status
      - due_date
    groupBy:
      property: status
      direction: ASC
    summaries:
      due_date: Latest

Common Pitfalls

Quote strings that contain YAML-special characters such as :, #, [, ], {, }, or ,.
Wrap formulas containing double quotes in single quotes.
Do not reference formula.X unless X is defined in formulas.
Reuse existing note properties when possible instead of creating a new tracking schema for every view.

References

Gives 0 of the 12 instructions most note taking skills give in 951 tokens

Counted across 686 of the 876 authors here whose files we hold, read 2026-08-06

include a visual element on every slidein 44 of 686, across 13 files
use wikilinks for internal vault linksin 35 of 686, across 11 files
commit to a single visual motif across every slidein 34 of 686, across 9 files
read pptxgenjs guide before creating presentations from scratchin 30 of 686, across 6 files
keep 0.5 inch minimum marginsin 30 of 686, across 7 files
use subagents to visually inspect rendered slidesin 30 of 686, across 6 files
re-verify affected slides after every fixin 27 of 686, across 5 files
run content QA checks before declaring successin 26 of 686, across 3 files
Use Markdown links for external URLs onlyin 26 of 686, across 10 files
pick a bold topic specific color palettein 24 of 686, across 2 files
read editing guide before editing existing presentationsin 23 of 686, across 1 file
use one dominant color across all slidesin 23 of 686, across 1 file

Said here and by no other author read

Keep .base files valid YAML
Define scope with the smallest useful filters
Prefer existing metadata before inventing schema
Add formulas only when raw properties fail
Add views with clear order and optional grouping
Use native file properties over custom frontmatter

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.