Introduction¶

The philosophy of DSH (DeepSeek Harness) is “everything is a plugin.” Community maintainers create independent plugins for engineering tasks such as agent writing and prompt discipline. The dsh-writing-discipline introduced below (maintained by oobitoooo, categorized as admin-security) is one that leans towards auditing: it is not a typesetting tool, nor a style polisher, but a “writing discipline gate.”

The problem it targets is specific: when models write, they tend to write to avoid blame rather than to deliver. The result is that defensive expressions like disclaimers, “as an AI,” preaching, meaningless hedging, and process narration appear in large quantities in deliverables, leaving the reader unable to act. There are many tools on the market to clean up these expressions, but the biggest risk is not that they cannot be deleted cleanly, but that they accidentally delete real facts along with them—negatives in subjects, numbers, citations, applicability boundaries, and claim intensity. This plugin does two things simultaneously: clear defensive noise, and use a conservation lock to prove that the fact layer hasn’t moved a single character before and after rewriting.

What is it¶

One-sentence positioning: A zero-network, zero-LLM, pure-local regex plus statistics DSH plugin. It uses five deterministic tools to detect and clear defensive writing while ensuring rewriting does not break the fact layer. It does not call any external services; the same input always gives the same output, so it can be put in CI or pre-commit.

• Name: dsh-writing-discipline
• Maintainer: oobitoooo
• Category: admin-security
• Current version: 0.2.1
• License: MIT
• Homepage: https://www.skillhub.cn/plugins/oobitoooo/dsh-writing-discipline
• GitHub: https://github.com/oobitoooo/dsh-writing-discipline

The plugin’s corresponding homepage is maintained by the community and has no official affiliation with DeepSeek or HF.

The Five Issues it Targets¶

The README lists the problems it targets as a table, with each category corresponding to a fixed expression in reality:

A tool that only does one part is incomplete: cleaning only is a typesetting tool, checking facts only is an auditing tool. This plugin explicitly states that both are indispensable.

Five Tools¶

After installation, five tools starting with wd_ will appear in the tool table, all deterministic.

wd_scan — Scan¶

{ "text": "……", "profile": "chat", "severityMin": "warn", "maxWarn": 3, "verbose": true }
// or { "filePath": "docs/report.md" }

Returns ERROR / WARN / INFO counts, per-hit details (rule, line number, paragraph, original text, semantic fragment, suggested action), and text metrics (average sentence length, hedging density, dash density).

The profile controls strictness. The README clearly distinguishes several document types:

• chat: hedge as WARN, preaching / disclaimer as ERROR (chat is described as the default common value).
• report / readme / email: same as above, but meta-commentary residues are weighted heavier.
• academic: all hedging is downgraded to INFO, as academic hedging is considered legitimate expression recognized by ICMJE.
• review: process residues like “as requested” do not trigger errors.

wd_rules — Quick Rules Reference¶

Lists the actual severity of 24 rules and 3 density rules under the current profile. The README usage suggestion is to scan once before writing, which is cheaper than fixing after writing.

wd_rewrite — Deterministic Rewrite¶

It only does three things with confidence: strip intro phrases (Good, / Please note, / Need to note, / Friendly tip:), compress stacked hedges (may perhaps -> may), and delete pure defensive sentences. The hard constraint is that sentences containing numbers, citations, figure numbers, or links are never deleted. Returns rewritten text, per-change records, and a re-scan of the rewritten text.

It is necessary to clarify boundaries: it does not generate new sentences. Semantic-level rewrites like “rewrite this sentence into a fact sentence” require human input.

wd_conservation — Conservation Lock¶

{ "original": 原文, "revised": 改后文本 }   // 或 originalPath / revisedPath

It compares before and after, checks four types of fact drift, and assigns levels:

Once INVARIANT or VIOLATION appears, ok: false. CI can go red immediately.

wd_stats — Metrics¶

Statistics on characters, Chinese word count, English word count, paragraphs, sentences, average sentence length, hedging density (per thousand language units), and dash density. The typical usage given in the README is to run before and after rewriting and use the numbers to speak.

Rules Table¶

The README lists 25 rules plus 3 density rules, grouped as follows:

Density rules are the key difference between this and ordinary banned-word lists: a single may isn’t a problem, but three mays in a paragraph with no numbers is.

Judgment Levels and Suggested Actions¶

Levels are divided into three tiers, each corresponding to different CI strategies:

Every hit carries an action with four values:

• CUT: Delete the whole sentence.
• TIGHTEN: Compress, keeping information, removing the safety layer.
• REFRAME: Rewrite into a fact sentence, from condition to consequence.
• REVIEW: Requires human judgment, do not auto-delete.

