Memory & Skills

Cross-conversation memory

• Tell it your name or preferences once; it remembers in every future chat.
• It notes during the chat and files after the reply. While it works, Naseem only jots down what seems worth keeping. When the reply is done, a separate step decides where each note belongs — about you, this project, or everywhere — merges it with what is already known, and leaves out one-off details. The chat never waits for it.
• Memory is plain Markdown under ~/Library/Application Support/Naseem — inspect or edit it anytime.

Naseem's profile

• AGENT.md is who Naseem is: its name, its mission, its tone, and principles you asked for. Edit it in the brain icon → Memory, or just ask — "call yourself Nemo", "be more formal". Naseem changes it only when you ask, one part at a time, and never rewrites the rest.
• USER.md is about you only: your name, your work, the languages you speak and where you are. How you want Naseem to answer is one of its principles, in AGENT.md. One line per item; a new value replaces the old one instead of piling up.

Each project keeps its own memory

• A project's memory lives in the project. Decisions and facts that stay true go into naseem/memory.md inside the project's folder, and how to avoid mistakes there goes into naseem/lessons.md — next to project.md, roadmap.md and journal.md. Plain Markdown: open them in any editor, commit them with git, take them to another Mac. Your edits win: Naseem reads the file again before every change.
• Every message sees the current files. A short memory.md is read whole; a long one by its titles, and Naseem reads an entry when it needs it. An edit you make outside Naseem counts from the next message.
• What it learns about you is not filed anywhere in particular. Your name, how you like a plan written, that you want to be told what to do next — those hold whatever you are working on, so they come with you everywhere.
• A chat with no project sees the general memory alone, which is what you want for a passing question.
• See and refile. The brain icon → Memory shows Naseem's profile and USER.md (both editable — ⌘S saves), the facts that hold everywhere, and each project's memory.md with Open file. Belongs to a project moves a fact into that project's file. In Lessons, Applies to a project moves the lesson into its lessons.md.
• Older project memory. Facts and lessons filed before this version stay in Naseem's own memory, and keep working, until you move them: Move project memory… in the Memory tab shows one item per project. You approve or skip each, everything is backed up first, and nothing you skip moves. A project without a folder stays where it is.
• Keep them out of git if you prefer: right-click the project → Keep Naseem's project files out of git. It adds naseem/ to the repository's local exclude list — never your .gitignore — and turning it off removes exactly that line. If you already excluded naseem/ there yourself, the item shows as on and Naseem leaves your line alone.
• Recently filed lists every change — filed after a reply, made by Naseem at your request, or made by you — with Undo. If the entry changed since, Undo asks first. If a project's folder can't be found, Undo waits until it is back; if only the file was deleted, Undo says so. If a project's folder can't be written, what Naseem noted waits and is tried again later.
• Tidy up memory proposes moves, merges and removals for memory that grew mixed. You approve or skip each one; nothing changes until you apply, and your memory folder is copied to memory-backups first.

Lessons from failures

• When a run hits a real mistake — an action you denied, a failure it had to work around, a guardrail — Naseem may file one lesson: a short rule it follows from then on. A flaky moment is not a lesson: tools that only read are tried once more automatically.
• Each lesson applies somewhere: everywhere, one project, or one kind of tool (Simulator, Mail…). A chat only gets the lessons that apply to it.
• See, edit, move or delete them in the brain icon → Lessons. A project's own lessons are in its naseem/lessons.md — Open at the bottom of the tab opens it for the selected chat's project. Every lesson filed or changed shows in Memory → Recently filed, with Undo.
• Turn learning off for one project (benchmarks, experiments) from its menu in the sidebar: Learn lessons here. Turn it off everywhere in Settings → Integrations → Capture lessons from failures.
• Lessons from an earlier version: Tidy up lessons proposes what to keep, merge or remove, for you to review. Your lessons are backed up first.

Self-improving skills

• Naseem turns recurring multi-step tasks and corrected mistakes into reusable, keyword-triggered skills (via learn_skill, Pro).
• Import skills or whole skill collections from URLs and repos — human-review gated.
• Browse what it knows in the Knowledge inspector (memory / skills / tools).
• Switch any skill on or off — every skill in the brain icon → Skills has a switch. Off keeps the file and its text but hides the skill from the model, so a run cannot pick it.
• The skills Naseem ships with start off. A skill is a procedure Naseem follows whenever it judges a request fits, so it changes how Naseem works rather than only what it knows. Turn on the ones that match your work. Two are marked RECOMMENDED — one makes Naseem prove a change works before calling it done, the other keeps a project's plan current — and one button turns both on.
• Every run names the skill it followed, under the reply's header. If a skill steered a run the wrong way, one click there turns it off for future runs.
• Skills say what they are not for. The code-review skill refuses a folder with no source rather than treating your documents like a codebase.
• Codebase review (trial) — hands the reading to sub-agents so the main model never loads the code: it sizes the job first, uses one reviewer for a small project and one per dimension for a large one, and each writes findings to a file under naseem/reviews/<date>/. Every finding is then re-checked against the cited lines and the ones that don't survive are thrown out, so you get a short list with file and line rather than a long plausible one. In approval mode it tells you the plan first — files, lines, how many reviewers, roughly how many calls — and asks whether you want the full review, reviewers without verification, or a quick single-pass look. In Autonomous mode it prints the plan and goes.