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:
| File | What it holds |
| story.md | The contract |
| technical-spec.md | The plan |
| grooming.md | The conversation and rationale |
| status.md | Current state and progress |
| decisions/, artifacts/ | Evidence and story-scoped decisions |
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:
- Read the repo.
- Make decisions.
- 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.
