Monorepos and Large Repos

Large codebases and monorepos put more distance between a task and the code that matters to it. Amara can navigate them well, but a little structure on your side makes the difference between focused work and wasted exploration. This guide covers how to keep Syntic Code effective as the repository grows.

Scope the work to a subtree

The single most useful thing you can do in a big repo is tell Amara where to work. Name the package, directory, or service the task concerns, and ask it to stay within that boundary. Launching syntic from inside the relevant subdirectory naturally narrows its attention. When a change genuinely spans packages, say so explicitly and list them — otherwise Amara will assume the local scope you started from.

Use per-package memory

In a monorepo, a single root SYNTIC.md cannot capture the conventions of every package. Place a SYNTIC.md inside each package or service with the rules that apply there: its build command, its test runner, its local patterns. Amara picks up the closest memory file when it works in that area, so the right instructions apply automatically without cluttering a global file. Keep shared conventions in the root file and pull them into package files with @imports.

Manage context deliberately

Very large repositories contain far more than any single task needs. Point Amara at the specific files or modules that matter rather than asking it to survey the whole tree, and lean on plan mode for cross-cutting changes so you can confirm the blast radius before edits begin. Exclude generated code, vendored dependencies, and build artifacts from attention where you can. Breaking a large effort into a sequence of scoped sessions, each resumed from a clean checkpoint, keeps every step fast and reviewable.