Why another board — and why it should live in git
If delivery state lives only in Slack threads and a SaaS board nobody opens, humans and coding agents drift. Who owns the card? What does "done" mean? What shipped this week?
dsh-delivery-board keeps stages, owners, handoffs, soft WIP hints, a weekly Markdown client report, and a local kanban + calendar Timeline in one in-repo file (delivery.json by default). Views are projections of that same state — reviewable in PRs, offline-friendly, and intentionally not a Jira/Linear replacement.
This post is about v0.2.0: the board now runs as a standalone CLI. You do not need DeepSeek Harness (dsh) installed. (The optional DSH plugin path still works unchanged.)
Distinct from the earlier Dev.to post that introduced the project mainly as a DSH plugin. Here the headline is: CLI-first, works alone.
30-second standalone quickstart
npx github:jerryxff26-alt/dsh-delivery-board init '{"customer":"ACME","template":"governance"}'
npx github:jerryxff26-alt/dsh-delivery-board card '{"title":"API integration","stage":"analyze","owner":"Ada"}'
npx github:jerryxff26-alt/dsh-delivery-board open # loopback board + Timeline; Ctrl+C to stop
npx github:jerryxff26-alt/dsh-delivery-board weekly
If/when the package is on the npm registry under dsh-delivery-board, the same commands work as npx dsh-delivery-board …. Until then, the GitHub install string above is the reliable path.
What you get
- Stage pipeline + cards — owner, due date, acceptance criteria, Definition of Done
- Handoff audit — stage moves record who handed what to whom
- Weekly Markdown report — pipeline snapshot, shipped this week, handoffs, open/resolved risks, optional next bets
- Soft WIP limits — warn when a stage is over; never hard-block
-
Local editable board — drag-and-drop on
127.0.0.1, saves back to the same file - Timeline view — calendar-axis bars per card (created → handoffs → shipped/archived), due markers, light/dark
- Offline HTML snapshot — single read-only file teammates can open without the CLI
Optional: DeepSeek Harness plugin
Same domain model, skill-backed /delivery workflow for agent-led planning and moves:
dsh plugin --profile web add github:jerryxff26-alt/dsh-delivery-board
Tested with DSH 0.2.1-rc.2 (also compatible with 0.2.0-rc.2). No runtime dependencies.
Compared to alternatives (short)
| Need | This project | Typical SaaS kanban | Markdown checklists alone |
|---|---|---|---|
| Lives in the git repo | Yes (delivery.json) |
Usually remote | Yes, but unstructured |
| Handoff audit + weekly client report | Built-in | Custom fields / exports | Manual |
| Local editable UI + Timeline | Loopback board | Full web app | No |
| Works with AI coding agents | CLI for any shell; optional DSH skill | Often API / MCP | Prompt-only |
Links
- Repo: jerryxff26-alt/dsh-delivery-board (MIT)
- Release notes: v0.2.0 — standalone CLI
- LibHunt listing: libhunt.com/r/dsh-delivery-board
If this saves a standup or a messy Friday paste, a star helps others find it. Feedback welcome on the repo.
Top comments (2)
a board that lives in the repo. does it replace the dashboard, or just move it somewhere else?
delivery.json 하나에서 보드·타임라인·주간 보고서를 만든다는 구조가 일관성을 확인하기 좋네요. 여러 작업 브랜치에서 같은 카드나 인계를 동시에 바꾸는 경우에는 충돌을 어떤 기준으로 정리하도록 안내하시는지도 궁금합니다. 카드 식별자와 인계 순서를 검증하는 예시가 있으면 팀에서 도입할 때 도움이 될 것 같습니다.