quick-prompt puts a prompt library inside every text field

The trigger is a slash command typed into a normal input box

The core interaction is deliberately small. Type /p in any text field on any page and a prompt selector opens; pick an entry and it is inserted into the field you were typing in. There is a keyboard route too, with Ctrl+Shift+P on Windows and Linux and Command+Shift+P on macOS. The saved selection is inserted into the current input box, which is the part that matters, because it removes the copy and paste round trip entirely. The same shortcut family handles capture: with text selected, Ctrl+Shift+S on Windows and Linux or Command+Shift+S on macOS saves that selection as a new prompt, and the same action is available from the right-click context menu. The extension is built on WXT and React, with the component and library folders at the repository root alongside entrypoints, lib, utils, types and a tailwind.config.js.

A prompt carries categories, tags, attachments and variables

The data model is richer than a flat list of strings, and this is where the extension earns its keep. A prompt can have a category, a title, content, attachments, tags and variables. Variables are the standout feature, since a prompt can contain placeholders in the {{variable name}} format, and when you pick that prompt a dialog asks you to fill in the values before it is inserted. That turns one stored template into many concrete prompts, which is the difference between a clipboard manager and something you can actually build a workflow on. Search and filtering over the library are also supported, and the interface is described as adapting automatically to the system light and dark theme. The management page is where you add, edit, delete, tag and categorise entries, and it is reached from the extension icon.

Four sync backends, and a JSON export that is the real safety net

The library is not locked to one machine. The README lists cloud sync through WebDAV, a Notion database, and Gitee or GitHub Gist, which covers self hosted storage, a database many teams already run, and two git hosts. Alongside that there is plain export and import of the whole library as a JSON file from the management page, and import supports either merging with what is already there or overwriting it. The merge option is the one that gets attention, because it is what lets you pull a shared library into a second machine without losing local entries. The JSON export also matters for a reason the README does not spell out, and that is the only copy you control. Since the extension overwrites an existing prompt when you edit it, a versioned export taken before a batch edit is the practical undo. The repository also ships a CHANGELOG.md and a docs/ directory, so the behaviour of each release is recorded even if the extension itself keeps no history.

Two build targets, and the WXT scripts behind them

The package manifest defines a small set of scripts, all of them thin wrappers around WXT.

  "scripts": {
    "dev": "wxt",
    "dev:firefox": "wxt -b firefox",
    "build": "wxt build",
    "build:firefox": "wxt build -b firefox",
    "zip": "wxt zip",
    "zip:firefox": "wxt zip -b firefox",
    "compile": "tsc --noEmit",
    "test": "vitest",

The same split shows up in the install and build instructions in the README.

pnpm install

# 开发模式 (Chrome)
pnpm dev
# 开发模式 (Firefox)
pnpm dev:firefox

There is a postinstall hook running wxt prepare, so a fresh clone is wired up automatically, and the package is set to private with pnpm as the package manager. The test stack is vitest with jsdom and testing-library, and there is a separate tsc typecheck script, so the project does treat types and tests as part of the workflow rather than decoration.

Loading an unpacked build differs between Chrome and Firefox

The README covers installing a built extension in both browsers, and the paths are not interchangeable. For Chrome and Edge you open chrome://extensions or edge://extensions, enable developer mode, choose to load an unpacked extension, and point at the .output/chrome-mv3/ directory. For Firefox you open about:debugging, pick this Firefox, choose to load a temporary add-on, and select the manifest.json file inside .output/firefox-mv2/. The difference in manifest version and in what the browser accepts is the reason the project keeps a separate Firefox build script rather than shipping one artefact. The output directories also differ, which catches people out when they build for Chrome and then look for a Firefox folder. For ordinary users there is a simpler path, since the extension is published in the Chrome Web Store and on the Firefox add-ons site, and a GitHub Releases page carries the built package for anyone who wants to install it manually.

Where a prompt manager becomes a liability

The extension stores your prompts where a browser extension can reach them, and the README does not describe encryption of the local library or of an exported file. That is not a reason to avoid the tool, but it is a reason to keep regulated or third-party confidential material out of it. The second limitation is the same in a different form. Because the extension injects text into any page, the page receives whatever you insert, and a prompt that embeds a customer name or an internal identifier is pasted into a third-party application whose retention you do not control. A third point is the trigger collision. The /p prefix is short and generic, so on a site with a slash command of its own the selector can appear unexpectedly, and the README does not describe a way to change that prefix. There is also no documented way to store a prompt version history, which means an edit to a shared prompt is a silent overwrite for everyone who syncs from the same backend.

The configuration file points at Google Cloud credentials

The repository includes a .env.example that shows what the build expects for release signing and distribution, and the keys are about Google Cloud Console client identifiers rather than anything about your prompts.

# Google Cloud Console Configuration
# Replace these with your own Google Cloud Console client IDs
WXT_CHROME_APP_CLIENT_ID_PREFIX=your-chrome-app-client-id-prefix
WXT_WEB_APP_CLIENT_ID_PREFIX=your-web-app-client-id-prefix
[email protected]

The WXT_FIREFOX_EXTENSION_ID value is the add-on identifier Firefox recognises, and the two client id prefixes are the application identifiers used when the extension is published or updated through Google services. None of these are needed to run the extension locally, so a user who only wants prompts in their browser never touches this file. What the file does tell you is that the release path is designed around a Google Cloud project, which is worth knowing if you fork the project and intend to publish your own build. The licence is MIT, so forking and republishing is straightforward from a legal standpoint, and the contribution guidance in the README is a short fork, branch, commit, push and pull request sequence.

Editorial conclusion

quick-prompt suits someone who reuses the same prompts daily across many web apps and wants one library reachable from any input box, and it suits teams already keeping prompts in a synced Notion database who want a faster path into them. It is the wrong tool if you handle confidential material in a regulated environment, since the README does not describe encryption at rest for the local library, and it is the wrong tool if you need version history, since a prompt overwrite replaces the previous text with nothing to fall back on. Before adopting it, export the library to JSON and keep that file, decide which sync backend holds the authoritative copy, and check that the /p trigger does not collide with a site that already uses it. The last push was on 2026-08-25 and the current release is 2.0.4 from 2026-08-27, which added prompt quick injection.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. wenyuanw/quick-prompt on GitHub