What is repo-native?
The repo is the source of truth.
That sentence is the whole idea. Repo-native software keeps the records that run a company (todos, content, plans, mail history, the map of what has been built) as files inside a git repository. The CLI, dashboard, website, and service are views of those files. They can make the work easier, but none of them gets to become the only place where the truth exists.
This is a storage decision, not a terminal aesthetic. A teammate can edit the records through a polished client. A deployment can render them on a global network. An email provider can deliver a message. The test is what remains when the tool goes away. If the complete, readable record is still in the repo, the system has a graceful exit. If deleting the app deletes the truth, it does not.
We call this category repo-native.
Why this matters now
Putting structured operational data in files used to ask a lot of humans. People had to remember formats, keep links straight, and resist the convenient empty field. SaaS earned its place by handling that structure for us.
Agents change the trade.
An agent already knows how to read a directory, search markdown, edit a file, and explain a diff. Give it a checkout and it can work from the formats and ownership rules already visible there. The manifesto makes the broader cost comparison; this post focuses on what that shared workspace makes possible.
More important, git puts a review boundary around the work. An agent can draft a post, reorganize a queue, or update a plan on a branch. Its changes do not become company reality merely because the agent finished. They become a pull request: a finite diff a human can read, question, accept, or discard.
That makes the repo a shared workspace both sides can understand. Humans write direction and review changes. Agents do the work between. The handoff is not trapped in a chat session because the files carry the state.
One branch, one launch
A launch makes this concrete. Code, launch copy, email source, and the task outcome can live on one branch. The pull request shows the release as one proposal; after merge, the site can render the post and a delivery service can send the message. The history keeps the plan, words, decision, and diff together.
The repo-native manifesto carries the broader historical case; this post stays with the practical question of what the convention changes now.
The idea in practice
The repo.md products illustrate the claim across four jobs. RepoTodo keeps the work queue in markdown and renders it through a CLI, dashboard, and agent tools. Folderblog treats the posts folder as the CMS. Sidequest reads the map of your projects from their repositories. Tinbox keeps mail history in git while a service handles delivery. They cover different jobs, but compose through the filesystem: no webhook is required for the todo tool to see that a post exists.
These are not four attempts to pull every workload into markdown. Secrets belong in secret managers. Payment processing, high-volume analytics events, large media, and realtime multiplayer state have better homes. Repo-native claims the system-of-record layer where files, git, and asynchronous review are strengths. Services still render, compute, and deliver at the edges.
The limit matters. “Everything must be a file” is a slogan. “The records you should own must survive their tools” is an operating rule.
Start with the map
Adopting that rule does not require a migration project or one of our
products. Add a REPO.md file at the root of a repository. List the systems
of record inside it, where their files live, and which external services still
own something important. Keep it short. Nouns, not instructions.
The file gives the next human or agent a lobby directory for the repo.
Read the REPO.md convention, add the file, and send it as a pull request. That is the smallest useful act.
For the complete argument, including the invariants and the honest limits, read the repo-native manifesto.