Introduction¶

In DSH’s plugin ecosystem, memory plugins typically take one of two approaches: either let the agent build its own memory database, or extract historical sessions into entries and perform vector retrieval. Both approaches introduce a second copy of data, which gradually drifts apart from the source files.

dsh-wb-memory takes a different path. It does not build a database or create a local copy; it directly renders the existing WorkBuddy Markdown (SOUL / USER / MEMORY / topics) into an independent section of the system prompt. The write-back operation also targets the same batch of source files.

The plugin is maintained by Nero0427, categorized as “Memory”, licensed under MIT, current version 0.1.2, and the repository is at https://github.com/Nero0427/dsh-wb-memory. Below, it is introduced in the order of “Install → Configure → Use”.

Positioning¶

One sentence: Connect the human-written long-term memory in the workspace directly into DSH’s system prompt.

Its premise is: the memory is already a piece of Markdown maintained by humans, not something that needs to be extracted from sessions. What the plugin does is “read this Markdown → render it into a segment → insert it into the system prompt → allow the agent to write back to the same file according to the protocol”.

The workflow can be summarized as:

~/.workbuddy/user-*-personal/
  SOUL.md      ┐
  USER.md      ├─ 渲染 ──▶  system prompt 的一个独立 section（dsh-wb-memory）
  MEMORY.md    │              不写任何副本
  IDENTITY.md  │
  topics/*.md  ┘  只放索引，正文按需 read

All three directions must be covered:

• Read: When assembling the system prompt, render identity, persona, and long-term memory into a segment and insert it after the dsh-purge injection but before its trailing anchor.
• Write: The same segment contains the “Memory Protocol,” allowing the agent to write back pitfalls, conventions, and decisions to the source files. It uses the host’s built-in edit tool and does not create a new tool.
• Sync: Cache based on source file modification times (mtime). When the source changes, the next request carries the new content; after DSH writes back, another client will naturally read the same file in the next session.

Installation and Enablement¶

The prerequisite is that the host is DSH and the memory directory already exists (automatically detected by default as ~/.workbuddy/user-*-personal).

It is recommended to install from the GitHub repository so that the plugin marketplace can recognize the source and detect and apply updates:

cd <DSH_HOME>/profiles/desktop
pnpm add github:Nero0427/dsh-wb-memory

You can also download dsh-wb-memory-<version>.zip from Releases, extract it, and place the entire plugin directory into node_modules/dsh-wb-memory.

For development, use link: to mount a local copy, pointing to the repository root, not src/:

{
  "dependencies": { "dsh-wb-memory": "link:/path/to/dsh-wb-memory" },
  "dsh": { "profile": { "bundles": ["dsh-wb-memory"] } }
}

Note that link: dependencies belong to local development copies; the plugin marketplace will not provide updates for them.

Next, disable the AGENTS.md loader in the profile’s cordis.patch.yml and insert this plugin:

- id: agent-instructions
  name: '@deepseek-ai/dsh-agent-instructions'
  disabled: true          # Disable AGENTS.md loader

- insert:
    - id: dsh-wb-memory
      name: dsh-wb-memory
      inject: [systemPrompt, webServer]
      config:
        enabled: true
        maxBytes: 60000
        topicsMode: index
        projectMemory: true

Restart DSH, and the “Memory” section will appear on the left side of the Settings page.

There are two reasons to disable the AGENTS.md loader: it creates a copy of AGENTS.md under $DSH_HOME, which is separate data from the source files; also, dsh-purge’s dropWorkspaceBaseline will discard its injection under strict/fallback strategies. Injecting directly into the system prompt avoids these two problems.

Configuration¶

The configuration options are listed below, all with default values:

Configuration has three levels of priority: the <DSH_HOME>/dsh-wb-memory/config.json written in the Settings page > the config in cordis.patch.yml > built-in defaults. Changes in the Settings page take effect in the next request without needing a new session.

To compress the size, the priority is: slimming down MEMORY.md (moving static paragraphs like hardware and system into topics) > turning off topic index > turning off protocol.

Typical Usage¶

After installation, you can manually check the status and troubleshoot injection issues:

/memory          Status (bytes, injection rounds, last time)
/memory render   Clear cache and recalculate
/memory preview  View content
/memory path     Source directory and segment name

For example, if you modified MEMORY.md but it didn’t change in this round, use /memory render to force a recalculation first. If it still didn’t take effect, use /memory path to confirm the source directory was detected, and then use /memory preview to see if the content is empty.

The write-back process does not require a manual trigger. The memory segment contains the protocol; the agent determines the timing within the session and directly modifies the source files using the host’s edit tool. The protocol also requires: when finding outdated entries, directly modify or delete them instead of appending “updated”; do not record the raw tool output, large blocks of code, or one-off debugging conclusions.

Regarding token overhead, the author tested (2026-11-04): SOUL.md is about 650 tokens, USER.md about 500, MEMORY.md about 1.3K, topics index about 240, and the memory protocol about 450. The total is about 3.3K tokens, occupying 0.3% of the 1M window. Since DSH resends the complete context every round and is charged at approximately 1/10 after prefix cache hits, the marginal cost of this fixed content is almost zero.

Relationship with dsh-purge¶

Both are mounted on the same system-prompt/assemble waterfall, but have different responsibilities:

The tested order is dsh-purge → dsh-wb-memory → dsh-purge:anchor. It does not duplicate injection and does not overwrite the purge body. You can install just one; when used together, the order is guaranteed by this rule without extra configuration.

Applicable Scenarios and Notes¶

Suitable scenarios: You are already maintaining a human-written Markdown memory (SOUL / USER / MEMORY / topics) and want multiple agent clients to reuse the same data, while accepting the “write-back via protocol by the model” approach.

A few points to note:

• The plugin runs with the current DSH process permissions and can read/write the source file directory. Before installation, it is recommended to read the source code and license (MIT) to confirm that the injected content and write-back behavior meet expectations.
• The file structure is a hard constraint. File names like SOUL.md, USER.md, MEMORY.md, and topics/*.md are defined by render.js; renaming them requires modifying the source code accordingly.
• One process reads one source directory; multi-user support is not provided.
• Project-level memory is not injected automatically; the protocol allows the agent to read <cwd>/.workbuddy/memory/ itself to save tokens.
• If /rules in purge uses complete (exclusive to the entire prompt), the memory segment will be discarded by the host, which can be seen in the /memory injection rounds.

Summary¶

The value of dsh-wb-memory lies in compressing the concept of “memory” into one sentence: the same Markdown file, read by two clients, and written back by the agent to the same file. No database, no extraction, no retrieval—trading for no copy drift.

Related Resources:

• Plugin Directory Page: https://www.skillhub.cn/plugins/Nero0427/dsh-wb-memory
• GitHub Repository: https://github.com/Nero0427/dsh-wb-memory
• License: MIT