Project instructions
Polyglot reads a project instructions file and prepends it to the system prompt, so the agent starts every session already knowing your build command, your conventions, and what not to touch - without you re-typing it each time.
- Package manager is `pnpm`, never `npm`.- Run `pnpm test` before claiming a change works.- `src/generated/` is codegen - never edit it by hand.- Prefer named exports; this repo has no default exports.Drop that in your repo root and every polyglot session in that directory picks it
up. /status shows which files are loaded.
Which files
Section titled “Which files”| Path | Purpose |
|---|---|
<repo>/POLYGLOT.md |
Polyglot-specific project rules. Highest priority. |
<repo>/AGENTS.md |
The cross-tool standard (opencode, Codex, …). A repo that already has one just works. |
~/.polyglot/POLYGLOT.md |
Your personal rules, applied in every project. |
~/.polyglot/AGENTS.md |
Personal cross-tool rules. |
All that exist are concatenated into one ## Project instructions block in the
system prompt, each section headed with # From <path>. The order is global before
project, and AGENTS.md before POLYGLOT.md, so a project POLYGLOT.md comes last
and reads as the most specific. If you have genuinely conflicting rules across files,
state the winner explicitly rather than relying on ordering.
Scope and limits
Section titled “Scope and limits”- Repo root only. Nested per-directory files aren’t walked (yet).
- 16 KB per file. Anything past that is dropped with a visible
[... truncated]marker - this is context for every turn, it shouldn’t crowd out the conversation. - Empty or whitespace-only files are ignored.
- Sub-agents inherit it. Work delegated via the
tasktool gets the same instructions, so a sub-agent editing the repo follows the same conventions. CLAUDE.mdis not read. Deliberate for now - copy the parts you want intoAGENTS.md.
Turning it off
Section titled “Turning it off”Set POLYGLOT_NO_INSTRUCTIONS=1 (or true) to skip loading entirely - useful for a
clean-room run or when benchmarking the bare system prompt.
What to put in it
Section titled “What to put in it”Good: build/test/lint commands, directory conventions, code-style rules that aren’t obvious from the code, “always do X before Y”, areas that are generated or vendored.
Skip: anything already clear from the code, long prose explanations, secrets (this text goes to the model provider like any other prompt - see Data handling).