Gemini CLI Memory Add: Save and Inspect Instructions

If you are looking for Gemini CLI memory add, first check the commands in your installed version: do not assume that /memory add is supported. The reliable workflow is to save a clear instruction in the appropriate memory file, inspect the loaded context, and confirm it in a fresh session. fenbs can hold changing project progress and decisions separately from those standing instructions.

What should you check before adding a memory?

1. Start Gemini CLI in the intended project directory. Confirm that you are working on the correct repository before saving anything.
2. Run /help inside the interactive CLI and inspect the available memory commands. Slash commands belong in the CLI conversation, not in your operating system shell.
3. Run /memory show to review the instruction text currently loaded. Look for an existing rule before adding another version of the same instruction.
4. Choose whether the new fact belongs to every project, this repository, a smaller component, or a private note.
5. Save the instruction through a supported memory action or edit the relevant file, then reload context using the command your version documents.

The current command reference↗ (opens in a new tab) lists memory inspection and refresh commands, without listing an add subcommand. That is why an example found elsewhere should be checked against your installation before you rely on it. Use our Gemini CLI installation guide if the CLI itself is not set up.

/help
/memory show

These are inspection steps. Seeing the instruction text is a stronger check than receiving an acknowledgment that something was remembered. It also gives you something concrete to compare when the assistant behaves differently in a later session.

Where should a new instruction live?

Google’s context-file documentation↗ (opens in a new tab) describes a hierarchy: global instructions, workspace-related files, and more specific files discovered when relevant. The default instruction filename is GEMINI.md. Global settings apply broadly, so do not put one repository’s commands there by convenience.

Think about the next person who will read the file. A useful instruction names the action and where to find supporting information. Follow the existing test script is clearer when it also points to the relevant project documentation. Avoid making the assistant guess which of several similar commands you meant.

The Gemini CLI best-practices guide covers the wider working loop. Keep your memory file focused on the rules that should shape that loop, rather than turning it into a transcript.

How can you save a fact without a universal add command?

Google’s memory-file documentation↗ (opens in a new tab) describes durable facts being saved by editing Markdown files, with different locations for shared instructions and private preferences. You can edit the intended instruction file directly, or ask the assistant to remember a clearly scoped fact and review the resulting change.

For example, ask: remember for this repository that screenshots for documentation belong in the docs images folder; show me the file and exact instruction you will change. This makes the destination reviewable. It also lets you catch a project instruction accidentally being written as a global preference.

# Project instructions

- Keep documentation screenshots in the existing docs images folder.
- Read the project contribution guide before changing build commands.
- Report checks actually run and their results.

Review the file change before treating it as durable. Check scope, duplicated rules, and wording that would become stale after one task. Keep credentials and private customer details out of shared instruction files. A memory file should explain how to work without becoming a place to store everything the assistant encountered.

How do you confirm that the session loaded the change?

Inspect the saved file, refresh the session’s context, and run /memory show again. Google’s memory-management tutorial↗ (opens in a new tab) documents the inspection workflow. Compare the displayed text with the instruction you intended to save, including any imported instructions that may conflict.

There is a documentation wrinkle: the command reference uses /memory refresh, while the context-file guide and tutorial use /memory reload. Follow the options exposed by your installed CLI. If a command is not recognized, consult /help or restart a fresh session rather than assuming the file was never saved.

Test with a small question that requires the instruction. Ask where a new documentation screenshot should go without giving the answer. If the assistant gets it wrong, investigate the loaded text and scope before adding a louder duplicate instruction. Repeated copies can hide the original problem.

This CLI workflow is separate from browser-app personalization; the Gemini memory feature guide covers that adjacent subject. Do not expect a browser conversation preference to establish which repository instructions a terminal session loaded.

What should stay out of standing instructions?

Keep completed steps, failed checks, current blockers, and temporary next actions with the work. A file that says always run the project checks is a useful instruction. A line saying the build is currently broken needs a current result and a next step; otherwise it can survive long after the problem was fixed.

Suppose you stop after implementing a contact form. The next session needs to know that submission delivery has not been checked. Record that as task progress and Where we left off. Leave the instruction file to explain how to discover and run the appropriate checks.

In fenbs project context, Decisions and rules describe approved choices while tasks and saved progress describe the current situation. The Gemini CLI plan-mode guide covers planning a coding session; the resulting plan still needs an honest status when work stops.

How to do this with fenbs

1. Create a free account and add the project whose coding sessions need continuity.
2. Record people’s approved choices in Decisions and rules. Add active tasks with the remaining work and actual check results.
3. Connect Gemini CLI through the supported guide in Integrations, using the browser sign-in.
4. Ask the assistant to read the project context before working and save task progress and Where we left off before stopping.

fenbs does not replace Gemini CLI’s instruction loader or change which local files it reads. If you only need a repository style rule, a small reviewed instruction file is enough. Add fenbs when project decisions and changing progress also need to reach other supported assistants.

A good first check is simple: inspect the loaded rule, complete one small task, and save a precise next step. The AI memory hub covers other ways to separate durable instructions from active context.