Zed Prompt Library: Organize and Reuse Coding Instructions

A Zed prompt library is a set of reusable AI instructions stored in your project so every session in the editor starts from the same context. Zed's AI assistant reads rules files and context you add to the conversation, which means you can organize common instructions once and load them when you need them, rather than rewriting them session by session. A tool like fenbs extends that library beyond the editor: team decisions and shared rules live there, readable by any connected AI, not just the Zed session on your machine.

This guide covers how Zed handles AI context, how to write a project rules file, how to structure reusable prompt snippets, and how to keep shared context available across projects and team members.

How Zed handles AI context and prompts

Zed's built-in AI assistant panel lets you chat with a connected model, add files and code selections as context, and use slash commands to trigger specific actions. Instructions you write in a rules file at the project level are injected into conversations automatically, so the assistant sees the project's standing rules without you pasting them each time.

Zed also supports custom slash commands that you define for your project. These let you load a specific prompt from a file into the assistant panel with a short command, which is the closest equivalent to a prompt library built into the editor. For the current list of what Zed supports, check the official Zed documentation, as AI features are updated frequently.

Writing a project rules file

A rules file at the project level sets the standing context for every AI conversation in that project. Write it as a plain text or Markdown file in your project root or a .zed directory, depending on how your Zed version loads it. Keep it focused on what the assistant needs to know before touching any file in the project.

# Project rules for [project name]

## Language and conventions
- All code is TypeScript with strict mode enabled.
- Use async/await, not .then() chains.
- Prefer named exports over default exports.
- Error messages should say what failed and what to do next, not just "error".

## Testing
- Every new function needs at least one test in the adjacent .test.ts file.
- Do not modify existing tests unless the behavior they test has changed.
- Tests use the project's existing test runner; do not add a new one.

## Scope
- Work only on files mentioned in the task.
- Do not refactor code outside the current task.
- If you notice a problem in nearby code, flag it in a comment rather than fixing it unasked.

Keep rules specific and actionable. A rule like "write clean code" gives the assistant no useful instruction. A rule like "do not modify existing tests unless the behavior they test has changed" gives it a clear boundary it can follow.

Reusable prompt snippets for common tasks

Beyond standing rules, you will have prompts you use repeatedly for specific tasks: reviewing a function, writing a test, explaining a piece of code to a new team member. Store these as text snippets in your project so you can load and adapt them quickly rather than rewriting them each session.

# Code review
Review the function above for edge cases. List each one and whether the current code handles it. Do not rewrite the function.

# Unit test
Write a unit test for the function above. Use the same test file pattern as the existing tests in this folder. Cover the happy path and the two most likely failure modes.

# Explanation
Explain what this function does to a developer new to this codebase. Use plain language and avoid jargon. Note any non-obvious behavior.

# Refactor check
Identify any issues in the code above that would make it harder to maintain or test six months from now. List each one with a one-sentence explanation. Do not rewrite the code.

These are starting points. Adapt each one to your project's conventions and save the adapted version. A prompt tuned for your codebase is more useful than a generic one because it already knows the test file pattern, the naming conventions, and the scope limits that matter to your team.

Organizing prompts across multiple projects

• Keep project-specific rules in the project. A rules file in the repo travels with the code and is available to every team member who opens the project.
• Keep cross-project prompts in a shared document or tool. Rules that apply to all your projects, such as how to write commit messages or how to document a decision, belong somewhere every project can access.
• Name prompts by the task, not the tool. "Code review" works across editors; "Zed code review" limits reuse unnecessarily.
• Version your rules files. A rules file in version control gives you a history of what instructions changed and when, which helps when AI outputs change unexpectedly after an update.

For prompts tied to specific AI tools and how they compare, see Zed AI. For a guide to building and organizing a prompt library outside the editor, how to build a prompt library covers the broader approach.

When Zed rules need shared context

A rules file in the repo handles what the AI should know about the code. It does not handle what the AI should know about the project: the current priorities, the decisions made last week, the context a new team member would need to start contributing. That kind of context changes faster than code conventions and does not belong in a file the whole team has to review before merging.

When a teammate opens the same project in their Zed, they get the same rules file. They do not automatically get the project context you have been building in your AI conversations. A shared tool outside the editor bridges that gap: the project rules stay in the repo, the project context stays in fenbs, and both are available at the start of any session.

How to do this with fenbs

Use Zed's rules file for coding conventions and scope limits. Use fenbs for the project decisions, current priorities, and lessons that go beyond what belongs in the codebase.

1. Create a free account. Add your project with a short description of its goal and current state.
2. Write the standing rules for this project as Decisions and rules in fenbs. Include anything that should apply to every AI session, whether in Zed or another tool.
3. Add your reusable coding prompts to Skills and prompts. Name each one by the task it performs. This gives any connected AI access to the same prompt library your Zed session uses.
4. Connect your AI apps at Integrations. At the start of a new Zed session on a fresh task, ask the connected assistant to read the project context from fenbs before working. It will start from the current priorities rather than the last session's memory.