Introduction

DeepSeek Harness (DSH) adopts a plugin-based architecture, allowing users to extend workflow capabilities through plugins. The dsh-e2e-dev-sdd plugin is designed to provide DSH Web with a five-stage Specification-Driven Development (SDD) workbench. It separates requirement discussion, prototype output, system design, specification design, and development/testing into five independent entry points. Unlike traditional fixed pipelines, these five stages exist by default as optional capabilities. Users can select the required sources and accepted deliverables based on current needs, iterate through conversations with the DSH Agent, and submit the results.

Core Features

Project Board and Delivery Management

The project board aggregates and separates requirement packages, independently deliverable work units, standalone defects, and defects within requirements. It provides defect delivery coverage, external workload statistics, five-stage status distribution, delivery scope burn-up charts, and a filterable delivery matrix. Defects within a requirement are grouped under that requirement and do not add additional five-stage rows or burn-up scope.

Five-Stage Workflow

It provides five top-level menus for requirement discussion, prototype, system design, specification design, and development/testing, all sharing the same project and deliverable protocol. Each DSH Workspace corresponds to a committable .sdd/ project space. Each independently deliverable sub-item under a main requirement has its own work unit.

Source and Synchronization Mechanism

Business adapters uniformly return source-bundle@1. A built-in zero-configuration manual source allows users to directly enter titles and descriptions when no enterprise adapter is available. When re-syncing the same primary ID, new, modified, removed, and unchanged items are previewed and applied only after confirmation. Before import, users can review the full content, metadata, business relationships, and currently imported version item by item.

Deliverables and Templates

During initialization, it generates .sdd/templates/<stage>/template.yaml and deliverable.md. A deliverable is a multi-file package that can contain content, diagrams, prototypes, and attachments. Deliverables are manually accepted, and their content SHA-256 is frozen. Accepted deliverables cannot be silently overwritten. Requirement changes save a new source snapshot without overwriting history.

Repository Integration and Planning

Code repositories can be centrally registered in project settings. Associated repositories are automatically used as read-only auxiliary inputs for requirement, prototype, system design, and specification design sessions. An internal planning engine runs through all five stages, but users do not need to be aware of the underlying OpenSpec. The development/testing stage creates sdd/... feature branches from the selected baseline and creates an independent Worktree or Clone for code development for each requirement, without polluting the main project space.

Extension and Adaptation

It supports registrable requirement/defect Source Providers (including the Cordis service and a built-in shell-free command-based Provider). Enterprise-general Connectors and adapters are placed in the plugin’s business/ directory, while project-specific adaptations are placed in .sdd/business/. Each stage has its own System Prompt, input gates, tool execution Guards, structural quality checks, and acceptance checklists.

Installation

Install the plugin into the Web profile:

dsh plugin --profile web add dsh-e2e-dev-sdd@latest

After installation, restart dsh web. The sidebar will show entry points for the five stages.

Typical Usage

  1. Initialize project: Open a Git repository as a Workspace in DSH. Enter any stage menu and check .sdd/project.yaml. If not initialized, click “Initialize project”.
  2. Configure repository: In “Project settings”, configure the remote, collaboration baseline, sync policy, and commit scope for the outer SDD project repository.
  3. Sync sources: On the project board, click “Fetch and preview requirement packages” or “Fetch and preview standalone defects”. Apply after confirming the list contents.
  4. Select inputs: Select the current requirement work unit from the top of the page, then click “Select/adjust inputs” to choose the current source and the latest accepted deliverables from upstream stages.
  5. Start stage: Select the draft and start the stage conversation. The plugin installs the stage System Prompt in the corresponding Session.
  6. Iterate and deliver: Iterate with the Agent. The Agent must follow the template shown on the page to output and write confirmed conclusions into the deliverable round by round. Review the delivery package and structural quality, confirm the stage acceptance checklist, and accept the version.
  7. Develop and test: In the development/testing stage, create an isolated code space only for the confirmed target repository. Run relevant tests via “Let AI verify”.
  8. Archive: Click “Archive and consolidate into product” to generate the FEAT feature version and the current product specification.

Applicable Scenarios and Notes

  • Flexible mode: By default, you can skip stages and freely combine inputs; the plugin does not automatically run all stages sequentially. Only when strict mode is enabled does it enforce the required dependencies declared by the project.
  • Data source: Git repository files are the project source of truth, not browser state.
  • Version management: Internal identities use UUIDs. Deliverable identifiers are deterministically generated by the plugin per stage. Enterprise external identifiers are preserved as-is and explicitly linked.
  • History protection: Historical deliveries remain immutable. The current product specification expresses only currently valid facts. .sdd/ carries R&D process data, while product/ and deliveries/ are inherent assets in the project root directory that can be directly read, committed, and handed off.
  • External materials: External materials must first be converted into a Source Envelope, then integrated by AI into formal deliverables.

Summary

The dsh-e2e-dev-sdd plugin decouples requirement, design, development, and testing workflows, providing a more flexible specification-driven development approach. Through templates, multi-file deliverables, and strict change-checking mechanisms, it ensures the quality and traceability of deliverables. It is suitable for teams that need to build standardized R&D processes in DeepSeek Harness.

Plugin directory | GitHub repository