Context Files
Reliant reads these context files on the chat’s machine:
Every file that exists is loaded and included in every conversation. A
reliant.local.md is read wherever a reliant.md is, in the project root and in each nested repository, and comes right after that reliant.md, so your personal notes have the last word. It is loaded even when there is no reliant.md beside it.
The reliant.md a new project starts with
When you add a project in Reliant and it has no reliant.md yet, Reliant writes one in the project root, so the file exists before you have written anything. It has these parts:
- Guidelines and Key Context, two empty lists for you to fill in with your conventions and background.
- Code navigation and Available Skills, which point the agent at the code-search, Reliant configuration and workflow-building skills.
reliant.md keeps it untouched.
What Reliant can do
Separately from your memory files, Reliant gives every conversation, in every project, a short routing guide. A chat agent only knows what is in front of it, and without this guide it tends to answer “run it on a cron job” or “deploy it to Vercel” when Reliant has a built-in way to do the same thing. The guide tells the agent which Reliant feature fits which kind of request: something that should run on its own (on a schedule, from a webhook, or when a GitHub, Gmail, Slack or Twilio event arrives) is a workflow with a trigger; an agent that acts on outside services uses integrations; work that needs a person’s approval pauses the run; and anything that will be deployed is a forge project. That includes a frontend with no backend (a landing page, a marketing or docs site, a single-page app or a PWA) as much as a backend, workers, cron jobs, Kubernetes operators, a CLI or a mobile app. It also tells the agent to propose the Reliant option and say what it commits you to, to use any tool or platform you named yourself, and to check the Reliant docs before recommending outside infrastructure. The guide comes with Reliant rather than living in a file, so every project gets the current version, including projects created before it existed. Your own memory still has the last word: if your team has standards that differ (“we deploy everything to our own cluster”), say so inreliant.md and the agent follows it.
Projects created by older versions of Reliant had a copy of this guide written into their reliant.md, under a ## What Reliant can do heading. Reliant leaves that file alone on disk but skips that section when it loads your memory, so the agent reads only the current guide. You can delete the section from the file whenever you like.
What to Include
Project Context (reliant.md)
Include information that benefits everyone working on the project:
Personal Context (reliant.local.md)
A reliant.local.md in the project root holds your personal preferences and local setup for the project. Keep it out of git (add it to .gitignore) so it stays yours. In a project made of several repositories, a reliant.local.md beside a repository’s reliant.md does the same for that one repository. For preferences that apply to every project, use the global context file instead.
Projects with several repositories
A project can hold several git repositories side by side. Reliant finds each nested repository and loads itsreliant.md and reliant.local.md as that repository’s context, labelled with the repository’s path, so the agent knows which rules apply where. Put what applies to the whole project in the root reliant.md and what applies to one repository in that repository’s own file.
Together, the repositories’ files (each repository’s reliant.md and reliant.local.md) may take up to a tenth of the model’s context window; any that don’t fit are left out, and the agent is told where they are so it reads them before working in that repository. The project root’s reliant.md and reliant.local.md are always included in full. Parent directories above the project are not searched.
Best Practices
Keep it concise — Context files are included in every conversation. Large files consume tokens without proportional benefit. Update regularly — As your project evolves, keep context files current. Outdated information is worse than no information. Separate concerns — Put team knowledge inreliant.md, your notes for one project in its reliant.local.md, and preferences for every project in your global ~/.reliant/reliant.md.
Use structure — Headings and bullet points are easier to scan than prose.
Avoid secrets — Never put API keys, passwords, or sensitive data in context files.
Global Context
You can also add global context that applies to all projects. Create areliant.md file in your global config directory:
Related Topics
- Model Configuration — Configure models and providers
- MCP Servers — Extend capabilities with external tools
- Custom Workflows — Create specialized workflows