The existence of REVIEW has a clear reason: not X but Y used once is emphasis, used three times is a trope; we think is sometimes a weak legitimate explanation. The tool only marks it; deletion is up to you.

Installation and Activation¶

Method A: Local link (Development / Self-use)¶

dsh plugin --profile desktop add link:C:/path/to/dsh-writing-discipline

Method B: Install from GitHub¶

dsh plugin --profile desktop add github:oobitoooo/dsh-writing-discipline

After installation, restart DSH (or wait for hot loading), and the five wd_* tools will appear in the tool table.

Note: The link: / github: prefix in the install command and --profile desktop are as written in the original README. It only uses ctx.tools.register and defineTool, works in both DSH 0.1.x and 0.2.x. The README explicitly states there is no postinstall script, no disk writing, and no config modification.

Command Line (CI / pre-commit)¶

The plugin comes with a standalone CLI—once installed, you have wd-lint:

wd-lint README.md docs/DESIGN.md      # Multiple files
cat x.md | wd-lint -                  # stdin
wd-lint -t "本内容仅供参考。"           # Directly test a segment
wd-lint -m 3 src/                     # WARN budget 3
wd-lint --json x.md                   # JSON, for CI parsing
wd-lint --fix x.md                    # Rewrite in place (original file saved to .bak)
wd-lint --diff before.md after.md     # Conservation lock: whether the two versions drifted in facts

Exit codes: 0 pass; 1 has ERROR or exceeds WARN budget; 2 usage or IO error.

The README specifically explains the purpose of the WARN budget: existing projects will inevitably have a bunch of WARNs at the start, freezing everyone. Clear to ERROR=0 first, then compress the budget from 20 week by week to 0. wd-lint -m 3 means “tolerate at most 3 WARNs this week.”

pre-commit example:

- repo: local
  hooks:
    - id: writing-discipline
      name: writing discipline
      entry: wd-lint -m 0
      language: node
      types: [markdown, text]

Integrating with CI¶

The README gives two ways. One is directly calling the rule module in the workflow:

- name: writing discipline
  run: node -e "import('./lib/rules.js').then(m=>{const r=m.scan(require('fs').readFileSync('dist/README.md','utf8'),{profile:'readme'});if(!r.ok){console.error(m.formatReport(r));process.exit(1)}})"

The other is directly importing pure functions; scan / rewrite / conservation / stats do not depend on the DSH runtime:

import { scan, conservation } from 'dsh-writing-discipline/rules'

const r = scan(text, { profile: 'report' })
if (!r.ok) throw new Error(`防御性写作 ${r.counts.error} 处`)

const c = conservation(before, after)
if (!c.ok) throw new Error('改写破坏了事实层：' + c.items.filter(i => i.severity === 'error').map(i => i.message).join('; '))

Use Cases and Notes¶

Who is it for: DSH developers who need to standardize Chinese technical docs, READMEs, reports, and emails in a single pipeline, especially teams that want to make writing discipline a CI threshold rather than a verbal agreement. It can do in-place rewriting for --fix scenarios and can use the conservation lock as a safety net in CI.

The boundaries to note, clearly listed by the README itself:

1. Chinese rules are relatively strict: may is often true uncertainty in technical text, not defensive. README suggests using profile=academic or severityMin=warn to filter.
2. Does not rewrite semantics: wd_rewrite only deletes, doesn’t create, so it cannot provide alternative text for “changing into a fact sentence.”
3. Conservation lock is heuristic: Number comparison is literal token-based; 840 ms and 840ms are seen as different; claim intensity relies on paired word lists, not covering all verbs. It is a seatbelt, not brakes.
4. Does not handle .docx/.pdf: Pure text in, pure text out. Office documents should use corresponding skills to extract first.

The plugin runs with the current DSH process permissions. Source code and license should be checked before installing. The repo comes with code and rule implementation. Tests run with npm test (17 cases, pure node:assert, no dependencies), npm run check for syntax. Rules are concentrated in the RULES array in lib/rules.js; adding one is adding an object. test/smoke.mjs validates “all regexes compile” and “ruleId is unique.”

Conclusion¶

The value of this plugin lies not in “one-click elimination of nonsense,” but in binding together two things usually done separately: using deterministic rules to clear defensive expressions, and using a conservation lock to keep numbers, citations, negatives, and claim intensity pinned in place. The former determines whether the deliverable can be acted upon, the latter determines whether the automatic cleanup can be trusted.

Homepage: https://www.skillhub.cn/plugins/oobitoooo/dsh-writing-discipline
GitHub: https://github.com/oobitoooo/dsh-writing-discipline