dsh-product

English | 中文

dsh-product 是一个“互联网资讯查询 + 本地项目上下文”的 DeepSeek Harness 插件，用于把已经确认的产品机会转化为可验证、可交付、可迭代的产品。

dsh-product is a web-aware DeepSeek Harness plugin that combines public internet research with local product context to turn a validated opportunity handoff into a shippable, observable and iterated product.

Public six-plugin collaboration contract: SUITE.md.

DSH compatibility and installation

Closed-loop handoff guide: owned receipts, evidence gates and feedback. Start cross-plugin work with product_handoff_receive; an accepted receipt is not approval or completion.

Tested against DeepSeek Harness 0.2.1-rc.2, the npm latest channel checked on 2026-10-29, with Cordis 4.0.5. Node.js must satisfy ^22.19.0 || >=24.0.0. DSH peer packages are pinned to the tested version; other release channels need a fresh compatibility check.

npm install -g @deepseek-ai/dsh@0.2.1-rc.2
dsh --version
dsh plugin --profile web add github:winyh/dsh-product
dsh --profile web --dump-config
dsh web

Install into the profile you actually launch: web for dsh web, or replace it consistently with your custom profile name. Installing into default does not enable the plugin in web. Restart the running profile after an update.

GitHub installations use the committed prebuilt entry point. For reproducible deployments, pin a reviewed Git commit. Maintainers must run pnpm run build and commit the generated lib/index.mjs and lib/index.d.mts when source changes. A built tarball from pnpm pack can also be installed with dsh plugin --profile web add ./package.tgz.

The profile supplies tools and fs. It also supplies web and its search/fetch providers. The standard DSH base includes them; custom profiles must configure them explicitly. This plugin shares the profile's provider lifecycle, proxy and transport limits. Private docs/ files remain excluded from Git and package contents.

For maintainers, run pnpm install --frozen-lockfile and pnpm run verify. Verification includes type checking, lint, unit tests, build, package checks and plugin:runtime:validate: a keyless Cordis Loader test of the built plugin with real DSH services, model-visible tools, file reads, argument/output validation, cancellation and unload cleanup.

协作可靠与反馈闭环

product_artifact_review 校验产品交接工件；product_feedback_close 将销售或 Beta 反馈绑定到具体动作、负责人、截止日期和验证状态，避免“写了文档就算完成”。

product_artifact_review validates product handoffs; product_feedback_close binds sales or beta feedback to an action, owner, due date and explicit verification state instead of treating documentation as completion.

Its workflow is:

Demand → Product → Marketing → Monetization → Product iteration / new opportunity discovery

It complements dsh-idea and dsh-growth:

• dsh-idea owns demand and opportunity discovery.
• dsh-product owns product definition, feasibility, delivery gates and PMF evidence.
• dsh-business owns the cross-cutting commercial strategy: value, business model, pricing and profitability.
• dsh-geo and dsh-growth own the marketing stage: discoverability, acquisition, activation and growth operations.
• dsh-sales owns monetization execution: qualification, closing, expansion and renewal.

Plugin Positioning and Collaboration Navigation

dsh-product is the product-delivery and PMF layer in the six-plugin system. It turns an evidence-backed opportunity into a shippable, observable and iterated product, using PMF evidence to decide whether to continue, adjust or pause.

• Owns: Product strategy, user/problem definition, POC, MVP, beta/release gates, PMF reviews and growth handoffs.
• Inputs: Opportunity handoffs and user/context evidence from dsh-idea, commercial constraints from dsh-business and behavior data from dsh-growth.
• Outputs: Product briefs, scope boundaries, validation plans, release checks, PMF reviews and growth handoffs for commercial strategy, sales and growth.
• Does not own: Opportunity discovery, pricing/profitability design, sales follow-up, growth operations or website content execution. It does not create code, design files or CRM records.

Positioning Architecture: Commercial Strategy Layer + Four-Stage Core Flow

The six plugins work together to turn a real demand signal into a deliverable product, reach target customers through marketing, and use monetization results to drive product iteration or discover new opportunities.

flowchart TB
    S["dsh-business<br/>Commercial strategy layer<br/>Value · model · pricing · profit"]

    subgraph MAIN["Four-stage core flow"]
        direction LR
        A["1. Demand<br/>dsh-idea"] --> B["2. Product<br/>dsh-product"]
        B --> C["3. Marketing<br/>dsh-geo + dsh-growth"]
        C --> D["4. Monetization execution<br/>dsh-sales"]
    end

    S -. "Sets commercial direction and guardrails" .-> A
    D --> R["Feedback<br/>Deals · renewals · revenue · cost"]
    R -->|Product iteration| B
    R -->|New discovery| A

    classDef strategy fill:#FFF4D6,stroke:#B7791F,color:#5C4500
    classDef stage fill:#E8F1FF,stroke:#3366CC,color:#173A7A
    classDef feedback fill:#E8F7EE,stroke:#2F855A,color:#1C4532
    class S strategy
    class A,B,C,D stage
    class R feedback

This plugin owns the product stage: after dsh-idea proves that a problem is worth testing, it defines what to build, how small to start and how to measure the result. dsh-business supplies commercial constraints; dsh-geo and dsh-growth take the product into marketing; and dsh-sales returns close, loss, renewal and unmet-need evidence.

Plugin Navigation

Plugin	Clear responsibility	Direct link
dsh-idea	External opportunities, demand signals, candidate directions and smallest useful tests	README
dsh-product	Product definition, POC/MVP, release gates and PMF (this plugin)	README
dsh-business	Cross-cutting commercial strategy, value, pricing and profitability	README
dsh-sales	Monetization execution: qualification, deal progression, closing, expansion and renewal	README
dsh-growth	Acquisition, activation, retention, revenue analysis and growth experiments	README
dsh-geo	SEO/GEO/AEO, content production and search/answer-engine discoverability	README

Recommended Handoffs

Output from this plugin	Hand off to	Handoff question
Product brief, POC/MVP scope and user-value evidence	dsh-business	How should we package and price it, and can the unit economics work?
PMF review, behavior data and core usage contexts	dsh-growth	Which funnel, retention or revenue lever should we test first?
Confirmed value proposition, capability boundaries and sales inputs	dsh-sales	Which customers are worth pursuing and how should we progress the deal?
Product language, user problems and release content	dsh-geo	How can target users discover the product through search and answer engines?

product_sales_handoff emits the versioned product-sales-handoff contract only after a proceed or scale product decision. It carries value evidence, proof points, delivery boundaries and commercial dependencies to dsh-sales; it never sets a price or expands the product promise.

Use the commercialContext field to attach a dsh-business commercial-handoff or its source path. Product scope and packaging may use those constraints, but they remain separate from demand and PMF evidence.

The plugin reads local Markdown and bounded CSV/JSON/JSONL evidence, can query public product information, preserves lineage and uses preview-plus-confirmation for file writes. Web research does not automatically send local files, cookies or login state to a provider. It does not create code, design files, CRM records or external campaigns.

See the Chinese README for the Chinese workflow and examples.