Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/bastndev/f1/llms.txt

Use this file to discover all available pages before exploring further.

My Memory is F1’s built-in project context engine. Before a CLI session starts, it scans your workspace with a fast fs pass, writes a structural summary into a .f1/ directory, and updates your agent instruction files (AGENTS.md and CLAUDE.md) so the agent reads the map automatically at the start of every session. The entire process is pure TypeScript — no Python, no LLM, no network — so it is always fast and never blocks a launch.

​
What My Memory writes

When My Memory runs, it creates and manages a .f1/ directory at the root of your workspace containing three files:

project-map.md

A compact, AI-readable Markdown summary of your project — package name, version, scripts, dependencies, and top-level folder structure. Written by writeProjectMap() from a scanProject() pass.

memory.json

Internal configuration and state written on first launch. Records the version, mode, and creation timestamp. Managed entirely by F1 — do not edit manually.

smart-rules.md

Working rules for the agent. This file is empty when using My Memory standalone. When Smart + Skills is enabled, SmartService.writeRules() populates it with the built-in skill rules before launch.
.f1/ is fully managed by F1. Avoid editing its contents manually. F1 writes these files atomically (skipping the write if the content hasn’t changed) and removes them automatically when the session ends.

​
How My Memory works

1

Enable the engine

MemoryService.setEnabled(true) is called — either directly (when you turn on the Memory toggle) or automatically by SmartService when Smart + Skills mode is used. Without this flag, onLaunch() is a no-op, so the engine adds zero overhead when disabled.
2

Scan the project and write the map

onLaunch(root, slug) calls scanProject(root, config.ignoreDirs) which reads package.json and lists top-level folders (skipping ignored dirs). The result is passed to writeProjectMap(), which renders it as Markdown and writes .f1/project-map.md atomically — only if the content has changed.
const config = resolveConfig(root);
const mapPath = path.join(root, MEMORY_DIR, MEMORY_MAP_FILE);
if (!fs.existsSync(mapPath)) {
  writeProjectMap(root, scanProject(root, config.ignoreDirs));
}
syncInstructionFileForSlug(root, slug);
3

Sync the instruction files

syncInstructionFileForSlug(root, slug) writes a managed block (between <!-- F1-MEMORY:START --> and <!-- F1-MEMORY:END --> markers) at the top of AGENTS.md — just below the first H1 heading if one exists. The block points the agent at .f1/smart-rules.md and .f1/project-map.md.For Claude Code (slug claude), a thin @AGENTS.md import line is prepended to CLAUDE.md so Claude reads the same hub file without maintaining a duplicate block.
4

Agent reads context on launch

Because the managed block is at the very top of AGENTS.md, the agent reads the .f1/ references before scanning any source files. It gets the project structure and working rules for free, without token-hungry directory listings.

​
The managed block in AGENTS.md

The block F1 writes into AGENTS.md looks like this: 
<!-- F1-MEMORY:START -->
## Project context (F1 Smart + Skills)

Before scanning files, read these first — they define how to work here and save tokens:
- `./.f1/smart-rules.md` — working rules: how to behave in this project.
- `./.f1/project-map.md` — a prebuilt structural map of the project.
<!-- F1-MEMORY:END -->
Only the content between these markers is ever managed by F1. Everything else in AGENTS.md — your hand-written rules, team conventions, custom instructions — is never touched.

​
MemoryService API

MemoryService is the public class exported from src/my-plus/my-memory/my-memory.ts. All methods are best-effort and never throw.
Called right before a CLI session starts. Ensures .f1/ exists with a fresh project-map.md and keeps the launching CLI’s instruction file pointed at it. Skips silently if isEnabled() is false or root is undefined.
public onLaunch(root: string | undefined, slug: string | undefined): void
Writes content into .f1/smart-rules.md atomically. The write is skipped if the content hasn’t changed (idempotent). Ensures the .f1/ directory exists before writing. Used by SmartService to inject built-in skill rules.
public writeRules(root: string | undefined, content: string): void
Removes the .f1/ directory and strips the managed block from AGENTS.md, restoring the file to the state it was in before F1 touched it. Returns an array of the paths that were cleaned. Never touches any content outside the marked block.
public cleanup(root: string | undefined): string[]
Read or set the enabled flag. When false (the default), onLaunch() and all scan/write operations are skipped entirely. SmartService calls setEnabled(true) in its constructor so Smart launches always build the map.
public isEnabled(): boolean
public setEnabled(value: boolean): void

​
Configuration and ignoreDirs

My Memory reads configuration from a 4-level cascade (highest priority wins):
  1. F1_MODE environment variable
  2. .f1/config.json in the project (walks up to the filesystem root)
  3. ~/.config/f1/config.json (user global; honours XDG_CONFIG_HOME)
  4. Built-in defaults
The ignoreDirs field in any config layer lets you add directory names to skip during the project scan. The base ignore list — always applied regardless of config — includes: 
node_modules, dist, out, build, coverage, .next, .cache, .git, .f1, graphify-out
Any names you add in .f1/config.json or your global config are merged onto this base set.

​
Instruction file strategy

My Memory uses a hub-and-pointer pattern to stay compatible with every major coding CLI:
FileRoleWhich CLIs
AGENTS.mdHub — carries the managed F1 blockClaude Code, Codex, Cursor, OpenCode, Kiro, Kilo Code, Grok, Antigravity, Copilot
CLAUDE.mdPointer — contains only @AGENTS.mdClaude Code (which keys off CLAUDE.md and won’t read AGENTS.md on its own)
This means there is only ever one copy of the managed block — in AGENTS.md — and CLAUDE.md is kept as a thin import that delegates to it.
Cleanup is non-destructive by design. cleanup() only removes the content between the F1-MEMORY:START and F1-MEMORY:END markers in AGENTS.md. Your hand-written rules, team conventions, and any other content in the file are never modified or deleted. F1 takes a pristine backup of AGENTS.md before writing into it, so the original content can always be restored.

Build docs developers (and LLMs) love

Get started for freeTalk to us