obsidian-dev-skills 1.1.3 → 1.2.0

package/README.md

@@ -49,6 +49,7 @@ node node_modules/obsidian-dev-skills/scripts/init.mjs
 - Obsidian API usage
 - Plugin lifecycle management
 - Command and settings implementation
+- `obsidianmd` ESLint rule patterns (`createDiv`/`createSpan`, `activeWindow`, `activeDocument`, sentence case)
 
 ### obsidian-theme-dev
 - CSS/SCSS development patterns
@@ -61,6 +62,9 @@ node node_modules/obsidian-dev-skills/scripts/init.mjs
 - Version management
 - Sync procedures
 - Testing and quality assurance
+- Obsidian community **scorecard compliance** mapping (vulnerable transitive dep handling via `pnpm.overrides`, duplicate CSS selector detection, ESLint rule violations)
+- Release workflow with **build provenance attestation** (`actions/attest-build-provenance@v2`)
+- Portable **`CONTRIBUTING.md` template** for the scorecard hygiene check
 
 ### obsidian-ref
 - API documentation
@@ -80,7 +84,10 @@ Each project should also have a `project/` skill in `.agent/skills/project/` tha
 
 ### Updating Skills
 
-When skills are updated in this repository, all linked projects automatically get the updates. No manual sync required.
+The update flow depends on how a project consumes this package:
+
+- **npm install (default)**: When this package publishes a new version, downstream projects pick up updates the next time they run `pnpm obsidian-dev-skills` (or the equivalent npx/manual command). The init script re-copies skill files into `.agent/skills/`.
+- **Sibling clone + symlinks (advanced)**: If a project symlinks `.agent/skills/<name>` to a sibling clone of this repository (e.g. via `scripts/setup-local.ps1`), updates appear instantly the moment files change here, with no per-project sync step.
 
 ### Tracking Sync Status
 

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

@@ -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
 

package/obsidian-ops/SKILL.md

@@ -29,7 +29,10 @@ This skill covers:
 
 - `references/build-workflow.md`: Standard build and development commands.
 - `references/release-readiness.md`: Checklist for ensuring a project is ready for release.
+- `references/scorecard-compliance.md`: Map of Obsidian community plugin scorecard signals to concrete fixes (vulnerability overrides, attestation workflow, CSS dedup, obsidianmd rules).
+- `references/contributing-template.md`: Portable CONTRIBUTING.md template for the scorecard hygiene check.
+- `references/security-privacy.md`: Developer policies, mandatory disclosures, and dependency vulnerability hygiene via `pnpm.overrides`.
 - `references/sync-procedure.md`: How to pull updates from reference repositories.
-- `references/versioning-releases.md`: Workflow for versioning and GitHub releases.
+- `references/versioning-releases.md`: Workflow for versioning and GitHub releases, including the build-provenance attestation pattern.
 - `references/troubleshooting.md`: Common issues and their resolutions.
 - `references/quick-reference.md`: One-page cheat sheet for common operations.

package/obsidian-ops/references/contributing-template.md

