Cyning12/dsh-coding-kit0

dsh-coding-kit

DSH plugin + P0 CLI: ICVO coding standards (Inform · Constrain · Verify · Orchestrate). Plugin does not auto-inject; call apply_coding_standards. CLI: npx dsh-coding-kit.

包名
dsh-coding-kit
版本
1.5.1
许可证
MIT
最近更新
2026年8月24日

安装

$npx -p @deepseek-ai/dsh dsh plugin --profile web add github:Cyning12/dsh-coding-kit

dsh-coding-kit

简体中文 | English

dsh-coding-kit@1.5.1 is a bundle plugin for DeepSeek Harness (DSH), shipping a P0 gate CLI and the G1–G7 process commands. The discipline assets remain ICVO (Inform · Constrain · Verify · Orchestrate).

Loading ≠ injecting. Installing or loading this plugin does not automatically rewrite the system prompt. apply() only registers tools. Only after you or the model calls apply_coding_standards will later turns' runtime context contain # Coding Standards.

Which entry to choose

Who you areEntryDo NOT
DSH session / model calling toolsdsh plugin add dsh-coding-kitDon't just npm install (without the bundle layer the tools won't appear)
Cursor / CI / daily gates on existing reposnpx dsh-coding-kitDon't treat the plugin init_coding_kit and the CLI init as the same entry

Both entries ship from the same npm package dsh-coding-kit@1.5.1. The plugin surface and the CLI surface do not replace each other.

The @deepseek-ai/cordis and @deepseek-ai/dsh-tools entries in peerDependencies are the DSH host plugin contract (needed only when the host loads this package as a plugin; not needed for CLI-only use), and are marked optional in peerDependenciesMeta.

Entry A · DSH plugin

Prefer npm (prebuilt, no allowBuilds needed):

dsh plugin --profile web add dsh-coding-kit

Fallback: install from GitHub (needs a Node build; pnpm 10+ may require allowBuilds):

dsh plugin --profile web add github:Cyning12/dsh-coding-kit#main

Confirmation layer

dsh --profile web --dump-config

After a successful install, the profile's package.json will show the dsh-coding-kit dependency, and dsh.profile.bundles will contain the package name. Users generally don't need to hand-edit bundles; dsh plugin add maintains them.

Activation and invocation

  1. Start DSH with that profile (e.g. dsh --profile web / dsh --profile web web).
  2. Say in the conversation: Please apply the coding standards (or "write code per the coding-kit standards").
  3. The model should call the apply_coding_standards tool.
  4. On success, later turns' runtime context contains # Coding Standards.

Optional parameters: profile=l1|l1+l2|full (default l1+l2); persist=false returns the body only in the current tool result.

Profile tier semantics:

TierContent
l1L1 standards + coding_wiki
l1+l2 (default)all standards + coding_wiki
fullequivalent to l1+l2 in the current version; the enum value is reserved for future bundle extensions (differentiated injected content)

Override root lookup rule (since 1.3.0): apply_coding_standards probes upward from the current working directory for .coding-kit and .dsh/coding-kit, stopping at the nearest ancestor directory containing .git (the git root) — so starting DSH from a monorepo subdirectory still hits the repo-root override, and directories above the git root are never picked up by mistake. Without .git, lookup continues to the filesystem root. The tool output's source=override|package and root= lines make the actual hit observable.

When injected content exceeds 24k characters it is truncated at file boundaries: the cut only falls between files, never injecting half a file; skipped files can be derived from the full set under root minus the tool output's files list, and truncated=true carries the truncation marker.

Initializing the project template (plugin surface)

Initialization goes through the init_coding_kit tool (not the CLI init).

Conversation: Please initialize the coding-kit templates into this project → the model calls init_coding_kit.
Then edit .coding-kit/ and call apply_coding_standards again (source=override). init_coding_kit never overwrites existing files.

Note (asymmetric read/write roots, made explicit in 1.3.0): the read side (apply_coding_standards) looks up to the git root; the write side (init_coding_kit) still writes into the current working directory. Call init_coding_kit from a repo-root conversation, to avoid initializing in a monorepo subdirectory while the read side hits the repo root.

Some IDEs / yaml-language-server treat the root cordis.patch.yml as an RFC6902 JSON Patch and report missing op / path / value. This is a false positive and can be ignored; the file must keep the - insert form — do not convert it to JSON Patch.

Entry B · CLI (Cursor / CI)

P0 gates and G1–G7 (delivered in 1.2.0):

