Store Instructions and Memories

Amara reads a file called SYNTIC.md at the start of every session and treats it as standing instructions. This is where you record the facts, conventions, and preferences that you would otherwise have to repeat in each prompt: your build commands, your code style, the directories to avoid, and anything else that stays true across tasks. A good memory file is the single highest-leverage thing you can maintain for Syntic Code.

The memory hierarchy

Syntic Code loads memory from more than one place and merges them, with more specific files taking priority.

• Project memory — a SYNTIC.md file at the root of your repository. Commit this so your whole team shares the same instructions.
• User memory — a SYNTIC.md under ~/.syntic/ in your home directory. This holds personal preferences that apply to every project you touch, such as your preferred commit message style.
• Directory memory — a SYNTIC.md placed deeper in the tree. Amara picks it up when it works in that part of the repo, which is useful in monorepos where each package has its own rules.

When the same topic appears in more than one file, the closer file wins.

Using @imports

To keep files short and avoid duplication, SYNTIC.md supports imports. Write @path/to/file.md on its own line and Amara will pull that file’s contents in at load time. This lets you keep a shared conventions document in one place and reference it from several memory files, or split a long file into focused fragments. Imports are resolved relative to the file that declares them.

Writing effective memory

Keep entries short, specific, and imperative. Prefer “Run tests with pnpm test” over a paragraph of explanation. Group related rules under headings so they are easy to scan and edit. Remove instructions that no longer apply — stale memory is worse than none, because Amara will act on it. Review the file whenever your tooling or conventions change.