Two weeks ago I had listed out the problems I could remember offhand: https://news.ycombinator.com/item?id=47956979
It sounds like there's intentionally no attempt to handle the last one (that this is by devs for devs), and points 3 and 4 might be addressed somehow since it mentions syncing automatically. Does it store data separate from git to avoid the first two?
- Issue state is not tied to commits in the checked out repo. Events live in append-only user-scoped logs and are materialized independently of the checked out branch, so switching branches does not change issue state. This is solved with git worktrees.
- Epiq keeps state in a dedicated state branch and does not put issue data into normal code history. The working branch stays clean.
- Sync uses normal git push/pull semantics.
- Multi-user conflicts are prevented because each user writes only to their own immutable event log file. You never co edit a file. Logs converge state in memory from the combined event stream. There’s no shared mutable issue document being edited.
- The non-developer distribution can be addressed with exported state .md files (with the board as ascii). They are currently not generated automatically, but you can generate them at will. [edit - addition: Considerable effort has also been put into making the tool accessible to non-technical people, so there is auto completion, hints, a command palette with descriptions of each command, arrow key navigation and so on. It is my hope that anyone can pick it up rapidly. And a web interface could definitely be crafted for that usecase]
I’d (re)consider a couple of things if you intend to work on it and make it viable for a wider audience.
1. Who is it aimed for? If product managers and designers _are_ in scope e.g. you imagine full engineering teams using it, then a TUI isn’t gonna cut it. It’s a great interface choice for devs but I don’t think it’s organizationally viable to force everyone else in the terminal.
2. I’d think about either having a central issues repository as a default / recommended option or creating an easy way for linking issues together across repos. To me, as appealing as it sounds to have your code and issues together, these things often evolve at a different pace. If I want to edit an issue I’m working on to add some new info or address changing requirements, I almost definitely don’t want to commit and push it with my local WIP version of the code.
Let me address these:
1. I envision people already comfortable with the terminal as the first to pick it up, but as someone else pointed out, a considerable amount of effort has gone into lowering the threshold and making it usable for people with limited command-line experience. I can also definitely see a future web UI being added over time.
2. There is no requirement to run Epiq alongside your codebase - you could also use a separate repository dedicated to issue tracking. When you run epiq, it traverses upward until it finds the nearest project definition. In theory, you could initialize Epiq at a higher-level scope and have multiple child repositories share the same board state, although that setup has not been officially verified or supported yet, so I would wait until there is a version that explicitly supports it.
The current TUI is built with Ink, which is a React renderer for the terminal, so conceptually the UI structure already maps naturally to the web.
> The MCP server lets AI tools interact with Epiq in a predictable way.
Or maybe just publish a skill for the agent to use your CLI? The agent alredy uses CLI commands to interact with git itself
There is a small level of noise in TUI output, and structures that are easily parsed by a human can be ambiguous for an agent (for instance column layouts). You could definitely let agents interact with Epiq purely through the CLI, but the idea behind the MCP server is to provide stable, predictable interfaces where determinism matters.
This. Skills effectively turned MCPs obsolete in the vast majority of MCP applications. A single CLI tool implemented following a progressive disclosure style doesn't even need a agent skill for coding agents to use it effectively.
To be clear, I'm really into this. I'm using a custom git-based agent and this is a viable replacement for its issue tracking.
Do I understand correctly that if 2 people add a lot of information to one issue only one of them 'wins' and becomes visible? Or is it more subtle?
If only the latter one becomes visible, how do you get to the edits of the other person and 'merge' it again?
In the event of conflicting updates to the same text block (currently title or description fields), later events take precedence.
What you can do is use commands like ":peek prev" (takes you to the previous edit), ":peek 1h", or other time-travel commands to inspect previous states and manually recover overwritten changes if needed.
