Introduction

Writing collaboration rules for agents often involves stacking all conventions into a single global prompt. When there are many rules, two problems arise: irrelevant content occupies context, and the model struggles to distinguish “which rule applies to which files”. Claude Code solves this with rules.md and # Path: sections—rules declare the file scope they govern themselves, and only take effect when matching files are touched.

If you are developing on DeepSeek Harness (DSH) and want the same mechanism, the dsh-rules introduced below provides exactly that: rules match files using glob patterns, and when the agent reads or edits matching files, the rule content is automatically injected into the conversation.

What is this

dsh-rules is maintained by rj-jiangyichen, current version 0.1.1, MIT license. The positioning can be summed up in one sentence: providing glob-activated rule prompts for DSH—each rule declares a glob pattern, the rule activates when the agent touches (reads/edits) matching files, content is injected as a <rules> snapshot into the conversation, overwriting the previous snapshot; mechanism-wise, it aligns with Claude Code’s rules.md / # Path: style.

DSH’s philosophy is “everything is a plugin”, and this plugin follows that: it applies to all DSH deployment forms—desktop / web / tui / headless / custom profiles, without dependencies specific to desktop.

How it works

First, let’s look at the complete chain from files to conversation:

  1. The agent reads or edits a file; the plugin records the touched paths on a per-session basis.
  2. In every step, the agent/pre-step listener matches touched paths against all rules’ globs to collect active rules.
  3. Matching results are rendered into a <rules> snapshot and injected into the conversation as a user message.

There are several design aspects worth noting around this chain:

  • Visible and Persistent: The injection is a user message, visible in the UI, and persisted in session logs; each snapshot overwrites the previous one, ensuring the model always sees the currently active rule set.
  • Byte Budget: Default injection size is 32 KB (32768 UTF-8 bytes); when over budget, low-priority rules are discarded first, and the final rule is truncated; content is escaped to prevent it from breaking out of the framework tags.
  • Session Recovery: During resume, the last snapshot and matching files are restored from logs to avoid redundant injections.
  • Session-based Tracking: Each agent/session independently records touched files, including sub-agents; global rules without a declared path are always active.
  • Hot Reload of Rules: Rule sources are probed every step with version caching; changes to rule files take effect in the next step. File reading prioritizes the harness fs service (including inclusion checks), falling back to the Node file system if the service is not mounted.

Installation and Activation

The general installation method is to complete installation and activation in one step from the npm registry (change profile to desktop / web / tui / headless based on deployment form):

dsh plugin --profile desktop add dsh-rules

After installation, restart DSH (restart the application for desktop, restart the process for web/headless) for it to take effect. Use the update subcommand, or remove then add:

dsh plugin --profile desktop update dsh-rules

For local development, run the following command in the repository root:

dsh plugin --profile desktop add .

Note: pnpm splits add arguments at spaces; if the repository path contains spaces, installation must be done via a junction without spaces (e.g., mklink /J).

DSH Desktop (Windows) also provides a one-click script: clone the repository first, then run:

node scripts\install-desktop.mjs

After the script completes, restart DSH Desktop; the plugin will take effect on the next load.

There are two ways to uninstall, choose either:

# Method 1: One-click script uninstall
node scripts\install-desktop.mjs --uninstall

# Method 2: dsh command uninstall
dsh plugin --profile desktop remove dsh-rules

Neither installation nor uninstallation touches the DSH installation directory (resources\app.asar.unpacked); it only modifies the profile configuration and is fully reversible; remember to restart the application after operations. Environment requirements: Node ^22.19.0 || >=24.0.0.

How to Write Rules

Rules have two sources and can be mixed.

Source A: Rule Files. Place them in .dsh/rules/*.md within the project, and user-level rules in ~/.dsh/rules/*.md (optional). The path field in frontmatter declares the glob:

---
path:
  - "src/**/*.ts"
  - "!src/**/*.test.ts"