@@ -0,0 +1,96 @@
+<!--
+Source: Authored for Obsidian plugin scorecard compliance
+Last synced: See sync-status.json for authoritative sync dates
+Update frequency: Update when the standard development setup changes
+Applicability: Plugin
+-->
+
+# CONTRIBUTING.md Template
+
+The Obsidian community scorecard's **Hygiene** check looks for a `CONTRIBUTING.md` at the repo root. The template below is portable across plugin repositories without modification, because it uses relative GitHub links (`../../issues`) and references generic plugin concepts.
+
+## When to drop in unmodified
+
+Use the template as-is when the repo:
+
+- Uses pnpm with the standard `pnpm dev`, `pnpm build`, `pnpm lint`, `pnpm lint:fix` scripts.
+- Builds `main.js`, `styles.css`, and `manifest.json` to the repo root.
+- Is licensed MIT.
+- Uses the house terminology rules (properties, Markdown capitalized).
+
+## When to customize
+
+Change the template only when:
+
+- The plugin uses npm/yarn/bun instead of pnpm (update the install/build commands).
+- The plugin has additional scripts the contributor needs to run (e.g. a separate test command).
+- The license is not MIT (update the License section).
+
+Do not customize the issue link — the relative `../../issues` form resolves correctly on any GitHub repo.
+
+## Template
+
+```markdown
+# Contributing
+
+Thanks for your interest in contributing. This document describes how to report issues, propose changes, and get a local development environment running.
+
+## Reporting issues
+
+- Search [existing issues](../../issues) before opening a new one.
+- For bugs, include: Obsidian version, plugin version, operating system, reproduction steps, and what you expected vs. what happened. Screenshots or a short screen recording help.
+- For feature requests, describe the use case and the problem the feature would solve, not just the proposed solution.
+
+## Development setup
+
+Requirements:
+
+- [Node.js](https://nodejs.org/) (LTS recommended)
+- [pnpm](https://pnpm.io/). This repo pins a specific version via `packageManager` in `package.json`.
+
+`​`​`bash
+pnpm install
+pnpm dev      # watch mode build
+pnpm build    # production build
+pnpm lint     # check code style
+pnpm lint:fix # auto-fix where possible
+`​`​`
+
+Build artifacts (`main.js`, `manifest.json`, `styles.css`) are produced at the repo root.
+
+To test against a real vault, point the build output at `<vault>/.obsidian/plugins/<plugin-id>/` (symlink the three files, or use a tool like [hot-reload](https://github.com/pjeby/hot-reload)).
+
+## Pull requests
+
+- Open an issue first for anything non-trivial so we can agree on direction before you spend time on it.
+- Keep PRs focused. One concern per PR is easier to review.
+- Run `pnpm lint` and `pnpm build` before submitting; CI will run these too.
+- Follow the existing code style. Use **"properties"** (not "frontmatter") when referring to YAML metadata. **"Markdown"** is always capitalized.
+- Update the README if you change user-facing behavior.
+
+## Code style
+
+- TypeScript strict mode, no `any` unless unavoidable.
+- Prefer Obsidian's API (`Vault`, `MetadataCache`, `Workspace`) over Node `fs` for vault access.
+- No network requests from the plugin runtime.
+
+## Releases
+
+Maintainers cut releases by bumping the version in `manifest.json`, `package.json`, and `versions.json`, committing, then tagging and pushing the tag. The release workflow builds and attaches `main.js`, `manifest.json`, and `styles.css` with build provenance attestation.
+
+## License
+
+By contributing, you agree that your contributions will be licensed under the [MIT License](LICENSE).
+```
+
+## Style notes
+
+- The template avoids em dashes (`—`); prefer periods, commas, or parentheses instead.
+- The template avoids the word "Claude" and any reference to AI assistance, since the file is user-facing documentation.
+- Headings use sentence case to match Obsidian UI conventions.
+
+## Related Documentation
+
+- [scorecard-compliance.md](scorecard-compliance.md) — covers every scorecard signal, not just the contributing guide.
+- [release-readiness.md](release-readiness.md) — broader pre-release checklist.
+- [versioning-releases.md](versioning-releases.md) — release workflow setup.

package/obsidian-ops/references/scorecard-compliance.md

