Introducing Claude Storythe local dashboard for Claude Code projects

There is a point where using Claude Code stops feeling like chatting with an assistant and starts feeling like managing a real project.

At first it is simple. You ask Claude to work on a feature. It makes progress. You review it. You keep moving.

Then the project stops fitting in one session.

Now there are open tickets, follow-up issues, session handovers, roadmap phases, and half-finished work that needs to survive more than one terminal session. Some of it lives in repo notes. Some in markdown files. Some in GitHub Issues. Some in chat history. Some of it only exists in your head.

Session handovers are a big part of that. They are written records of what happened in a session, what decisions were made, why those decisions were made, what is still open, and what should happen next.

That is the point where the workflow starts to break down.

Not because Claude Code stops being useful. It is still useful. The problem is that once the work spans a project, there is no clean place to see what is happening, what changed, what is blocked, and what should happen next.

The problem is visibility

A lot of people focus on what Claude can produce in a single session.

That matters, but it is not the whole workflow.

Once you are working across multiple tasks, the bottleneck shifts. The hard part is no longer just generating code. The hard part is keeping track of the work: which ticket is active, which issue was discovered during implementation, what was handed off at the end of the last session, and whether the current work still matches the broader direction of the project.

That is a visibility problem.

And most developers solve it with a mix of whatever is nearby: markdown files, repo notes, TODO comments, issue trackers, terminal history, and memory. That works for a while, until the project starts depending on information that no longer lives in one place.

A local dashboard for Claude Code

That is why we built ClaudeStory.

ClaudeStory is a local dashboard and project memory layer for Claude Code.

It gives you one place to track tickets, issues, handovers, roadmap phases, and project state while Claude works. Instead of reconstructing the state of a project from scattered notes and session history, ClaudeStory keeps that state structured inside the repo and visible in a native Mac app.

The dashboard is the point. You stop carrying the whole project in your head.

You can open it and immediately see what Claude is working on, what moved forward, what got blocked, what issues were found, and what still needs attention. The project starts feeling less like a long stream of prompts and more like a system you can actually manage.

When Claude-generated work is easy to see, it becomes easier to manage.

What changes when the work becomes visible

The value of a dashboard like this is not just that it looks cleaner.

It changes the workflow.

Tickets stop disappearing into chat history. Issues stop living as random TODOs. And session handovers stop being fragile notes tied to a single session.

In ClaudeStory, handovers are part of the project record. They capture what changed in a session, which decisions were made, why those decisions were made, what is still unresolved, and what should happen next.

That matters because code history alone cannot tell the whole story. Git can show the diff. It can show the commit. But it usually cannot show the reasoning behind a decision, the tradeoffs that were considered, or the context that made one path make sense at that moment.

Over time, handovers become a historical record of how the project evolved. They help the next session start with continuity, and they give you something to refer back to when the question is not just "what changed?" but "why did we do it this way?"

A lot of the friction around AI-assisted development is not that the model cannot help. It is that the work it produces is hard to track once it spreads across a real project. ClaudeStory is built to make that work legible.

So instead of asking "what did Claude do last time?" or "where did that issue come from?" or "what was supposed to happen next?", you can look at the project state directly.

Why local matters

ClaudeStory is built around local files for the same reason. Project state lives in a .story/ folder inside the repo. That means it stays inspectable, portable, and close to the work itself. You can read it, version it, and understand it without depending on a hosted memory layer or a black box service.

That also means you are not pushing AI-generated project noise into shared tools just to keep track of what Claude did. The state lives with the project.

That was important to us from the beginning. We did not want a tool that felt like another layer of infrastructure sitting on top of the repo. We wanted something that made the repo itself easier to work with. Local files turned out to be the right foundation for that.

Learn more about the CLI and file structure.

A cleaner starting point for every session

The dashboard is only one half of it.

ClaudeStory also gives Claude Code a cleaner way to start. With the /story command, Claude can read the current project state directly: what exists, what is in progress, what changed, and what comes next. New sessions start from the project's actual state, not from guesswork.

That is the part that makes the whole system feel connected. The dashboard helps you see the work. The local file structure keeps that work grounded in the repo. And /story gives Claude a practical way to pick up where the project actually is.

The product in one line

ClaudeStory helps you track and manage Claude Code work across a project.

Not just one prompt. Not just one session. The project.

If you use Claude Code on ongoing projects and want one local place to track tickets, issues, handovers, and project state, that is why we built ClaudeStory.