Introduction

In agent workflows like DSH, if rules are only written in documents, execution often relies on the model’s self-awareness. dsh-rule-engine is the plugin implementation of the DSH Rule Execution Engine v3. It treats ~/.dsh/AGENTS.md as the single source of truth, automatically parsing and executing rules. Below is an introduction to its positioning, available commands, and installation methods.

What is it

dsh-rule-engine is maintained by jilian-dsh and is licensed under MIT. It does not include a built-in security checklist independent of users; instead, it parses rules using ~/.dsh/AGENTS.md as the single source of truth and executes rules via tool guards, text detection, timing checks, and audit logs.

The core idea of this plugin is: rules are written in AGENTS.md, and the plugin is responsible for checking, executing, and recording these rules at runtime. After dynamic rule parsing, adding, deleting, or modifying rules does not require rewriting the plugin.

Core Features

The following are the main capabilities listed:

  • Parse and execute rules using ~/.dsh/AGENTS.md as the single source of truth.
  • Provide tool guards, text detection, timing checks, and audit logs.
  • Rules are parsed dynamically; adding, deleting, or modifying rules does not require rewriting the plugin.
  • Provide the /guard command to view status, rules, audit logs, and manage authorization/unlock/whitelists.
  • Packaged according to bundle specifications; cordis.patch.yml inside automatically mounts the plugin entry.
  • Support configuration for task contracts and anti-over-engineering modes, budget/category whitelists, etc.
  • Support LLM adjudication and fail-closed noise injection governance.

When there is no AGENTS.md in the environment, the documentation states the engine loads with zero errors, zero rules, and zero false blocks.

Installation and Enablement

The installation command provided in the documentation is:

dsh plugin --profile web add dsh-rule-engine

This command uses --profile web; the documentation does not state whether this command applies to all profiles.

Another method is to manually add dsh-rule-engine to the dsh.profile.bundles array of the target profile.

The plugin is packaged according to bundle specifications. The cordis.patch.yml inside automatically mounts the plugin entry, as shown below:

- insert:
    - id: dsh-rule-engine
      name: 'dsh-rule-engine'

Typical Usage

The rule body can bind an executor via comments:

<!-- handler: xxx -->

Alternatively, an executor can be explicitly bound using handlerOverrides in the plugin configuration.

After installation and enabling, you can use the /guard command to view the engine status, rule list, and audit logs:

/guard status
/guard rules
/guard log [N]

If the plugin’s own configuration or the artifacts it understands need to be written, the documentation states that a direct edit/write will be rejected by the guard and requires using /guard unlock first.

Task contracts and anti-over-engineering modes are disabled by default. When enabled, the default mode is observation mode; only switching to armed truly blocks actions. Popup queries are disabled by default; when askEnabled is on, actions like dependency/hash will go through the official approval query.

Please note: Changes to the plugin’s lib code take effect only after restarting DSH. The documentation also mentions that dev_reload_package hot reload is unreliable under bundle assembly.

Suitable Scenarios and Notes

This plugin is suitable for users who have a ~/.dsh/AGENTS.md rule set and do not want rule execution to rely solely on the model’s self-awareness. If you are only using DSH temporarily and do not maintain a rule file that requires machine execution, the benefits will be limited.

Before using it, it is recommended to pay attention to the following points:

  • Project documentation may contain numerous incompleteness, misjudgments, or boundary issues and is still in a stage where it is functional but requires continuous refinement.
  • Plugin configuration/understood artifacts are read-only to the model; direct edit/write will be rejected by the guard and requires /guard unlock.
  • Changes to plugin lib code must restart DSH to take effect; dev_reload_package hot reload is unreliable under bundle assembly.
  • Runtime requires node >=22.
  • dshCompat range is min 0.1.0-rc.3 max 0.2.0.
  • The plugin runs with the current DSH process permissions. Before installing, check the source code, configuration options, and license. The license is marked as MIT, but the documentation does not fully display the content of the LICENSE file; it is recommended to refer to the actual file in the repository.

Conclusion

The value of dsh-rule-engine is to transform the rules in AGENTS.md from “document conventions” into objects that are checkable, auditable, and executable at the plugin layer. It is more suitable for DSH users who have clear rule management needs and are willing to maintain AGENTS.md.

Directory page: https://www.skillhub.cn/plugins/jilian-dsh/dsh-rule-engine

GitHub: https://github.com/jilian-dsh/dsh-rule-engine