Module project_context 

What the repository itself says about how to work in it.

Until this existed, everything a coder session knew about the repo it was pointed at was two lines from summarize_repo — the top-level entries and which build files exist. Three separate bodies of project knowledge sat on disk and none of them reached the loop (car#1071).

Why a directory listing is not enough

The rules that get a diff rejected are almost never expressible as an outcome contract. They are review-time rules: “no cargo feature flags, ever”; “any change crossing the FFI boundary updates five surfaces in the same change, two of which are hand-maintained files”. A model that has not read them does the normal thing — adds a [features] entry to make something optional — and produces a diff that compiles, passes its contract, and is rejected on sight. Contract-green and mergeable are different properties, and only one of them was reaching the model.

What this loads

• Agent instructions — both AGENTS.md and CLAUDE.md at the worktree root, plus any git-tracked nested ones, each labelled with the subtree it governs (nested_instructions).
• .car/ project knowledge — identity and knowledge entries, via car_memgine::project, whose discovery already walks up from a starting directory the way .gitignore resolution does.

Two limits, stated because they are easy to mistake for coverage

Instructions that delegate are followed only one level. This repo’s own CLAUDE.md says the full binding surface “lives in the car-bindings-api skill — invoke it whenever work touches the FFI boundary”. Loading the root file gets the model the pointer, not the rule, and closing that needs skill selection — a larger change than reading a file. available_skills narrows the gap by indexing the skills so the pointer at least resolves to a path the model can read_file.

Nested CLAUDE.md files are no longer part of this limit: nested_instructions inlines them, scoped to the directory each governs.

This is untrusted-adjacent input. The text lands in a system prompt, and it comes from the repository under work. That is the same trust level as the code the session is already reading and editing, so for a repo an operator pointed the coder at, it is fair. It would NOT be fair for content that arrived from a public tracker — see car#1081 — and nothing here should ever be extended to load one.

Constants

MAX_INSTRUCTIONS_BYTES

Combined content-byte ceiling for root instruction files.

MAX_KNOWLEDGE_BYTES

Byte ceiling for rendered .car/ knowledge.

Functions

agent_instructions

Read all nonempty root instruction files, preserving source labels. Each file gets a share of the combined budget; unused space from a short file goes to the other. A large file cannot crowd out the other convention. Truncation is announced with a path the model can read before editing.

available_skills

Index the repository’s agent skills by name and description.

dot_car_knowledge

Render .car/ identity and knowledge entries, if a project is discoverable.

named_file_context

Cut to a byte ceiling on a UTF-8 boundary, and say so when cut. Bounded source evidence for paths explicitly mentioned in a task or revision. Planning does not run the coding agent’s read tools, so a directory listing alone cannot ground checks that preserve existing text. Reuse the same repository read clamp as discussions; never follow a named path outside it. JSON strings preserve line endings and distinguish file data from guidance.

nested_instructions

Nested CLAUDE.md / AGENTS.md files — scoped rules that apply to one subtree (car#1071).

project_context

The full block for the system prompt, or None when the repo carries neither instructions nor a .car/ project.