Zed System Prompts: Customize Your Assistant Instructions

Zed is a code editor with a built-in AI assistant that you configure through its settings files. You can write assistant instructions at the global level (applying to all projects) or at the project level (applying only in the current directory). Tools like fenbs keep the team's project decisions and reusable instructions in one place that every connected coding tool can read, so rules stay consistent when developers switch between Zed, Cursor, or Claude Code.

The exact settings keys and file paths in Zed can change between releases. Check the Zed documentation↗ (opens in a new tab) for the current configuration reference before setting up a project.

How Zed handles assistant instructions

Zed's assistant uses the AI model you configure in settings (Claude, GPT-4o, and others are supported). The instructions you write go into the system context for every assistant session in the relevant scope. They tell the model how to behave in your editor: what the project is, how to format code, which patterns to follow, and what to ask about before changing.

Zed distinguishes between the assistant panel (a chat interface) and inline completions (suggestions as you type). System instructions primarily shape the assistant panel. Inline completions depend more on the model's general coding ability and the current file context. Keep this distinction in mind when testing your instructions.

Project-level vs. global instructions

Global instructions in Zed's user settings apply across all projects. Use this for truly universal preferences: your preferred coding style, output language, or how detailed you want explanations to be.

Project-level instructions go in the project settings file (.zed/settings.json in the project directory). These apply only when Zed is open in that project. Use project instructions for stack-specific rules: the framework, the naming conventions, the patterns to avoid, and the constraints specific to that codebase. Project instructions take priority over global ones when there is a conflict.

What to put in project instructions

Effective project instructions for a coding assistant cover three areas: the context the model needs to understand the codebase, the rules it should follow, and the boundaries of what it should change on its own versus ask about.

• Stack: "This is a TypeScript project using React 19 and Tailwind v4."
• Conventions: "Use named exports. Place tests in __tests__ folders alongside source files."
• Patterns to avoid: "Do not use class components. Do not use any as a type escape."
• Off-limits: "Do not change files in the db/ folder without asking."
• Checks: "After any change to a component, explain how it would be tested."

Keep project instructions concise. A file that takes two minutes to read in full is already at the limit of what will actually be maintained. If the rules grow longer, consider whether some belong in the project README as developer documentation rather than as model instructions.

Verifying scope

After setting up instructions, open the Zed assistant panel and ask a question where the answer should differ from Zed's default behavior. If you specified TypeScript, ask for a snippet in a different language and check whether the model follows the rule or ignores it. If you set a format preference, ask for output that would normally violate it.

Also check scope boundaries. Open Zed in a different project that does not have project-level instructions and confirm your global preferences still apply. Open the project that has instructions and confirm only those instructions are active.

For more on how instructions flow through different editor tools, context engineering vs. prompt engineering explains the trade-off between what goes in a system instruction and what goes in the task.

Sharing prompts across coding tools

A project rule you set in Zed probably needs to apply in Claude Code, Cursor, or whatever tool a teammate uses. Writing the same rule in four different formats is error-prone, and the copies diverge when someone updates one and forgets the others.

The most maintainable approach is to keep approved decisions in one central place and derive each tool's configuration from it. The decision "use Vitest, not Jest" belongs in the team's shared record. Each tool's configuration file states that decision in the format that tool expects.

How to do this with fenbs

1. Create a free account. Start with a personal kanban board for this project.
2. Add a task for setting up your Zed project instructions. In the plan, list the key rules and who approved them.
3. For each standing decision -- a rule that should apply from now on -- record it in fenbs as a Decision with the deciding person and the reason.
4. Connect Zed or another coding tool to fenbs over MCP from Integrations. The connected tool reads your project Decisions and rules at the start of each session.
5. When the project rules change, update the Zed settings file and the corresponding Decision in fenbs on the same day.

For reusable prompt patterns, system prompt examples has practical starting points. The Zed AI guide explains the broader AI feature set in Zed. Prompt engineering covers the general principles for writing instructions that hold up.