@@ -0,0 +1,308 @@
+<!--
+Source: Obsidian community plugin scorecard (community.obsidian.md/plugins/<id>)
+Last synced: See sync-status.json for authoritative sync dates
+Update frequency: Check the Obsidian community portal scorecard format for changes
+Applicability: Plugin
+-->
+
+# Community Plugin Scorecard Compliance
+
+The Obsidian community portal publishes an automated scorecard for every plugin. It scans the latest GitHub release plus the source repository and reports across four health categories (**Hygiene**, **Maintenance**, **Responsiveness**, **Adoption**) and a **Review** section that flags concrete issues from automated scans.
+
+This document maps the scorecard signals to concrete fixes you can apply. Use it when a user asks "why is my score low?" or "help me fix my plugin's scorecard."
+
+## Health Category Fixes
+
+### Hygiene
+
+The portal checks for four files at the repo root.
+
+| Signal                | Fix                                                                                                                                  |
+| --------------------- | ------------------------------------------------------------------------------------------------------------------------------------ |
+| Missing readme        | Add `README.md` describing the plugin's purpose, installation, usage, and screenshots.                                               |
+| Missing license       | Add `LICENSE` (MIT is typical).                                                                                                      |
+| Missing description   | Ensure `manifest.json` has a clear `description` field.                                                                              |
+| Missing contributing  | Add `CONTRIBUTING.md`. See [contributing-template.md](contributing-template.md) for a portable template.                             |
+
+### Maintenance, Responsiveness, Adoption
+
+These reflect commit cadence, issue close rate, install count, and stars. They are not directly fixable by editing files. Steer the user toward consistent maintenance habits rather than a one-shot fix.
+
+## Review Section Fixes
+
+The Review section is where most score improvement happens. Issues are grouped into **Risks**, **Warnings**, **Disclosures**, **Other**, and **Passed**.
+
+### Disclosures (informational, not fixable)
+
+Disclosures are not deductions, they are informational. Common ones for plugins:
+
+- **Vault Enumeration** — uses `vault.getFiles()`, `getMarkdownFiles()`, etc.
+- **Vault Read** — uses `vault.read()` or `vault.cachedRead()`.
+- **Vault Write** — uses `vault.modify()`, `vault.create()`, etc.
+- **Clipboard Access** — reads or writes the system clipboard.
+- **Malware scan not available** / **Vulnerable dependencies scan not available** — scanner-side limitations.
+
+Do not try to remove these. They reflect the plugin's actual API surface and the user should understand them when installing.
+
+### Vulnerable transitive dev dependencies
+
+The scanner reports advisories like:
+
+> Potentially vulnerable dependency `<pkg>` (via `<parent>`). Upgrade to version X or later.
+
+These are almost always **dev-only transitives** pulled in through `eslint`, `eslint-plugin-obsidianmd`, and `@typescript-eslint/*`. They never ship in `main.js`, but the scorecard still counts them.
+
+**Fix**: add a `pnpm.overrides` block to `package.json` that forces patched versions. Major-version-scoped ranges keep API compatibility while bumping the patch:
+
+```json
+{
+  "pnpm": {
+    "overrides": {
+      "minimatch@<3.1.3": "^3.1.3",
+      "minimatch@^4 || ^5 || ^6 || ^7 || ^8": "^8.0.5",
+      "minimatch@^9": "^9.0.6",
+      "picomatch@<2.3.2": "^2.3.2",
+      "picomatch@^3 || ^4": "^4.0.4",
+      "brace-expansion@<1.1.13": "^1.1.13",
+      "brace-expansion@^2": "^2.0.3",
+      "ajv@<6.14.0": "^6.14.0",
+      "ajv@^7 || ^8": "^8.18.0",
+      "flatted@<3.4.0": "^3.4.0",
+      "fast-uri@<3.1.1": "^3.1.1",
+      "yaml@<2.8.3": "^2.8.3"
+    }
+  }
+}
+```
+
+Then run `pnpm install` and `pnpm why <pkg>` to verify the patched version is resolved.
+
+**Why this format**: pnpm override selectors match against resolved versions. The `package@<range>` key form lets you target one major at a time. A bare `package: "version"` would force every consumer to the same major and break anything depending on a different one.
+
+### Missing GitHub artifact attestation
+
+> X release assets are missing a GitHub artifact attestation.
+
+**Fix**: add a release workflow that runs `actions/attest-build-provenance@v2` against the release files. Drop this at `.github/workflows/release.yml`:
+
+```yaml
+name: Release
+
+on:
+  push:
+    tags:
+      - "*"
+
+permissions:
+  contents: write
+  id-token: write
+  attestations: write
+
+jobs:
+  release:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+      - uses: pnpm/action-setup@v4
+      - uses: actions/setup-node@v4
+        with:
+          node-version: "20"
+          cache: "pnpm"
+      - run: pnpm install --frozen-lockfile
+      - run: pnpm build
+      - uses: actions/attest-build-provenance@v2
+        with:
+          subject-path: |
+            main.js
+            styles.css
+            manifest.json
+      - env:
+          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+          TAG: ${{ github.ref_name }}
+        run: |
+          gh release create "$TAG" \
+            --title="$TAG" \
+            --generate-notes \
+            main.js styles.css manifest.json
+```
+
+Then cut releases by pushing a tag (e.g. `git tag 0.1.0 && git push origin 0.1.0`) instead of uploading files manually. The workflow attaches the assets and registers the attestation, which the scorecard checks against the source repo for byte-for-byte reproducibility.
+
+### Duplicate CSS selectors
+
+> Unexpected duplicate selector ".foo .bar", first used at line N.
+
+**Fix**: merge the two rule blocks. If they target the same selector and have non-overlapping properties, combine into one block. If they target the same selector and one is meant to override the other (e.g. inside a media query), wrap the override in a more specific selector or use a CSS variable.
+
+### `obsidianmd` ESLint rules (Warnings and Risks)
+
+`eslint-plugin-obsidianmd` enforces Obsidian-idiomatic patterns. Common signals and fixes:
+
+#### `obsidianmd/ui/sentence-case` (Risk if disabled, Warning if violated)
+
+User-facing strings must follow sentence case. The rule auto-detects most static strings; template literals are sometimes missed but still violate the spirit of the rule.
+
+```ts
+// Wrong
+new Notice('Click Here To Continue');
+this.countEl.setText('0 selected');
+
+// Right
+new Notice('Click here to continue');
+this.countEl.setText('0 Selected');
+```
+
+**Never disable this rule.** The scorecard explicitly flags `eslint-disable-next-line obsidianmd/ui/sentence-case` as a Risk and counts each occurrence. If a string genuinely cannot be sentence case (e.g. it embeds a proper noun or product name), fix the casing instead of disabling.
+
+#### `obsidianmd/prefer-create-el-shorthand` (Warning)
+
+Use `createDiv()` and `createSpan()` instead of `createEl('div')` and `createEl('span')`.
+
+```ts
+// Wrong
+const wrap = containerEl.createEl('div', { cls: 'my-wrap' });
+const label = wrap.createEl('span', { text: 'Hello' });
+
+// Right
+const wrap = containerEl.createDiv({ cls: 'my-wrap' });
+const label = wrap.createSpan({ text: 'Hello' });
+```
+
+#### `obsidianmd/prefer-active-doc` (Warning)
+
+Use `activeDocument` instead of `document` and `activeWindow.setTimeout/setInterval/clearTimeout/clearInterval` instead of the globals. This ensures behavior in Obsidian popout windows.
+
+```ts
+// Wrong
+this.registerDomEvent(document, 'click', handler);
+setTimeout(refresh, 500);
+clearInterval(this.intervalId);
+
+// Right
+this.registerDomEvent(activeDocument, 'click', handler);
+activeWindow.setTimeout(refresh, 500);
+activeWindow.clearInterval(this.intervalId);
+```
+
+#### `obsidianmd/no-eslint-disable-without-description` (Risk)
+
+> Unexpected undescribed directive comment. Include descriptions to explain why the comment is necessary.
+
+Every `eslint-disable*` comment must end with `--` and a reason.
+
+```ts
+// Wrong
+// eslint-disable-next-line @typescript-eslint/no-explicit-any
+
+// Right
+// eslint-disable-next-line @typescript-eslint/no-explicit-any -- third-party type is loose
+```
+
+This is the most common Risk-tier finding for plugins that accumulated `eslint-disable` comments before adopting the rule. Audit every existing disable comment and either add a reason or refactor the code to avoid the disable.
+
+#### `@typescript-eslint/no-unused-vars` (Warning)
+
+> 'foo' is defined but never used. Allowed unused args must match /^_/u.
+
+**Fix**: prefix unused parameters with `_` (e.g. `_file`, `_index`, `_settings`). For destructured properties you don't need, remove them.
+
+#### `@typescript-eslint/no-explicit-any` (Warning)
+
+> Unexpected `any`. Specify a different type.
+
+**Fix**: replace `any` with `unknown` and narrow at the use site, or with a proper type. If the API is genuinely typed loosely (e.g. `JSON.parse`), use `unknown` and validate. Reserve `any` only for cases where even `unknown` is infeasible and document with an inline disable that has a description.
+
+#### `@typescript-eslint/no-unnecessary-type-assertion` (Error after upgrading typescript-eslint)
+
+> This assertion is unnecessary since it does not change the type of the expression.
+
+**Fix**: run `pnpm lint:fix`. The autofix removes the redundant assertion.
+
+#### `@typescript-eslint/no-misused-promises` (Warning)
+
+> Promise returned in function argument where a void return was expected.
+
+**Fix**: explicitly `void` or `.catch()` the promise:
+
+```ts
+// Wrong
+button.onclick = async () => { await doThing(); };
+
+// Right (fire-and-forget)
+button.onclick = () => { void doThing(); };
+
+// Better (handle errors)
+button.onclick = () => { doThing().catch(console.error); };
+```
+
+#### `@typescript-eslint/no-floating-promises` (Warning)
+
+> Promises must be awaited, end with a call to .catch, or be explicitly marked as ignored with the `void` operator.
+
+Same fix as above.
+
+### `Plugin name should not be in all caps` (manifest.json)
+
+Lowercase the `name` field in `manifest.json`. Title case is fine; all caps is not.
+
+```json
+// Wrong
+"name": "SEO"
+
+// Right
+"name": "SEO Checker"   // proper noun is OK
+"name": "Search engine optimization"
+```
+
+## ESLint Config Pattern for the Type-Aware Rules
+
+When you bump `eslint-plugin-obsidianmd` to a version that adds type-aware rules (0.3.0+), the rules will fail on non-TypeScript files because there is no `parserOptions.project` for them. Scope the recommended config to TS only:
+
+```js
+import obsidianmd from "eslint-plugin-obsidianmd";
+
+export default defineConfig([
+  { ignores: ["main.js", "node_modules/**", "*.js", "scripts/**"] },
+  // Only run obsidianmd recommended rules on TypeScript files
+  ...obsidianmd.configs.recommended.map((config) => ({
+    ...config,
+    files: config.files ?? ["**/*.ts"],
+  })),
+  {
+    files: ["**/*.ts"],
+    languageOptions: {
+      parser: tsparser,
+      parserOptions: { project: "./tsconfig.json", sourceType: "module" },
+      // ...
+    },
+  },
+]);
+```
+
+## Verification Workflow
+
+After applying fixes:
+
+1. `pnpm install` to refresh the lockfile.
+2. `pnpm why <vulnerable-pkg>` for each advisory to confirm the patched version is resolved everywhere.
+3. `pnpm build` to confirm the production build still works.
+4. `pnpm lint` to confirm no new errors.
+5. Bump `version` in `manifest.json`, `package.json`, and `versions.json`.
+6. Commit, then tag and push the tag. The release workflow handles the rest.
+7. Wait for the scorecard to refresh (usually within an hour of the release).
+
+## What the Scorecard Doesn't Penalize
+
+- Plugin runtime API surface (vault read/write, clipboard, network) — these become **Disclosures** and inform the user, not deductions.
+- Obsidian API breadth — using lots of API is fine and expected.
+- Plugin file count or repo size.
+- The plugin's actual functionality or popularity (Maintenance and Adoption are reported separately and do not require code changes).
+
+## Related Documentation
+
+- [contributing-template.md](contributing-template.md) — canonical CONTRIBUTING.md text.
+- [versioning-releases.md](versioning-releases.md) — release workflow setup.
+- [security-privacy.md](security-privacy.md) — dependency vulnerability handling.
+- [release-readiness.md](release-readiness.md) — broader pre-release checklist.
+- [code-patterns.md](../../obsidian-dev/references/code-patterns.md) — idiomatic API usage that satisfies obsidianmd rules.
+- [ux-copy.md](../../obsidian-ref/references/ux-copy.md) — sentence case and other UI text rules.

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

