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.)