Obsidianizer

Obsidianizer

Turn one vault section into a clean, usable Obsidian surface.

This skill is for folder-level standardization in this workspace, especially when the user wants the same pattern we have been applying across Inbox, Journal, Programs, Workspaces, Areas, Resources, Archive, or workspace subfolders.

Use This Skill For

• A folder that needs a proper Base + Dashboard + Canvas pattern
• A folder that already has notes but lacks a usable command surface
• Fixing broken or incomplete Bases
• Cleaning up naming like Dashboard.md, duplicate dashboards, ugly README labels, or legacy wrappers
• Standardizing a folder so it works better in Obsidian explorer and Bases

Do not use this skill for generic note writing or for isolated markdown edits. For those, use obsidian-markdown. When editing .base syntax, use obsidian-bases.

Core Outcome

Given one designated folder, produce the smallest coherent system that fits its real contents:

1. Inspect the folder deeply enough to understand its information model
2. Decide whether it needs a Base
3. Create or fix the Dashboard naming and content
4. Create a Canvas that explains the flow visually when that adds value
5. Normalize naming and remove UX confusion
6. Update links so the surface is actually usable

Standard Pattern

Aim for this shape, adapted to the folder's purpose:

<Folder>/
├── _<Name>_Dashboard.md        # main command surface for section-level folders
├── <Name>.base                # optional; only if the folder has enough structured notes
├── <Name> Workflow.canvas     # optional but preferred when process/structure benefits from visual explanation
├── README.md                  # guide/reference, if the folder benefits from one
└── content...

For workspace-local folders inside 02_Programs/1-Workspaces/<Workspace>/, use:

<Workspace>/
├── <Workspace>_Dashboard.md
├── README.md
├── <Workspace>_Context.md     # if that workspace already uses context maps
└── content...

Naming Rules

Apply these defaults unless the folder already has a stronger local convention:

• Section-level folders: _Inbox_Dashboard.md, _Journal_Dashboard.md, _Programs_Dashboard.md, _Areas_Dashboard.md, _Resources_Dashboard.md, _Archive_Dashboard.md, _Skills_Dashboard.md
• Workspace-level dashboards: <Workspace>_Dashboard.md
• Main guide file: README.md
• Legacy aliases like *_README.md should become compatibility shims, not the main entrypoint
• Avoid leaving duplicate dashboard files that represent the same surface

Decision Rules

When to Create a Base

Create or fix a Base if the folder has enough structured items that benefit from filtering, grouping, or summary views.

Good signals:

• Many homogeneous notes
• Repeated frontmatter fields
• Natural views like active/archive/status/year/type
• The user expects “database-like” navigation

Avoid creating a Base when:

• The folder is tiny
• The content is mostly one-off docs
• A curated dashboard is enough

When to Create a Canvas

Create a Canvas when the folder benefits from visual explanation:

• workflow
• hierarchy
• lifecycle
• relationship map
• operating model

Do not create a decorative canvas. It should clarify how the folder works.

Workflow

1. Inspect the Designated Folder

Read:

• folder structure
• representative notes
• existing dashboard/base/canvas/readme files
• frontmatter patterns
• naming inconsistencies

Look for:

• duplicate entrypoints
• broken formulas
• missing properties needed by Bases
• ugly explorer naming
• dashboards that are wrappers instead of real surfaces
• legacy files still acting as primary entrypoints

2. Infer the Folder Model

Figure out:

• what entities live there
• which properties are stable
• which views matter operationally
• whether the folder is process-centric, catalog-centric, or guide-centric

3. Propose the Minimal Coherent Surface

Usually this means:

• one main dashboard
• zero or one main base
• zero or one canvas
• one main README only if useful

Prefer fewer strong surfaces over many weak ones.

4. Implement

Typical work:

• create/fix the Base
• rename dashboard files to standard names
• turn wrapper files into real entrypoints
• demote legacy files into aliases if needed
• add embeds and quick links
• create a canvas note or canvas file for the visual flow
• update links in nearby notes/docs

5. Verify

Check:

• the Base does not use unsupported formula patterns
• properties referenced in views/formulas actually exist or degrade gracefully
• there is only one main dashboard per logical surface
• explorer naming is understandable
• embeds and wikilinks point to real files

Dashboard Expectations

A good dashboard should usually include:

• purpose or quick orientation
• embeds or links to the primary Base(s)
• links to important notes/subfolders
• the visual canvas if relevant
• the minimum context someone needs to operate the folder

Do not make the dashboard a wrapper that only embeds another wrapper.

Base Expectations

When creating or fixing a Base:

• filter by stable signals such as type, folder, date presence, or explicit properties
• avoid brittle year-specific or hardcoded-folder logic unless the folder model truly requires it
• prefer formulas that degrade safely
• if Obsidian Bases syntax is involved, follow the obsidian-bases skill

Canvas Expectations

The canvas should explain the actual operating model of the folder, not a generic hierarchy.

Examples:

• Inbox: capture → pending streams → classify → destinations
• Journal: daily notes → reviews → cadence
• Workspaces: dashboard ↔ context ↔ ops/planning/evergreen

If a previous “Visual” note exists but the real need is a Canvas, migrate the concept and leave a clear pointer if needed.

Output Style

When reporting back:

• say what surface was standardized
• explain whether a Base was created, fixed, or intentionally skipped
• note naming changes
• mention any Obsidian limitations that are structural rather than repo-fixable

This Vault Conventions

• Use shared vault skills from .claude/skills/
• Workspace-specific skills belong under 02_Programs/1-Workspaces/*/.claude/skills/
• Prefer README.md as the human guide and a properly named dashboard as the operational entrypoint
• Preserve existing patterns when they are already coherent; standardize only what improves UX