Introduction

The DeepSeek Harness (DSH) philosophy emphasizes “everything is a plugin.” When developing or maintaining Obsidian plugins, there is a gap between existing toolchains (such as Webpack/Vite and the official Obsidian template) and interaction with LLM agents. dsh-obsidian-plugin is a suite of tools that provides DSH agents with the full Obsidian plugin development lifecycle. It is maintained by LeeLee592 and runs through the DSH plugin system, addressing the problem that agents, after generating code, lack the ability to automate building, testing, deploying, and runtime validation.

Core Capabilities

This plugin provides a set of tools covering the entire process, from code generation to runtime interaction.

1. Development and Build

  • obsidian_plugin_scaffold: Generates a standards-compliant plugin skeleton from the official obsidianmd/obsidian-sample-plugin template, with built-in naming and commit checks.
  • obsidian_plugin_build: Packages the plugin project into a loadable main.js (CommonJS, with obsidian externalized) and performs static self-checks (Level L1). It resolves the entry point and falls back to the project’s own configuration, local build scripts, or default policies. If the lookup fails, it lists all attempted paths.
  • obsidian_plugin_validate: Validates required fields in manifest.json, naming rules, mappings in versions.json, and version consistency in package.json, and uses the official obsidianmd/eslint-plugin for code linting.
  • obsidian_plugin_version: Synchronizes version numbers across manifest.json, versions.json, and package.json.

2. Testing

  • obsidian_plugin_test: Runs offline smoke tests (Level L2). It loads the built package in a pure Node environment and runs lifecycle tests against a stubbed Obsidian API. It does not require Obsidian to be installed and can resolve local @codemirror/* and @lezer/* dependencies in the project.
  • obsidian_plugin_e2e: Sets up sandboxed E2E tests (Level L4) based on WebdriverIO and wdio-obsidian-service. It creates an independent Obsidian instance and an isolated configuration directory, avoiding interference with the developer’s current window.

3. Deployment and Interaction

  • obsidian_plugin_deploy: Installs the build artifacts into <vault>/.obsidian/plugins/<id>/ and updates the vault’s community-plugins.json (preserving existing entries). It also records the vault in dsh.obsidian.json.
  • obsidian_plugin_reload: Makes code changes take effect. Supports reload, enable, disable, rescan (refreshes the plugin manifest index, which is critical for newly deployed plugins), and unrestrict (disables the vault’s restricted mode).
  • obsidian_plugin_vault: Manages vaults for live validation. Supports checking status, registering/opening a vault (ensure), and closing a vault.
  • obsidian_plugin_inspect: Performs read-only observation of a running application. Provides features such as status (health report, registered vaults, plugin status, and trust modal status), console, and screenshot. This is the primary means of reading application state, requires no approval, and takes precedence over eval.
  • obsidian_plugin_eval: Executes JavaScript in a running application. This is the only high-privilege tool, used for reading plugin instances, driving interactions, or attempting fixes. Executed code is echoed as an audit trail, and a warning is issued when the code involves window focus. This operation requires approval.

Validation Levels

The plugin defines four validation levels. The default development loop includes L1, L2, and L4.

Level Method Description
L1 Static Performs artifact, module format, and manifest checks in obsidian_plugin_build, with no interference.
L2 Offline smoke obsidian_plugin_test loads the built package in Node, with no Obsidian installation required and no interference.
L3 Your Obsidian Uses tools such as obsidian_plugin_vault, reload, and inspect against your running app, driven by the CLI.
L4 E2E obsidian_plugin_e2e uses WebdriverIO to run in a sandboxed environment, fully isolated.

Installation and Usage

This plugin is installed through the DeepSeek Harness plugin system. After installation, DSH agents can invoke the tools above by name (for example, obsidian_plugin_build).

Notes:
- obsidian_plugin_eval requires approval to execute and has high privileges; use it with caution.
- Before performing code operations, it is recommended to use obsidian_plugin_inspect for read-only inspection first.
- The plugin runs with the permissions of the DSH process. Review the source code and license (MIT) before installing.

References