Je Jira-ticket als geheugen: AI-context die niet weglooptYour Jira ticket as memory: AI context that doesn't walk away
Goede AI-output begint met goede context. Maar context die alleen in een chatvenster leeft, ben je morgen kwijt. Zo bouwden wij geheugen in met CLAUDE.md en Jira.Good AI output starts with good context. But context that only lives in a chat window is gone tomorrow. Here's how we built memory into our workflow with CLAUDE.md and Jira.
Goede AI-output begint met goede context. Dat klinkt logisch, en toch gaat het daar zo vaak mis.
Wij werken al een tijdje met AI: code reviews, data-analyse, herhalende taken, kleine implementaties. Binnen een DDD + CQRS-architectuur, gedocumenteerd in een CLAUDE.md zodat Claude exact weet hoe onze codebase in elkaar zit. Werkt goed. Maar we hadden een zwakke schakel: onze Jira-tickets. Soms een omschrijving. Soms alleen een ontwerp. Soms alleen een titel. En dan verwacht je dat AI zinvol werk levert. Garbage in, garbage out.
Een teamlid dat nooit ziek is
CLAUDE.md klinkt als een bestand, maar het is eigenlijk ons levende architectuurdocument. Wat erin staat: de volledige DDD + CQRS-mappenstructuur. Naamconventies per laag, van domeinentiteiten tot event subscribers. De dependency-richting: Infrastructure afhankelijk van Domain, nooit andersom. Onze feature-flag-aanpak met .env-variabelen. Welke services in welk XML-bestand horen. En een volledig uitgewerkt CQRS-voorbeeld, van Console Command tot Message Handler.
Elke nieuwe aanpak of vastgelegd patroon gaat erin. Het resultaat: Claude Code heeft op dag één dezelfde context als een developer die al een jaar meeloopt. En eerlijk? Het dwingt ons ook om scherper na te denken over onze eigen keuzes. Want als je het niet kunt opschrijven, snap je het zelf ook niet goed genoeg.
Eerst verrijken, dan pas vragen
Voor de tickets bouwden we een /jira-enrich command in Claude Code. Die haalt het ticket op via de Jira MCP, controleert of de context volledig is, zoekt ontbrekende info op in de codebase zelf, herstructureert de beschrijving en stuurt alles terug naar het ticket.
Het belangrijkste zit in de volgorde. Een ticket met alleen een titel is niet nutteloos, het is een startpunt. De skill duikt eerst zelf de codebase in: welke bestanden zijn relevant, wat is het huidige gedrag? Pas daarna stelt Claude vragen, en alleen over wat hij écht niet zelf kan bedenken. Geen "wat is de verwachte uitkomst?" als dat al uit de code blijkt. Wel "is dit alleen een probleem op mobiel of ook desktop?" of "heeft dit invloed op de checkout flow?"
Het verschil klinkt klein. Maar je geeft als developer twee minuten antwoord in plaats van tien minuten context uit te schrijven die Claude zelf al had kunnen ophalen.
Het ticket als logboek
Na het verrijken doen we nog iets. Tijdens het werken aan een issue logt Claude Code automatisch terug naar het ticket. Als reactie, zonder dat ik erom vraag. Root causes die we vinden. Onverwachte bevindingen en edge cases. Welke bestanden zijn gewijzigd en waarom. Geblokkeerde punten. Ontwerpbeslissingen met onderbouwing.
Elke reactie heeft een categorie: FINDING, CHANGE, DECISION of BLOCKER. Kort, scanbaar, met bestandspaden en regelnummers. Aan het einde van een sessie volgt een SUMMARY met het totaaloverzicht.
Het ticket is nu geen taak meer. Het is een geheugen. Iemand anders pakt het op? De context staat erin. Ik kom er na twee weken op terug? De context staat erin. De klant vraagt wat er is gedaan? De context staat erin.
Zo begin je
Niet met een grote migratie. Niet met een nieuw platform. Gewoon klein.
Stap 1: schrijf op wat je altijd vergeet uit te leggen aan een nieuwe developer. Mappenstructuur, naamconventies, één concreet voorbeeld. Dat is je eerste CLAUDE.md.
Stap 2: kijk naar je slechtste tickets. Niet de tickets zonder omschrijving, maar de tickets met een omschrijving die je een week later zelf niet meer begrijpt. Wat mist er? Schrijf dat op als sjabloon.
Stap 3: automatiseer één ding. Bij ons was dat de ticket-verrijking. Kies iets dat je nu handmatig doet en altijd half doet omdat er geen tijd voor is.
De tools zijn er. Claude Code of een andere AI-assistent, Jira of een ander ticketsysteem: het principe blijft hetzelfde. En het is geen grote investering. Dit is een middagje werk.
Het verschil tussen een AI-tool die je gebruikt en een AI-tool die voor je werkt, zit in de context die je hem geeft. Begin daar.
Good AI output starts with good context. Sounds obvious, and yet that's exactly where things go wrong so often.
We've been using AI for a while now: code reviews, data analysis, repetitive tasks and small implementations. All within a DDD + CQRS architecture, documented in a CLAUDE.md so Claude knows exactly how our codebase fits together. Works well. But we had a weak link: our Jira tickets. Sometimes a description. Sometimes just a design. Sometimes only a title. And then you expect AI to deliver meaningful work. It can't. Garbage in, garbage out.
A team member who's never off sick
CLAUDE.md sounds like a file, but it's really our living architecture document. What's in it: the complete DDD + CQRS folder structure. Naming conventions per layer, from domain entities to event subscribers. The dependency direction: Infrastructure depends on Domain, never the other way around. Our feature flag approach with .env variables. Which services belong in which XML file. And a fully worked-out CQRS example, from Console Command to Message Handler.
Every time we pick a new approach or settle on a pattern, it goes in. The result: on day one, Claude Code has the same context as a developer who's been on the team for a year. And honestly? It forces us to think harder about our own decisions too. Because if you can't write it down, you don't understand it well enough yourself.
Enrich first, ask questions later
For the tickets we built a /jira-enrich command in Claude Code. It fetches the ticket via the Jira MCP, checks whether the context is complete, looks up missing information in the codebase itself, restructures the description and sends everything back to the ticket.
The key is in the order. A ticket with only a title isn't useless, it's a starting point. The skill dives into the codebase first: which files are relevant, what is the current behaviour according to the code? Only then does Claude ask questions, and only about what it genuinely can't figure out on its own. No "what's the expected outcome?" when that can be derived from the code. But yes to "is this only an issue on mobile or on desktop too?" or "does this affect the checkout flow?"
The difference sounds small. But as a developer you spend two minutes answering instead of ten minutes writing out context Claude could have retrieved itself.
The ticket as a logbook
After enriching, we do one more thing. While working on an issue, Claude Code automatically logs back to the ticket. As comments, without me asking. Root causes we find. Unexpected findings and edge cases. Which files changed and why. Blockers. Design decisions with their reasoning.
Every comment has a category: FINDING, CHANGE, DECISION or BLOCKER. Short, scannable, with file paths and line numbers. At the end of a session there's a SUMMARY comment with an overview of everything.
The ticket is no longer a task. It's a memory. Someone else picks it up? The context is right there. I come back to it two weeks later? The context is right there. The client asks what was done? The context is right there.
How to start
Not with a big migration. Not with a new platform. Just small.
Step 1: write down what you always forget to explain to a new developer. Folder structure, naming conventions, one concrete example. That's your first CLAUDE.md.
Step 2: look at your worst tickets. Not the ones without a description, but the ones with a description you no longer understand yourself a week later. What's missing? Write that down as a template.
Step 3: automate one thing. For us that was ticket enrichment. Pick something you do manually today and always do halfway because there's never time for it.
The tools are there. Claude Code or another AI assistant, Jira or another ticketing system: every stack is different, but the principle stays the same. No big investment either, it's an afternoon of work.
The difference between an AI tool you use and an AI tool that works for you is the context you give it. Start there.