[Feature Request] First-class persistent roadmap / work-item system

Summary

Claude Code has TaskCreate for session-scoped task tracking and CLAUDE.md for durable instructions, but nothing for durable work-item tracking — the equivalent of an issue tracker or backlog that both the user and Claude can query, update, and plan against across sessions. I've built this ad-hoc for a project (109 items tracked, 65 completed) and it's been genuinely load-bearing. Proposing Claude Code add native support.

Reference implementation lives in Babelr, under .daedalus/roadmap/.

The gap

Today's persistence layer looks like:

• TaskCreate / TaskList — excellent for within-session step tracking, but the state evaporates between conversations. You can't come back next week and ask \"what were we going to do next?\"
• CLAUDE.md — durable but imperative (rules, conventions). Not designed for \"here are 40 things we haven't built yet, ranked.\"
• Auto-memory (the memory/ directory pattern) — holds facts about user/project/feedback, not prioritized work.
• GitHub Issues — works if the project is public and you're willing to context-switch to a browser. Friction is high enough that I've watched myself and other users just... not use it for early-stage solo work.

The missing primitive is a structured, queryable backlog that lives in the repo, survives compaction, and Claude can interact with directly.

What I built

A file-based roadmap system at .daedalus/roadmap/:

• index.json — flat list of work items with {id, title, description, type, priority, status}
• CLI commands: daedalus roadmap list, daedalus roadmap add \"...\" --priority P1 --type feature, filters by status/priority/assignee
• A custom subagent (.claude/agents/roadmap.md) that can read and reason about the backlog
• Status flow: backlog → ready → in_progress → review → done
• Priority levels P0–P3, item types (feature, bug, chore, security)

Outcomes

Current state of my project:

• 109 items tracked
• 65 marked done
• Breakdown: 8 P0, 36 P1, 51 P2, 14 P3

Concrete things it unlocks that TaskCreate can't:

1. Cross-session planning conversations. I can walk in cold and say \"look at the roadmap, what's next?\" and Claude gives a prioritized answer grounded in real state, not guessing from the last commit.
2. Context for hard decisions. When deciding to abandon a P2P mesh WebRTC approach after 11 failed bug-fix attempts and switch to an SFU topology, the roadmap held the history of those attempts. Claude had real evidence to weigh \"more patches vs. change the shape\" rather than fresh-eyes handwaving.
3. Decision audit trail. Superseded items get marked with why they were superseded. Future sessions can trace why the code looks the way it does without me having to re-explain.
4. Natural scope containment. When Claude proposes a refactor, I can say \"open a roadmap item for the follow-ups, keep this PR focused\" — and it actually happens because writing to the roadmap is as easy as writing to memory.

Rough estimate: I'd say this has made early-stage feature planning with Claude Code ~30–50% more productive because we're not rebuilding context every session.

Proposal

A first-class roadmap feature in Claude Code. Rough shape:

• File-backed (like memory), so it lives in the repo and is version-controlled
• Structured schema: id, title, description, status, priority, type, timestamps, optional assignee
• Built-in tools: RoadmapList, RoadmapAdd, RoadmapUpdate, RoadmapGet (analogous to the Task* family but persistent)
• Status transitions surfaced in the TUI so users can see the backlog at a glance (similar to how tasks render today)
• Optional bidirectional sync with GitHub Issues for teams that use both
• Skill integration: a /roadmap slash command that opens it for the user to edit directly, the way /memory works for memory files

Why in-tree (file-backed) rather than a separate service: same reason memory is in-tree — it needs to travel with the repo, be diffable in PRs, and be readable by humans without tooling.

Why this belongs in Claude Code rather than userland

I built the userland version and it works, but:

• Every project rebuilds the same wheel with slightly different schemas
• The subagent/CLI integration is fiddly — most users won't invest the effort
• Without a standard shape, skills and hooks can't compose around it
• The TUI can't render something it doesn't know about; \"what's on the roadmap\" lives at the same layer as \"what tasks are open\" and should get the same treatment

Happy to share the full schema and CLI source if useful — the Babelr repo above has it all in-tree.