In short: AI coding agents do not just need more context. They need context that stays true. Repo Forge is a workflow for turning repository knowledge into living operational memory: structured, versioned, reviewable, and maintained as the code evolves.
Your code evolves. Your repository context should evolve with it.
What happens to AI context after three weeks?
Creating context for an AI coding agent is easy. You write an AGENTS.md, describe the architecture, add a plan, maybe record a few decisions, and the next session starts with a much better map of the project.
Then the project moves.
A feature changes direction. An architectural assumption stops being true. A plan is completed differently from the way it was written. A new constraint appears during implementation. The code moves forward while the context quietly stays behind.
Generating context is easy. Keeping it true is the hard part.
Stale context is not harmless. An agent can follow an outdated instruction perfectly and still make the wrong change. It can re-derive a decision the project already made, resurrect an approach that was deliberately abandoned, or trust an architecture document that describes a system that no longer exists.
What should an AI-ready repository remember?
A useful repository context layer should be able to answer a few practical questions without forcing every new session to reconstruct the project from scratch:
- What is this project and what is it trying to become?
- How is the system structured?
- Which architectural rules should not be broken?
- What are we working on now?
- What should happen next?
- Why were important decisions made?
- What changed recently?
- Has the written context drifted away from the code?
- Where should a new request, idea, or decision go?
The important part is not any single file. It is the relationship between them, and whether those relationships still describe reality.
A repository needs living operational memory
I started thinking of files such as AGENTS.md, ARCHITECTURE.md, plans, ADRs, backlogs, changelogs and intake rules as something different from traditional documentation. They are an operational memory layer for both humans and agents.
They are versioned with the project. They explain intent, boundaries, current work and past decisions. Most importantly, an agent can use them before changing the code.
But memory only works if it is maintained. That is the problem I built Repo Forge to address.
How does Repo Forge keep repository context alive?
Repo Forge treats context as a lifecycle rather than a file-generation task:
SCAN → SEED → INTAKE → WORK → KEEP → ↻
Scan: understand what already exists
Existing repositories should not be overwritten by a generic template. Scan inspects the project first, identifies the context that already exists, and exposes missing or inconsistent pieces before anything is reorganized.
Seed: establish a coherent context layer
Seed creates the structure a repository needs to explain itself: agent instructions, architecture, plans, backlog, decisions and the other durable artifacts that allow future sessions to understand the project instead of rediscovering it.
Intake: decide where new work belongs
Not every idea should immediately become code. Intake routes new requests into the right place: direct work, a plan, backlog, analysis, an architectural decision, or something that should not be implemented yet. It protects the project from turning every prompt into an unplanned change.
Work: let the coding agent do its job
Repo Forge is not trying to replace the coding agent. Claude Code, Codex, Cursor, Copilot or another agent can still do the implementation. The repository provides the durable context around that work.
Keep: detect drift and reconcile reality
This is where the lifecycle becomes different from simply generating documentation. Keeper checks whether plans, architecture, backlog, decisions and agent instructions still agree with what the repository has become. It is designed to preserve decisions and context while bringing stale information back in line with reality.
Why is stale context worse than missing context?
Missing context creates uncertainty. Stale context creates confidence in the wrong answer.
If an agent cannot find an architectural rule, it may stop and investigate. If it finds an obsolete rule written as authoritative project context, it has a reason to follow it. That makes context drift a maintenance problem, not merely a documentation problem.
The goal is therefore not to maximize the number of tokens loaded into every session. The goal is to make the durable context small enough to use, explicit enough to trust, and maintained enough to remain useful.
Does Repo Forge depend on one AI coding agent?
No. The context lives in the repository rather than in the identity of a single model or coding tool. The same project memory can guide different agents because the durable source is the repository itself.
That distinction matters. Models will change. Editors will change. Agent interfaces will change. The project’s architecture, decisions, constraints and history still need somewhere durable to live.
Try Repo Forge on a real repository
Repo Forge is open source. The simplest way to understand the idea is not to read another explanation of it, but to run it against a repository whose context has already had time to drift.
npx skills add peorthyr/repo-forge --allStart with the project on GitHub. If you want the thinking behind the repository context layer, I previously wrote about Intent Source; for a file-by-file walkthrough, see I file che leggo prima di toccare il tuo codice.
Your AI agent does not need a repository that remembers everything. It needs a repository that remembers what is still true.