@@ -51,9 +51,43 @@ If your theme requires any of the following, you **must** disclose it clearly in
 
 Themes are CSS-only and have minimal security surface area, but still follow privacy guidelines for any optional features.
 
+## Dependency Vulnerability Hygiene (Plugins)
+
+The community scorecard scans the lockfile and flags any package with a known advisory, even if the package is dev-only and never ships in `main.js`. Common offenders are transitives pulled in by `eslint`, `eslint-plugin-obsidianmd`, and `@typescript-eslint/*`: `minimatch`, `picomatch`, `brace-expansion`, `ajv`, `flatted`, `fast-uri`, `yaml`.
+
+Use `pnpm.overrides` in `package.json` to force patched versions of vulnerable transitives without changing direct dependencies. Major-version-scoped ranges avoid breaking consumers that depend on a specific major:
+
+```json
+{
+  "pnpm": {
+    "overrides": {
+      "minimatch@<3.1.3": "^3.1.3",
+      "minimatch@^4 || ^5 || ^6 || ^7 || ^8": "^8.0.5",
+      "minimatch@^9": "^9.0.6",
+      "picomatch@<2.3.2": "^2.3.2",
+      "picomatch@^3 || ^4": "^4.0.4",
+      "brace-expansion@<1.1.13": "^1.1.13",
+      "brace-expansion@^2": "^2.0.3",
+      "ajv@<6.14.0": "^6.14.0",
+      "ajv@^7 || ^8": "^8.18.0",
+      "flatted@<3.4.0": "^3.4.0",
+      "fast-uri@<3.1.1": "^3.1.1",
+      "yaml@<2.8.3": "^2.8.3"
+    }
+  }
+}
+```
+
+Verify with `pnpm install` then `pnpm why <pkg>` for each advisory. Every resolved version should be at or above the advisory's fix version.
+
+If a direct dependency (e.g. `eslint-plugin-obsidianmd`) has a newer release that already pulls in patched transitives, prefer bumping the direct dep before adding an override. Overrides are appropriate when no upstream release covers your case.
+
+See [scorecard-compliance.md](scorecard-compliance.md) for the full set of scorecard signals and their fixes.
+
 ## Related Documentation
 
 - [release-readiness.md](release-readiness.md) - Comprehensive release checklist including policy adherence
