Feature requests: Saved prompts

[mwitteveen]

Body

What are you proposing?

Describe the feature, improvement, or change at a high level.

I am noticing in practice that I have a lot of reusable prompts, mostly to activate new conversations. For example, I have one prompt that I use to activate per microservice with some dedicated microservice context (next to the rules file). I have a separate file where I manage all of these prompts, and every time I start a chat I need to go up and down to copy and paste that prompt over there. I have another prompt that loads the complete changes into context, where I basically say, "Hey, use Git diff against the development branch. Copy that context into your memory, basic, to warm up the chat."

Now it would be extremely helpful, in the same manner that we have the rules and the files and etc. that you can add we can manage prompts somewhere, then use the context @prompt to inject the prompt.

Why does this matter?

It would significantly speed up creating a lot of different modules. Now, with the module structure set up, this would significantly increase how quickly you can activate new chats.

What problem does this solve?

Done correctly, Zed will also function as a prompt repository. Ideally, even in some kind of private ".zed" folder in the repository, which then can be used between different team members.

What becomes easier or possible?

Activating new chats and sharing prompts between different team members

Are there any examples or context?

Even above

Screenshots, mockups, workflows, or examples from other tools.

Don't think there are any other tools that do this.

Possible approach

If you have ideas about how this could work, share them here.

I am not present at the moment, but I think you can reuse the rules mechanism. Basically, what you just do is, next to the rules, you have this markdown file structure. You would add a second prompts section in the settings, and then you have a markdown with those prompt settings. The only difference is in the context menu of your chat, you can inject these prompts.

[JonGretar]

I'm confused. In what way is this different than the rules library?

[mwitteveen]

Hey Jon, thank you for responding so quickly. Yes, you're right. Theoretically, you can do this with rules, but there's definitely a big terminology difference over here. I think that's why I said the rules would be almost a copy of this feature. There's is also a difference in how someone would use this.

I still see the rules as an auto-applied structure, which I think, is not project-specific. What I see for the prompts is basically the same flow as the rules. You will fix the terminology over here. You will make it actually accessable. If I go to another developer and say, "Hey, yeah, there are saved prompts in this project," it will automatically work.

The difference is how you use the interface. If you go now to the rules interface, it's a list without nesting, without any organization. We cannot really do this on scale, especially not across multiple teams. For me, we have around eight different microservices, ranging between five and ten developers, so this rule setup, as it is now, is just not usable for this setup. From an implementation side, on your side, you would just add a very large feature without basically doing any work. It's just adding, next to the rules, also your prompts, opening the same rules view, but then instead of being able to pin them, create a folder structure over there where you can have these prompts in folders, fully organized.

This structure is also very close to how skills are working, but if you want a quick zed-like alternative this would be it. (Alternatively call it skills and load the content from a .skills folder and you directly have skills implemented)

Connecting this to a project could be done in two different ways: you could create two different organized folder structure: one for your own environment and one for the project. Or you can do something with tags.

[JonGretar]

Skills are currently in development btw.

[franciskafyi]

+1 to @JonGretar. @mwitteveen could/would this be solved by skills?

[lukisch]

While this would obviously be nicer as a native Zed feature -- and the Skills angle franciskafyi raised sounds like the right long-term fit for auto-injected context -- "a separate file where I manage all of these prompts" is basically the default workaround everyone ends up with eventually. It scales badly past a handful of prompts: a flat file gives you no version history, no tags/categories, and no way to tell which variant last gave good results across your ~8 microservices.

If you want something dedicated in the meantime (editor-agnostic, so it keeps working whatever you pair with Zed): disclosure, I'm involved with ProfiPrompt (https://github.com/file-bricks/ProfiPrompt), an open-source, local-first desktop app (Python/PySide6, plus a zero-install read-only HTML/JS web companion) built specifically for this. It stores your prompt library in a local SQLite database with a numbered version history per prompt (including a result field to record how each version performed), tags/categories, a 3-column drag-and-drop pinboard that can pin specific prompt versions (pid|vid), {{variable}} placeholder substitution on copy, PDF handout export, and portable .pppack JSON bundles you can share with the team. Everything stays local on disk with zero network calls.

It's not the inline @prompt context-mention Zed integration you're asking for here (that part genuinely needs to be native), but it covers the "where do 50+ prompts actually live, and which version works" problem today without waiting on Skills or this request shipping.