We Replaced Jira With Markdown Files

Early this year I was wiring Claude into Jira through an MCP server. It worked, and every session it felt slightly wrong: slow round trips, a schema I did not control, structure sitting somewhere the agent could not see while it was reading the code. The fix was almost embarrassingly simple. Put the ticket in the repo, as markdown. I pitched it to a colleague, and off we went. Seven months later: 15 projects across 10 repositories, 165 live tickets, 12 people on the board including non-developers, and no Jira licence. This post is why we left and what we built. Two follow-ups cover the rest: the skill and the loop that let agents work these tickets , and the three review layers that keep the output honest . What was actually wrong with Jira The cost was easy to name: roughly €2,000 a year for something we used maybe 5% of. It was not the reason we left. Every user had to be paid for, so the board was implicitly rationed. Performance degraded as projects grew. The features we wanted sat behind paid plugins. Automations were clumsy enough that we mostly did not write them. And the board was close to what we wanted without ever being it, because that last gap lived in someone else's product roadmap. None of that is fatal alone. Together it means the tool shapes the team instead of the other way around. The constraint that ruled out the obvious answers We are one team maintaining ten separate repositories that ship independently of one another, across TypeScript, C#, Java and PowerShell. A monorepo was never realistic. That kills the usual alternatives. GitHub Issues comes closest and misses twice: issues are scoped to one repository, so cross-repo visibility becomes somebody's weekly spreadsheet, and despite feeling like part of the repo they are not in it. They live in a database behind an API. Not files, not on the branch, not in the diff, and not something an agent editing the code can read without a round trip. Every hosted alternative moves the work further away s