DeepSeek Harness 的程式碼庫原生交付管理：階段、交接與自動生成的週報

Why delivery state belongs next to the code

If you ship ToB or agency work, you already know the Friday ritual: dig through chats and sheets for "what moved," "who owns it," and "what slipped." The model in your IDE sees the repo; your board lives somewhere else. Alignment dies in the gap.

I wanted the opposite: delivery context as a first-class citizen of the codebase. Humans and agents share one source of truth. Views (board, audit, weekly) are projections — not another product to keep in sync.

That's what dsh-delivery-board is: a skill-backed DeepSeek Harness (dsh) plugin.

What it actually does

• Stage pipeline + cards — owner, due date, acceptance criteria, Definition of Done. Stages can evolve after init.
• Handoff audit — moving a card across stages records who handed what to whom, with notes.
• Weekly Markdown report — pipeline snapshot, shipped this week (terminal stage or archive), open risks, risks resolved in-window, and optional Next bets (Shape Up–ish framing without betting tables).
• Soft WIP limits — optional per-stage wipLimit. Board and move responses warn when a stage is over; moves are never blocked.
• Local board — /delivery Open the editable board serves a drag-and-drop UI on 127.0.0.1 that saves back to the same state. Offline HTML snapshot for teammates without DSH.

Install (web profile):

dsh plugin --profile web add github:jerryxff26-alt/dsh-delivery-board

Compatible with DSH engines.dsh >=0.2.0-rc.2 <0.3.0 (smoke path: 0.2.1-rc.2). Listed in awesome-dsh-plugin.

How you work day to day

Normal path is the /delivery skill: ask for outcomes in plain language; the model reasons, tools persist.

/delivery Initialize a governance delivery board for ACME
/delivery Hand off the API card to Test, assign Morgan
/delivery Open the editable board
/delivery Prepare the client weekly report for the week starting 2026-10-20

Deterministic controls (no model) live under /delivery-admin so they don't intercept skill prompts.

Templates cover a ToB pipeline (Client Requirements → … → Live) and a governance pipeline (Plan → … → Live). Gates are checkable checklists stored in state — they do not hard-block moves.

Methodology without a PM suite

v0.1.5 deliberately fused only two lightweight ideas:

1. Kanban soft WIP — visibility when a lane is overloaded, zero ceremony.
2. Weekly shipped / risk burn-down / Next bets — the report answers what left the building, what risk closed, and what we're betting on next.

What we did not build: Timeline views, Gantt, hard DoR gates, Dual Track ceremony. Stay usable in-repo, not another SaaS.

Boundaries (said up front)

• Board is single-machine (127.0.0.1); no realtime multiplayer.
• State travels with git pull/push, not a hosted sync service.
• Soft warnings over hard blocks — including WIP and gate checklists.

Feedback from people who run real BA → TL → build → test → go-live handoffs is especially welcome.

• Repo: https://github.com/jerryxff26-alt/dsh-delivery-board
• Discussion: https://github.com/deepseek-ai/deepseek-harness/discussions/9224