Zed and Cursor Rules: Move Your Project Instructions

Moving project instructions from Cursor to Zed means converting .cursor/rules/*.mdc files into the format Zed uses for assistant context. The content translates well: the same conventions, the same verification steps, and the same boundaries all apply. The format and activation mechanism are different.

The deeper issue is that project decisions stored only in rule files stay with the editor. fenbs solves this by keeping project decisions, tasks, and context outside any editor, so the same record is available whether you are in Cursor, Zed, or switching between them.

How Cursor rules and Zed context differ

Cursor rules are .mdc files in a .cursor/rules/ folder at the project root. Each file has frontmatter that specifies a description, a glob pattern for when it applies, and whether it is always active. The frontmatter controls how Cursor decides which rules to include in a session.

Zed uses a different mechanism for giving the assistant project context. As of October 2026, Zed supports an AGENTS.md file at the project root (or configured location) that the assistant reads as project instructions. You can also add context through Zed's assistant panel. Check Zed's documentation↗ (opens in a new tab) before translating your rules, as the context system continues to evolve.

What translates directly

The instructions themselves translate with no change. If your Cursor rule says "run tsc --noEmit before marking a task done", that instruction works in Zed too. Naming conventions, folder layouts, verification commands, and escaping rules all port directly because they describe your project, not a specific editor feature.

Review your Cursor rules for content that assumes a Cursor-specific feature. Glob-based activation (globs: in the frontmatter) is a Cursor feature; Zed does not activate instructions based on file patterns in the same way. Those instructions may need to become general project instructions or be placed in a context note rather than an automatic trigger.

What to rewrite

Frontmatter fields like globs, alwaysApply, and description are Cursor-specific. They tell Cursor when to attach the rule to a session. In Zed, the assistant receives instructions through a different input: the AGENTS.md file, a context note, or a message in the assistant panel.

This is also an opportunity to review the quality of each rule. When you read a Cursor rule to rewrite it for Zed, you read it with fresh eyes. Rules that seemed clear when written may contain project jargon that is obvious to the team but opaque to a new assistant. The rewriting step is a natural audit of each rule's clarity and completeness.

For Zed, combine the rules that apply to the whole project into one AGENTS.md file. Rules that were glob-activated in Cursor (for example, a Playwright rule that only applied to **/*.spec.ts) may need to be included in the general instructions with a note about when they apply, or added as a context file you attach manually for test work.

# Project instructions

## TypeScript
- Strict mode is on. Do not introduce code that requires loosening it.
- Shared types live in `packages/types/src/index.ts`.

## Testing (applies to *.spec.ts and *.test.ts)
- Use getByRole and getByLabel locators; avoid CSS selectors.
- Import fixtures from tests/fixtures/index.ts.
- Run `pnpm test` before marking a task done.

## Verification
- Run `tsc --noEmit` in every package before finishing.

## Decisions and context
- Read project decisions in fenbs before planning work that affects a
  named boundary or an approved convention.

Keeping decisions outside both editors

Rule files and AGENTS.md files solve the problem of giving an assistant project conventions. They do not solve the problem of giving it current project context: which tasks are in progress, what was decided last week, where the last session left the work. That context lives in your chat history, which stays behind when you switch editors.

This is a structural limitation of any editor-resident context: the context lives in the editor, not in the project. When a rule file or AGENTS.md records a convention — how packages import each other, what the verification command is — that convention is stable enough to write down and keep in a file. But the current state of a feature, the decision made in last week's design review, or the reason a particular approach was chosen: these belong in a system that is not bound to a single editor.

Storing decisions, current tasks, and progress in fenbs solves this. Both Cursor and Zed can connect to fenbs over MCP and read the same project record at the start of a session. A decision recorded in fenbs is available to whichever editor you open next, without copying anything.

See Zed AI for more on Zed's assistant features and how it connects to outside tools. See cursor rules examples for the patterns most worth porting. For organizing rule files by scope within a project, see cursor rules globs and cursor rules hierarchy.

How to move Cursor rules to Zed with fenbs

1. Create a free account and add your project if you have not already.
2. Export the decisions from your Cursor rules into fenbs: any approved convention that was arrived at through discussion rather than being an obvious default. Record those as Decisions.
3. Create an AGENTS.md file at the project root. Combine your always-applicable Cursor rules into it. Add a note telling the assistant to read the project context in fenbs before starting.
4. For glob-activated rules, decide whether to merge them into AGENTS.md with a scope note or attach them manually for the sessions where they apply.
5. Connect Zed to fenbs via Integrations following the Zed setup guide.

Keep your Cursor rules as well. If the project switches back or you use both editors in parallel, having both sets of instructions ready avoids duplicate work.