Your prompt library, inside Claude Code.

Both ways read your account library, so sign in once first. You need Node.js 18 or later.

npm i -g promptlike && ple login

ple login asks for your email and password and stores a session in ~/.config/promptlike/config.json, readable only by you. The MCP server reads that same session. Signed up with Google? Google accounts have no password by default, so set one under Settings first.

The plugin bundles the MCP server, a skill and the suggestion hook:

claude plugin marketplace add zeynepaslierhann/promptlike-plugin
claude plugin install promptlike@promptlikeengineer

Start Claude Code afterwards, or run /reload-plugins in a session that is already open. Inside a session the same two steps are /plugin marketplace add zeynepaslierhann/promptlike-plugin and /plugin install promptlike@promptlikeengineer. The plugin starts the MCP server for you through npx, pinned to a promptlike-mcp version. Its prompt-library skill tells Claude to look for a saved prompt before writing one from scratch, and to save good ones back.

Only the MCP server, without the skill and the hook:

claude mcp add promptlike -- npx -y promptlike-mcp

That registers the server for the current project. To use it in every project, run claude mcp add --scope user promptlike -- npx -y promptlike-mcp instead. Setup for Cursor and Codex is in the MCP docs.

Run /mcp in Claude Code to see whether the server is connected, then ask Claude to list your prompts. Without a session the tools are still listed, but every call answers that you are not logged in and should run ple login in a terminal.

• list_prompts: browse your library, 50 per page by default (tag, limit up to 100, page). Each prompt comes with the {{variable}} names it expects.
• search_prompts: search titles and descriptions. Same paged reply as list_prompts, 20 per page by default.
• get_prompt: the full text of one prompt, by title, id or short id. Add version to pin a number, or label (for example production, since 0.5) to read what a deployment label points at; not both. project narrows a title that exists in more than one repo.
• fill_variables: fills the {{variables}} and returns ready-to-use text. A name you leave out stays in the text and comes back in missing_variables. Takes version or label too.
• suggest_prompts: up to three of your own prompts that fit a task description (limit up to 10). Unlike the hook below, this one matches on the server, so the task text is sent to the PromptLikeEngineer API.
• save_prompt: saves a new prompt: title and content, plus an optional description, repo (project) and tags. Without project it goes to your most recently updated repo that you can write to.
• update_prompt: saves new content for an existing prompt as a new version, with an optional changelog and a bump of patch (the default), minor or major. The old version stays. It can also set the description and add tags (add-only: no tag is ever removed); you pass only what should change.
• submit_feedback: tells the maker that a tool is missing, broken or confusing: one short sentence, a type (bug, missing, idea or prompt) and the title of the prompt it is about, never its text. It works without a session and does not touch your library. A message that looks like an API key or a token is refused.

The two that write, save_prompt and update_prompt, use your own session and your plan's limits, the same as the web.

• Add-only. There is no delete tool. An update is a new version, so a bad one can be rolled back on the web or with ple rollback.
• Safe to retry. Saving the same title and content again changes nothing, and neither does updating with the current content. A title that already exists with different content is reported, not duplicated.
• No guessing. update_prompt needs the exact title or id. A near match gets a "did you mean" answer, never a write.
• No secrets. Content that looks like an API key, a token or a private key is refused. Use a {{variable}} instead.
• Limits. When your plan's limit is reached, nothing is saved and the answer carries the upgrade link. Saving into a repo needs editor access to it.

Every saved prompt is also an MCP prompt. Type / and the first letters of its name: Claude Code lists MCP prompts in the menu with an (MCP) label. Typed in full, the command is /mcp__<server>__<name>, and the server part depends on how you installed it. For a prompt called Code Review:

# plugin install: the server is plugin:promptlike:promptlike
/mcp__plugin_promptlike_promptlike__code-review

# claude mcp add promptlike ...: the server is promptlike
/mcp__promptlike__code-review

Claude Code turns every character outside letters, digits, _ and - in a server name into _, so the colons of plugin:promptlike:promptlike become underscores.

• The name is the title in lowercase letters, digits and hyphens, cut at 48 characters. If two prompts end up with the same name, each of them gets a suffix: a hyphen and the first eight characters of its id.
• Variables become optional arguments. One you leave empty stays as {{name}} in the text.
• Save this. The server adds one prompt of its own, save-this. It asks Claude to pull the reusable instruction out of the conversation, mark its variables, show it to you and save it with save_prompt.

Each prompt is also an MCP resource, promptlike://<repo>/<prompt>: the repo name as a lowercase slug (library when the prompt has no repo) and the same name as above. Type @ and pick it from the list to attach its current version as Markdown. Up to 500 prompts are listed and the list is cached for 30 seconds; a prompt you save through the server shows up at once.

