dsh-spec-loop: A Spec-Driven Development Loop Plugin for DeepSeek Harness
tianji-qingtian/dsh-spec-loop
A DSH plugin with a /spec command family driving a spec-driven dev loop: propose → approve → implement → verify → archive, OpenSpec-compatible.
dsh-spec-loop provides an OpenSpec-compatible spec-driven development loop for DeepSeek Harness, turning propose, approve, implement, verify, and archive into a /spec command family.
dsh plugin --profile web add github:tianji-qingtian/dsh-spec-loop- Category
- Workflow & Automation
- Platform
- DSH-Plugin
- Author
- tianji-qingtian
- Distribution
- Plugin
dsh-spec-loop Key Features
dsh-spec-loop Repository

dsh-spec-loop Repo Summary
dsh-spec-loop is a spec-driven development loop plugin (DSH plugin) for DeepSeek Harness (DSH), maintained by tianji-qingtian under the MIT license, last updated in 2026-08. It addresses the challenge of managing specs, changes, and acceptance within a DSH workspace using an OpenSpec-compatible directory layout (<workspace>/openspec/), turning the full loop of "propose → approve → implement → verify → archive" into a /spec command family. Core capabilities include the /spec command family (init, new <goal>, status, list, show <id>, approve <id>, implement <id>, verify <id> [--deep], archive <id>, validate [id], edit <id>), a built-in validator matching the OpenSpec CLI rules, and a durable state machine (proposed → approved → implemented → verified → archived) folded from standard events.
What core features does the dsh-spec-loop DSH plugin support?
The plugin provides a complete spec-driven development loop. /spec new asks up to three built-in choice questions (scope/constraints/acceptance) through the harness question UI, in the language of the goal; verify judges every Requirement/Scenario with a bounded judge call (flash by default, main model with --deep), runs verification commands declared in proposal.md, and writes verify.md with a ✅/❌ table plus raw judge output. The state machine is folded from standard events (command/run/command/done pairs + machine-readable markers), so change cards, stages, and gates survive restarts without appending custom event types to the log.
How do I install dsh-spec-loop?
Before installing, ensure the dsh CLI is on your PATH (if you only used the harness via npx, install @deepseek-ai/dsh globally first). Then add the plugin to your web profile using the following command (prefer a release tag like #v0.1.2; #main tracks the latest commit):
dsh plugin --profile web add github:tianji-qingtian/dsh-spec-loop#v0.1.2
After adding, restart the harness with that profile to activate the plugin.
Which DeepSeek Harness versions and platforms does dsh-spec-loop support?
The plugin targets the DeepSeek Harness developer preview, which iterates quickly and may introduce breaking changes. It depends on official packages such as @deepseek-ai/dsh-commands, @deepseek-ai/dsh-fs, @deepseek-ai/dsh-llm, @deepseek-ai/dsh-session, and leverages harness capabilities like agent.steer, conversation.input.dock, and the locale service. The plugin is written in JavaScript, and the repository includes committed build artifacts under lib/, so no build script runs at install time.
What are the change directory layout and validation rules of dsh-spec-loop?
Change directories follow the OpenSpec layout: openspec/project.md, openspec/specs/<capability>/spec.md, openspec/changes/<change-id>/{proposal.md,tasks.md,design.md,verify.md,specs/<cap>/spec.md}, archived to changes/archive/YYYY-MM-DD-<id>/. Spec deltas use ## ADDED|MODIFIED|REMOVED Requirements with #### Scenario: per requirement. The built-in validator runs automatically after proposal generation, steering a correction request back to the agent on failure (bounded retries); approve refuses changes that do not validate, and archive refuses missing changes.
How does the change card and task progress work in dsh-spec-loop?
A full-width row above the input card (conversation.input.dock) shows the current change-id, stage, task progress x/y, and the next command to run. Task progress reads the standard todos projection (the implement prompt mirrors tasks.md into todo_write) with zero RPC. UI strings are localized through the harness locale service, supporting both Chinese and English.