September 11, 2026
THE CORE FILES OF AN AI PROJECT

The easiest way to lose control of an AI project is to let the project live only in your head and in a long chain of chats. Every new session starts with reconstruction: what are we making, what changed, what did we decide, and what should happen next?
Files solve that problem. They give each kind of information a home.
The small file system that carries a project
You do not need all of these on day one. Start with the files that answer the questions your project already has.
| File | Question it answers | When to update it |
|---|---|---|
README.md | What is this project and how do I use it? | When setup or purpose changes |
CONTEXT.md | What background and decisions matter? | When research or direction changes |
SPEC.md | What exactly are we building now? | Before a meaningful build phase |
TASKS.md | What work remains? | After planning or completing work |
DECISIONS.md | What did we choose, and why? | Whenever a choice should not be re-litigated |
AGENTS.md | How should AI work in this repository? | When workflows, limits, or standards change |
SKILL.md | How does AI perform one reusable capability? | When the capability improves |
A file is a promise to the next session
Suppose you tell Codex to add accounts to your application. It changes the design, chooses an authentication provider, and updates the database. If you do not record that decision, the next AI session may propose a different provider or rebuild the same work.
Put the decision where it belongs:
# Decisions
## 2026-09-11 — Authentication
We are using passwordless email login for version one.
Why: it reduces setup friction for the target user and avoids supporting
password reset in the first release.
Do not add social login until the core product is working.
This is not bureaucracy. It is how you prevent context drift.
When you stop in the middle: use a restart system
Long AI work rarely finishes in one sitting. A coding session ends, a model runs out of context, or you simply need to return tomorrow. Do not rely on memory alone. Use three small files to make the handoff explicit:
| File | Job |
|---|---|
MEMORY.md | The durable brief: purpose, rules, decisions, and current state |
HISTORY.md | A short running handoff: what changed, what was tested, and where work stopped |
RESTART.md | The exact instruction for the next AI session |
Your restart prompt can be simple:
# Restart Prompt
Read MEMORY.md first. Then read the newest entries in HISTORY.md.
Inspect the files named there before making changes.
Tell me your understanding of the current state, then continue from the next action.
When the work is complete, update HISTORY.md and MEMORY.md.
This does not replace a specification. It makes the specification usable after an interruption. It also gives you a way to test whether an agent actually understands the project before you let it change anything.
Git and GitHub make the file system stronger
Git records changes to a project over time. GitHub is a common place to store that history, share the repository, and read Markdown in the browser. You do not need to master Git in this lesson. For now, understand the advantage: project memory is safer when you can see what changed, compare versions, and return to an earlier version if a later change was wrong.
In the Project Control section of this course, you will learn commits, branches, pull requests, and reverts properly. Here, the practical habit is enough: keep your durable project files inside the same repository as the work they direct.
What is an AI skill?
A skill is a reusable, bounded capability. It is not merely a personality prompt.
For example, a SKILL.md for “competitive research” might define when the skill should be used, what sources count, what it must return, how it should cite evidence, and what it must not do. A skill for “publish a blog post” might define the checks, metadata, artwork, and publishing steps.
The purpose is consistency. You should not have to reinvent the same working method every time.
Sonariq as a supporting example
Sonariq’s research workflow has separate prompt files for different roles, plus shared standards and handoff documents. That is a larger version of the same idea. Each agent has a defined job; shared files keep all of the jobs pointed at one research standard.
You can begin much smaller. One README.md, one CONTEXT.md, one SPEC.md, and one TASKS.md will put you ahead of most AI projects.
Set up your project now
Create this structure:
my-project/
README.md
CONTEXT.md
SPEC.md
TASKS.md
DECISIONS.md
Write only what you know. Then ask Codex:
This creates a healthy pattern: read first, plan second, change third.
Check your understanding
1. Which file would you use to record a product decision and its reason? 2. Which file should explain the next version of the product? 3. What is the difference between AGENTS.md and SKILL.md? 4. Why should an AI read project files before it starts changing code?
ARTICLE DISCUSSION
JOIN THE
CONVERSATION.
Got a question, a take, or a better way to do this? Log in and leave a comment.
