[!note] dsh adaptation Ported from claude-obsidian (MIT, © 2026 AgriciDaniel) for the Lion-1209 dsh adaptation. Upstream product scripts referenced below are not bundled; filesystem and web operations map to the standard dsh fs/shell/web tools.
Obsidian Bases
Use this as a compact workflow and fallback syntax reference. Prefer a
separately installed kepano/obsidian-skills obsidian-bases skill, then the
current official Bases syntax, for
detailed or version-sensitive fields and functions.
Answer design and syntax questions read-only. For a requested .base edit,
resolve the user vault and use one inspected transaction; never write the file
directly.
Resolve the installed product root from this skill's own location, not from the vault or current working directory:
PRODUCT_ROOT=/absolute/path/to/installed/claude-obsidian
CORE="$PRODUCT_ROOT/scripts/claude-obsidian.py"
test -f "$CORE"
Workflow
Inspect representative note properties and any existing
.basefile.Define the smallest filter that selects the intended notes.
Add formulas only for values that must be computed.
Choose views and display order. Do not assume a view type or option is supported by the user's Obsidian version or installed plugins.
Validate YAML, expression quoting, property names, formula references, and null handling.
Preview the complete file and expected result set before a mutation.
If an edit was requested, read operation-transactions.md, keep the
.basefile underwiki/, and build oneclaude-obsidian.transaction.v1bundle withoperation_type: base. Inspect it, then setAPPROVAL_SHA256to the returnedapproval_sha256only after review and apply once:python3 "$CORE" transaction inspect "$BUNDLE" --vault "$VAULT" python3 "$CORE" transaction apply "$BUNDLE" --vault "$VAULT" \ --approved-plan-sha256 "$APPROVAL_SHA256"Ask the user to render the Base in Obsidian when application-level behavior cannot be verified locally.
Compact schema
.base files are YAML. Common top-level keys are filters, formulas,
properties, summaries, and views.
filters:
and:
- file.inFolder("wiki")
- 'status != "archived"'
formulas:
age_days: '((now() - file.ctime) / 86400000).round(0)'
status_label: 'if(status == "mature", "Ready", "Review")'
properties:
status:
displayName: "Status"
formula.age_days:
displayName: "Age (days)"
views:
- type: table
name: "Wiki pages"
order:
- file.name
- type
- status
- updated
- formula.age_days
Global filters apply to every view. A view may also define its own filters.
Recursive filter objects use one of and, or, or not at each level.
filters:
or:
- file.hasTag("concept")
- and:
- file.hasTag("source")
- 'status == "active"'
Use note properties by name, file metadata as file.name, file.path,
file.folder, file.ext, file.ctime, file.mtime, or file.tags, and
computed properties as formula.<name>.
Formula and YAML rules
- Quote expressions that contain operators, colons, or nested string quotes.
- Guard nullable properties with
if(). - Subtracting two dates returns a millisecond number. Divide by
86400000before rounding when a whole-day count is intended. - Define every
formula.<name>before referencing it in a view or property display configuration. - Do not transplant Dataview-only keys such as
fromorwhereinto a Base. - Do not invent properties absent from the selected notes without explaining that the resulting column will be empty.
formulas:
days_until: 'if(due_date, ((date(due_date) - today()) / 86400000).round(0), "")'
Table, cards, and list views are common:
views:
- type: cards
name: "Reading list"
order:
- file.name
- author
- status
- type: list
name: "Quick list"
order:
- file.name
- status
Embed a Base or one named view in a Markdown note:
![[Dashboard.base]]
![[Dashboard.base#Wiki pages]]
After an applied edit, report the operation ID, exact changed path, validation performed, and anything that still requires rendering in Obsidian. Do not commit Git.