Gsd Beads

gsd-beads

Beads issue tracking for gsd-core's plan→execute→verify→ship lifecycle

What it does

[gsd-core](https://github.com/open-gsd/gsd-core) is an agentic planning framework that turns a feature request into phased plans, tracked execution, and a ship gate, orchestrated through lifecycle commands and markdown under a project's `.planning/` directory. [Beads](https://github.com/gastownhall/beads) (`bd`) is a durable, git-native issue tracker with a local Dolt database, issue dependencies, and blocker tracking, built for work that has to survive multi-session handoff between people and agents.

`gsd-beads` is a gsd-core capability — an installable overlay, not a fork — that makes `bd` the single source of truth for gsd's task state: one beads issue per plan task, task dependencies become `bd dep` links, task completion closes its issue, and gsd's planner/executor/ship gate all read live `bd` state instead of duplicating it as hand-maintained `.planning/` prose.

Why not just use gsd-core's built-in tracking?

gsd-core's `.planning/` markdown is a good fit for plan *content* — what a phase is for, how a task should be approached, what "done" means. It is a poor fit for task *state*. Without a bridge, a developer who uses both trackers maintains two hand-written representations of the same work by hand: every planned task gets re-typed as an issue, every finished task gets closed twice, and the two drift silently because nothing compares them. `gsd-beads` makes `bd` the single source of truth for task state, so no duplicated task-state bookkeeping survives in `.planning/`.

Need	.planning/ markdown	beads
Query "what can I work on now?"	read files, reason	bd ready
Dependencies and blocking	prose ordering	first-class, enforced
Status across phases	per-phase files	one query
Survives milestone archival	archived away	persists
Visible outside one project	no	yes
Machine-updatable without