Update: Same idea as before — structured fields + a readable body in the repo. The files are now .md (YAML front matter + Markdown body) instead of .yaml.
Here is my actual workday before I changed anything: write code in the IDE, alt-tab to the board to check what the ticket said, alt-tab back, forget half of it, alt-tab again. And when I finally got an AI agent doing real work for me, it could see all my code and none of my tasks. I was the API between the two.
MCP into Jira doesn't really fix this. It gives the agent a way to query the board, but that's another server, another auth flow, more schema in the context window — and the ticket still isn't in the pull request. The board updates later, by hand, if anyone remembers.
What I do instead
Tickets are just files in the repo:
.gitoza/tasks/tickets/{project}/{id}.md
What you actually need on top of that is a UI that renders the file and lets you edit it. Nobody wants to manage tasks by poking at raw markup all day.
Front matter for the machine, Markdown for the human:
---
title: Lockout after failed logins
type: bug
status: open
priority: high
tags: [auth]
---
## Description
Brief context for the agent and the reviewer.
## Acceptance criteria
- …
Here's what that looks like in Gitoza:
Two things fall out of this format, and both matter more than I expected.
The Markdown body means it renders. Description, acceptance criteria, checklists — you get a readable ticket in any preview pane, no special tooling required.
The front matter means state is structured. status, priority, type are real fields, not prose, so you can filter and roll them up without parsing English.
And for the agent it's just a file it already indexes. No tool call, no JQL, no "fetch issue then map fields." I can say "AUTH-102 is done, update it" or "draft a ticket for this bug" and it edits the ticket the same way it edits code. Way fewer steps, way fewer things to get wrong — a wrong field value shows up in the diff instead of silently landing in someone's SaaS board.
The other half of it: the ticket ships in the same PR as the change. Reviewers see scope and acceptance criteria next to the implementation, and after merge the file in the repo is the truth. No row someone forgot to flip.
I run the tool on itself
I build Gitoza, an open-source desktop app for exactly this (tickets, wiki, test cases, and runs as Markdown in Git), and I plan Gitoza with it. Every feature, every bug, every release is a ticket file in the project's own repo. Releases get planned, scoped, and closed without me opening a browser tab.
That's really the whole pitch. I stopped context-switching, and the agent finally got to see both halves of the job.
Try it: gitoza.com · GitHub
