OB

obsidian-multi-env-setup

Setup isolated Obsidian vaults for dev, test, and production environments.

Install

mkdir -p .claude/skills/obsidian-multi-env-setup && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/7856" && unzip -o skill.zip -d .claude/skills/obsidian-multi-env-setup && rm skill.zip

Installs to .claude/skills/obsidian-multi-env-setup

Activation

This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.

Configure multiple Obsidian environments for development, testing, and
70 charsno explicit “when” trigger
Intermediate

Key capabilities

  • Create separate development, testing, and production vaults
  • Symlink plugin source into a dev vault for immediate changes
  • Configure environment-specific plugin settings using a config factory
  • Generate vault templates for consistent team onboarding
  • Implement sync strategies for vaults using Git, Obsidian Sync, or cloud services

How it works

The skill uses file system operations to create distinct vault directories and symlinks plugin source code for development. It also provides code patterns for environment-specific plugin configurations.

Inputs & outputs

You give it
Bash commands to create directories and symlinks, or a TypeScript config factory
You get back
Isolated Obsidian vaults, symlinked plugin source, or environment-specific plugin configurations

When to use obsidian-multi-env-setup

  • Create isolated dev and test vaults
  • Setup templates for team onboarding
  • Manage environment-specific plugin settings
  • Sync configurations across vaults

About this skill

Obsidian Multi-Environment Setup

Overview

Configure separate development, testing, and production vaults for Obsidian plugin work. Covers vault templates for team onboarding, environment-specific plugin settings, sync strategies, and .obsidian/ directory management across environments.

Prerequisites

  • Obsidian desktop app installed
  • Node.js 18+ and npm/pnpm for plugin builds
  • Git for version control (recommended)
  • Basic understanding of symlinks and file system operations

Instructions

Step 1: Create the Environment Structure

Set up three isolated vaults -- dev, test, and prod:

# Base directory for all environments
mkdir -p ~/obsidian-envs/{dev,test,prod}

# Dev vault: your working vault with symlinked plugin source
mkdir -p ~/obsidian-envs/dev/.obsidian/plugins/your-plugin
mkdir -p ~/obsidian-envs/dev/sandbox  # scratch notes for testing

# Test vault: clean environment for QA
mkdir -p ~/obsidian-envs/test/.obsidian/plugins/your-plugin
mkdir -p ~/obsidian-envs/test/test-data

# Prod vault: mirrors real user setup
mkdir -p ~/obsidian-envs/prod/.obsidian/plugins/your-plugin

Step 2: Symlink Plugin Source for Development

In the dev vault, symlink your plugin's build output so changes appear immediately:

# Remove the empty plugin directory in dev
rm -rf ~/obsidian-envs/dev/.obsidian/plugins/your-plugin

# Symlink to your plugin's repo (contains manifest.json, main.js, styles.css)
ln -s /path/to/your-plugin ~/obsidian-envs/dev/.obsidian/plugins/your-plugin

For hot reload during development, use the Hot Reload plugin:

# Clone hot-reload into dev vault's plugins
git clone https://github.com/pjeby/hot-reload.git \
  ~/obsidian-envs/dev/.obsidian/plugins/hot-reload

Then enable both your plugin and hot-reload in .obsidian/community-plugins.json:

["your-plugin", "hot-reload"]

Step 3: Environment-Specific Plugin Settings

Each vault gets its own data.json for your plugin. Create a config factory:

// config/environments.ts
interface PluginConfig {
  debugMode: boolean;
  logLevel: 'debug' | 'info' | 'warn' | 'error';
  apiEndpoint: string;
  featureFlags: Record<string, boolean>;
}

const ENV_CONFIGS: Record<string, Partial<PluginConfig>> = {
  dev: {
    debugMode: true,
    logLevel: 'debug',
    apiEndpoint: 'http://localhost:3000',
    featureFlags: { experimentalEditor: true, betaSync: true },
  },
  test: {
    debugMode: true,
    logLevel: 'info',
    apiEndpoint: 'https://staging.api.example.com',
    featureFlags: { experimentalEditor: true, betaSync: false },
  },
  prod: {
    debugMode: false,
    logLevel: 'error',
    apiEndpoint: 'https://api.example.com',
    featureFlags: {},
  },
};

export function detectEnvironment(vaultPath: string): string {
  if (vaultPath.includes('obsidian-envs/dev')) return 'dev';
  if (vaultPath.includes('obsidian-envs/test')) return 'test';
  return 'prod';
}

export function getConfig(env: string): PluginConfig {
  const defaults: PluginConfig = {
    debugMode: false,
    logLevel: 'error',
    apiEndpoint: '',
    featureFlags: {},
  };
  return { ...defaults, ...ENV_CONFIGS[env] };
}

Use it in your plugin's onload():

