# PIMP MY VAULT

> Source: <https://gist.github.com/ERICJ3ffrey/a27238066752ecd0474e1b5babf8ea6f>
> Published: 2026-07-13 19:47:14+00:00

| type | guide | ||||
|---|---|---|---|---|---|
| status | active | ||||
| version | 1.1 | ||||
| updated | 2026-07-13 | ||||
| tags |
|

A free prompt pack for turning one visual reference into a coordinated Obsidian theme and, if you have one, a matching custom dashboard skin.

Use the prompts in order. Review each result before your agent writes code or installs files.

Created by [Eric Michaud](https://www.youtube.com/@theericmichaud) at Easy Machine AI.

For the full workflow shown in the video, use [Impeccable](https://impeccable.style/) inside an AI coding tool that can inspect and edit local files, such as Codex CLI, Claude Code, Cursor, Gemini CLI, or another agent with project access.

You can run the analysis and mockup prompts in a normal web chat. That chat cannot build, test, or install a working theme unless it can access your vault files.

The plain prompts still work without Impeccable, but you will need to carry the approved decisions from one step to the next yourself. Impeccable is the recommended route because it keeps the product context, design rules, build, and quality checks connected.

You are using one reference image to create a working design system, not asking an AI to copy a picture into CSS.

The process has two connected outputs:

- A skin for your custom dashboard or plugin, if you have one.
- A full Obsidian theme for the rest of the vault.

Impeccable stores the product context in `PRODUCT.md`

and the approved visual rules in `DESIGN.md`

. Your agent then uses that same contract for the dashboard and the Obsidian workspace. This is what makes the final vault feel like one system instead of two unrelated themes.

| What happens | Section | Impeccable step | Output |
|---|---|---|---|
| Set the product context | Before A | `/impeccable init` |
`PRODUCT.md` and initial design context |
| Study one inspiration image | A | Use the analysis prompt | Approved Take/Avoid list |
| See the direction before coding | B | Use the mockup prompt | Approved visual mockup or mockup brief |
| Turn the look into rules | C | `/impeccable shape ...` |
Shared `DESIGN.md` contract |
| Apply it to a custom dashboard | D | `/impeccable craft ...` |
Scoped dashboard skin |
| Apply it to all of Obsidian | E | `/impeccable craft ...` |
Installable Obsidian theme |
| Check the finished system | F | `/impeccable audit ...` , then `/impeccable polish ...` |
Tested final files |

| Goal | Use these sections | What you need |
|---|---|---|
| Study a reference and create a visual concept | A-B | An image-capable AI assistant |
| Theme a normal Obsidian vault | A-C, E-F | Impeccable and an AI coding tool with vault access |
| Theme a vault plus a custom dashboard or plugin UI | A-F | Impeccable and an AI coding tool with source-code access |
| Port the finished design to another dashboard | G | The completed `DESIGN.md` and the target dashboard source |

Skip the dashboard sections if your vault does not contain a custom dashboard or plugin interface.

Build and test in a copy of your vault. Obsidian recommends a separate development vault when plugin work could affect files or settings.

Before you begin:

- Copy the vault or create a test vault.
- Keep the original theme enabled until the new files pass review.
- Check for existing
`PRODUCT.md`

and`DESIGN.md`

files before creating new ones. - Never give an agent credentials, private keys, or unrelated folders.
- Use another theme only to understand file coverage and structure. Do not copy proprietary CSS.

The prompts tell the agent to wait for approval before installation. Keep that gate.

[Impeccable](https://impeccable.style/) gives your coding agent the design workflow used by this pack. Install it before starting Section A if you want to follow the complete video process.

- Node.js 22.12 or newer
- An AI coding harness
- A local project or vault folder

Run installation commands in a terminal from the root of the project you want to style.

```
npx impeccable install
```

Reload your coding tool after installation. You should see `/impeccable`

in its command list.

GitHub Copilot app users can skip the install and enable Impeccable under **Settings > Experimental**.

Codex users may need to open `/hooks`

and approve the project hook after installation or an update.

Type this inside your AI coding tool, not in the terminal:

```
/impeccable init
```

Impeccable will ask about your audience, visual references, voice, and anti-references. For this workflow, choose **product** when you are styling an app, dashboard, or working vault interface.

Review the generated `PRODUCT.md`

. Keep your existing file if the project already has one, or merge the useful parts instead of overwriting it.

If your vault or dashboard already has a visual system, capture it next:

```
/impeccable document
```

Skip `document`

when you are starting from a blank project with no interface or styles to inspect. Section C will create the shared design contract for the new direction.

- Install Impeccable and reload your coding tool.
- Run
`/impeccable init`

and review`PRODUCT.md`

. - Run
`/impeccable document`

if the project already has an interface worth documenting. - Complete Sections A and B. Approve the Take/Avoid list and one visual direction.
- Use
`/impeccable shape`

in Section C to turn that direction into a shared`DESIGN.md`

. - Use
`/impeccable craft`

in Sections D and E to build the dashboard skin and Obsidian theme from that same contract. - Use
`/impeccable audit`

and`/impeccable polish`

in Section F before installing anything in your main vault.

Run these from the project root in a terminal:

```
npx impeccable check
npx impeccable update
```

Claude Code users can add the official plugin marketplace:

```
/plugin marketplace add pbakaus/impeccable
```

Open `/plugin`

and install Impeccable from the list.

The general skills installer also works:

```
npx skills add pbakaus/impeccable
```

That route installs a shared build instead of one tailored to your coding tool.

Official references:

Replace each placeholder before implementation.

```
[PRODUCT_NAME] = the dashboard, plugin, workspace, or vault name
[PRODUCT_ROOT] = the folder containing the product source; use . for the current root
[VAULT_ROOT] = the root folder of the Obsidian vault
[CONFIG_DIR] = the Obsidian configuration folder; usually .obsidian
[DASHBOARD_ROOT_SELECTOR] = the CSS selector that scopes the custom dashboard
[THEME_NAME] = the human-facing theme name, such as Dust and Ink
[THEME_SLUG] = the lowercase hyphenated name, such as dust-and-ink
[AUTHOR_NAME] = the name shown in manifest.json
[REFERENCE_THEME_PATH] = optional path to a complete reference theme
```

`[PRODUCT_ROOT]`

and `[DASHBOARD_ROOT_SELECTOR]`

apply only to a custom dashboard or plugin UI.

Ask your agent to find the dashboard root selector if you do not know it. Do not guess.

Collect what you have:

- a screenshot of the current vault or dashboard
- one strong visual reference
- the relevant source files
- existing product or design documentation
- tests or a repeatable manual test checklist

One reference with a clear point of view beats a folder full of unrelated images.

Run `/impeccable init`

first. Then paste this into the same coding-agent session:

```
Use Impeccable throughout this project. We are turning one visual reference into
a coordinated design system for an Obsidian vault, then applying that system to
the custom dashboard or plugin and the surrounding Obsidian workspace.

Before editing anything:
1. Read PRODUCT.md and any existing DESIGN.md files.
2. Inspect the project structure and identify whether this is a plain vault, a
   vault with CSS snippets, or a vault with a custom dashboard/plugin UI.
3. Find any existing theme files, snippets, root
   selectors, styling APIs, and tests.
4. Tell me which sections of this prompt pack apply.
5. Treat each approved output as an input to the next section. Keep the
   Take/Avoid list, mockup, and DESIGN.md aligned.
6. Flag missing inputs instead of inventing them.

Do not install files into the live Obsidian configuration folder, change plugin
logic, alter vault content, or perform Git actions without my approval.

If you cannot access local files, say so. Return complete file contents in
Markdown code blocks with the intended save paths so I can install them myself.
```

Attach the current interface and the reference image.

```
Analyze the attached visual reference as inspiration for a dense Obsidian-based
product interface.

Study the screenshot of the existing [PRODUCT_NAME] interface so your analysis
stays grounded in the real product. Extract the reference's color roles,
typographic character, spacing rhythm, surface hierarchy, borders, shadows,
textures, control shapes, and interaction-state ideas.

Separate reusable design principles from literal imagery that would make the
product harder to use. Return a concise Take/Avoid list. Explain how each Take
item would affect a working interface.

Do not write CSS or change files yet.
```

If you are working from one or more reference `DESIGN.md`

files:

```
Inspect the selected reference DESIGN.md files and screenshots of the existing
[PRODUCT_NAME] interface.

Extract the traits that can survive dense product UI: typography, surface
hierarchy, density, spacing, borders, controls, active states, shadows, and
graphic treatments.

Return a concise Take/Avoid list. Cite the source file for each extracted rule.
Do not build or edit the product yet.
```

Approve the Take/Avoid list before continuing.

Attach the current interface and approved reference.

```
Create a high-fidelity visual mockup of the attached [PRODUCT_NAME] interface.

Preserve the existing navigation, information hierarchy, modules, labels,
controls, and approximate density. Restyle the interface using the attached
reference and this direction:

[DESCRIBE THE DIRECTION IN PLAIN LANGUAGE]

Keep dense product text readable. Do not invent features, remove modules, or
turn the interface into a generic analytics dashboard. Return one visual
concept, not implementation code.
```

If the assistant cannot generate images, replace the final sentence with:

```
Return an implementation-ready mockup brief with a layout map, semantic color
roles, typography choices, spacing values, component treatments, and a short
visual acceptance checklist.
```

Once the direction works, stop generating alternatives and formalize it.

Run this Impeccable command first:

```
/impeccable shape the visual system described by the approved reference analysis
```

Then give your agent this scope:

```
Create a shared visual design contract for [PRODUCT_NAME] and its surrounding
Obsidian workspace.

Read, when present:
- PRODUCT.md
- DESIGN.md
- screenshots of the real interface
- the selected reference or approved mockup
- the approved Take/Avoid notes
- useful reference DESIGN.md files

Write:
[PRODUCT_ROOT]/themes/[THEME_SLUG]/DESIGN.md

If you cannot write files, return the complete Markdown document and label it
with that save path.

Define:
- the creative direction and intended working environment
- semantic color roles for light and dark modes
- typography roles and readable information density
- spacing and layout rhythm
- borders, radii, shadows, textures, and material treatments
- buttons, inputs, tabs, menus, cards, tables, lists, and statuses
- hover, focus, active, selected, disabled, loading, warning, error, and success
- responsive and narrow-pane behavior
- reduced-motion behavior and WCAG AA requirements
- anti-references and prohibited treatments

Create separate application guidance for:
1. Custom dashboard or plugin components, if the project contains them.
2. Obsidian app chrome and Markdown content.

Preserve navigation, modules, data, actions, and behavior. Allow presentational
geometry and component micro-layout to change when the approved direction
benefits.

Define a small customization vocabulary for accent, background, surface, text,
border, radius, shadow, typography, and density. End with measurable acceptance
checks. Do not write production CSS yet.
```

Review the contract before implementation. Check the tokens, component states, Obsidian rules, dashboard rules, and anti-references.

If you cannot use Impeccable, skip the slash command and give your assistant the scope prompt directly. Save its approved output as the same `DESIGN.md`

so the later steps still share one source of truth.

Skip this section for a plain Obsidian vault.

Run this Impeccable command first:

```
/impeccable craft the dashboard skin from [PRODUCT_ROOT]/themes/[THEME_SLUG]/DESIGN.md
```

Then apply this scope:

```
Build the [PRODUCT_NAME] dashboard styling layer from the approved DESIGN.md.

Read:
- PRODUCT.md, if present
- [PRODUCT_ROOT]/themes/[THEME_SLUG]/DESIGN.md
- the dashboard's base stylesheet
- the app shell or layout source
- an existing dashboard skin, if available
- relevant styling tests

Create:
[PRODUCT_ROOT]/themes/[THEME_SLUG]/[THEME_SLUG].css

Inspect the existing theme API first. Replace literal radius, spacing, gap,
color, and shadow values with stable theme tokens only where the base CSS blocks
the approved design.

Scope every dashboard rule to [DASHBOARD_ROOT_SELECTOR] or one of its
descendants. Do not change plugin logic, vault writes, navigation, data, content
architecture, or actions. Do not use global Obsidian selectors in the dashboard
stylesheet.

Implement readable light and dark modes with clear hover, focus, active,
selected, disabled, loading, warning, error, and success states. Respect reduced
motion and keep controls dimensionally stable when their state changes.

Expose a small customization block for accent, background, surface, text,
border, radius, shadow, typography, and density.

Add or update checks for token consumption, selector scope, prohibited global
selectors, and theme structure. Test each major view, narrow panes, keyboard
focus, hidden and visible help states, and both color modes.

Do not install the stylesheet into [CONFIG_DIR] until the checks pass and I
approve the preview. Do not perform Git actions.
```

After approval, copy the verified stylesheet to:

```
[VAULT_ROOT]/[CONFIG_DIR]/snippets/[THEME_SLUG].css
```

In Obsidian, open **Settings > Appearance > CSS snippets**, reload the snippets, and enable it.

If you cannot use Impeccable, skip the slash command and give your coding assistant the scope prompt directly.

Run this Impeccable command first:

```
/impeccable craft the matching Obsidian theme from [PRODUCT_ROOT]/themes/[THEME_SLUG]/DESIGN.md
```

Then apply this scope:

```
Build a complete Obsidian theme from the approved [THEME_NAME] DESIGN.md.

Read:
- PRODUCT.md, if present
- [PRODUCT_ROOT]/themes/[THEME_SLUG]/DESIGN.md
- [PRODUCT_ROOT]/themes/[THEME_SLUG]/[THEME_SLUG].css, if a dashboard skin exists
- [REFERENCE_THEME_PATH], if provided

Use the reference theme only to understand the breadth and structure of a
complete Obsidian theme. Do not copy its visual direction or proprietary code.

Create:
- [PRODUCT_ROOT]/themes/[THEME_SLUG]/obsidian-theme/[THEME_NAME]/manifest.json
- [PRODUCT_ROOT]/themes/[THEME_SLUG]/obsidian-theme/[THEME_NAME]/theme.css

Use the stable folder and theme name [THEME_NAME]. Include valid manifest fields:
name, version, minAppVersion, and author. Use semantic versioning such as 1.0.0.
Set author to [AUTHOR_NAME]. If this may become a community theme, use a short
Basic Latin name and do not include the words Obsidian or Theme.

Carry the design contract's semantic token intent into the Obsidian theme.
Override official Obsidian CSS variables first. Add narrow selectors only where
variables cannot express the approved design.

Cover the app background, workspace, title bar, tabs, splits, ribbon, sidebars,
status bar, file explorer, search, command palette, menus, popovers, tooltips,
modals, Settings, buttons, inputs, selects, toggles, sliders, checkboxes,
Markdown editing and reading views, headings, links, lists, blockquotes, tables,
code, embeds, callouts, tags, selection, drag targets, scrollbars, and major
interaction states.

Keep notes and dense Settings screens readable. Support light and dark modes and
narrow windows. Decorative texture must preserve contrast and cannot carry
status information by itself.

Do not place selectors owned by [DASHBOARD_ROOT_SELECTOR] in the Obsidian theme.
Skip that rule when the project has no custom dashboard. Do not require Style
Settings or another plugin for the theme to work.

Expose a small customization block for accent, background, surface, text,
border, radius, shadow, typography, and density. Use the same semantic names as
the dashboard skin where practical, or document the mapping.

Add checks for manifest validity, required files, color-mode coverage,
prohibited dashboard selectors, private paths, remote assets, and absolute
machine paths. Inspect reading view, editing view, Settings, menus, explorer,
tabs, and the embedded dashboard when present.

Do not install the theme into [CONFIG_DIR] until the checks pass and I approve
the preview. Do not perform Git actions.
```

After approval, copy the folder to:

```
[VAULT_ROOT]/[CONFIG_DIR]/themes/[THEME_NAME]/
  manifest.json
  theme.css
```

Select the theme under **Settings > Appearance > Themes**. Reload Obsidian if the theme does not appear.

If you cannot use Impeccable, skip the slash command and give your coding assistant the scope prompt directly.

Official Obsidian references:

Run these Impeccable commands in order:

```
/impeccable audit the [THEME_NAME] dashboard skin and Obsidian theme
/impeccable polish the [THEME_NAME] dashboard skin and Obsidian theme
```

If you cannot use Impeccable:

```
Audit the completed dashboard skin and Obsidian theme against the approved
DESIGN.md.

Check contrast, keyboard focus, text overflow, narrow panes, light and dark
modes, reduced motion, selector ownership, Markdown readability, Settings,
menus, tabs, explorer, and unchanged product behavior.

List failures with file paths and selectors. Fix only confirmed failures. Run
the relevant tests again and report the results.
```

Test the final files in the development vault before copying them to your main vault.

Use this section when another version exposes a different root selector or theme API. Port the design contract instead of copying selectors.

```
Read:
- [PRODUCT_ROOT]/themes/[THEME_SLUG]/DESIGN.md
- the target dashboard's base stylesheet
- the target dashboard's customization documentation
- an existing target-version skin, if available

Create a separate dashboard skin that applies the approved design contract
through the target version's public theme API.

Preserve navigation, modules, actions, data, and plugin logic. Do not copy
selectors from another dashboard version. Scope every component override to the
target dashboard's root selector and add no global Obsidian selectors.

Test each major view, narrow panes, keyboard focus, and light and dark modes. Do
not replace a live plugin or perform Git actions without approval.
```

Run `npx impeccable install`

from the project root, then reload your coding tool. Check that the installer wrote files into the tool's expected skill folder.

Attach the image in chat or save it inside the project and provide the exact path. Ask the agent to confirm that it opened the image before analysis.

Ask the agent to inspect the rendered dashboard root and base stylesheet. Keep dashboard rules out of the global Obsidian theme until the selector is confirmed.

Disable it under **Settings > Appearance > CSS snippets**. The stylesheet contains unscoped selectors. Ask the agent to scope every rule to `[DASHBOARD_ROOT_SELECTOR]`

.

That can be correct. The Obsidian theme owns app chrome and Markdown. The separate dashboard stylesheet owns custom dashboard components.

Test narrow panes during development. Remove unsupported effects, oversized fixed widths, remote assets, and hover-only controls. Keep a readable fallback for each decorative treatment.

Confirm that the assistant has local filesystem access. A web chat can write file contents for you, but you must save, test, and install them yourself.

Confirm each item before sharing the generated theme:

- no private names, machine paths, credentials, or internal URLs remain
- every placeholder has been replaced
`manifest.json`

uses valid JSON and semantic versioning- dashboard and Obsidian selectors stay in their respective stylesheets
- light and dark modes remain readable
- keyboard focus and reduced-motion behavior work
- source images and fonts are local or licensed for redistribution
- product navigation, data, actions, and note content remain unchanged
- tests and the manual inspection checklist pass
- installation instructions name the correct files and folders

This prompt pack is free to use and adapt. Impeccable and Obsidian are separate projects maintained by their respective creators. Link to their official documentation when you redistribute this file so readers receive current installation instructions.