npx dsh-coding-kit init [--preset NAME] [--yes]   # NAME vocabulary: harness-only (the only legal value)
npx dsh-coding-kit upgrade --yes
npx dsh-coding-kit refresh-ide-blocks [--target PATH] [--dry-run] [--yes] [--json]
npx dsh-coding-kit check
npx dsh-coding-kit verify --task 
npx dsh-coding-kit gate-check --task 
npx dsh-coding-kit audit --task 
npx dsh-coding-kit task lint --file 
npx dsh-coding-kit task close --file 
npx dsh-coding-kit status [--target] [--task] [--json] [--check]
npx dsh-coding-kit timeline --task FILE
npx dsh-coding-kit lifecycle show [--json]
npx dsh-coding-kit lifecycle dry-run --transition ID --from STATE
npx dsh-coding-kit discipline show [--json]
npx dsh-coding-kit graph yaml compile|check|export
npx dsh-coding-kit graph ingest|snapshot|axioms
npx dsh-coding-kit sync index
npx dsh-coding-kit skills install [--target DIR] [--out DIR] [--global] [--force] [--with-execute-hats]
npx dsh-coding-kit skills build [--with-execute-hats]
npx dsh-coding-kit skills check
npx dsh-coding-kit wiki export --json
npx dsh-coding-kit task lint-done
npx dsh-coding-kit task lint-wiki-delta
npx dsh-coding-kit task check --file PATH

init / upgrade / sync index / skills build never overwrite the S2 process domain (docs/tasks/, reviews/, invokes/by-task/).

refresh-ide-blocks (R-07 · literal refresh of stale commands in existing IDE blocks)

