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 (5)
a board that lives in the repo. does it replace the dashboard, or just move it somewhere else?
Neither, really. The goal is shared context, not a new dashboard. Planning, ownership and delivery status live in the same repo as the code, so the PM view and the engineer view are reading the same source (
delivery.json) instead of two systems that drift apart. You can still render a board or weekly report from it, but the point is that everyone from management to delivery works off one context.Got it. So the board is just a view, and delivery.json is the thing both sides trust.
delivery.json 하나에서 보드·타임라인·주간 보고서를 만든다는 구조가 일관성을 확인하기 좋네요. 여러 작업 브랜치에서 같은 카드나 인계를 동시에 바꾸는 경우에는 충돌을 어떤 기준으로 정리하도록 안내하시는지도 궁금합니다. 카드 식별자와 인계 순서를 검증하는 예시가 있으면 팀에서 도입할 때 도움이 될 것 같습니다.
좋은 질문 감사합니다! 지금은 카드 ID나 인계 순서를 검증하는 예시는 아직 없습니다. 권장하는 방식은 trunk-based 개발입니다. 브랜치는 짧게 유지하고, 머지 전에 먼저 rebase 해서
delivery.json충돌을 일반 코드 충돌처럼 해결하는 것을 추천합니다.(EN: No validation example yet. We recommend trunk-based development: keep branches short-lived and rebase before merging, so any
delivery.jsonconflict is resolved like a normal code conflict.)