---
Rule body (markdown, injected into conversation when activated)

Glob syntax supports **, *, ?, {a,b}, [abc], and exclusion with ! (underlying library is picomatch); paths are relative to the project root and use / as separators. When path is missing or empty, the rule becomes a globally active rule. Frontmatter also supports an optional name field for deduplication of rules with the same name; if omitted, the filename (without the .md suffix) is used.

Source B: # Path: Sections. Requires includeClaudeSections: true. The plugin parses # Path: headers in AGENTS.md / CLAUDE.md (including .local.md variants and ~/.dsh/AGENTS.md):

# Project notes

# Path: src/**/*.ts, scripts/**
This section is only activated when touching files under src/**/*.ts or scripts/

Each # Path: header starts a rule; content continues until the next header or end of file, and globs can be separated by commas or spaces. Note that content before the first # Path: header is not injected by this plugin—that part is injected by DSH’s built-in agent-instructions with the full AGENTS.md/CLAUDE.md baseline.

Priority and deduplication rules: Project rules (rank 100) > User rules (rank 200) > # Path: Sections (rank 300). Only the rule with the highest priority is kept for rules with the same name; rendering order is determined by (rank, name) and remains consistent across steps.

Configuration

The plugin runs with default hardcoded values by default; to override by profile, set the config for the entry in <profile>/cordis.patch.yml:

- id: dsh-rules
  name: dsh-rules
  config:
    includeClaudeSections: true
    projectRootMarkers: [".git", ".dsh"]

The above enables # Path: section parsing and expands project root markers to .git and .dsh. Common configuration options are listed below (refer to the repository README for the full list):

Configuration Item Default Value Description
dshHome $DSH_HOME / ~/.dsh Root directory for user rules and ~/.dsh/AGENTS.md
projectRootMarkers [".git"] Marker files/directories used when searching upwards for the project root
ruleDirNames [".dsh/rules"] Project rule directories (relative to project root, multiple can be configured)
includeUserRules true Whether to enable ~/.dsh/rules/*.md
includeClaudeSections false Whether to parse # Path: sections
instructionFileCandidates ["AGENTS.md", "CLAUDE.md"] Candidate filenames for # Path: sections
localInstructionFileCandidates ["AGENTS.local.md", "CLAUDE.local.md"] Candidate filenames per directory
maxBytes 32768 Rendering budget for each injection (UTF-8 bytes); disables plugin if <= 0
maxSourceBytes 1048576 Upper limit for single rule source file size; files exceeding this limit are skipped

There are two boundaries that are easy to cross: setting maxBytes to 0 or a negative number will directly disable the entire plugin; single rule source files exceeding 1 MB will be skipped entirely and not partially injected.

Use Cases and Notes

Who is it for:

  • Developers maintaining multi-module projects on DSH who want “apply src rules when modifying src, apply test rules when modifying tests”;
  • Teams migrating from Claude Code—.dsh/rules/*.md and # Path: sections in AGENTS.md / CLAUDE.md can be used directly;
  • Scenarios where context usage is a concern: rules are only injected when touching matching files, with a byte budget to fall back on.

Notes:

  1. The plugin runs with the permissions of the current dsh process; please check the repository source code and license before installing (this project is MIT).
  2. When the local repository path contains spaces, you must create a junction without spaces before installing, otherwise pnpm will split the add argument incorrectly.

Summary

dsh-rules brings Claude Code’s path-based rule mechanism to DSH: rules declare globs via frontmatter or # Path:, injection only occurs when the agent touches matching files, snapshots are recoverable, budgets are controllable, and it is compatible with all deployment forms (desktop / web / tui / headless). If you are managing collaboration rules for multi-module projects on DSH, you can start using it directly after the installation and rule writing steps above.

Finally, a note: the directory page above is from a community-maintained plugin site and has no official affiliation with DeepSeek / Hypersphere.