> ## Documentation Index
> Fetch the complete documentation index at: https://cli.fuxicode.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# How Fuxi remembers your project

> Give Fuxi persistent instructions with FUXI.md files, and let Fuxi accumulate learnings automatically with auto memory.

Each Fuxi Code session begins with a fresh context window. Two mechanisms carry knowledge across sessions:

* **FUXI.md files**: instructions you write to give Fuxi persistent context
* **Auto memory**: notes Fuxi writes itself based on your corrections and preferences

This page covers how to:

* [Write and organize FUXI.md files](#fuxi-md-files)
* [Scope rules to specific file types](#organize-rules-with-fuxi/rules/) with `.fuxi/rules/`
* [Configure auto memory](#auto-memory) so Fuxi takes notes automatically
* [Troubleshoot](#troubleshoot-memory-issues) when instructions aren't being followed

## FUXI.md vs auto memory

Fuxi Code has two complementary memory systems. Both are loaded at the start of every conversation. Fuxi treats them as context, not enforced configuration. To block an action regardless of what Fuxi decides, use a [PreToolUse hook](/en/hooks-guide) instead. The more specific and concise your instructions, the more consistently Fuxi follows them.

|                      | FUXI.md files                                   | Auto memory                                                      |
| :------------------- | :------------------------------------------------ | :--------------------------------------------------------------- |
| **Who writes it**    | You                                               | Fuxi                                                           |
| **What it contains** | Instructions and rules                            | Learnings and patterns                                           |
| **Scope**            | Project, user, or org                             | Per repository, shared across worktrees                          |
| **Loaded into**      | Every session                                     | Every session (first 200 lines or 25KB)                          |
| **Use for**          | Coding standards, workflows, project architecture | Build commands, debugging insights, preferences Fuxi discovers |

Use FUXI.md files when you want to guide Fuxi's behavior. Auto memory lets Fuxi learn from your corrections without manual effort.

Subagents can also maintain their own auto memory. See [subagent configuration](/en/sub-agents#enable-persistent-memory) for details.

## FUXI.md files

FUXI.md files are markdown files that give Fuxi persistent instructions for a project, your personal workflow, or your entire organization. You write these files in plain text; Fuxi reads them at the start of every session.

### When to add to FUXI.md

Treat FUXI.md as the place you write down what you'd otherwise re-explain. Add to it when:

* Fuxi makes the same mistake a second time
* A code review catches something Fuxi should have known about this codebase
* You type the same correction or clarification into chat that you typed last session
* A new teammate would need the same context to be productive

Keep it to facts Fuxi should hold in every session: build commands, conventions, project layout, "always do X" rules. If an entry is a multi-step procedure or only matters for one part of the codebase, move it to a [skill](/en/skills) or a [path-scoped rule](#organize-rules-with-fuxi/rules/) instead. The [extension overview](/en/features-overview#build-your-setup-over-time) covers when to use each mechanism.

### Choose where to put FUXI.md files

FUXI.md files can live in several locations, each with a different scope. The table below lists them in load order, from broadest scope to most specific, so a project instruction appears in context after a user instruction.

| Scope                    | Location                                                                                                                                                                | Purpose                                                    | Use case examples                                                    | Shared with                     |
| ------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------- | -------------------------------------------------------------------- | ------------------------------- |
| **Managed policy**       | • macOS: `/Library/Application Support/FuxiCode/FUXI.md`<br />• Linux and WSL: `/etc/fuxi-code/FUXI.md`<br />• Windows: `C:\Program Files\FuxiCode\FUXI.md` | Organization-wide instructions managed by IT/DevOps        | Company coding standards, security policies, compliance requirements | All users in organization       |
| **User instructions**    | `~/.fuxi/FUXI.md`                                                                                                                                                   | Personal preferences for all projects                      | Code styling preferences, personal tooling shortcuts                 | Just you (all projects)         |
| **Project instructions** | `./FUXI.md` or `./.fuxi/FUXI.md`                                                                                                                                  | Team-shared instructions for the project                   | Project architecture, coding standards, common workflows             | Team members via source control |
| **Local instructions**   | `./FUXI.local.md`                                                                                                                                                     | Personal project-specific preferences; add to `.gitignore` | Your sandbox URLs, preferred test data                               | Just you (current project)      |

FUXI.md and FUXI.local.md files in the directory hierarchy above the working directory are loaded in full at launch. Files in subdirectories load on demand when Fuxi reads files in those directories. See [How FUXI.md files load](#how-fuxi-md-files-load) for the full resolution order.

For large projects, you can break instructions into topic-specific files using [project rules](#organize-rules-with-fuxi/rules/). Rules let you scope instructions to specific file types or subdirectories.

### Set up a project FUXI.md

A project FUXI.md can be stored in either `./FUXI.md` or `./.fuxi/FUXI.md`. Create this file and add instructions that apply to anyone working on the project: build and test commands, coding standards, architectural decisions, naming conventions, and common workflows. These instructions are shared with your team through version control, so focus on project-level standards rather than personal preferences.

<Tip>
  Run `/init` to generate a starting FUXI.md automatically. Fuxi analyzes your codebase and creates a file with build commands, test instructions, and project conventions it discovers. If a FUXI.md already exists, `/init` suggests improvements rather than overwriting it. Refine from there with instructions Fuxi wouldn't discover on its own.

  Set `FUXI_CODE_NEW_INIT=1` to enable an interactive multi-phase flow. `/init` asks which artifacts to set up: FUXI.md files, skills, and hooks. It then explores your codebase with a subagent, fills in gaps via follow-up questions, and presents a reviewable proposal before writing any files.
</Tip>

### Write effective instructions

FUXI.md files are loaded into the context window at the start of every session, consuming tokens alongside your conversation. The [context window visualization](/en/context-window) shows where FUXI.md loads relative to the rest of the startup context. Because they're context rather than enforced configuration, how you write instructions affects how reliably Fuxi follows them. Specific, concise, well-structured instructions work best.

**Size**: target under 200 lines per FUXI.md file. Longer files consume more context and reduce adherence. If your instructions are growing large, use [path-scoped rules](#path-specific-rules) so instructions load only when Fuxi works with matching files. You can also split content into [imports](#import-additional-files) for organization, though imported files still load and enter the context window at launch.

**Structure**: use markdown headers and bullets to group related instructions. Fuxi scans structure the same way readers do: organized sections are easier to follow than dense paragraphs.

**Specificity**: write instructions that are concrete enough to verify. For example:

* "Use 2-space indentation" instead of "Format code properly"
* "Run `npm test` before committing" instead of "Test your changes"
* "API handlers live in `src/api/handlers/`" instead of "Keep files organized"

**Consistency**: if two rules contradict each other, Fuxi may pick one arbitrarily. Review your FUXI.md files, nested FUXI.md files in subdirectories, and [`.fuxi/rules/`](#organize-rules-with-fuxi/rules/) periodically to remove outdated or conflicting instructions. In monorepos, use [`fuxiMdExcludes`](#exclude-specific-fuxi-md-files) to skip FUXI.md files from other teams that aren't relevant to your work.

### Import additional files

FUXI.md files can import additional files using `@path/to/import` syntax. Imported files are expanded and loaded into context at launch alongside the FUXI.md that references them.

Both relative and absolute paths are allowed. Relative paths resolve relative to the file containing the import, not the working directory. Imported files can recursively import other files, with a maximum depth of four hops.

Import parsing skips Markdown code spans and fenced code blocks. To mention a path in your FUXI.md without importing it, wrap it in backticks: writing `` `@README` `` keeps the text literal, while `@README` outside backticks imports the file.

To pull in a README, package.json, and a workflow guide, reference them with `@` syntax anywhere in your FUXI.md:

```text theme={null}
See @README for project overview and @package.json for available npm commands for this project.

# Additional Instructions
- git workflow @docs/git-instructions.md
```

For private per-project preferences that shouldn't be checked into version control, create a `FUXI.local.md` at the project root. It loads alongside `FUXI.md` and is treated the same way. Add `FUXI.local.md` to your `.gitignore` so it isn't committed; running `/init` and choosing the personal option does this for you.

If you work across multiple git worktrees of the same repository, a gitignored `FUXI.local.md` only exists in the worktree where you created it. To share personal instructions across worktrees, import a file from your home directory instead:

```text theme={null}
# Individual Preferences
- @~/.fuxi/my-project-instructions.md
```

<Warning>
  The first time Fuxi Code encounters external imports in a project, it shows an approval dialog listing the files. If you decline, the imports stay disabled and the dialog does not appear again.
</Warning>

For a more structured approach to organizing instructions, see [`.fuxi/rules/`](#organize-rules-with-fuxi/rules/).

### AGENTS.md

Fuxi Code reads `FUXI.md`, not `AGENTS.md`. If your repository already uses `AGENTS.md` for other coding agents, create a `FUXI.md` that imports it so both tools read the same instructions without duplicating them. You can also add Fuxi-specific instructions below the import. Fuxi loads the imported file at session start, then appends the rest:

```markdown FUXI.md theme={null}
@AGENTS.md

## Fuxi Code

Use plan mode for changes under `src/billing/`.
```

A symlink also works if you don't need to add Fuxi-specific content:

```bash theme={null}
ln -s AGENTS.md FUXI.md
```

On Windows, creating a symlink requires Administrator privileges or Developer Mode, so use the `@AGENTS.md` import instead.

Running [`/init`](/en/commands) in a repo that already has an `AGENTS.md` reads it and incorporates the relevant parts into the generated `FUXI.md`. It also reads other tool configs like `.cursorrules`, `.devin/rules/`, and `.windsurfrules`.

### How FUXI.md files load

Fuxi Code reads FUXI.md files by walking up the directory tree from your current working directory, checking each directory along the way for `FUXI.md` and `FUXI.local.md` files. This means if you run Fuxi Code in `foo/bar/`, it loads instructions from `foo/bar/FUXI.md`, `foo/FUXI.md`, and any `FUXI.local.md` files alongside them.

All discovered files are concatenated into context rather than overriding each other. Across the directory tree, content is ordered from the filesystem root down to your working directory. For the `foo/bar/` example, `foo/FUXI.md` appears in context before `foo/bar/FUXI.md`, so instructions closer to where you launched Fuxi are read last. Within each directory, `FUXI.local.md` is appended after `FUXI.md`, so your personal notes are the last thing Fuxi reads at that level.

Fuxi also discovers `FUXI.md` and `FUXI.local.md` files in subdirectories under your current working directory. Instead of loading them at launch, they are included when Fuxi reads files in those subdirectories.

If you work in a large monorepo where other teams' FUXI.md files get picked up, use [`fuxiMdExcludes`](#exclude-specific-fuxi-md-files) to skip them. For the full layout of root and per-directory FUXI.md files and rules, see [Monorepos and large repos](/en/large-codebases).

Block-level HTML comments (`<!-- maintainer notes -->`) in FUXI.md files are stripped before the content is injected into Fuxi's context. Use them to leave notes for human maintainers without spending context tokens on them. Comments inside code blocks are preserved. When you open a FUXI.md file directly with the Read tool, comments remain visible.

#### Load from additional directories

The `--add-dir` flag gives Fuxi access to additional directories outside your main working directory. By default, FUXI.md files from these directories are not loaded.

To also load memory files from additional directories, set the `FUXI_CODE_ADDITIONAL_DIRECTORIES_FUXI_MD` environment variable:

```bash theme={null}
FUXI_CODE_ADDITIONAL_DIRECTORIES_FUXI_MD=1 fuxi --add-dir ../shared-config
```

This loads `FUXI.md`, `.fuxi/FUXI.md`, `.fuxi/rules/*.md`, and `FUXI.local.md` from the additional directory. `FUXI.local.md` is skipped if you exclude `local` from [`--setting-sources`](/en/cli-reference).

### Organize rules with `.fuxi/rules/`

For larger projects, you can organize instructions into multiple files using the `.fuxi/rules/` directory. This keeps instructions modular and easier for teams to maintain. Rules can also be [scoped to specific file paths](#path-specific-rules), so they only load into context when Fuxi works with matching files, reducing noise and saving context space.

<Note>
  Rules load into context every session or when matching files are opened. For task-specific instructions that don't need to be in context all the time, use [skills](/en/skills) instead, which only load when you invoke them or when Fuxi determines they're relevant to your prompt.
</Note>

#### Set up rules

Place markdown files in your project's `.fuxi/rules/` directory. Each file should cover one topic, with a descriptive filename like `testing.md` or `api-design.md`. All `.md` files are discovered recursively, so you can organize rules into subdirectories like `frontend/` or `backend/`:

```text theme={null}
your-project/
├── .fuxi/
│   ├── FUXI.md           # Main project instructions
│   └── rules/
│       ├── code-style.md   # Code style guidelines
│       ├── testing.md      # Testing conventions
│       └── security.md     # Security requirements
```

Rules without [`paths` frontmatter](#path-specific-rules) are loaded at launch with the same priority as `.fuxi/FUXI.md`.

#### Path-specific rules

Rules can be scoped to specific files using YAML frontmatter with the `paths` field. These conditional rules only apply when Fuxi is working with files matching the specified patterns.

```markdown theme={null}
---
paths:
  - "src/api/**/*.ts"
---

# API Development Rules

- All API endpoints must include input validation
- Use the standard error response format
- Include OpenAPI documentation comments
```

Rules without a `paths` field are loaded unconditionally and apply to all files. Path-scoped rules trigger when Fuxi reads files matching the pattern, not on every tool use. {/* min-version: 2.1.198 */}As of v2.1.198, matching also works when Fuxi reaches a file through a symlinked path to the project directory, for example in a symlinked checkout.

Use glob patterns in the `paths` field to match files by extension, directory, or any combination:

| Pattern                | Matches                                  |
| ---------------------- | ---------------------------------------- |
| `**/*.ts`              | All TypeScript files in any directory    |
| `src/**/*`             | All files under `src/` directory         |
| `*.md`                 | Markdown files in the project root       |
| `src/components/*.tsx` | React components in a specific directory |

You can specify multiple patterns and use brace expansion to match multiple extensions in one pattern:

```markdown theme={null}
---
paths:
  - "src/**/*.{ts,tsx}"
  - "lib/**/*.ts"
  - "tests/**/*.test.ts"
---
```

Glob syntax treats `[` as the start of a bracket expression such as `[abc]`. A pattern with a `[` that can't be read as a bracket expression, such as `photos [2024/**`, is invalid: it matches nothing, and the rule's other patterns keep working. To match a literal `[` in a file name, escape it as `photos \[2024/**`. {/* min-version: 2.1.207 */}Before v2.1.207, one invalid pattern made the Read tool fail for every file the rule was evaluated against, instead of matching nothing.

#### Share rules across projects with symlinks

The `.fuxi/rules/` directory supports symlinks, so you can maintain a shared set of rules and link them into multiple projects. Symlinks are resolved and loaded normally, and circular symlinks are detected and handled gracefully.

This example links both a shared directory and an individual file:

```bash theme={null}
ln -s ~/shared-fuxi-rules .fuxi/rules/shared
ln -s ~/company-standards/security.md .fuxi/rules/security.md
```

#### User-level rules

Personal rules in `~/.fuxi/rules/` apply to every project on your machine. Use them for preferences that aren't project-specific:

```text theme={null}
~/.fuxi/rules/
├── preferences.md    # Your personal coding preferences
└── workflows.md      # Your preferred workflows
```

User-level rules are loaded before project rules, giving project rules higher priority.

### Manage FUXI.md for large teams

For organizations deploying Fuxi Code across teams, you can centralize instructions and control which FUXI.md files are loaded.

#### Deploy organization-wide FUXI.md

Organizations can deploy a centrally managed FUXI.md that applies to all users on a machine. This file cannot be excluded by individual settings.

<Steps>
  <Step title="Create the file at the managed policy location">
    * macOS: `/Library/Application Support/FuxiCode/FUXI.md`
    * Linux and WSL: `/etc/fuxi-code/FUXI.md`
    * Windows: `C:\Program Files\FuxiCode\FUXI.md`
  </Step>

  <Step title="Deploy with your configuration management system">
    Use MDM, Group Policy, Ansible, or similar tools to distribute the file across developer machines. See [managed settings](/en/permissions#managed-settings) for other organization-wide configuration options.
  </Step>
</Steps>

The `fuxiMd` key lets you put managed FUXI.md content directly inside `managed-settings.json` instead of deploying a separate file.

**Scope**: every Fuxi Code session on the machine, in every repository. For repository-specific guidance, commit a project FUXI.md instead.

**Precedence**: same as a managed FUXI.md file. Loads before user and project FUXI.md.

**Where it's honored**: managed and policy settings only. Setting `fuxiMd` in user, project, or local settings has no effect.

The example below adds behavioral instructions directly in a managed settings file:

```json theme={null}
{
  "fuxiMd": "Always run `make lint` before committing.\nNever push directly to main."
}
```

A managed FUXI.md and [managed settings](/en/settings#settings-files) serve different purposes. Use settings for technical enforcement and FUXI.md for behavioral guidance:

| Concern                                        | Configure in                                              |
| :--------------------------------------------- | :-------------------------------------------------------- |
| Block specific tools, commands, or file paths  | Managed settings: `permissions.deny`                      |
| Enforce sandbox isolation                      | Managed settings: `sandbox.enabled`                       |
| Environment variables and API provider routing | Managed settings: `env`                                   |
| Authentication method and organization lock    | Managed settings: `forceLoginMethod`, `forceLoginOrgUUID` |
| Code style and quality guidelines              | Managed FUXI.md                                         |
| Data handling and compliance reminders         | Managed FUXI.md                                         |
| Behavioral instructions for Fuxi             | Managed FUXI.md                                         |

Settings rules are enforced by the client regardless of what Fuxi decides to do. FUXI.md instructions shape Fuxi's behavior but are not a hard enforcement layer.

#### Exclude specific FUXI.md files

In large monorepos, ancestor FUXI.md files may contain instructions that aren't relevant to your work. The `fuxiMdExcludes` setting lets you skip specific files by path or glob pattern.

This example excludes a top-level FUXI.md and a rules directory from a parent folder. Add it to `.fuxi/settings.local.json` so the exclusion stays local to your machine:

```json theme={null}
{
  "fuxiMdExcludes": [
    "**/monorepo/FUXI.md",
    "/home/user/monorepo/other-team/.fuxi/rules/**"
  ]
}
```

Patterns are matched against absolute file paths using glob syntax. You can configure `fuxiMdExcludes` at any [settings layer](/en/settings#settings-files): user, project, local, or managed policy. Arrays merge across layers.

Managed policy FUXI.md files cannot be excluded. This ensures organization-wide instructions always apply regardless of individual settings.

## Auto memory

Auto memory lets Fuxi accumulate knowledge across sessions without you writing anything. Fuxi saves notes for itself as it works: build commands, debugging insights, architecture notes, code style preferences, and workflow habits. Fuxi doesn't save something every session. It decides what's worth remembering based on whether the information would be useful in a future conversation.

### Enable or disable auto memory

Auto memory is on by default. To toggle it, open `/memory` in a session and use the auto memory toggle, or set `autoMemoryEnabled` in your project settings:

```json theme={null}
{
  "autoMemoryEnabled": false
}
```

To disable auto memory via environment variable, set `FUXI_CODE_DISABLE_AUTO_MEMORY=1`.

### Storage location

Each project gets its own memory directory at `~/.fuxi/projects/<project>/memory/`. The `<project>` path is derived from the git repository, so all worktrees and subdirectories within the same repo share one auto memory directory. Outside a git repo, the project root is used instead.

To store auto memory in a different location, set `autoMemoryDirectory` in your `settings.json`. It is read from any [settings scope](/en/settings#settings-precedence): user, project, local, policy, or `--settings`.

```json theme={null}
{
  "autoMemoryDirectory": "~/my-custom-memory-dir"
}
```

The value must be an absolute path or start with `~/`. When set in a project's `.fuxi/settings.json` or `.fuxi/settings.local.json`, the value is honored only after you accept the workspace trust dialog for that folder, the same gate that governs hooks.

The directory contains a `MEMORY.md` entrypoint and optional topic files:

```text theme={null}
~/.fuxi/projects/<project>/memory/
├── MEMORY.md          # Concise index, loaded into every session
├── debugging.md       # Detailed notes on debugging patterns
├── api-conventions.md # API design decisions
└── ...                # Any other topic files Fuxi creates
```

`MEMORY.md` acts as an index of the memory directory. Fuxi reads and writes files in this directory throughout your session, using `MEMORY.md` to keep track of what's stored where.

Auto memory is machine-local. All worktrees and subdirectories within the same git repository share one auto memory directory. Files are not shared across machines or cloud environments.

### How it works

The first 200 lines of `MEMORY.md`, or the first 25KB, whichever comes first, are loaded at the start of every conversation. Content beyond that threshold is not loaded at session start. Fuxi keeps `MEMORY.md` concise by moving detailed notes into separate topic files.

This limit applies only to `MEMORY.md`. FUXI.md files are loaded in full regardless of length, though shorter files produce better adherence.

Topic files like `debugging.md` or `patterns.md` are not loaded at startup. Fuxi reads them on demand using its standard file tools when it needs the information.

Fuxi reads and writes memory files during your session. When you see "Writing memory" or "Recalled memory" in the Fuxi Code interface, Fuxi is actively updating or reading from `~/.fuxi/projects/<project>/memory/`.

### Audit and edit your memory

Auto memory files are plain markdown you can edit or delete at any time. Run [`/memory`](#view-and-edit-with-%2Fmemory) to browse and open memory files from within a session.

## View and edit with `/memory`

The `/memory` command lists all FUXI.md, FUXI.local.md, and rules files loaded in your current session, lets you toggle auto memory on or off, and provides a link to open the auto memory folder. Select any file to open it in your editor.

When you ask Fuxi to remember something, like "always use pnpm, not npm" or "remember that the API tests require a local Redis instance," Fuxi saves it to auto memory. To add instructions to FUXI.md instead, ask Fuxi directly, like "add this to FUXI.md," or edit the file yourself via `/memory`.

## Troubleshoot memory issues

These are the most common issues with FUXI.md and auto memory, along with steps to debug them.

### Fuxi isn't following my FUXI.md

FUXI.md content is delivered as a user message after the system prompt, not as part of the system prompt itself. Fuxi reads it and tries to follow it, but there's no guarantee of strict compliance, especially for vague or conflicting instructions.

To debug:

* Run `/memory` to verify your FUXI.md and FUXI.local.md files are being loaded. If a file isn't listed, Fuxi can't see it.
* Check that the relevant FUXI.md is in a location that gets loaded for your session (see [Choose where to put FUXI.md files](#choose-where-to-put-fuxi-md-files)).
* Make instructions more specific. "Use 2-space indentation" works better than "format code nicely."
* Look for conflicting instructions across FUXI.md files. If two files give different guidance for the same behavior, Fuxi may pick one arbitrarily.

If the instruction is something that must run at a specific point, such as before every commit or after each file edit, write it as a [hook](/en/hooks-guide) instead. Hooks execute as shell commands at fixed lifecycle events and apply regardless of what Fuxi decides to do.

For instructions you want at the system prompt level, use [`--append-system-prompt`](/en/cli-reference#system-prompt-flags). This must be passed every invocation, so it's better suited to scripts and automation than interactive use.

<Tip>
  Use the [`InstructionsLoaded` hook](/en/hooks#instructionsloaded) to log exactly which instruction files are loaded, when they load, and why. This is useful for debugging path-specific rules or lazy-loaded files in subdirectories.
</Tip>

### I don't know what auto memory saved

Run `/memory` and select the auto memory folder to browse what Fuxi has saved. Everything is plain markdown you can read, edit, or delete.

### My FUXI.md is too large

Files over 200 lines consume more context and may reduce adherence. Use [path-scoped rules](#path-specific-rules) to load instructions only when Fuxi works with matching files, or trim content that isn't needed in every session. Splitting into [`@path` imports](#import-additional-files) helps organization but doesn't reduce context, since imported files load at launch.

{/* min-version: 2.1.206 */}The [`/doctor`](/en/commands#all-commands) checkup proposes trims for a checked-in FUXI.md: it cuts content Fuxi can derive from the codebase, such as directory layouts, dependency lists, and architecture overviews, and keeps pitfalls, rationale, and conventions that differ from tool defaults. The trim check requires Fuxi Code v2.1.206 or later.

### Instructions seem lost after `/compact`

Project-root FUXI.md survives compaction: after `/compact`, Fuxi re-reads it from disk and re-injects it into the session. Nested FUXI.md files in subdirectories are not re-injected automatically; they reload the next time Fuxi reads a file in that subdirectory.

If an instruction disappeared after compaction, it was either given only in conversation or lives in a nested FUXI.md that hasn't reloaded yet. Add conversation-only instructions to FUXI.md to make them persist. See [What survives compaction](/en/context-window#what-survives-compaction) for the full breakdown.

See [Write effective instructions](#write-effective-instructions) for guidance on size, structure, and specificity.

## Related resources

* [Debug your configuration](/en/debug-your-config): diagnose why FUXI.md or settings aren't taking effect
* [Skills](/en/skills): package repeatable workflows that load on demand
* [Settings](/en/settings): configure Fuxi Code behavior with settings files
* [Subagent memory](/en/sub-agents#enable-persistent-memory): let subagents maintain their own auto memory