Part 2 of 2. Part 1 made the case for moving delivery out of Jira and into the repo. This is the how, concrete enough to copy. 

In Part 1, I argued that a tracker quietly makes humans the integration layer, and that moving delivery artifacts into the repo hands much of that assembly work to the tooling. 

This is the operating model that fell out of that idea. 

The goal is simple: 

Every artifact should be readable by both a human and an assistant without translation. 

Stories, decisions, sprint history, status updates, technical plans, reports: all of it lives in a form that the team can read directly and that an assistant can traverse without APIs, connectors, or synchronization. 

None of this is exotic. It’s markdown files, Git, and an agent-aware editor like Cursor or Claude Code. 

The discipline is what makes it work. 

Two repos, two rhythms 

The first decision is to stop forcing artifacts and code to share a history. 

They have different cadences, different gates, and different owners. 

So they get different repos. 

The delivery repo holds artifacts only: stories, sprints, decisions, context, prompts, and reports. 

The code repos stay exactly as they should be: feature branches, pull requests, CI, and release workflows. 

Each code repo’s CLAUDE.md points back to the delivery repo so that any assistant reading the code also has access to the project’s intent and decisions. 

That separation solves a surprisingly common problem. 

Trackers go stale because updating them competes with shipping code. When artifacts live in their own frictionless repo, there is nothing competing for attention. A decision or status update takes seconds to commit and lands immediately. 

No connector, no second system 

There is no tracker and no connector. 

The files are the context. The same editor the engineer uses to build is where the assistant reads stories, specifications, decisions, and status. 

That is also why this is a team model rather than a PM productivity hack. 

Managing a project through a Jira connector is something one person does from their own AI session. Here, everyone works from the same source. Engineers build from it. Designers contribute to it. Reports generate from it. 

Nobody waits for a board to catch up. 

The story is a directory, not a ticket 

Our unit of work is a folder, not a line item. 

A story directory holds a few files, each with one job: 

Together they form the work surface. 

When an engineer opens a story, the assistant sees the same picture they do: the requirements, the implementation plan, prior decisions, open questions, and evidence. 

Dependencies are recorded as simple wikilinks such as [[E2-1]], giving assistants a graph they can traverse rather than a collection of disconnected tickets. 

For engineers: a control plane, not PM docs in Git 

It would be easy to read all of this as project managers moving their paperwork into Git. That is not what it is. 

For an engineer, the repo turns delivery artifacts into part of the work surface, instead of a parallel system to keep in sync. 

Start with the thing engineers feel every day: context switching. Recovering intent from a tracker means leaving the editor, finding the ticket, reading a description written weeks ago, and scanning the comments. Here, story.md, technical-spec.md, and grooming.md sit beside the code. You read the contract, the plan, and the reasoning without leaving Cursor, and so does your agent. 

It also front-loads the ambiguity. The spec-drafting prompt asks the agent to flag acceptance criteria that are vague or untestable before any code gets written, so you are not halfway through a build when you realize the AC could mean two things. 

Evidence lives with the work. artifacts/ is the natural home for eval outputs, screenshots, scorecards, generated datasets, and review forms. When someone revisits the story to debug or review, the proof is right there, not scattered across Drive and Slack. 

Dependencies are plain text. A wikilink like [[E2-3]] is easier to traverse than a tracker’s dependency UI, for you and for the agent, and you can grep the whole tree. 

The code ties back to the contract. Code repos point at the delivery stories, and tests validate the acceptance criteria in story.md, so a reviewer checks against a real definition of done rather than “matches the ticket.” 

The quiet win under all of it: no stale duplicate truth. A tracker usually becomes a second copy of what the engineer learned while building, and it drifts the moment the build teaches you something. Here, when the spec changes, the same repo captures the change, the reason, and the evidence, in one place. 

A lightweight engineering control plane, where context, decisions, specs, evidence, and status live where developers and agents can use them directly. 

The coding agent inherits the contract 

When a coding agent opens a story, it inherits the contract. 

The story, acceptance criteria, technical spec, grooming notes, and code all sit in the same context window. 

Before implementation starts, the engineer has the agent draft technical-spec.md from the story and checks that the plan actually matches the intent. 

Misunderstandings surface in prose instead of three commits later. 

Then the acceptance criteria become something the agent can actively steer toward. 

The definition of done is no longer a memory of a meeting. It is a file sitting beside the code. 

That changes behavior. Agents drift less. They gold-plate less. They spend less time solving adjacent problems and more time solving the one the story actually describes. 

In a tracker-centric workflow, those criteria often live somewhere the coding agent never looks. 

The sprint is a narrative, not a board 

If the story is the unit of work, the sprint is the unit of time. 

One sprint. One file. 