IDE blocks embedded by the wizard marker merge in the old @cyning/harness era () may still hold stale command literals. refresh-ide-blocks performs whitelisted literal replacement only inside such product marker block bodies:

  • Dry-run by default: with no flag (or an explicit --dry-run) it only scans + reports — zero writes, exit 0; only --yes writes to disk.

  • Discovery surface (frozen whitelist): repo-root AGENTS.md, CLAUDE.md, .cursor/rules/*.mdc (single level). Files outside the discovery surface are not processed even if they contain markers.

  • Mapping table (frozen · effective only inside block bodies):

    GroupRuleBehavior
    A1npx @cyning/harnessnpx dsh-coding-kitauto-replaced; subcommand and arguments preserved verbatim
    A2npx @cyning/harness@npx dsh-coding-kitauto-replaced; the version pin is dropped entirely (report records dropped_pin)
    A3npx --yes @cyning/harness[@]npx --yes dsh-coding-kitauto-replaced; --yes kept, pin dropped
    A4bare-bin forms harness skills build / harness skills checknpx dsh-coding-kit skills build / npx dsh-coding-kit skills checkauto-replaced (re-run guard when the line prefix already contains npx dsh-coding-kit)
    B1–B5CYNING_HARNESS / --with-scripts / wizard/ paths / harness: script names / other bare @cyning/harness referencesreported as "manual only", never replaced
  • Discipline: marker lines and out-of-block content stay byte-untouched; `` blocks are never rewritten; docs/tasks/, docs/harness/reviews/, docs/harness/invokes/by-task/ (S2) are always write-refused.

  • preflight (--yes-only fail-fast, exit 2, zero writes): a dirty git tree / mixed old-and-new literals in one file (MIXED) / malformed marker pairing (MALFORMED) / any S2 assertion gate hit → refuse to write.

  • Backup and rollback: before --yes writes, the original bytes are backed up to .cyning-harness/backups/refresh-ide-blocks// (keeping the latest 5 generations); for rollback prefer git checkout -- , or copy back from the backup in non-git repos.

  • Idempotent: re-running on already-refreshed files yields 0 group-A hits, files_written=0, unchanged bytes, exit 0.

  • --json prints a single-line machine report (schema dsh-coding-kit/refresh-ide-blocks-report@1).

D5 test-artifact detection boundary (audit / verify · test_strategy=required)

When a task declares test_strategy=required, audit / verify run the D5 hard check: the target repo must contain real test artifacts, otherwise exit 2. D5 is artifact detection — it does not execute test commands. Detection scope (tightened in 1.3.0):

Strong-signal probes (presence = PASS)

  • Directories: test/ tests/ spec/ specs/ __tests__/
  • Config files: jest.config.{js,ts} vitest.config.{js,ts} playwright.config.{js,ts} cypress.config.js pytest.ini
  • Test file names (within 3 levels of the repo root): *.(test|spec).(js|ts|mjs|cjs), *_test.py, test_*.py

CI detection: every *.yml|*.yaml under .github/workflows/ is read as text; CI counts as having tests only if it hits one of these test-step patterns: pytest vitest jest npm (run )?test pnpm (run )?test yarn test node --test go test cargo test tox unittest, or a step name: containing test.

Known false positives and the escape hatch

  • pyproject.toml / setup.py are no longer treated as test artifacts (every modern Python repo has them, regardless of whether tests exist).
  • Pure lint / pure deploy workflows (no test step) no longer pass.
  • Detection depth is 3 levels from the repo root; for deeper monorepo layouts or custom test commands (e.g. make test) that miss the whitelist, drop any strong-signal file into the repo (e.g. a tests/ directory, *_test.py).
  • WARN transition hardened (1.5.0): the transitional branch from 1.3.0–1.4.0 — "new detection fails but the old heuristic passes → D5: WARN transition exit 0, non-blocking" — has been removed; since 1.5.0 that situation is always a FAIL (verify BLOCKED / audit FAIL, exit 2). Before upgrading, add real test artifacts to the repo (e.g. tests/, *_test.py, *.test.ts, or CI with a test step).

Migrating from @cyning/harness

After pinning dsh-coding-kit@1.5.1 you can drop @cyning/harness. Minimal path, three steps (required, in order):

  1. Replace the devDependency @cyning/harness with dsh-coding-kit (pin 1.5.1).
  2. Run npx dsh-coding-kit upgrade --yes at the repo root (reads the old .cyning-harness/manifest.json; version pinned at 1.5.1, from_version records the old number).
  3. In CI / scripts, replace npx @cyning/harness with npx dsh-coding-kit.

Skill installation is recommended, not required (the minimal path does not depend on DSH scanning skills). Commands are always npx dsh-coding-kit.

FAQ · pnpm peer

If pnpm install still fails on the peer chain (e.g. resolving to an unpublished host package): set auto-install-peers=false at the repo root (or one-shot pnpm add -D dsh-coding-kit --config.auto-install-peers=false). Even though 1.2.2 already marked cordis / dsh-tools as optional, keeping this fallback is recommended.

Copy-paste Prompt (for agents maintaining existing repos)

Paste the whole block:

You = the maintenance agent of this repository. Migrate this repo from @cyning/harness to dsh-coding-kit@1.5.1.

Minimal path (required, in order):
1. package.json devDependency: delete @cyning/harness, replace with dsh-coding-kit (pinned at 1.5.1).
2. Run at the repo root: npx dsh-coding-kit upgrade --yes
   (reads the old .cyning-harness/manifest.json; version pinned at 1.5.1, from_version records the old number; never overwrites docs/tasks, reviews, invokes/by-task.)
3. Replace every npx @cyning/harness in CI and scripts with npx dsh-coding-kit.
Commands are always npx dsh-coding-kit. Never write npx @cyning/harness skills build again.

Recommended (not required · skill installation):
- In-repo: npx dsh-coding-kit skills install
  Copies the pre-generated skills from the npm package (excluding 30/40 by default) into this repo's .dsh/skills. Existing files are not overwritten by default; add --force to overwrite.
- User-level: npx dsh-coding-kit skills install --global
  Writes to $HOME/.dsh/skills (HOME is expanded; do not treat ~ as a relative path).

Path reference (never mix them up):
- .dsh/skills or $HOME/.dsh/skills = skill installation target (this command).
- .claude/skills or ~/.claude/skills = Claude Code's skill directory (this command does not write there by default; if you use Claude, copy separately or use --out).
- .dsh/coding-kit or .coding-kit = standards override (apply_coding_standards / init_coding_kit), NOT a skill directory.

Verified (against DSH upstream source): the DSH runtime automatically scans this repo's .dsh/skills and $HOME/.dsh/skills and loads them on demand. A skill is a /SKILL.md directory package or a flat .md file; frontmatter must include name/description; evidence anchors are in the README "Scan verification" section.

Do NOT: GitHub Archive; npm publish / deprecate; make apply auto-inject at load time; install 30/40 by default; copy skills into .dsh/coding-kit.

Path reference

PathPurposeWritten by
Product package assets/skillssource of truth for generated artifacts; the comparison root of skills checkmaintainer skills build (G5 freeze)
/.dsh/skillsconsumer skill installation targetskills install
$HOME/.dsh/skillsuser-level installation targetskills install --global
/.claude/skills or ~/.claude/skillsClaude Code skill directoryuser copies separately or uses --out; not written by default
/.dsh/coding-kit or .coding-kitstandards override (standards / wiki)init_coding_kit; forbidden as a skill dest

Scan verification (checked against DSH upstream source)

Verified (2026-08-22 · against DSH upstream source deepseek-harness@141eb6f, i.e. dsh 0.1.0-rc.8): the DSH runtime automatically scans /.dsh/skills and $HOME/.dsh/skills and loads them on demand — these are exactly the two installation targets of this package's skills install. Evidence anchors:

  • packages/skill/skill-filesystem/src/index.ts:246 — scans /.dsh/skills (source=project-dsh, rank 100); same file :253 — scans /skills ($DSH_HOME or ~/.dsh, source=user-dsh, rank 400).
  • docs/subsystems/skills.md "Local discovery priority" table says the same (the rank 100/400 rows); loading mechanism: skill summaries are injected into the session catalog, and the model pulls the full body on demand via the skill({ name }) tool (the "Session catalog and tool contract" section of that document).

Structure and frontmatter requirements (same source): directory package /SKILL.md or flat .md (index.ts:724-728); frontmatter must include name/description, and name must be kebab-case (index.ts:810-816); projectRoot = the nearest ancestor directory containing .git (index.ts:937-947).

Note: scanning/loading is a behavioral contract of the DSH runtime and evolves with upstream versions; the anchors above correspond to 0.1.0-rc.8. This package's responsibility ends at writing skills to the correct target and keeping frontmatter valid (skills check).

GitHub topics

This repository's current GitHub topics: dsh-plugin (DSH's official discovery tag — see upstream deepseek-harness README.md and `CONTR