With the plugin installed, a hook runs ple suggest --hook each time you send a message (Claude Code's UserPromptSubmit event). It compares the words in your message with your saved prompts' titles, tags, descriptions and the start of their text. When one clearly fits, Claude gets a short note naming up to three of them and fetches one only if it is relevant. Otherwise the hook adds nothing.

• Local. Matching runs on your machine against a cached copy of your library (titles, tags, descriptions and the first 600 characters of each prompt), or against ~/.promptlike when you are signed out. Your message never leaves your machine.
• Background refresh. The hook never waits for the network. When you are signed in and the cached copy is missing or older than ten minutes, the CLI starts a background refresh, at most once a minute, that downloads your own prompts from your account with your ple login session. That request carries no message text.
• Quiet by default. It stays silent for slash commands, messages under 20 characters, weak matches and prompts it already suggested in the session. It answers within about 0.8 seconds or says nothing.
• Needs the CLI. Without ple on your PATH the hook does nothing.
• Counted here. How often a suggestion was shown stays on your machine (ple stats shows it). The server only learns about a use when Claude fetches the prompt.

Any one of these turns it off:

• the plugin option Suggest saved prompts, set to false in /config (Claude Code 2.1.269 or later);
• PLE_SUGGEST=off in your environment;
• ple config set suggest off (ple config set suggest on turns it back on).

Each of them also stops the background refresh that the hook starts.

The plugin's skill already points Claude at your library before it writes a long prompt from scratch. If you only use the MCP server, paste this into your CLAUDE.md:

## Prompt library (PromptLikeEngineer)
- Before writing a long prompt from scratch, call the promptlike MCP tool
  search_prompts to check whether I already saved one.
- Reuse a match with get_prompt, or fill_variables when it has {{variables}}.
  Pass the label "production" when I ask for the live version.
- When I ask you to keep a prompt, save it with save_prompt, or with
  update_prompt when it is a new version of an existing one. Show me the text
  first and never include secrets: use a {{variable}} instead.

1. Save in one session, reuse in the next.

1. Once a prompt works well, run the built-in save-this prompt (type / and pick it from the menu). Claude drafts a title, a description and the text with its {{variables}} marked, shows them to you, and saves it with save_prompt.
2. In your next session, in any project where the server is available, type / and the first letters of its name, or ask for it by name. Claude can find it with search_prompts and read it with get_prompt.
3. When you improve it, ask Claude to save the new text with update_prompt. The old version stays.

2. Pin a version and read it from a job. Labels need ple 0.9 or later, an account, and editor access to set them.

ple log "code review"                 # versions, newest first
ple diff "code review" 2 3            # what changed between v2 and v3
ple tag "code review" 3 production    # point the production label at v3
ple get "code review" --label production | claude -p

Moving the label later never touches the version history, and every move is logged: ple tag "code review" --list shows the labels and the recent moves. ple get prints only the prompt to stdout and claude -p reads its prompt from stdin, so the last line also works in a scheduled job. It uses the session ple login wrote, so run it on a machine where you are signed in. If the plugin is installed, set PLE_SUGGEST=off for the claude process so the hook cannot add a note to a scripted prompt. In a live session, ask Claude for the production version instead: get_prompt and fill_variables take a label. How labels work.

3. Fill variables from the shell. Say the prompt pr review reads:

Review this diff.{{#if strict}} Flag every style nit.{{/if}}

{{diff}}

ple get "pr review" --var strict=1 --var diff="$(git diff)" | claude -p

--var key=value can be repeated. A variable counts as set when its value is not empty, false or 0. A name you do not fill stays as {{name}} in the output, and ple get warns about it on stderr, so the warning never reaches the pipe. More in templates with variables.

4. Export to AGENTS.md or a skill.

# append one prompt to AGENTS.md
ple export "code review" --format agents-md >> AGENTS.md

# or write it as a skill folder
ple export "code review" --format skill --out ~/.claude/skills    # every project
ple export "code review" --format skill --out .claude/skills      # this repository

Both are snapshots of the prompt's current version, not of a label. After you edit the prompt, export it again: add --force to overwrite a skill folder, and replace the old section in AGENTS.md by hand. Exports work signed out too, from your local prompts. A skill lands in <name>/SKILL.md, the folder named after the title, and Claude Code keeps only a skill's description in context until the skill is used. If your project has a CLAUDE.md, add the line @AGENTS.md to it so Claude Code loads the exported file too.

• Your account library. The tools, slash commands and @-mentions read the library in your account. Prompts you only saved on this machine, with ple save while signed out, show up there after ple sync (--dry-run lists what would be uploaded first).
• Same title in two repos. The tools return the candidates with their repo names, and Claude can ask you or retry with project.

More: the MCP docs (Cursor and Codex setup), the CLI reference, and versioning and rollback.