The sprint document contains the goal, committed stories, a running log of mid-sprint events, delivered work, and the retro. 

The key rule is append-mostly. 

Committed work stays committed. When reality changes, and it always does, you add an event explaining what changed and why. 

The sprint becomes a readable history instead of a constantly rewritten snapshot. 

That turns out to be useful for both retrospectives and stakeholder conversations. 

Decisions live where their scope lives 

One small rule removes a surprising amount of friction. 

Story-level decisions live with the story. 

Sprint-level decisions live in the sprint file. 

Project-level decisions live in /decisions/. 

Six months later, when someone asks why a choice was made, there is a dated file with the answer. 

Every ceremony ends in a commit 

The decision lives in the file before the meeting ends. 

If “I’ll update it later” creeps back in, the model degrades into Jira-by-other-means within a sprint. 

Planning, standup, review, and retro all follow the same pattern: 

1. Read the repo. 

2. Make decisions. 

3. Commit the outcome. 

The ceremony is the conversation. 

The commit is the memory. 

The same data feeds all of these. 

A single status.md file becomes the morning brief, the risk log, the retro, and the stakeholder report. 

You author once and query many ways. 

Status itself remains human-owned. The assistant drafts it from commits and chat context, but a person reviews and commits the result. Otherwise the no-code days (debugging dead ends, credential issues, design discussions) disappear from the record. 

Where it becomes an asset 

Prompts do not stay prompts. 

A query used a few times becomes a skill. 

The skills, plus the directory structure and conventions, become a scaffold. 

The scaffold becomes reusable. 

The next engagement starts from a template that already knows how stories, sprints, decisions, and ceremonies fit together. 

The cost of standing up a new project keeps dropping because the operating layer already exists. 

One principle keeps that from tipping into over-automation: 

Automate aggregation and synthesis. Do not automate judgment. 

Draft the brief. Draft the retro. Draft the report. 

But decisions, scope, priorities, and commitments stay human. 

The moment you automate judgment, the model quietly rots. 

What it costs, honestly 

It isn’t free. 

The committing discipline is load-bearing, and no tool nags you into doing it. 

It assumes the team works in an agent-aware editor. Open these files in a plain editor and much of the leverage disappears. 

Design tools do not go away. Figma and Miro still exist. The repo simply becomes the place where design decisions and handoffs are recorded. 

There are still open questions too. On a small team without dedicated QA, who formally signs off that acceptance criteria have been met? We are still working that out. 

I’d rather name those edges than pretend the model is finished. 

The honest reframe is that this approach does not eliminate the tracker’s job. 

It absorbs it. 

The consistency Jira enforced for free becomes something you own on purpose. 

For the kind of AI-native work we do, that ownership is the point. 

The repo is already where the work happens. 

So we started asking a simple question: 

What happens if coordination happens there too? 

This operating model is our current answer. 

Not because Git is magical. 

Not because Jira is broken. 

Because operational context now accumulates in one place, and we’re interested in what becomes possible when the people, the artifacts, and the assistants all work from the same source. 

Whether this becomes a broader pattern remains to be seen. 

But after working this way, it is difficult to imagine moving the source of truth back into a system designed primarily to describe the work rather than participate in it. 

How we moved from Jira + AI connectors to a single repo where humans and agents work from the same source of truth. 

Part 1 of 2: The why. Part 2 walks through the operating model itself. 

Almost every product tool I open lately is reaching for the same idea: put an AI copilot on top of the backlog. Jira has Rovo. ServiceNow ships agile story generation that claims to cut epic breakdown by around 80%. Linear, Azure DevOps, and the rest are adding a button that turns a fuzzy feature into a tidy stack of tickets. 

That is genuinely useful. I do not want to wave it away. 

The version I run into most these days is subtler. Plenty of teams now connect Jira to their AI assistant as an MCP connector (in Claude’s Cowork, for instance) so the assistant can read and update tickets for them. For a solo PM, that can feel like a small miracle. The assistant can summarize the board, draft updates, and move work along without the usual tab-hopping. 

But the shape of the system has not really changed. 

The tracker is still a second system the AI has to reach into over an API, one round trip at a time. Someone still has to keep that system in sync with the work. The integration layer did not disappear. It just got automated. 

Which leaves a more interesting question sitting in the open: 

If AI can generate the work, and read the work, do we still need the tracker to be the home of the work? 

At Robots & Pencils we build AI products for enterprises, which means we have felt the gap between how these systems get built and how we were managing the building. On a recent enterprise pilot, I started an experiment: run delivery without Jira as the source of truth. 

Generate the epics and stories from a skills pipeline. Let the whole team (PM, designer, engineer) work out of a Git repo where stories, sprints, and decisions are versioned markdown files. 

The goal was not a tidier way for me, the PM, to manage a project from my own AI session. That would have been a nicer cockpit, not a better operating model. 