+- [scorecard-compliance.md](scorecard-compliance.md) - Mapping of scorecard signals to concrete fixes
 - [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/versioning-releases.md

@@ -18,6 +18,57 @@ Update frequency: Check Obsidian Sample Theme repo for updates
 - Attach `main.js`, `manifest.json`, and `styles.css` to the release as individual assets.
 - Follow the plugin submission process to add/update your plugin in the community catalog.
 
+### Automated plugin releases with build provenance attestation
+
+The Obsidian community scorecard penalizes plugin releases whose assets are missing a GitHub artifact attestation. The recommended way to satisfy this signal is a tag-triggered release workflow that runs `actions/attest-build-provenance@v2` against the release files.
+
+Drop the following at `.github/workflows/release.yml`:
+
+```yaml
+name: Release
+
+on:
+  push:
+    tags:
+      - "*"
+
+permissions:
+  contents: write
+  id-token: write
+  attestations: write
+
+jobs:
+  release:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+      - uses: pnpm/action-setup@v4
+      - uses: actions/setup-node@v4
+        with:
+          node-version: "20"
+          cache: "pnpm"
+      - run: pnpm install --frozen-lockfile
+      - run: pnpm build
+      - uses: actions/attest-build-provenance@v2
+        with:
+          subject-path: |
+            main.js
+            styles.css
+            manifest.json
+      - env:
+          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+          TAG: ${{ github.ref_name }}
+        run: |
+          gh release create "$TAG" \
+            --title="$TAG" \
+            --generate-notes \
+            main.js styles.css manifest.json
+```
+
+Cut releases by pushing a tag (`git tag 0.1.0 && git push origin 0.1.0`). The workflow attaches the three required assets and registers the attestation. The scorecard's "Build verified" signal also fires once the workflow has run, because the attested artifacts can be reproduced byte-for-byte from source.
+
+For the full set of scorecard signals and their fixes, see [scorecard-compliance.md](scorecard-compliance.md).
+
 > [!NOTE]
 > Themes and plugins have different asset requirements and submission paths. Ensure you follow the correct flow for your project type.
 

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "obsidian-dev-skills",
-  "version": "1.1.3",
-  "description": "Agent skills for Obsidian plugin and theme development",
+  "version": "1.2.0",
+  "description": "Agent skills for Obsidian plugin and theme development, including community scorecard compliance, release workflow attestation, and dependency vulnerability hygiene.",
   "keywords": [
     "obsidian",
     "plugin",
@@ -9,7 +9,9 @@
     "development",
     "skills",
     "ai",
-    "agent"
+    "agent",
+    "scorecard",
+    "compliance"
   ],
   "homepage": "https://github.com/davidvkimball/obsidian-dev-skills",
   "repository": {
@@ -18,12 +20,14 @@
   },
   "license": "MIT",
   "author": "David V. Kimball",
+  "funding": "https://patreon.com/davidvkimball",
   "files": [
     "obsidian-dev/",
     "obsidian-theme-dev/",
     "obsidian-ops/",
     "obsidian-ref/",
-    "scripts/"
+    "scripts/init.mjs",
+    "scripts/setup-local.ps1"
   ],
   "bin": {
     "obsidian-dev-skills": "./scripts/init.mjs"
@@ -32,6 +36,6 @@
     "postinstall": "node ./scripts/init.mjs"
   },
   "engines": {
-    "node": ">=16.0.0"
+    "node": ">=18.0.0"
   }
 }

package/scripts/setup-local.ps1

@@ -1,8 +1,11 @@
-# Setup skills symlinks for this repository
-# This script creates symlinks to the obsidian-dev-skills repository
+# Setup skills symlinks for a downstream project
+# This script creates symlinks to the obsidian-dev-skills repository.
+# Intended to be copied into a downstream project's scripts/ directory.
+# The default $SkillsRepoPath assumes obsidian-dev-skills is a sibling
+# of the downstream project's repository root.
 
 param(
-    [string]$SkillsRepoPath = "$PSScriptRoot\..\obsidian-dev-skills"
+    [string]$SkillsRepoPath = "$PSScriptRoot\..\..\obsidian-dev-skills"
 )
 
 $ErrorActionPreference = "Stop"

package/scripts/bulk-update.mjs

@@ -1,40 +0,0 @@
-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

@@ -1,45 +0,0 @@
-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 | - | - |`);
-    }
-}