obsidian-dev-skills 1.1.2 → 1.1.4

package/obsidian-dev/references/agent-dos-donts.md

@@ -12,29 +12,28 @@ Update frequency: Review periodically for AI agent-specific guidance
   - **DO NOT** create a `.ref` subfolder inside the plugins/themes folder - clone the repo directly there
   - Then create symlink in project's `.ref/` folder pointing to the global location
   - For local projects, symlink directly in project's `.ref/` (don't clone to global)
-  - See [ref-instructions.md](ref-instructions.md) for details.
+  - See [ref-instructions.md](../../obsidian-ref/references/ref-instructions.md) for details.
 - Add commands with stable IDs (don't rename once released).
 - Provide defaults and validation in settings.
 - Write idempotent code paths so reload/unload doesn't leak listeners or intervals.
 - Use `this.register*` helpers for everything that needs cleanup.
-- **Always run `pnpm build` after making changes** to catch build errors early. Only check for pnpm installation if the build fails. See [build-workflow.md](build-workflow.md) for details.
-- **Summarize commands**: When user requests "Summarize" or "Summarize for release", follow the workflow in [summarize-commands.md](summarize-commands.md). Always read actual file changes, not just chat history.
-- **Release preparation**: When user asks "is my plugin ready for release?" or similar, use [release-readiness.md](release-readiness.md) checklist. Run automated checks where possible, ask user interactively for items requiring their input (like platform testing).
+- **Always run `pnpm build` after making changes** to catch build errors early. Only check for pnpm installation if the build fails. See [build-workflow.md](../../obsidian-ops/references/build-workflow.md) for details.
+- **Summarize commands**: When user requests "Summarize" or "Summarize for release", follow the workflow in [summarize-commands.md](../../obsidian-ops/references/summarize-commands.md). Always read actual file changes, not just chat history.
+- **Release preparation**: When user asks "is my plugin ready for release?" or similar, use [release-readiness.md](../../obsidian-ops/references/release-readiness.md) checklist. Run automated checks where possible, ask user interactively for items requiring their input (like platform testing).
 
 ## Don't
 - Introduce network calls without an obvious user-facing reason and documentation.
 - Ship features that require cloud services without clear disclosure and explicit opt-in.
 - Store or transmit vault contents unless essential and consented.
-- **File structure**: Never have `main.ts` in both root AND `src/` - this causes build confusion. For simple plugins, `main.ts` in root is acceptable. For plugins with multiple files, place `main.ts` in `src/` (recommended). See [file-conventions.md](file-conventions.md) and [common-pitfalls.md](common-pitfalls.md#maints-file-location).
+- **File structure**: Never have `main.ts` in both root AND `src/` - this causes build confusion. For simple plugins, `main.ts` in root is acceptable. For plugins with multiple files, place `main.ts` in `src/` (recommended). See [file-conventions.md](../../obsidian-ref/references/file-conventions.md) for standard structure and common pitfalls.
 - **Git operations**: Never automatically commit, push, or perform any git operations. All git operations must be left to the user.
-- **Git updates**: When checking for updates to repos in `.ref`, you can use read-only commands like `git fetch` and `git log` to check what's new, but **never automatically pull** - always ask the user first. See [ref-instructions.md](ref-instructions.md) for how to check for updates.
+- **Git updates**: When checking for updates to repos in `.ref`, you can use read-only commands like `git fetch` and `git log` to check what's new, but **never automatically pull** - always ask the user first. See [ref-instructions.md](../../obsidian-ref/references/ref-instructions.md) for how to check for updates.
 
 ## Fixing Linting Errors
 
 **DO**:
 - Read the error message carefully - note the exact line and column
 - Understand what the error is actually complaining about
-- Check the [linting-fixes-guide.md](linting-fixes-guide.md) for the specific error type
 - Fix the root cause, not the symptom
 - Test with `pnpm lint` after each fix
 - Verify `pnpm build` still works
@@ -49,9 +48,8 @@ Update frequency: Review periodically for AI agent-specific guidance
 
 **When Stuck**:
 1. Read the error message - what line/column is it complaining about?
-2. Check [linting-fixes-guide.md](linting-fixes-guide.md) for that specific error type
-3. Understand the type signature - what does the function expect?
-4. Fix the actual type mismatch, not just suppress the warning
-5. If you've tried the same thing 3 times, stop and re-read the error message
+2. Understand the type signature - what does the function expect?
+3. Fix the actual type mismatch, not just suppress the warning
+4. If you've tried the same thing 3 times, stop and re-read the error message
 
 

package/obsidian-dev/references/code-patterns.md

@@ -130,119 +130,16 @@ class MySettingTab extends PluginSettingTab {
 this.addSettingTab(new MySettingTab(this.app, this));
 ```
 
-## Settings with Groups (Conditional / Backward Compatible)
+## Settings with Groups
 
 **Source**: Based on `.ref/obsidian-api/obsidian.d.ts` (API is authoritative) - `SettingGroup` requires API 1.11.0+
 
-**Use this when**: You want to use `SettingGroup` for users on Obsidian 1.11.0+ while still supporting older versions. This provides conditional settings groups that automatically use the modern API when available, with a fallback for older versions.
+**Use this when**: You want to visually group related settings together.
 
-**Note**: Use the backward compatibility approach below to support both users on Obsidian 1.11.0+ and users on older versions. Alternatively, you can choose to:
-- Continue using the compatibility utility (supports all versions)
-- Force `minAppVersion: "1.11.0"` in `manifest.json` and use `SettingGroup` directly (simpler, but excludes older versions)
-
-### Step 1: Create the Compatibility Utility
-
-Create `src/utils/settings-compat.ts` (or wherever you keep utilities):
-
-```ts
-/**
- * Compatibility utilities for settings
- * Provides backward compatibility for SettingGroup (requires API 1.11.0+)
- */
-import { Setting, requireApiVersion } from 'obsidian';
-
-/**
- * Type definition for SettingGroup constructor
- * Note: SettingGroup may exist at runtime in 1.11.0+ but may not be in TypeScript definitions
- * 
- * IMPORTANT: This type signature is inferred from usage patterns. When .ref/obsidian-api/obsidian.d.ts
- * is available, verify the actual signature there. The signature shown here matches the expected
- * behavior based on Obsidian's API design patterns.
- */
-type SettingGroupConstructor = new (containerEl: HTMLElement) => {
-  setHeading(heading: string): {
-    addSetting(cb: (setting: Setting) => void): void;
-  };
-};
-
-/**
- * Interface that works with both SettingGroup and fallback container
- */
-export interface SettingsContainer {
-  addSetting(cb: (setting: Setting) => void): void;
-}
-
-/**
- * Creates a settings container that uses SettingGroup if available (API 1.11.0+),
- * otherwise falls back to creating a heading and using the container directly.
- * 
- * Uses requireApiVersion('1.11.0') to check if SettingGroup is available.
- * This is the official Obsidian API method for version checking.
- * 
- * IMPORTANT: We use dynamic require() instead of direct import because SettingGroup
- * may not be in TypeScript type definitions even if it exists at runtime in 1.11.0+.
- * This avoids compile-time TypeScript errors while still working at runtime.
- * 
- * @param containerEl - The container element for settings
- * @param heading - The heading text for the settings group (optional)
- * @param manifestId - The plugin's manifest ID for CSS scoping (required for fallback mode)
- * @returns A container that can be used to add settings
- */
-export function createSettingsGroup(
-  containerEl: HTMLElement,
-  heading?: string,
-  manifestId?: string
-): SettingsContainer {
-  // Check if SettingGroup is available (API 1.11.0+)
-  // requireApiVersion is the official Obsidian API method for version checking
-  if (requireApiVersion('1.11.0')) {
-    // Use dynamic require() to access SettingGroup at runtime
-    // This avoids TypeScript errors when SettingGroup isn't in type definitions
-    // eslint-disable-next-line @typescript-eslint/no-require-imports
-    const obsidian = require('obsidian');
-    const SettingGroup = obsidian.SettingGroup as SettingGroupConstructor;
-    
-    // Use SettingGroup - it's guaranteed to exist if requireApiVersion returns true
-    const group = heading 
-      ? new SettingGroup(containerEl).setHeading(heading)
-      : new SettingGroup(containerEl);
-    return {
-      addSetting(cb: (setting: Setting) => void) {
-        group.addSetting(cb);
-      }
-    };
-  } else {
-    // Fallback path (either API < 1.11.0 or SettingGroup not found)
-    // Add scoping class to containerEl to scope CSS to only this plugin's settings
-    if (manifestId) {
-      containerEl.addClass(`${manifestId}-settings-compat`);
-    }
-    
-    // Fallback: Create a heading manually and use container directly
-    if (heading) {
-      const headingEl = containerEl.createDiv('setting-group-heading');
-      headingEl.createEl('h3', { text: heading });
-    }
-        
-    return {
-      addSetting(cb: (setting: Setting) => void) {
-        const setting = new Setting(containerEl);
-        cb(setting);
-      }
-    };
-  }
-}
-```
-
-**Note**: The dynamic `require()` approach is necessary because `SettingGroup` may not be in TypeScript type definitions even if it exists at runtime in Obsidian 1.11.0+. This avoids compile-time TypeScript errors while maintaining runtime compatibility.
-
-### Step 2: Use in Settings Tab
-
-Update your settings tab to use the compatibility utility:
+**Important**: You must set `minAppVersion: "1.11.0"` in your `manifest.json` to use `SettingGroup`.
 
 ```ts
-import { App, PluginSettingTab, Setting } from "obsidian";
-import { createSettingsGroup } from "./utils/settings-compat";
+import { App, PluginSettingTab, Setting, SettingGroup } from "obsidian";
 
 interface MyPluginSettings {
   generalEnabled: boolean;
@@ -271,7 +168,7 @@ class MySettingTab extends PluginSettingTab {
     containerEl.empty();
 
     // General Settings Group
-    const generalGroup = createSettingsGroup(containerEl, "General Settings", "my-plugin");
+    const generalGroup = new SettingGroup(containerEl).setHeading("General Settings");
     
     generalGroup.addSetting((setting) => {
       setting
@@ -304,7 +201,7 @@ class MySettingTab extends PluginSettingTab {
     });
 
     // Advanced Settings Group
-    const advancedGroup = createSettingsGroup(containerEl, "Advanced Settings", "my-plugin");
+    const advancedGroup = new SettingGroup(containerEl).setHeading("Advanced Settings");
     
     advancedGroup.addSetting((setting) => {
       setting
@@ -343,69 +240,9 @@ class MySettingTab extends PluginSettingTab {
 this.addSettingTab(new MySettingTab(this.app, this));
 ```
 
-### Step 3: Add CSS Styling (Required for Older Obsidian Builds)
-
-**Important**: When using the compatibility utility for older Obsidian builds (< 1.11.0), you must add CSS to prevent double divider lines. The fallback creates a heading with class `setting-group-heading`, and without proper CSS, you'll see a double divider (one from the heading's border-bottom and one from the first setting-item's border-top).
-
-**CRITICAL**: The CSS **MUST** be scoped to your plugin's settings container using a manifest-ID-based class to avoid affecting other plugins' settings. Global CSS selectors will impact all settings in Obsidian, not just your plugin's settings.
-
-Add this CSS to your `styles.css` file, replacing `{manifest-id}` with your plugin's manifest ID:
-
-```css
-/* Group settings compatibility styling for older Obsidian builds (< 1.11.0) */
-/* Scoped to only this plugin's settings container to avoid affecting other plugins */
-.{manifest-id}-settings-compat .setting-group-heading h3 {
-    margin: 0 0 0.75rem;
-    padding-bottom: 0.5rem;
-    padding-top: 0.5rem;
-    font-size: 1rem;
-    font-weight: 600;
-    border-bottom: none !important;
-}
-```
-
-**Example**: If your manifest ID is `sample-plugin`, use `.sample-plugin-settings-compat` as the scoping class.
-
-**How it works**:
-- The CSS uses the `:has()` selector to detect if a `.setting-item` immediately follows the heading
-- If settings exist below the heading, no border-bottom is applied (avoiding double divider)
-- If no settings follow, border-bottom is applied for visual separation
-- The scoping class (`{manifest-id}-settings-compat`) ensures CSS only affects headings within this plugin's settings container
-- This only affects older builds (< 1.11.0) where the compatibility fallback is used
-- On Obsidian 1.11.0+, `SettingGroup` handles styling automatically, so this CSS has no effect
-
-**Note**: The `:has()` selector is well-supported in modern Obsidian (Chromium-based). If you need to support very old browsers, see the alternative TypeScript-based approach in the Common Pitfalls section below.
-
-### How It Works
-
-- **On Obsidian 1.11.0+**: Uses `SettingGroup` with proper styling and grouping
-- **On older versions**: Creates a manual heading (`<h3>`) and uses regular `Setting` objects
-- **Same API**: Your code using `addSetting()` works identically in both cases
-
 ### Common Pitfalls
 
-#### Pitfall 1: TypeScript Errors with SettingGroup Import
-
-**Problem**: You may see this TypeScript error:
-```ts
-Module '"obsidian"' has no exported member 'SettingGroup'
-```
-
-**Cause**: `SettingGroup` may exist at runtime in Obsidian 1.11.0+ but may not be in the TypeScript type definitions, causing compile-time errors.
-
-**Solution**: Use dynamic `require()` instead of direct import, as shown in the compatibility utility above. Do not import `SettingGroup` directly:
-
-```ts
-// ❌ WRONG - Causes TypeScript errors
-import { SettingGroup } from 'obsidian';
-
-// ✅ CORRECT - Use dynamic require()
-// eslint-disable-next-line @typescript-eslint/no-require-imports
-const obsidian = require('obsidian');
-const SettingGroup = obsidian.SettingGroup as SettingGroupConstructor;
-```
-
-#### Pitfall 2: Missing Closing Parentheses
+#### Pitfall 1: Missing Closing Parentheses
 
 **Problem**: Arrow functions with method chaining need proper closing parentheses and semicolons.
 
@@ -431,7 +268,7 @@ generalGroup.addSetting((setting) =>
 ); // Closing parenthesis and semicolon required
 ```
 
-#### Pitfall 3: Storing Setting References
+#### Pitfall 2: Storing Setting References
 
 **Problem**: If you need to reference a `Setting` object later (e.g., for visibility toggling), you must use block syntax `{ }` instead of expression syntax.
 
@@ -460,27 +297,6 @@ generalGroup.addSetting((setting) => {
 mySetting.settingEl.style.display = this.plugin.settings.enabled ? "" : "none";
 ```
 
-### Alternative: Force Minimum Version
-
-If you don't need to support versions before 1.11.0, you can skip the compatibility utility:
-
-1. Set `minAppVersion: "1.11.0"` in your `manifest.json`
-2. Use `SettingGroup` directly:
-
-```ts
-import { Setting, SettingGroup } from "obsidian";
-
-// In settings tab:
-const group = new SettingGroup(containerEl).setHeading("My Settings");
-group.addSetting((setting) => {
-  // ... configure setting
-});
-```
-
-**Note**: Even with `minAppVersion: "1.11.0"`, you may still encounter TypeScript errors if `SettingGroup` isn't in the type definitions. In that case, you can still use the compatibility utility approach (it will always use `SettingGroup` when `requireApiVersion('1.11.0')` returns true), or use dynamic `require()` as shown in the compatibility utility.
-
-This approach is simpler but excludes users on older Obsidian versions. The compatibility utility still works and is recommended for maximum flexibility.
-
 ## Modal with Form Input
 
 **Source**: Based on `.ref/obsidian-plugin-docs/docs/guides/modals.md`

package/obsidian-dev/references/commands-settings.md

@@ -16,9 +16,6 @@ Applicability: Plugin
 
 ## Version Considerations
 
-When using newer API features (e.g., `SettingGroup` since API 1.11.0), consider backward compatibility:
-- **For new plugins**: You can set `minAppVersion: "1.11.0"` in `manifest.json` and use the feature directly
-- **For existing plugins**: Use version checking with `requireApiVersion()` to support both newer and older Obsidian versions
-- See [code-patterns.md](code-patterns.md) for backward compatibility patterns, including a complete example for `SettingGroup`
+When using newer API features (e.g., `SettingGroup` since API 1.11.0), you must set `minAppVersion: "1.11.0"` in your `manifest.json`.
 
 

package/obsidian-dev/references/common-tasks.md

@@ -12,7 +12,7 @@ Update frequency: Check Obsidian Sample Plugin repo for updates
 - **common-tasks.md**: Quick snippets and basic patterns for common operations
 - **code-patterns.md**: Complete, production-ready examples with full context and error handling
 
-> **Note**: If user asks "what does the Obsidian API say about X?" or similar, check `.ref/obsidian-api/obsidian.d.ts` first. See [ref-instructions.md](ref-instructions.md) for when to check `.ref` setup.
+> **Note**: If user asks "what does the Obsidian API say about X?" or similar, check `.ref/obsidian-api/obsidian.d.ts` first. See [ref-instructions.md](../../obsidian-ref/references/ref-instructions.md) for when to check `.ref` setup.
 
 ## Organize code across multiple files
 
@@ -137,7 +137,7 @@ this.addSettingTab(new MySettingTab(this.app, this));
 - `addSearch(cb: (component: SearchComponent) => any)` - Add a search input at the beginning of the group (useful for filtering)
 - `addExtraButton(cb: (component: ExtraButtonComponent) => any)` - Add an extra button to the group
 
-**Backward Compatibility**: To support users on both Obsidian 1.11.0+ and older versions, use a compatibility utility. See [code-patterns.md](code-patterns.md) for the complete implementation with `createSettingsGroup()` utility. Alternatively, you can force `minAppVersion: "1.11.0"` in `manifest.json` if you don't need to support older versions.
+**Important**: You must set `minAppVersion: "1.11.0"` in your `manifest.json` to use these methods.
 
 ## Secret Storage
 
@@ -221,7 +221,7 @@ const value = this.app.secretStorage.getSecret("my-api-key");
 
 **Important**: Secret IDs must be lowercase alphanumeric with optional dashes (e.g., `my-plugin-api-key`). Invalid IDs will throw an error.
 
-See [security-privacy.md](security-privacy.md) for security best practices and [code-patterns.md](code-patterns.md) for comprehensive examples with error handling.
+See [security-privacy.md](../../obsidian-ops/references/security-privacy.md) for security best practices and [code-patterns.md](code-patterns.md) for comprehensive examples with error handling.
 
 ## Modal Patterns
 

package/obsidian-ops/references/quick-reference.md

@@ -34,7 +34,7 @@ One-page cheat sheet for common Obsidian theme development tasks.
 - `add ref ../my-local-plugin` → Creates symlink to local project
 - `check API [feature]` → Searches obsidian.d.ts for feature (for theme CSS variables, etc.)
 
-**Note**: These commands are interpreted by AI agents and execute the corresponding workflows automatically. See detailed documentation in [AGENTS.md](../../AGENTS.md) for full workflows.
+**Note**: These commands are interpreted by AI agents and execute the corresponding workflows automatically.
 
 ## Build Commands
 
@@ -165,5 +165,5 @@ package.json
 Gruntfile.js       # Build configuration (if using Grunt)
 ```
 
-See [file-conventions.md](file-conventions.md) for details.
+See [file-conventions.md](../../obsidian-ref/references/file-conventions.md) for details.
 

package/obsidian-ops/references/release-readiness.md

@@ -202,9 +202,9 @@ When user asks "is my theme ready for release?" or similar:
 
 - [versioning-releases.md](versioning-releases.md) - Release process and versioning
 - [security-privacy.md](security-privacy.md) - Security and privacy guidelines
-- [manifest.md](manifest.md) - Manifest requirements and validation
+- [manifest.md](../../obsidian-ref/references/manifest.md) - Manifest requirements and validation
 - [testing.md](testing.md) - Testing procedures and platform testing
-- [ux-copy.md](ux-copy.md) - UI text conventions (for theme names and descriptions)
+- [ux-copy.md](../../obsidian-ref/references/ux-copy.md) - UI text conventions (for theme names and descriptions)
 - [build-workflow.md](build-workflow.md) - Build commands (if using build tools)
 - [performance.md](performance.md) - Performance optimization best practices
 

package/obsidian-ops/references/security-privacy.md

@@ -54,7 +54,7 @@ Themes are CSS-only and have minimal security surface area, but still follow pri
 ## Related Documentation
 
 - [release-readiness.md](release-readiness.md) - Comprehensive release checklist including policy adherence
-- [manifest.md](manifest.md) - Manifest requirements (includes security-related fields)
+- [manifest.md](../../obsidian-ref/references/manifest.md) - Manifest requirements (includes security-related fields)
 - [Developer Policies](https://docs.obsidian.md/Developer+policies) - Official Obsidian Developer Policies
 - [Theme Guidelines](https://docs.obsidian.md/Themes/Releasing/Theme+guidelines) - Official Theme Guidelines
 

package/obsidian-ops/references/sync-procedure.md

@@ -1,13 +1,13 @@
 <!--
 Source: Project-specific procedure
-Last synced: See sync-status.json for authoritative sync dates
+Last synced: 2026-02-08
 Update frequency: Update as sync process evolves
 Applicability: Both
 -->
 
 # Sync Procedure: Keeping .agents Up to Date
 
-**Sync Tracking**: All sync dates are tracked centrally in [sync-status.json](sync-status.json). Always update this file with the actual current date when syncing (use `Get-Date -Format "yyyy-MM-dd"` to get the date - never use placeholder dates).
+**Sync Tracking**: Keep track of sync dates manually in the documentation file headers to ensure traceability.
 
 This document outlines the standard procedure for keeping the `.agents` directory content synchronized with the latest updates from the 6 core Obsidian repositories:
 - [Obsidian API](https://github.com/obsidianmd/obsidian-api) - Official API documentation and type definitions
@@ -19,7 +19,7 @@ This document outlines the standard procedure for keeping the `.agents` director
 
 ## Prerequisites
 
-1. **Set up reference repositories** (see [ref-instructions.md](ref-instructions.md)):
+1. **Set up reference repositories** (see [ref-instructions.md](../../obsidian-ref/references/ref-instructions.md)):
    - The 6 core Obsidian projects should be available in `.ref/` (either as symlinks to a central location or as local clones):
      - `obsidian-api/` - API documentation
      - `obsidian-sample-plugin/` - Sample plugin template
@@ -284,7 +284,7 @@ For each file that needs updating:
    
    **Important**: Always use the actual current date from `Get-Date -Format "yyyy-MM-dd"`, never use placeholder dates.
 
-4. **Note**: Individual file headers still have "Last synced" dates, but the authoritative source is `.agent/sync-status.json`. When syncing, update the central file rather than individual file headers.
+4. **Note**: Individual file headers have "Last synced" dates. When syncing, update these dates to reflect the actual sync time.
 
 ### Step 6: Verify and Test
 
@@ -309,7 +309,7 @@ For each file that needs updating:
 - [ ] Review developer docs for policy/guideline updates
 - [ ] Review plugin docs for best practices
 - [ ] Update relevant `.agent/skills/**/*.md` files
-- [ ] **Update `.agent/sync-status.json` with actual current date** (use `Get-Date -Format "yyyy-MM-dd"` - never use placeholder dates)
+- [ ] **Update sync dates** in file headers
 - [ ] Review and commit changes
 
 ## Troubleshooting
@@ -354,39 +354,25 @@ ls -la .ref/obsidian-api
 - **When starting new features**: Verify current best practices
 - **Before releases**: Ensure guidelines are current
 
-## Automation Ideas (Future)
 
-Consider creating a script to:
-- Automatically check for updates in reference repos
-- Compare `AGENTS.md` from sample plugin with current `.agents` structure
-- Generate a diff report of what changed
-- Remind to update "Last synced" dates
 
 ## Updating Sync Status
 
-After completing a sync, update `.agent/sync-status.json`:
-
-**Easy way** (recommended): Use the helper script:
-```bash
-node scripts/update-sync-status.mjs "Description of what was synced"
-```
+After completing a sync, update the "Last synced" dates in the documentation file headers.
 
 **Manual way**: Edit the file directly:
 ```powershell
 # Get actual current date (CRITICAL: never use placeholder!)
 $syncDate = Get-Date -Format "yyyy-MM-dd"
 
-# Update sync-status.json with:
-# - "lastFullSync": "$syncDate"
-# - "lastSyncSource": "Description of what was synced"
-# - Update relevant dates in "sourceRepos" section for repos that were checked/synced
+# Update the file header with the actual sync date
 ```
 
-**Critical**: Always use the actual date from `Get-Date -Format "yyyy-MM-dd"`. Never use placeholder dates like "YYYY-MM-DD" or hardcoded dates. The sync-status.json file is the authoritative source for all sync dates.
+**Critical**: Always use the actual date from `Get-Date -Format "yyyy-MM-dd"`. Never use placeholder dates like "YYYY-MM-DD" or hardcoded dates.
 
 ## Notes
 
 - Not all changes need to be synced immediately - focus on breaking changes and new best practices
 - Some content may be project-specific and shouldn't be overwritten
 - Always review changes before committing to ensure they make sense for your project
-- **Always update sync-status.json with the actual current date** - this is the authoritative source for sync dates
+- **Always update sync dates** to reflect when the information was last verified

package/obsidian-ref/references/file-conventions.md

@@ -44,7 +44,7 @@ package.json
 
 - Source files in `src/scss/` are compiled to `theme.css`
 - Build tools (Grunt, npm scripts, etc.) handle compilation
-- Run build command after making changes (see [build-workflow.md](build-workflow.md))
+- Run build command after making changes (see [build-workflow.md](../../obsidian-ops/references/build-workflow.md))
 - **Example**: The `obsidian-oxygen` theme uses this pattern with Grunt
 
 ## Wrong Structure (Common Mistakes)

package/obsidian-ref/references/ref-instructions.md

@@ -102,7 +102,7 @@ If you cannot find `.ref` initially, try:
 3. **Report findings**:
    - If updates are available, show what changed (use `git log` or `git diff`)
    - Ask if the user wants to pull the updates
-   - **Never automatically pull** - always ask first (see [agent-dos-donts.md](agent-dos-donts.md))
+   - **Never automatically pull** - always ask first (see [agent-dos-donts.md](../../obsidian-dev/references/agent-dos-donts.md))
 
 4. **If repo not found**:
    - List what's available in `.ref/plugins/` or `.ref/themes/`
@@ -264,7 +264,7 @@ ln -s ../../.ref/obsidian-dev/plugins/plugin-name .ref/plugins/plugin-name
 ln -s ../../.ref/obsidian-dev/themes/theme-name .ref/themes/theme-name
 ```
 
-**Note**: See [sync-procedure.md](sync-procedure.md) for the standard procedure to keep `.agents` content synchronized with updates from these repositories.
+**Note**: See [sync-procedure.md](../../obsidian-ops/references/sync-procedure.md) for the standard procedure to keep `.agents` content synchronized with updates from these repositories.
 
 ## Adding Additional References
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "obsidian-dev-skills",
-  "version": "1.1.2",
+  "version": "1.1.4",
   "description": "Agent skills for Obsidian plugin and theme development",
   "keywords": [
     "obsidian",

package/scripts/bulk-update.mjs

@@ -0,0 +1,40 @@
+import { execSync } from 'child_process';
+import path from 'path';
+import { fileURLToPath } from 'url';
+
+const __filename = fileURLToPath(import.meta.url);
+const __dirname = path.dirname(__filename);
+const initScript = path.join(__dirname, 'init.mjs');
+
+const projects = [
+    "C:\\Users\\david\\Development\\obsidian-alias-filename-history",
+    "C:\\Users\\david\\Development\\obsidian-astro-composer",
+    "C:\\Users\\david\\Development\\obsidian-astro-modular-settings",
+    "C:\\Users\\david\\Development\\obsidian-bases-cms",
+    "C:\\Users\\david\\Development\\obsidian-custom-slides",
+    "C:\\Users\\david\\Development\\obsidian-disable-tabs",
+    "C:\\Users\\david\\Development\\obsidian-explorer-focus",
+    "C:\\Users\\david\\Development\\obsidian-home-base",
+    "C:\\Users\\david\\Development\\obsidian-image-manager",
+    "C:\\Users\\david\\Development\\obsidian-oxygen-settings",
+    "C:\\Users\\david\\Development\\obsidian-periodic-links",
+    "C:\\Users\\david\\Development\\obsidian-property-over-file-name",
+    "C:\\Users\\david\\Development\\obsidian-seo",
+    "C:\\Users\\david\\Development\\obsidian-ui-tweaker",
+    "C:\\Users\\david\\Development\\obsidian-vault-cms",
+    "C:\\Users\\david\\Development\\obsidian-zenmode"
+];
+
+for (const project of projects) {
+    console.log(`\n🔄 Updating skills for: ${path.basename(project)}`);
+    try {
+        execSync(`node "${initScript}"`, {
+            cwd: project,
+            stdio: 'inherit',
+            env: { ...process.env, INIT_CWD: project }
+        });
+        console.log(`✅ Success: ${path.basename(project)}`);
+    } catch (error) {
+        console.error(`❌ Failed: ${path.basename(project)} - ${error.message}`);
+    }
+}

package/scripts/check-status.mjs

@@ -0,0 +1,45 @@
+import fs from 'fs';
+import path from 'path';
+
+const projects = [
+    "C:\\Users\\david\\Development\\obsidian-alias-filename-history",
+    "C:\\Users\\david\\Development\\obsidian-astro-composer",
+    "C:\\Users\\david\\Development\\obsidian-astro-modular-settings",
+    "C:\\Users\\david\\Development\\obsidian-bases-cms",
+    "C:\\Users\\david\\Development\\obsidian-custom-slides",
+    "C:\\Users\\david\\Development\\obsidian-disable-tabs",
+    "C:\\Users\\david\\Development\\obsidian-explorer-focus",
+    "C:\\Users\\david\\Development\\obsidian-home-base",
+    "C:\\Users\\david\\Development\\obsidian-image-manager",
+    "C:\\Users\\david\\Development\\obsidian-oxygen-settings",
+    "C:\\Users\\david\\Development\\obsidian-periodic-links",
+    "C:\\Users\\david\\Development\\obsidian-property-over-file-name",
+    "C:\\Users\\david\\Development\\obsidian-seo",
+    "C:\\Users\\david\\Development\\obsidian-ui-tweaker",
+    "C:\\Users\\david\\Development\\obsidian-vault-cms",
+    "C:\\Users\\david\\Development\\obsidian-zenmode"
+];
+
+console.log('| Project | Status | Last Sync | Source |');
+console.log('| --- | --- | --- | --- |');
+
+for (const project of projects) {
+    const name = path.basename(project);
+    let agentDir = path.join(project, '.agent');
+    if (!fs.existsSync(agentDir) && fs.existsSync(path.join(project, '.agents'))) {
+        agentDir = path.join(project, '.agents');
+    }
+
+    const syncStatusPath = path.join(agentDir, 'sync-status.json');
+
+    if (fs.existsSync(syncStatusPath)) {
+        try {
+            const status = JSON.parse(fs.readFileSync(syncStatusPath, 'utf8'));
+            console.log(`| ${name} | ✅ Found | ${status.lastFullSync || 'Unknown'} | ${status.lastSyncSource || 'Unknown'} |`);
+        } catch (e) {
+            console.log(`| ${name} | ⚠️ Parse Error | - | - |`);
+        }
+    } else {
+        console.log(`| ${name} | ❌ Missing | - | - |`);
+    }
+}