The goal was to put the whole team on one source: the engineer in their editor, the designer in theirs, no connector in the middle, and nobody waiting on me to sync a board. 

It worked well enough that it is quietly becoming how we deliver AI-native work. 

This piece is the why. The next one is the how. 

The tell: who’s doing the integrating 

Jira makes the human the integration layer. 

The work is there, but it is scattered into pieces: the ticket, the related tickets, the research doc, the decision from three weeks ago, the acceptance criteria that changed in grooming, the Slack thread nobody quite remembers. 

Before anyone can move, someone has to stitch the picture together. 

That was a reasonable deal when the only thing that could read a ticket was a human. 

It’s a worse deal now. 

The assistant doing more of the building can read the surrounding context, if the context is somewhere it can actually reach. When a story is a markdown file in the repo, the assistant can take in the story, the technical spec, the grooming notes, and the code itself in one pass, because they’re all just files in the same working surface. 

Nobody has to describe the map. The assistant can follow the links. 

Wiring the tracker into an AI assistant over MCP is still progress. It hands some of that assembly work to the assistant. But it also preserves the old shape: second system, API round trips, and a project record that has to be kept aligned with the place where the work is actually happening. 

Repo-native delivery asks for a cleaner cut. 

Move the artifacts to where the work and the AI already live, and the integration layer stops being a person. 

What about Linear? 

Linear is excellent. It is what a better tracker looks like: clean, fast, developer-friendly, with strong GitHub integration and improving AI. Plenty of teams, including parts of ours in the past, moved happily from Jira to Linear. 

But even Linear is still a tracker. The work artifacts live in Linear’s database. The AI reaches in through integrations. Engineers still cross from the issue tracker to their editor and back. The fundamental shape, a separate coordination system sitting next to the execution environment, stays intact. 

Repo-native delivery goes one step further. It asks whether we still need that separate system at all, once context is cheap and an assistant can read across stories, specs, decisions, and code in one pass. We are not trying to replace Jira or Linear with a nicer interface. We are moving the source of truth into the environment where the work, and the agents, already live. 

What changes when the repo is the truth 

The benefit I expected was speed. 

The benefit that actually mattered was quieter seams between people. 

The engineer felt it first. Their coding agent could open a story with the real acceptance criteria in context, not a paraphrase pasted into a chat window. That meant the agent built toward the definition of done instead of drifting toward a plausible interpretation of it. 

Even better, the criteria became something the agent could check its own work against. The story was not just an instruction. It was the contract. 

And the engineer never left the editor to find any of it. The story, the plan, and the reasoning sat beside the code, not behind another login. 

Handoffs changed too. 

A designer could drop an artifact and a one-line note into the story folder, and the next person’s editor would read it when they opened the story. No tagging. No “did you see my message?” No quiet dependency on someone remembering to move context from one place to another. 

The same source also starts feeding many views. One status.md file can become the morning brief, the sprint risk log, the retro, and the stakeholder report. 

You author once and query many ways. 

That is where the repo has an advantage over the tracker. A tracker’s data mostly feeds the tracker’s own views. Repo data feeds anything a team can write a prompt for. 

The query I lean on most isn’t a fancy one. Each morning, instead of asking the team what they did yesterday, I ask the repo. 

Jira is a coordination layer. The repo is where execution happens. 

The same assistant helping implement a story can also summarize sprint risk, trace dependencies, draft stakeholder updates, and explain why a decision was made. 

When the same system can participate in both coordination and execution, the boundary between the two starts to look less inevitable. 

That shift shows up in small ways at first. 

The prompts we run do not stay prompts. A query used a few times becomes a skill. The skills, plus the repo structure and conventions, become a scaffold. And that scaffold is portable. 

The next engagement does not begin with an empty Jira project. It begins from a template that already knows how stories, sprints, decisions, prompts, and ceremonies fit together. The operational cost of standing up a new project drops because the operating layer already exists. 

That is what turns a workflow into a capability. 

It also reframes the PM’s job. 

When a skill can draft the stories, the PM’s edge moves upstream: framing the right epics, encoding judgment into the pipeline, and curating the context the whole team’s tools draw from. 

The craft shifts from producing the backlog to designing the system that produces it. 

The judgment was always there. Now it has somewhere explicit to live. 

Maybe the bigger question is not how we teach our trackers to work with AI. 

Maybe it is whether the work still needs a separate coordination system at all. 

Was the tracker ever the right home for the work in the first place? 

Ours moved into the repo, and it has not asked to move back. 

Stay tuned for Part 2, where Nilesh walks through the operating model: the two-repo pattern, the story directory, the sprint-as-narrative, and how every ceremony ends in a commit, so you can copy it, not just nod at it.