async onload() {
  const vaultPath = (this.app.vault.adapter as any).basePath;
  const env = detectEnvironment(vaultPath);
  const config = getConfig(env);
  console.log(`[your-plugin] Running in ${env} mode`);

  if (config.debugMode) {
    // Register debug commands only in dev/test
    this.addCommand({
      id: 'dump-state',
      name: 'Dump Plugin State (debug)',
      callback: () => console.log(JSON.stringify(this.settings, null, 2)),
    });
  }
}

Step 4: Vault Templates for Team Onboarding

Create a template vault that new team members clone:

vault-template/
  .obsidian/
    app.json              # Standard app settings
    appearance.json       # Theme and font settings
    hotkeys.json          # Team-standard keybindings
    community-plugins.json  # Approved plugin list
    plugins/              # Pre-configured plugin data.json files
      dataview/data.json
      templater-obsidian/data.json
  templates/              # Note templates (daily, meeting, project)
    daily.md
    meeting.md
    project-kickoff.md
  README.md               # Vault orientation guide

Script to provision a new team member's vault:

#!/bin/bash
# provision-vault.sh <username> <role>
USERNAME=$1
ROLE=${2:-editor}

VAULT_DIR=~/obsidian-team-vaults/$USERNAME
cp -r vault-template "$VAULT_DIR"

# Inject user-specific settings
cat > "$VAULT_DIR/.obsidian/plugins/rbac-plugin/data.json" <<EOF
{
  "userEmail": "${USERNAME}@company.com",
  "role": "${ROLE}"
}
EOF

echo "Vault provisioned at $VAULT_DIR for $USERNAME ($ROLE)"

Step 5: Sync Strategies

Choose based on your team's needs:

Git sync (best for plugin developers):

cd ~/obsidian-envs/prod
git init
cat > .gitignore <<'EOF'
.obsidian/workspace.json
.obsidian/workspace-mobile.json
.obsidian/cache
.trash/
EOF
git add -A && git commit -m "Initial vault state"

Pair with the Obsidian Git plugin for auto-commit/push on a schedule.

Obsidian Sync (best for non-technical teams): Configure in Settings > Sync. Selective sync lets you exclude .obsidian/plugins/ on certain devices to prevent config conflicts.

iCloud/Dropbox (simplest, most fragile): Place the vault inside the sync folder. Avoid editing on multiple devices simultaneously. .obsidian/ conflicts are common -- keep a backup.

Step 6: Managing .obsidian/ Across Environments

The .obsidian/ directory holds all configuration. Key files and their sync behavior:

FileSync across envs?Why
app.jsonYesCore settings should be consistent
appearance.jsonYesTheme consistency
community-plugins.jsonPer-envDev may have debug plugins
hotkeys.jsonYesMuscle memory matters
workspace.jsonNeverLayout is per-device
plugins/*/data.jsonPer-envSettings differ by environment

Script to sync safe configs from prod to other environments:

#!/bin/bash
# sync-config.sh -- copy safe configs from prod to dev/test
SAFE_FILES="app.json appearance.json hotkeys.json"
SRC=~/obsidian-envs/prod/.obsidian

for env in dev test; do
  DST=~/obsidian-envs/$env/.obsidian
  for f in $SAFE_FILES; do
    cp "$SRC/$f" "$DST/$f" 2>/dev/null && echo "Synced $f to $env"
  done
done

Output

  • Three isolated vaults (dev/test/prod) with independent plugin configurations
  • Symlinked plugin source in dev vault with hot reload
  • Environment detection and config switching in plugin code
  • Vault template and provisioning script for team onboarding
  • Sync strategy configured (Git, Obsidian Sync, or cloud)
  • .obsidian/ management scripts for consistent cross-env config

Error Handling

IssueCauseSolution
Symlink not workingPermission denied on WindowsRun terminal as Administrator, or use mklink /D
Plugin not appearing in dev vaultSymlink target missing manifest.jsonRun npm run build first; ensure main.js exists
Wrong config loadedVault path detection failedCheck basePath matches expected pattern
Hot reload not triggering.hotreload file missingCreate empty .hotreload in plugin directory
Sync conflict on workspace.jsonMultiple devices open same vaultAdd workspace.json to .gitignore
Test vault has stale dataForgot to refresh after plugin updateCopy latest build artifacts: manifest.json, main.js, styles.css

Examples

Solo developer workflow: Dev vault symlinked to plugin repo with hot reload. Test vault gets npm run build output copied in manually for final QA. Prod vault is your daily-driver vault with the released version from BRAT or community plugins.

Team onboarding: Run provision-vault.sh alice editor to create Alice's vault from the team template. She opens it in Obsidian, and all approved plugins with team-standard settings are pre-configured.

CI testing across Obsidian versions: Create a headless test vault with your plugin installed. Use obsidian-cli or Electron automation to open the vault, run plugin commands, and verify output. Repeat for each Obsidian version in your support matrix.

Resources

Next Steps

For monitoring and logging across environments, see obsidian-observability. For access control on shared vaults, see obsidian-enterprise-rbac.

Prerequisites

Obsidian desktop app installedNode.js 18+ and npm/pnpm for plugin buildsGit for version control (recommended)Basic understanding of symlinks and file system operations

Limitations

  • Symlinks on Windows may require Administrator privileges or mklink /D
  • Plugin not appearing in dev vault if symlink target misses manifest.json
  • Wrong config loaded if vault path detection fails

How it compares

This skill establishes a structured multi-environment setup for Obsidian plugin development, unlike using a single vault for all development and testing.

Compared to similar skills

obsidian-multi-env-setup side by side with the closest alternatives in the catalog.

SkillInstallsUpdatedSafetyDifficulty
obsidian-multi-env-setup (this skill)126dReviewIntermediate
twinmind-hello-world126dNo flagsBeginner
granola-local-dev-loop126dReviewIntermediate
obsidian-cli0ReviewIntermediate

Try saying

Example prompts that trigger this skill in your AI assistant.

More by jeremylongshore

View all by jeremylongshore

analyzing-logs

jeremylongshore

Analyze application logs to detect performance issues, identify error patterns, and improve stability by extracting key insights.

14123

ollama-setup

jeremylongshore

Configure auto-configure Ollama when user needs local LLM deployment, free AI alternatives, or wants to eliminate hosted API costs. Trigger phrases: "install ollama", "local AI", "free LLM", "self-hosted AI", "replace OpenAI", "no API costs". Use when appropriate context detected. Trigger with relevant phrases based on skill purpose.

1167

backtesting-trading-strategies

jeremylongshore

Backtest crypto and traditional trading strategies against historical data. Calculates performance metrics (Sharpe, Sortino, max drawdown), generates equity curves, and optimizes strategy parameters. Use when user wants to test a trading strategy, validate signals, or compare approaches. Trigger with phrases like "backtest strategy", "test trading strategy", "historical performance", "simulate trades", "optimize parameters", or "validate signals".

1071

generating-database-seed-data

jeremylongshore

Process this skill enables AI assistant to generate realistic test data and database seed scripts for development and testing environments. it uses faker libraries to create realistic data, maintains relational integrity, and allows configurable data volumes. u... Use when working with databases or data models. Trigger with phrases like 'database', 'query', or 'schema'.

1033

cursor-codebase-indexing

jeremylongshore

Execute set up and optimize Cursor codebase indexing. Triggers on "cursor index setup", "codebase indexing", "index codebase", "cursor semantic search". Use when working with cursor codebase indexing functionality. Trigger with phrases like "cursor codebase indexing", "cursor indexing", "cursor".

885

testing-mobile-apps

jeremylongshore

Execute mobile app testing on iOS and Android devices/simulators. Use when performing specialized testing. Trigger with phrases like "test mobile app", "run iOS tests", or "validate Android functionality".

810

You might also like

twinmind-hello-world

jeremylongshore

Create your first TwinMind meeting transcription and AI summary. Use when starting with TwinMind, testing your setup, or learning basic transcription and summary patterns. Trigger with phrases like "twinmind hello world", "first twinmind meeting", "twinmind quick start", "test twinmind transcription".

114

granola-local-dev-loop

jeremylongshore

Integrate Granola meeting notes into your local development workflow. Use when setting up development workflows, accessing notes programmatically, or syncing meeting outcomes with project tools. Trigger with phrases like "granola dev workflow", "granola development", "granola local setup", "granola developer", "granola coding workflow".

12

obsidian-cli

Yash000

Use the Obsidian CLI to read, create, search, and manage vault content, or to develop and debug Obsidian plugins and themes from the command line.

00

notion-knowledge-capture

makenotion

Transforms conversations and discussions into structured documentation pages in Notion. Captures insights, decisions, and knowledge from chat context, formats appropriately, and saves to wikis or databases with proper organization and linking for easy discovery.

10115

apple-reminders

openclaw

Manage Apple Reminders via the `remindctl` CLI on macOS (list, add, edit, complete, delete). Supports lists, date filters, and JSON/plain output.

2593

memory-keeper-proactive-context-maintenance

b4CU-R4U

Automatically detect and maintain memory freshness by monitoring context staleness, significant code changes, task completions, and phase transitions. Proactively suggests and executes memory sync operations with user confirmation. Use when the user says "sync memory", "update context", or when the Skill detects that context is stale (>2 hours), significant changes have occurred (new commits), tasks completed, or major milestones reached. Replaces passive "context is stale" warnings with active maintenance.

694

Search skills

Search the agent skills registry