ZenHub

Promptfree, for everyone, and the only version there is

Copy the prompt for Claude CodeCopy the prompt for CodexCopy the prompt for Cursor

Copy

Build me the planning layer over GitHub that replaces ZenHub.

The idea is exactly right and worth copying precisely: **the issues stay in GitHub and nothing is duplicated.** A tool that copies issues into its own database creates two truths, and developers update neither.

STACK
- Node 20+ with Fastify, server-rendered HTML with a little vanilla JS
- SQLite through better-sqlite3, WAL mode — for the layer's own data and a read cache only
- GitHub API with webhooks
- Caddy in front

WHAT LIVES WHERE
- **GitHub owns**: the issue, its title, body, comments, labels, assignees and state. Never write a copy you treat as authoritative
- **Your layer owns**: sprint membership, estimate, epic relationships, board column when it is not a label, and the history of all of those
- A local cache of issues for fast rendering, refreshed by webhook and reconciled by a periodic full sync

THE DATA MODEL
- issues_cache: repo, number, title, state, labels_json, assignees_json, updated_at, etag
- estimates: repo, number, points, set_by, at — append-only, so changing an estimate mid-sprint is visible
- sprints: id, name, starts_on, ends_on, goal
- sprint_items: sprint_id, repo, number, added_at, removed_at — **append-only, and this is what makes scope change measurable**
- epics: id, title, description; epic_items linking issues
- column_state: repo, number, column, at

SYNCING WITHOUT LOSING THINGS
- Webhooks for issues, comments, labels and pull requests
- **A reconciliation job that lists everything changed since the last cursor**, because webhooks are lost and delivery is not guaranteed. Without it your board is quietly wrong
- Respect rate limits: conditional requests with ETags, and back off on the secondary limit rather than retrying into it

THE BOARD
- Columns from labels or from your own column state — pick one and be consistent. **Two sources for a card's position is the bug that makes a board untrustworthy**
- Drag moves the card and writes the change to GitHub where GitHub owns it
- Pull request links shown on the card, because 'is it in review' is the question the board is asked most

REPORTS THAT ARE ACTUALLY TRUE
- Burn-up with scope on it, from the sprint_items history. **Scope added mid-sprint is the single most useful fact a sprint report contains and burn-down hides it**
- Velocity over the last several sprints as a range, never a single number
- Cycle time from first commit to merge, which is measurable from the repository and means more than any estimate
- Issues open with no activity for a fortnight

WHAT MATTERS MOST
GitHub stays authoritative, and sprint membership is append-only. The first is why developers use it; the second is why the reports are honest.